三.计划阶段  

    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和团队的问题我们后面会讲到，这里我先祥林嫂一把，然后跳过。里程碑图表的特征是任务，成员和时间，任务和成员用文字标志，时间用数字描述并辅助以图线跨度，象阶梯一样非常形象，一目了然。管理起来非常方便，完了的打个钩就可以了。

    网络逻辑图是表示任务和逻辑关系的示意图，可以用先后次序表示，也可以用关键路径表示。其实把各个活动划分为1，2， 3，4等阶段，每个阶段包括小活动1.1，1.2，2.1，2.2，2.3，2.4，3.1，3.2，3.3，4.1，4.2等，日程计划也分四种，一般只提到从前向后和从后向前两种。从前向后的概念就是某项活动必须相同或晚于直接指向这项活动的的所有活动的最早结束时间的最晚时间。有些绕口，我们打个比方：2阶段指向3阶段，那么2阶段里的4个子阶段也都指向3。假设2.1结束时间为1月12日，2.2结束时间为1月22日，2.3结束时间为1月15 日，2.4结束时间为1月20日，那么，2阶段中最晚的结束时间是2.2的1月22日，所以在3阶段中的3个子阶段3.1，3.2，3.3的最早开始时间都不能早于1月22日。至于从后向前的例子大家自己去推吧，我就不举了，刚才几个123打的我累死了：）项目经常需要调整进度。在不改变项目范围的情况下，调整进度有几种方法：利用快速跟踪手段来改变任务间的关系；将串行的任务改成并行；改变工作方法（可能改变WBS）；改变日期限制，使关键路径上的任务开始或结束的更早。

    虽然方法多样化，在我看来只有一条，就是拼命的压榨程序员的劳动力。如何压榨，还是个技巧。如前面所分析的，需求分析恨不得多分点时间给它，压需求是不太可能；测试阶段后期接近完工，罗里巴唆的事情一大堆，忙都忙不完，那时候PM一门心思提前/按时完工，好收钱，压那段时间似乎也不太可能。说来残酷，最能压的还是CODING，编码阶段往往是压缩重点，总之大家埋头苦干就是了，大项目压缩的时候程序员吃喝拉撒都在公司是很正常的事情，相信不少人都有很深的体会，这里伤心事情也就不提了。只是我总结一下，让未来的PM们有压榨后来人的依据，呵呵。测试前期也可以适当的压一压，那时候人刚完工，都比较懒散。国内一般企业规模都不大，没有专门的质量控制部门，所以质量保证和测试往往就是程序员或PM本身。其实质量保证和测试人员的人数和素质都应该要高于程序员。在日本和CMM实施的公司里，编码压缩是很容易实现的事情，因为那些程序员真的是技能熟练的装配工人，压起来方便的很。他们这样培养人的目的或许就是为了压缩吧？！