三、计划阶段

　　1.定义结构分工结构图（WBS）

　　启动阶段结束后，项目进入计划阶段，也就正式进入实施。这里概念可能有些不太对头，其实是翻译的缘故，反正大家明白意思就行，不用拘泥于字面。WBS是一组要提交的项目元素，用来组织定义项目的总体范围，具体包括从工作内容，资源，成本角度考虑项目范围；建立一套系统所需要的分层工作结构；把项目分解成易于管理的几个细目，这概念有些模糊，其实跟资源管理器里分目录是一回事情。可以说，WBS是计划阶段的核心。WBS会详细的分到递交件，包括给自己人用的项目使用的过程文件，给客户用的模块和说明文档，完成每个细目的以及如何把这些细目的责任分配到具体的个人。WBS有缩进式和树状式，我这里也没办法画图，大家参考一些项目管理的书籍，里面有详细介绍。我整个文章只挑我觉得需要注意的地方，如非必要，对技术细节或者工具使用不做详细介绍。WBS的细目并不需要分解到同一水平，最下面的细目叫做工作包，分包的依据是个人的责任和可信度，也就是说到每个人头上的任务是否能落实，是否有把握完成；还有就是准备对项目进行控制的程度，程度越深，WBS树也就越深。由于WBS是实用性的东西，根据个人理解也不一样，所以一个项目可能会有几个正确的WBS，看PM的需要和最适合当前团队状态的进行选择。

　　WBS的定义还是很麻烦的。

　　PM要召开团队进行讨论，向成员提供与项目相关的所有详细，并把WBS树分解到二层三层。然后要花上一段时间让成员进行头脑风暴式（BRAINING STORM）思考，制订工作产出和相应人员的职责，记录每一个工作包的完成标准。在头脑风暴式思考时，会有很激烈的争论，PM要协调关系，调节气氛，从自己能考虑到的各个角度旁推侧敲，提示成员的思维角度和方向并加以总结。尽管很麻烦，制订WBS仍然是非常值得的。如同需求分析一样，WBS准备的越充分，编码的进度越快。

　　2.风险管理

　　既然是商业行为，那么项目的风险必然存在，相信阅读这个帖子的朋友不少人都经历过或大或小的风险。有些风险很容易解决，有些风险则大大损害利益。不论什么样的风险，能避免尽量避免，所以有必要对风险进行管理。由于风险的不可预知性，风险管理难度很大，概念也很难讲清楚，只能从一些可行的角度去分析，进行管理。

　　首先要识别风险。这是个难度很高的活。 PM要先召开风险识别会议，这个会议面向公司，高层，跨部门的有经验的人都将参加。然后审核由项目小组生成的风险清单并与重要成员进行风险沟通，检查一些重要的风险源如WBS，成本（时间）预估，人员计划，采购管理等等。最后就要用到PM本身在以前类似项目中得到的经验教训。

　　识别之后要进行分析。我们可以进行粗略的量化分析（精确分析是不可能的事情）。有经验的人可以一起参加讨论，把提交出来的风险进行分类。首先按发生的可能性分，一般分成高，中，低三个级别，虽然很勉强，但是好歹也有个量化了；然后按耗去的成本分，也是高，中，低三级。我们可以把这两种类别的三个级别进行组合，碰到可能性也高，成本也高的风险就定位为不能接受。碰到这种风险只好让客户修改需求或者增加风险预留成本，否则一旦亏起来不是亏一点点，有可能赔的很厉害。高和中，中和中的搭配都是属于高风险，中和低，低和低搭配属于低，高和低搭配属于中。

　　针对出现的可能性，需要采取一些手段降低风险。到目前为止也没有一个定论说有绝对好的方式，只能尽其所能的避免。有几种方法可以考虑，第一种是将风险纳入项目管理计划并指定负责人，由外部人员定期检查项目风险，一旦风险发生，执行风险管理计划；第二种是保险，这种属于风险转嫁；第三种方式有点奸，不过最保险，就是把客户拖下水，让他们一起参与风险管理，呵呵，到时候就好说话了：） 风险管理作为项目计划之后，PM需要更新WBS，修改日程计划和更新风险管理计划。 风险预留通常是成本的8%。

　　3.预估

　　预估是从量化的角度对项目进行评估，主要包括工作量，任务期限，人力，设备，材料，成本等，要注意预估不是财务策略或报价。预估其实并不是一次性工作，在整个项目过程中，预估始终需要。预估似乎没什么特别需要提的地方，每个PM接到项目的时候自然会有预估，在项目发生变更或进入下一阶段时也会预估。预估的作用主要还是让PM作到心中有个底，安排计划时不至于毫无头绪。

　　4.进度计划

　　进度计划就是一个模块或功能要写多长时间，PM安排个日期，设立里程碑，叫程序员们不能偷懒。进度计划是从WBS提取过来的。对PM来说，合理的安排进度计划对项目控制和激励团队士气有着很大的作用。对程序员来说，进度计划毫无疑问是噩梦。显示进度计划一般有先后顺序图，甘特图和里程碑图表。上回邵卫老师讲课，推荐的工具是m$的PROJECT，这个工具我还不会用，因为没时间去摸索。我的头倒是用的很溜了，近一个月来他就用这个PROJECT画了一个又一个的里程碑图，不停的折磨我和同事的神经。我们一般都是一边开发一边做UNIT TEST，效果上来看，因为有强大的时间压力，效率上比之前确实要提高不少，可是我们也只能结结巴巴的赶完进度。由于TEAM里人少，我们都是一个人做几个人的活。我每天早晨六点多出门，经过将近两小时颠簸，八点多点已经坐在位子上，中午吃15分钟的饭，干到晚上八点下班，到家吃完饭往往已经11点了。一个多月我从来没吃过早饭，没有睡过六个小时以上的懒觉。虽然强大的压力使我们能在短时间内掌握尽可能多的技能，开发更多的模块，但是对我们的情绪也是有很大的影响。所以说，项目里程碑是一把双刃剑，合理安排才能既促进效率也不至于打击士气。团队成员士气的逐级衰落会给项目后期的开发带来难以估计的影响，进度将会大大延缓。关于PM和团队的问题我们后面会讲到，这里我先祥林嫂一把，然后跳过。里程碑图表的特征是任务，成员和时间，任务和成员用文字标志，时间用数字描述并辅助以图线跨度，象阶梯一样非常形象，一目了然。管理起来非常方便，完了的打个钩就可以了。