Plan (3- 制作一份可执行的计划)

 

 抱歉，因为文章原本是给公司同事准备的培训材料（只有些大的提纲），所以都用的英文。等我把一些文档慢慢整理完贴上来以后，我会把一部分的内容翻译成中文的，再加入一些说明。   

  

首先，谈几种常见的制作项目计划的错误情况。

  1. 项目经理自己制作计划，然后发给项目组成员.

     缺点：1. 项目经理估计的任务完成时间并没有考虑人员能力因素。2. 项目计划是项目经理的计划，项目组成员只需要遵守，不需要负责。3. 谁都有考虑不全的时候，项目经理也不例外。

  2. 没有定义各任务的验收标准

      场景：我最长遇到的情况是，项目经理和程序员对于任务的进入前提和退出标准认识不一致。程序员经常认为根据详细设计就可以直接进行开发，而多数项目中仍然需要开发人员进行二次设计。另，有些程序员认为完成编码即算是完成开发任务，但程序经理的看法是，完成编码，完成单元测试编码，完成smoking test，才算任务的真正结束。:-)

      缺点：1. 任务没有真正完成，造成项目延期。 2. 进行整合时发现各模块质量不过关，需要大量的bug修复时间。

  3. 项目团队成员估计的任务完成时间不正确，通常过于乐观

      原因：1. 信息不对称，项目组成员并不知道某些风险的存在。2. 成员经验不足。3. 技术或领域不熟悉。4. 任务完成标准理解不一致。     

  4. 项目计划没有考虑任何风险因素

      原因：在某些时间紧迫的项目，常会出现一种现象，即使项目经理和项目组成员都知道项目存在某些风险，但是他们会自我安慰，采取...(如果.....那么就可以按时完成...)的乐观态度。 这是项目组缺乏风险意识的表现。参见： [原创] Plan (1- 几个真实的关于计划的故事)

      结果：如果项目组没有风险监控和管理意识，项目常会到后期才发现不能按时完工。 

  5. 项目组所有人员都必须100%的Focus在开发和测试中

      注：项目经理通常会花费80%-90%的时间在沟通上。定制计划时，应该为项目经理定义一个管理任务，而不应该将项目经理绑定在具体的项目任务中。

      缺点：没有人有精力去考虑，项目是否仍然在正常的轨迹上，是否有风险开始显现。

   6. 项目组不敢做计划

      情景：曾经遇到过一个项目，项目已经进行了很长时间，项目组仍然不愿做项目计划。项目组认为现在了解的内容还不够完整，怕如果做了计划，可是不能按时完成，则无形中给自己下了套子。

      分析：项目计划执行过程并不是单方面的承诺，应该认为他是一个多方面的博弈。一旦项目组提交了计划，得到高层和客户的同意。那么，大家就都需要遵守这个游戏规则了，首先高层管理人员不能随意将项目组主力人员抽调走，否则，项目组需要更新项目计划，也许会造成项目延期。其次，客户不能在项目周期中，无限制的提出需求，首先需求的数量应该与项目周期一致，否则就需要去除一些需求；再者，需求应该在需求分析阶段结束时，基本定义下来，之后再增加需求就需要走需求变更流程。 所以，项目计划不但是项目进度的一个度量基准，同时也是对项目各方的一个基本约束。

 

下面是培训用的提纲，我会在最后面用中文进行解释。

 

 1.3           Meeting for building plan

In project, we need hold meeting for project plan, as following:

1.  Sub-project plan: Attends: Module leader
2.  Module plan: Attends: team member

 1.4           Step for building plan

 1      Build WBS

 2      Discuss puzzled part to make all task clear.

 3      Identify task's relation, build task list

 4      Identify risk in task

 5      Identify deliverable

 6      Set task's priority

 7      Define milestone

 8      Assign people to task

 9      Let people evaluate time for their selves task

 10  Balance task time by team

Key:

1. Write 3 months plan as a iteration
2. Write weekly plan for small project or iteration.
3. Split trackable task to three days.

 

制作项目计划

1. 根据已有资料，项目经理初步划分项目阶段和模块，并分析项目风险

2. 项举行项目组会议，制定计划

  * 会议前，项目经理需要提前进行项目分解等工作

    2.1 项目经理介绍已有资料。 （项目组成员应该已经得到部分资料，这里只是为了统一一下认识）

    2.2 项目经理给项目组做短暂的如果做项目计划的培训

    2.3 项目经理带领团队制作WBS (项目经理给出WBS的骨架，下面介绍了如何制作WBS)

    2.4 消除有争议的任务项，方法：项目组讨论或与客户沟通。

    2.5 识别任务依赖关系

    2.6 识别各任务的相关风险 （项目组应该在这里共享各成员的信息，尽量达到风险共识； 项目经理带领团队识别各个任务的潜在风险，及可行的风险规避方法）

    2.7 识别任务中的提交物 （识别各阶段或任务的提交物，需要定义提交物的验收标准，如Coding阶段，每个Task的完成标准为完成代码，单元测试，整合和smoking test）

    2.8 定义各任务的优先级别 （模块和任务的优先级别，来自与客户对功能要求的优先级别）

    2.9 定义里程碑

    2.10 为每个任务设定执行人（每个任务的Owner只能是一个人，可以将项目组拆分为多个小组，每个小组一个负责人，任务与小组相关联）

    2.11 Owner对每个任务需要的时间进行预估

    2.12 根据任务时间和以来顺序做出初步计划

    2.12 对项目计划做Balance. 确认任务时间合理（有些任务考虑到新技术等问题，可能会估计时间过长；而某些任务没有考虑到风险，可能会估计的过短），检查人员等没有冲突。

 

建议：

    1. 对于大的项目，建议定义3个月一个周期的迭代。

    2. 用周计划来搭建，每3个月的计划。以周计划为基础，项目便于沟通和跟踪，并且便于安排每周的沟通，review和提交时间。

    3. 在3个月的计划中，每个任务应被拆分为小于3天的任务。便于跟踪和控制风险。

 1.3           How to do WBS

WBS includes:

 1      Project Work

 1.1      Sub-Project

 1.2      Software develop phase: Requirement, Analysis, Design, Implement, Test, Deliver.

 1.3      Module

 2      Management Work

 2.1      Prepare environment

 2.2      CM

 2.3      Weekly review meeting

 2.4      Knowledge share meeting

 2.5      Research on domain

* Save time for tasks which have risk.

 在做任务分解时，需要为存在风险的任务预留时间。一般可以通过添加，research时间，review时间，update or improve时间来藏足够的时间。不建议使用每个任务的预估时间乘以一个百分比的方式来增加项目计划时间。详细说明，请参见： [原创] Plan (6- 问答)

 

 

另，Plan系列文章的列表：

 [原创] Plan (1- 几个真实的关于计划的故事)

 [原创] Plan (2- 项目经理的职责)  http://www.cnblogs.com/joyyuan97/archive/2008/07/27/1252367.html

 [原创] Plan (3- 制作一份可执行的计划)

 [原创] Plan (4- 示例)

 [原创] Plan (5- 跟踪计划)

 [原创] Plan (6- 问答) ：如果为任务藏时间？ 当项目延期后，如果定位计划中的问题？如果更新项目计划？