PM及项目管理

原文地址：http://blog.csdn.net/cutesource/article/details/5448351

原文地址：http://blog.csdn.net/cutesource/article/details/5685537

在项目过程中，通过观察，感觉做好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有必要有意识地锻炼自己抗压能力，比如多做项目发布、设计评审和数据订正的工作，并且要有意识地储备一些应急方案，比如代码回滚，紧急发布等等。另外，要清晰地弄清楚团队之间和系统之间的依赖关系，往往这种依赖性是引发事件的根源。
保持平和的心态，多站在他人立场考虑问题

项目会进行地风风火火，项目成员之间也会争论得很激烈，往往这种时候，保持一个平和的心态很重要。不平和的心态往往会导致不平和情绪，不平和的情绪就会导致更加混乱的局面。保持平和心态的办法很多，很重要的一条是多站在他人立场考虑问题，一旦为他人体谅后，激烈的情绪会消退不少，并且在这种沟通态度的促发下，分歧方也会不由自主地为你考虑，非常有利于解决问题，达成一致。
加强项目自动化方面的能力

项目各个细节如果全都靠人肉去完成，会极大增加控制风险，而减少风险的最大利器就是用成熟的自动化方案去完成一些工作，特别是项目构建、持续集成和发布等工作。PM应该在怎样让日常工作流程化和工具化方面多动一点脑筋，而这方面敏捷开发提供很多很好的思路和方案。
共识和决议要通过邮件发给相关人

在项目过程中会产生很多变故，需求和设计文档里定义不了所以问题，为解决变故而形成的临时决议一定要通过邮件发给相关人，不光是知会，更重要的是为决议提供证据，这些临时的决议往往会引发问题，当问题产生追溯责任时需要用到这些证据
注意倾听组员的意见，给他们留出足够的发挥空间

特别是在大公司带项目，组员都算是开发的精英，都不是甘于做个机械的coder，因此学会倾听他们的想法，深入了解他们想得到的，尽量满足他们成长需求，就算是由于项目客观原因，没法采纳他们的建议，也得和他们把道理说清楚，不合适用强势方式来决断，毕竟技术人员的需求和管理不同一般
不以个人意愿为基准，凡是以大局为重

PM也是人，在平时工作过程中，难免会带有个人情绪，但PM应该清醒地认识到自己身后还有一个团队，大家的情绪和状态与自己息息相关，所以说话做事一定要三思而行，考虑清楚对别人的影响，切勿乱放炮，失去同仁的信任

如何在一般情况下进行工作量的评估？

类比估算法：根据类似的项目工作量进行预估，再对估计值根据具体情况进行调整。
参数估算法：我们公司可能缺乏这方面的数据支持，比如通过估计某个项目可能会有的代码行数，配备的成员技能，来进行估计。举个例子，某个项目的代码行估计可能会有10000行，一个一般技能的开发工程师一天可以完成的代码行为500行，那么开发需要的时间可能就是20人日。

三点估算法：目的是为了尽量降低估算的不确定性。估算时对一个功能点分别估算最悲观的估算值、最乐观的估算值、最可能的估算值，最后确定的估算值=(最悲观的估算值+最乐观的估算值+4*最可能的估算值)/6。
Delphi法：由一组专家对项目进行估算。

具体的步骤为：

1，组织者发给每位专家一份软件系统的规格说明合一张记录估算值的表格，请专家估算。

2，专家详细研究软件规格后，对该软件提出最乐观的估算值、最可能的估算值和最悲观的估算值。

3，组织者对专家表格中的答复进行整理，计算每位专家的平均值E=（最悲观的估算值+最乐观的估算值+4*最可能的估算值）/6，然后计算出期望值：E=(E1+E2+....+EN)

4，综合结束后，再组织专家无记名填表格，比较估算偏差，并查找原因。

5，上述过程重复多次，最终可以获得一个多数专家共识的软件规模。

