该帖子同步发自：(riverstone的博客  访问该博客)

　　自2007年参加工作以来，参与的项目也有好几个了，但都是以项目成员的角色参与，从来没有以项目经理的角色参与项目。中国有句古话叫“旁观者清”，同一个问题站的角度不同，可能会形成不同的结论。下面我就以一个普通项目成员的角度谈一下对项目管理的几个看法，希望大家给予指正。

　　1. 团队成员选择 人员选择要谨慎，要尽量选择合适的人员，在选择团队成员时要重点考虑其团队合作能力、编码可读性、能力和项目的匹配度等因素。

　　2. 项目远景的确定 项目初期项目经理需要和高层以及客户协商，定下项目的远景目标(即项目的目的，要实现的整体功能等)，远景目标不用太长太细，但一定要有，好的远景目标犹如大海中的灯塔一样，可以让项目组不会在项目过程中迷失方向。

　　3. 项目计划 项目计划是项目最重要的文档之一，需要由项目经理根据实际情况进行制定，需要注意的是项目计划不是一次确定永远不变的，项目计划是一个从粗到细、从大到小的逐步过程，需要在项目的整个周期不断细化，调整。

　　4. 需求阶段 按照公司的方向需求由专门负责需求的人员来收集，需求人员将需求定义好形成文档后，再由项目组人员进行设计。身为项目经理一定要尽早参与这一过程，介入越早越好，需求收集过程可以以需求人员为主，项目经理为辅的模式进行，由需求人员负责收集需求并以需求用例的方式编写文档，由项目经理审阅并组织需求评审，只有需求评审通过后，需求收集过程才能阶段性结束。

　　5. 项目框架选型和搭建 需求确定后，如果客户没有明确要求，项目经理需要为项目确定框架和采用的技术。有时这一过程可以由项目经理和项目组中的技术骨干一起来完成。

　　6. 设计阶段 由项目经理和技术骨干一起完成项目的总体设计并经过设计评审，然后各个分模块的设计可以分给具体的成员来设计、由项目经理和技术骨干审核;也可以不分统一由项目经理和技术骨干完成，但设计文档一定要由惟一的一个人来完成(项目经理通常是最佳人选)，一则可以保持文档编写风格的一致性，二则可以保证项目组有人可以通晓整个项目的详细设计，从整体上把关，三则可以节省项目成员的时间，让其将精力放在实现上。

　　7. 实现阶段 进入实现阶段后，项目经理需要控制的方面主要有代码质量控制、进度控制控制等，代码质量可以通过代码抽查、复查、制定代码签入规则等手段控制，进度可以通过检查进度表来控制，需要注意的是项目经理要随时准备好帮助项目成员解决遇到的难题，包括技术和非技术方面的。

　　8. 测试阶段 需求文档确定后，就需要和测试组进行协商，由测试组准备测试用例并提交大概需要的测试时间。随后的各个评审(如设计审核)要保证测试组必须有人参与，因为测试人员和QA人员更能发现评审问题。

　　9. 实施 进入实施阶段后，项目遇到的问题会比较多，其中很多并不是技术方面的，而是客户管理制度方面的、客户现场环境方面的。由于经过长期的开发阶段项目成员都比较疲惫并且在实施阶段出现的问题比较多，所以项目成员在士气和心情方面容易不稳定，这时就需要项目经理来掌控，要稳定项目成员的心情、提升士气，并多和客户沟通解决发现的问题。

　　10. 技术测试 如果项目是以前没有做过的类型，则需要通过技术测试来验证选定的技术是否具有可行性，技术测试需要注意的问题有技术测试一定要模拟最终用户的实际环境，不能在开发环境中进行测试。

　　11. 签入控制和进度控制 项目经理一定要保证每天有合适的时间段用来检查项目成员签入的代码的质量(包括功能正确性和规范性等)和任务的完成情况，发现问题要及时解决。

　　12. 任务分配 任务分配宜小不宜大，一般来说分配周期可以以一周为一个周期，在给成员分配任务时需要得到成员肯定，不能硬性的分配任务。可以参考XP的任务分配法。

