做好PM的几个关键事项.docVIP

做好PM的几个关键事项 在项目过程中，通过观察，感觉做好PM这个角色需要做好以下几点： 对项目关键点的细节要足够了解 虽然PM可以不参与具体的编码工作，但并不等于不需要了解具体的实现细节，特别是一些影响项目成败的关键点。有些PM离技术越来越远，远到一些功能是怎么实现的、用的是什么技术、有哪些地方需要特别注意都不清楚，这会非常影响他的决策力和判断力，特别是在处理突发事件时会手足无措。在现阶段，特别是项目规模不大的情况下，感觉PM兼任架构师比较好。 对项目各个阶段的时间点要足够清晰 PM头脑得时刻有一个清晰的项目roadmap，并对每个时间点做好准备，比如在项目立项前，预估好工作量和资源分配，与其他团队协调好时间点和容错方案；在需求评审前得组织项目骨干了解需求并做好架构设计，与PD深入探讨，避免业务上走不通；在设计评审前，得评估出所有风险点和合作方，并完成设计文档，与合作方充分探讨合作细节，并达成一致；在提交测试前，关注各个任务的进度，特别是有风险的，并为测试准备好环境；在开发联调前，与各个参与方的接口人联系好，并准备好环境；在发布前，做好发布计划，预估出发布风险点。总之，需要对各个关键时间点有清晰的认识，提前做好准备，控制好风险。 处理好与其他团队的关系 一个项目的成功不是只靠自己这个团队就能做到的，需要所有团队的通力合作，因此，非常有必要学会与其他团队处理好关系，而与其他团队沟通的接口人主要就是PM，PM对于团队之间的合作是否顺畅起着决定性的作用。首先需要弄清楚什么是原则性问题，什么是可以退让的，在有分歧的时候，要立即判断出是否可以出做让步。再则，一定得把问题想在前面，提前沟通，只要大家都是为了把项目做好，并在出现分歧前，就把这些可能的分歧点讨论清楚了，就没什么很难处理的关系。最后，学会与任何类型的人打交道，林子大了什么鸟都有，沟通不是为了争个输赢，而是达成一致，这方面的技巧就多了，需要学习和积累。 调动组员的积极性，尽量把事情让他人去做好 在以前待过的一个项目里，PM非常敬业，很多事情都是自己去做，结果出现一个很不好的现象，每天晚上，他的项目成员都走光了的时候，就留下他一个孤独的身影，奋力拼搏，结果每次发布的时候问题多多，惊险不断。这说明一个问题，你不是一个人在战队，并且你不应该冲在第一线，PM的成就感不应该是你自己把事情给搞定了，而是在你的策动下，你的组员把事情搞定了，只有这样项目团队才有战斗力，并且其他成员都希望在项目过程中体现价值，你需要学会锻炼和培养其他组员，发挥他们的最大潜力，这也是为什么在发挥同样出色的情况下，纳什比科比更容易获得MVP的原因了。 处理好风险点PM可以把不影响项目成败的点扔给你信任的人，但对于那些会导致失败的风险点必须给予足够的重视。我以前带过一个小项目，其他什么都完成很好，事情做得很漂亮，bug也没测出几个，但没有review其中几个比较容易出错的SQL，但QA告诉我没bug的时候我也没去多看两眼，结果它隐含了一个比较深层次的bug，在线上暴露了出来，造成了不小的损失和不良影响。其实，后来总结的时候，发现这个SQL存在明显的疏漏，如果当时认真地review，并审视测试case，是应该能发现问题的。PM必须对各个风险点心里有本帐，项目可以做得不漂亮，但如果在风险点上有任何疏忽，那就是失败。 安排好任务，并清晰了解任务的进度 PM需要对自己团队的组员深入的了解，了解他们的能力和兴趣点，把任务交给最合适的人，并保持与他们的深入沟通，了解他们面临的困难，你虽不是直接去完成任务的人，但一定是帮助别人完成任务的人。任务墙是个不错的方式，能让自己和他人清晰看到各个任务的完成情况，便与跟进 保持清晰的思路，储备应对各种突发事件的措施 项目里最需要保持思路清晰的人是PM，别人可以乱，但PM一定不能乱，特别是在有突发事情发生时。因此，PM有必要有意识地锻炼自己抗压能力，比如多做项目发布、设计评审和数据订正的工作，并且要有意识地储备一些应急方案，比如代码回滚，紧急发布等等。另外，要清晰地弄清楚团队之间和系统之间的依赖关系，往往这种依赖性是引发事件的根源。 保持平和的心态，多站在他人立场考虑问题 项目会进行地风风火火，项目成员之间也会争论得很激烈，往往这种时候，保持一个平和的心态很重要。不平和的心态往往会导致不平和情绪，不平和的情绪就会导致更加混乱的局面。保持平和心态的办法很多，很重要的一条是多站在他人立场考虑问题，一旦为他人体谅后，激烈的情绪会消退不少，并且在这种沟通态度的促发下，分歧方也会不由自主地为你考虑，非常有利于解决问题，达成一致。 加强项目自动化方面的能力 项目各个细节如果全都靠人肉去完成，会极大增加控制风险，而减少风险的最大利器就是用成熟的自动化方