PM听过一个关于PM（ProjectManager，项目经理）的经典讽刺：PM是个混蛋，指望9个女人1个月生1个孩子。做程序员的时候，听到很多前辈跟我抱怨：PM就是一群什么都不懂还喜欢指指点点的家伙。虽然很多时候，动手的人确实比幕后的人更有发言权，不否认在很多团队中都有这样的PM；但悲剧往往是动手的人以为自己可以创造一个新的世界。客户和PM想要的是一堵可以挡风的墙。不看重PM却被鄙视的团队可能会有这样的想法，团队不需要PM来管理，项目照样可以按时交付。这种团队理念其实是矛盾的：团队成员多的时候，基本上很难有高度的自主性；团队成员少的时候，大多数情况下，PM都是leader兼职，想不被重视都难。如果期望团队成员的高度自治来实现项目的成功交付，不如让团队清楚地了解项目随时可能失败。所以，大部分人都会有一个疑问：PM除了提醒进度还能做什么？PM除了提醒进度还能做什么？PM每天做的最多的事情就是：张三，昨天的界面怎么样？李斯，功能联调完成了吗？王舞，我们什么时候能出高保真……PM不断的识别项目风险，然后跟进风险问题。技术实施困难是项目风险；开发资源不足或资源项目分配不协调也是项目风险等，这些风险可能会影响项目无法如期交付。尤其是在项目立项初期，PM工作更难开展：除了识别项目风险外，还需要快速了解项目背景（包括业务关系、人员关系、资源分布等）。)，并快速合理地为项目分配资源，完成项目信息同步并获得团队成员（包括认为自己不需要管理的成员）的认可和支持。然后，PM需要一遍又一遍地确认项目的风险和进度是否在合理的计划之内。除了实现项目，团队成员还应该做什么？站在一个开发程序员的角度，我经常不喜欢PM询问自己的进度，认为这是对自己开发能力的一种怀疑和监控。在这里，我可以很负责任的告诉你：PM绝对不是监视你的。由于项目进度更新机制的需要，如果开发不能准确主动地更新自己的工作进度，那么被PM轮询开发进度可能是最有效的反馈项目进度的方式。举个最直观的场景例子：在敏捷项目管理过程中，每天早上10分钟的站会，需要汇报工作进度。如果卡片上的任务接受条件与记者心中的细节相符，则可以快速获取完成时间节点；对于不能及时受理的任务，记者的反馈有两个方向：乐观估计受理时间节点；或跳入技术难点的深坑。在任何一个方向上，未接受的任务都会在下一次投票时再次提出。PM除了每天/每周轮询项目的进展，还需要根据轮询的结果产生不同的数据报表。在完成汇报的过程中，可能更新了一个重要任务的进度，所以团队成员会因为一个重要且紧急的问题被PM多次询问。PM的项目管理必备技能PM不被重视苦是其次，最考验PM的其实是如何看待项目过程中的主要矛盾，避免项目中可能出现的陷阱，我们用这个技能来协调所有的项目资源叫wrangling.比如在给客户演示产品功能时，有客户问：后期会不会丰富数据报表的展示效果？在这种情况下，PM如何回答？客户没有明确要求额外的需求，也没有提出任何需求变更，PM往往需要权衡提出这个问题的人的角色？如果是需求增加，可能的风险点在哪里？如果是需求变更，是否会影响当前项目的结束？还有其他人对这个问题会有什么反应？一个成熟的PM会考虑一系列因素并得出一个合适的答案，因为项目团队中没有人比PM更适合花时间与客户讨论需求范围。综上所述，每一份工作/或每一个角色，都是与生俱来的优越感。比如sales会看不起只会无聊开发的技术人员，技术leader不能看不起只会指手画脚的PM，即使在技术开发的世界里从编程语言，编辑器，平台，到是否写{在if的同一行或下一行，不同阵营的人都有鄙视链。主要原因是对其他角色的工作不够了解，甚至误认为别人的工作低于自己。以上这种坐天论地的想法，很容易演变成一种不合理的看法，不利于整个项目组的协作。换个角度想，就好比你不会弹钢琴，就不应该被一个会弹钢琴的人看不起。我们应该首先尝试了解每个角色的工作。至于每个角色是好是坏，那就是后话了。建议在项目组中，PM如何更好的与项目组配合，并提出以下建议：1.PM进展的根本原因在于进展不明确：如果每项任务都有明确的领导者和有效的进度更新机制，PM会减少提醒的频率。例如：小团队汇报机制站会前花3分钟整理一下昨天做的工作。根据验收情况，进行合理的任务分工（明确任务里程碑）合理使用工具，帮助自己理清进度（粗略估算即可）2项目组梳理负责意识非常重要对于项目交付：每个团队成员负责明确告诉PM哪些需求不能按时交付，PM根据实际情况重新规划并与需求方确认。3、团队内部的沟通计划一定要明确：项目永远不会按计划进行。粗略的计划制定出来后，PM的职责更多的是动态调整。虽然制定沟通计划可能会在短期内影响开发速度，但从项目整体来看，可以减少很多不必要的资源浪费。【本文为栏目组织《奇安科技》原创文章，转载请微信公众号(bigsec)联系原作者】点此查看更多本作者好文
