做一个合格的项目经理

在中国的软件业，项目经理的名词往往都会和技术经理混淆，或者说项目经理≈技术经理，这种想法的我想应该不在少数。在一个项目中，大家过多的看重的是技术，素不知项目经理应该是管理+技术+业务的结合体，他们的比重用8:1:1，或者干脆是8:0:2，项目管理在一个项目经理的角色中占有的比重应该是很重的。

 

传统的软件开发流程，假设一个项目从需求开始，一般会经历需求定义->设计->编码->测试->发布这几个主要的阶段，而每一个阶段都涵盖了启动->计划->执行->监控->收尾的5个过程，其实这也是贯穿整个项目的5个过程。

 

一、计划

做任何事如果事前都有一个详细周密的计划，往往都能达到事半功倍的效果，软件项目管理也应如此。一个好的项目计划直接影响到整个项目的进度和质量。一般，我们可以把计划划分为范围计划、时间计划、资源计划、成本计划、风险计划、质量计划和沟通计划。

 

范围计划是所有计划的基础，也是整个项目管理的核心，一个好的项目计划就意味着一个项目好的开始。要将一个项目的范围定义全面，一般包括以下几点：
1. 总体描述
对项目的整体概括地描述，要求字眼尽量详细清晰，能让阅读者马上领会项目的主要功能要求等。
2. 交付物
最终提交到客户那里的产品及服务，如成型产品，设计说明书，安装操作指南，硬件设备等。
3. 验收标准
一般就功能，性能，安全性，设计风格等方面的标准。
4. 用户方责任
指明用户方需要做到的内容，一般这一点可以忽略，合并到假定条件中去说明。
5. 假定条件
一些项目开始或运行的条件，如硬件设备到位，需求明确等。
6. 约束
对项目的限制约束，如工期限制，人力资源调配等。

范围计划，往往可以形成一个标准的范围说明书。当然，仅仅上面这些应该还是不够的，我们要学会编制WBS(Work Breandown Structure，工作分解结构)，一般用到的软件就是M$ Project了，这是一个比较复杂的过程，也是整个项目管理的核心，如何将工作、时间、资源等分解得合理、细致，是一件费时费力而且反复的工作。制作一份好的WBS直接影响到后面的范围计划、时间计划、资源计划以及成本计划。

 

时间(进度)计划如何写？一般为了全面地去描述一个项目的时间计划，我们可以基于已有的WBS从两方面来描述：项目里程碑和时间进度表。什么叫做项目里程碑？如：
1. Kick-off meeting  1月8日
2. 批准要求
...
6. 通过集成测试  3月10日
7. 完成系统部署  3月15日
8. 通过验收          3月18日

这些个里程碑应该说也是WBS中按时间划分后，几个比较重要的活动结点。至于时间进度表，只要从WBS中摘抄下来就OK了。

 

资源计划为何物？资源计划也就是我们常提到的人力资源分配，一般我们也分为两点来阐述：组织结构及角色/小组责任、人员投入时间安排。注意这里的人员投入时间安排和时间计划中的时间进度表是有区别的，前者是基于活动，而后者是基于资源角色展开的。

 

对于软件项目，成本计划主要是人力资源成本，这是主要的一块，当然，也有开发电脑、开发工具、培训等费用项目，这些都应该用表格列出来。人力资源成本可以用M$ Project工具来生成。

 

至于风险计划，应该属于风险管理的范畴，但是拟在计划草案中便可以提前减少风险的发生。一般风险级别由风险发生的概率和风险影响的程度两个因素来确定。比如说，小王要离职跳槽，其概率估算为80%，而且由于他是项目的骨干人员，离职产生的风险影响程度就相应的很高为90%，如此一来，小王离职的这个事件就是一个高风险的事情了，作为项目经理的你，可以尝试提高小王的工资(项目成本增加)或者换人来处理这个风险。当然还有很多种风险，如政策、法律、市场、上级领导、技术能力等，这些都是应该考虑到的风险，风险必须明确一个责任人。

 

同样，质量计划也是非常重要的，直接会影响到项目的质量管理成败。质量计划首先要定义质量环节以及对应的质量标准，如系统需求报告、软件需求规格说明书、软件测试、软件编码等环节，都要有一个标准。既然有了这些标准，然后我们就要列明一些重要的质量问题，保证质量，针对这些问题提出保证措施和责任人。

 

相对于其他计划，沟通计划就是一些软性的指标了。根据项目的特点约定项目全体干系人(包括组员，客户，公司领导，公司其他部门等所有与项目相关的人员或组织)的沟通模式，可以是例行的各种会议、审查报告、情况通报，也可以是某一预定的工作结点或某一情况一旦发生应即进行的某些沟通活动。常见的沟通计划，就如我们项目中时常接触到的周例会、月报告，季度报告，甚至日报告，这些都可以列为沟通计划的一部分。

由此看来，一个详细周密的项目计划非常的重要，作为一个项目经理，不要怕做计划，认为那是一件耗时吃力的事情，但是只要你按着你定的计划来，不断调整和跟进，严格按照计划来行事，你必定能成功，任何事情都是熟能生巧的过程，只要敢于迈出第一步。

二、执行

项目执行的保障，主要包括质量管理、团队建设和沟通管理。对于质量管理和沟通管理，都隐隐约约在计划部分描述到了，我也不详细的再说什么了。至于团队建设，这应该是所有管理者应该兼顾到的，一个具有凝聚力的开发团队能大大的提高整个项目的绩效水平，比如说远离团队政治、以身作则、绩效评估、轻松的工作氛围、团体腐败等，都是团队建设的常用措施。

三、监控

常见的监控措施如日常工作检查、阶段评审、变更控制、风险管理等。其中变更控制和风险管理对大家来说是相对忽略的地方。

 

变更控制是基于一个完备、详细、准确的项目计划的，针对计划变更采用有效的措施来控制变更，避免失控，总结经验教训，不能一犯再犯。项目中一个环节的变更，可能直接影响到范围、时间、费用，甚至质量，项目变更管理的目的就是协调它们之间的关系，找出一个平衡点。

 

对于风险管理，其实已经在风险计划中已经提到了，不管怎样，提前预知、识别和分析风险是风险管理的最好的方式。在风险实际发生时，要懂得如何规避风险或减轻风险。

 

以上是我最近PMP培训的总结，说句实在话，做了许久的PM工作，从来都没有这么清晰的看清楚项目管理的骨架。欢迎大家与我共享交流软件项目管理的经验。

对于项目经理, 技术应该懂一些, 不必精通.

对于项目经理最主要的是  管理+业务.

8:0:2 这个比例也太夸张了吧.

管理:业务 = 8:2 ，这个比例我想也不夸张。当然，业务肯定也是重点，但是，业务这东西应该是团队的共同点，也是组员和项目经理的交集部分，所以我不想将业务在项目经理工作中赋予过高的比例。

或许大家能在这中间找一个比较平衡的比例，但是无论如何，管理和监督整个项目的执行是重点。

目前是项目经理，管理：技术：业务= 5:1:4
每个项目不同，项目经理的责、权、利也不同。
比例应该有所不同吧。
有的项目技术性较强，技术的比例应该会高一些。