　　13. 定位问题 项目经理首先要明白自己所处的位置，明白自己是一个枢纽，要起到润滑油的作用，处理好项目各关联方的关系。项目经理不一定是项目组中技术能力和管理能力最强的人，但一定要是项目组中最会处理人际关系的人，所有的管理问题归根结底都是人的问题，把人的关系处理好了，项目管理就成功了一大半，“会做的人让他做，不会做的人教他做，不愿做的人催他做”。

　　14. 项目规范的制定 身为项目经理就是项目的总负责人，有些项目的基础规范需要项目经理来制定，比如项目代码规范(可以在公司代码规范基础上进行修改)、项目沟通机制(项目例会多少时间召开一次?以什么样的形式召开?项目进行过程中如果遇到了问题怎么反馈?)等。

　　15. 权利的应用 身为项目经理，在项目中所拥有的权利肯定比其它团队成员要多，行使权利的机会也较多，但项目经理一定要合理的使用自己的权利，权利行使不当容易伤害团队的氛围，影响团队的战斗力。在行使权利时有两点要注意，

　　1)要多使用影响力，少使用组织赋予型权利，影响力是指自己通过平常的为人处事、通过自己的工作资历和解决问题的能力挣得的，有时可能一个普通的团队成员其影响力会大过项目经理;而组织赋予型权利是公司章程中赋予的，在项目团队中肯定是项目经理的组织赋予型权利最大。多使用影响力少使用组织赋予型权利可以比较柔性的管理项目团队、不会让人感到盛气凌人，不会引起反感，对凝聚团队成员比较有好处。但如果遇到非应用组织赋予型权利不可的时候也不要犹豫，一定要明白组织赋予型权利是解决问题的一种方式，只不过其优先级低于影响力。

　　2)切莫看低自己，有些项目经理以为自己只是干活的，和普通项目成员的惟一区别只是自己要干的活多一些，这是很错误的认识，如果有这样的认识就不能合理的行使自己的权利，就不能起到枢纽的作用。

　　16. 月考评的应用 公司规定项目经理给项目成员进行考评以决定项目成员每个月的绩效工资，这等于是交给了项目经理一把双刃剑，应用的好可以提高团队士气，应用的不好不仅会损害团队士气也会增加项目成本。在月考评时需要注意下面的几点：

　　1) 考评规则提前声明，在项目开始的时候就需要和团队成员一起制定一个考评的简单规则，规则制定时不要一人独断，要多听团队成员的意见。规则制定可以考虑出勤率、代码质量、代码规范、任务完成情况、是否提供了节省团队时间的工具等因素。

　　2) 考评要合理公正。不能依个人喜好打分，也不能全部打高分，要依据考评规则合理的打分。

　　17. 加班情况的处理 加班是不得已为之的行为， 要谨慎使用，如果逼不得已非要加班不可也要做好安排，要先将加班申请通过、要协调加班日期、要确定加班需要完成的任务并检查任务完成的情况。另外关于加班有一个说法是如果项目的某一个里程碑是通过大量加班完成的，那么下一个里程碑肯定会延后，我个人觉得这是很有道理的。

　　18. 出差情况的处理 公司开发人员大部分在济南而项目多是东营的，这就要求项目成员经常出差，这是无法改变的事实，但长时间的出差会影响团队士气和效率、也会增加项目的成本。这就要求项目经理多注意出差对项目的影响，要合理的安排出差的人员和周期，如果某些团队成员出差时间较长了，需要注意长时间的出差是否使其“后院不稳”，若有必要，可以出面帮忙解决。

　　19. 项目组杂事的处理 项目经理是项目的总负责，也是项目的总管。项目经理要为项目团队做好服务工作，不要让日常的琐事来骚扰团队，该为团队成员挡的琐事一定要挡在团队之外。

　　20. 责任的担当 项目经理是项目的总负责，所以一定要对项目负起责来，当项目能够顺利完成时，要明白这是项目团队合作的结果并不是自己独立完成的，要和项目团队分享功劳。当项目不能顺利成功时，要明白自己肯定是最大的责任人。另外要学会为项目成员承担责任，当某个项目成员犯错后，作为项目经理需要学会接受来自外部的批评并适度的保护项目成员。