团队估算法：类似与Delphi法，但是形式比较松散，参与评估的团队成员包括项目组的各个角色，大家一起对某一个功能点提出自己的估计值，如果比较接近则计算一个平均值作为估算值；如果差别比较大，则由每个人发表意见说明自己的评估理由，然后进行第二轮评估，直到评估值比较接近。
计划扑克：Delphi法的一种演变。敏捷扑克的每种花色均是一组13张牌组成的估算扑克牌，牌正面上印刷有供估算用的数字与符号，数字分别是1/2，1~10和20，符号为“！”，代表一些未知情况，如无法提供准确估算值等。一般我们推荐4到8人参与估算；人数太少，会使估算结果偏差很大，人数太多，会拉长估算时间，降低估算效率。估算时，我们经常会估算相对值，而不是绝对值。注意不要深入研究代码编写细节，这些是实际开发是再去解决的问题。一般情况下，最多3轮就可以得出一个比较统一的意见。如果3轮之后依然没有得到一个统一的意见，比如第四轮出牌结果依然是2，5，5，8；那么Scrum
Muster应当立即中断该条目的估算，取平均值或其他大家比较能接受的值作为估算结果。没有任何一种估算是高可靠度的，扑克也不例外，扑克估算的目的就是为了能够在一个尽可能短的时间内，让团队成员更加多的了解需要做的工作，同时顺带得到一个可接受的估算结果。
其实每一种估算方法都仅仅是估算，估算的结果就可能是不准确的，所以首先不要有概念估算的结果和实际的结果一定是一致的。估算时项目经理要根据具体情况灵活运用各种估算方法，综合各种方法所长，让估算结果尽量接近实际值。

如何在需求不明确情况下进行工作量的评估？

给量级的评估，由于需求不明确，所以估计不可能准确，误差很可能比较大。
储备：储备要留足，需求越不明确储备越要多。
先总后分：需求不明确也要有一个限度，项目的整体范围，整体框架还是要确定了才能接手项目的。
接受计划改变的必然性，既然需求不明确，那么计划的改变可能性是非常大的，需要提前和相关各位沟通到位。 
如何在跨部门情况下进行工作量的评估？

各个部门负责给出自己部分的工作量评估。
有专门的接口人负责协调资源，给出评估结果。
信任，很多时候我们并不了解对方的工作和流程，所以信任很重要。
信任的同时，尽可能多的了解对方的工作内容，积累经验，对未来的判断做准备。 
如何进行进度计划的安排？

理论基础：PDM(单代号网络图)，关键路径法和关键链法，时间提前量和滞后量。

具体步骤：

首先细分项目的每个功能点，针对功能点制定出我们需要进行的工作。
整理每项工作之间的逻辑关系，形成一个网络图。
评估每项工作的工作量。
安排每项工作对应的负责人。
根据具体负责人以及工作量调整网络图。
安排储备工作时间。
排出具体的进度计划
需求变更如何处理？

事前：

丑话当先，变更流程还是要有的。

变更流程可以分需求变更的规模，按大、中、小来区别对待，制定不同的流程。

事中：

执行过程中可能需要灵活应对了，对于需求的优先级和紧迫性需要有一个把握 。不是不能变，但对流程还是要坚持的，否则乱了只能是自己。
如果发布时间不能改变，需求又是一定要完成的，那我们就只能从其他方面来想办法了。这个可以参考六边形。

事后：

对人对事进行总结，未来对于类似的事情，相同的人，我们就需要更多的考虑需求变更的风险了。
对于前期需求不明确的项目如何控制需求范围？

前期需求的细节可以不清晰，但是整个项目的大范围需要确定。
项目的整体设计最好不要迭代，或者说不要做迭代的打算，一开始就对整体设计做一个统一的规划。
整体设计完成后，再对每个部分的功能分别来看。划分每个部分的系分功能点，各个功能点之间的优先级，是否需求已经明确，与其他功能点之间是否有关联等。
对已经比较清晰的功能点，并且与其他功能点之间的关联不是非常紧密的，先进行开发、测试。同时细化未清晰的功能点。
对于需求变更的控制重点把控。
这需要看项目经理的全局观，是否能对项目的整体设计，功能点间的关联关系有一个比较到位的把握。