项目计划的目的包含两个主要方面，对内是为项目的研发和管理工作制定合理的行动纲领，以便所有相关人员按照该计划有条不紊地开展工作；对外是为客户提供项目的统一视图，确保所有干系人能够根据计划进行工作配合、进度同步并最终提高客户对项目实施进度的满意度和认可度。本文主要阐述在项目计划过程中涉及的主要规程、可能存在的问题、分析并提出相应的改进措施。
一．项目计划的规程
项目计划过程涉及面很广，按照集成项目管理理念，项目计划除了项目实施计划之外还需要集成各种子计划，如《配置管理计划》、《质量保证计划》等，但本文崇尚轻量级过程改进，对这些子计划不做展开，文中的项目计划即为传统的项目时间和范围的组合体。同时，软件行业项目的成本因素也相对弱化，本文中一般也不把成本作为项目计划的一个约束条件。
个人认为项目计划管理的最核心原则是“信息不对称”，即在客户和研发团队之间形成信息传递的过滤和筛选，确保两者之间的信息不对称从而为项目经理把握项目进程提供缓冲并降低风险。如何进行信息的不对称管理，方法就是把项目计划拆分成两个维度，本文使用面向客户的项目实施计划和面向研发的项目研发计划来表示这两个维度。项目计划与信息传递的示意图如下：
根据上述思路，项目计划通常包括的规程有：
1. 制定项目实施计划
- 目的：项目实施计划面向客户，为项目启动、实施跟踪提供进度基础，并为销售、市场和运营团队提供统一项目视图。项目实施计划是项目启动会的主要输入，关于项目启动会请参考《轻量级过程改进之项目启动》
- 主要角色：项目经理主导项目实施计划制定
- 主要步骤：项目经理主要通过与销售、研发团队负责人的沟通和协调确定项目实施计划，包括项目实施的生命周期划分、里程碑时间、第三方供应商集成等，项目实施计划的依据是项目估计。项目估计的主要工具是粗粒度WBS和类比估算，即根据本项目的功能范围通过客户类别分析和以往项目实施经验来得出估算。项目经理根据项目估计制作《项目实施计划》并提交项目管理团队，通过评审之后发布给客户和相关干系人
2. 制定项目研发计划
- 目的：项目研发计划面向研发团队，为项目的开发、测试、部署、发布等提供时间依据，并为整个研发团队提供统一项目视图
- 主要角色：研发团队负责项目研发计划的制定，项目经理根据项目实施计划推动项目研发计划的形成和完善，注意研发人员眼中的实施计划和项目经理对外的实施计划应该是不对称的
- 主要步骤：项目研发团队根据项目实施计划中的研发阶段进行细化分解，按照研发团队中的研发过程模型（如瀑布、敏捷等）进行时间和人力资源细分。通常按照功能模块和功能点进行研发任务组织，结合系统开发、集成、测试等步骤进行进度安排并形成《项目研发计划》。项目研发计划的一个重点是系统集成，需要对第三方供应商的研发任务安排有细粒度的计划确保项目实施的顺利执行
3. 评审项目计划
- 目的：项目计划的评审是为了获取项目对内对外干系人的承诺。由于我们使用两个维度的项目计划管理，所以计划评审也同样采用两种评审模式
- 主要角色：项目相关关系人一起评审项目计划，项目经理负责项目计划达成一致
- 主要步骤：对于对外的项目实施计划，计划评审更多是一种计划确认，虽然对项目实施计划中的前置和约束条件进行粗粒度的确认就能启动项目，但面向客户的计划给出去之后是不能随便改的，所以评审项目实施计划应该是计划评审工作的重点；对于对内的项目研发计划，在项目线和研发线达成一致是评审的主要工作，通常对内的计划管理可以比对外的实施计划更加灵活的把握
二．项目计划中的问题
项目计划与研发团队关系密切，一份合理的项目计划无论对内对外都能起到指导作用。但项目计划也是项目管理中最难以把握的环节之一，项目计划过程中可能存在的问题包括：
1. 项目计划缺乏两维度分离理念
个人认为这是项目计划管理中最大的一个问题，表现为信息过于透明，信息在项目线和研发线之间缺乏过滤机制。作为项目计划制定者的一般策略是：对外我给出去的开发时间是2个月，对内我让研发团队在1个半月之内完成计划，那我就有半个月的时间缓存，也就是为自己留了一条退路。项目计划管理就是每走一步都能为自己留下一定的退路，这些退路最终会变成一条活路。如果不区分项目实施和项目研发两个维度，信息直接从项目线传递到研发线，就等于在项目经理和研发人员的眼中，开发时间就是2个月，那如果一不小心出现一些突发情况，项目经理就变得没有任何退路。
2. 项目实施计划和研发计划混淆
项目实施计划和研发计划混淆也是一个常见问题，表现为实施计划包含过多研发细节，或研发计划包含实施性内容。实际上这两份计划面向的受众完全不同，是两个独立的计划过程，需要使用不同的过程模型和计划方式。项目实施计划基于项目全生命周期进行梳理，而项目研发计划通常只包含项目实施计划中面向研发团队的部分，使用研发管理的过程模型进行梳理。
3. 项目实施计划制定缺乏客观评估和评审
项目实施计划面向客户，面向客户的东西都是重要的，都是需要过程把控的。但现实中往往是面向客户的东西项目经理或管理层不通过团队协作就很武断的作出决定，这是不对的。项目实施计划的执行需要有相对客观的评估依据和评审流程，因为通过评估和评审，大家就会对计划中的风险和技术陷阱进行提前预判，确保项目实施计划的完整性和合理性。项目实施计划是研发的依据和基础，我们有合理的项目实施计划通常就能得到合理的研发计划。
4. 项目实施计划未基于项目实施全生命周期
项目实施计划可能每个项目管理团队会形成各自的风格，但过程模型都是基于项目实施的全生命周期。全生命周期包括项目的正式启动到正式验收结项的所有环节，这些环节需要根据项目和服务本身的特点进行分析抽象，如服务部署、系统试运行等在互联网应用和企业级应用中可能存在较大差距。
5. 项目计划粒度把握不合理
项目实施计划和项目研发计划中的时间粒度上应该是不同的，两者应该保持时间上一个数量级别的差距，项目计划粒度会对后续的项目监控有较大影响。
6. 项目计划中缺乏对第三方供应商的管控
项目计划只考虑项目和研发团队自身，而忽略项目实施第三方供应商的参与无疑是致命的。对于系统集成性项目而言，内部研发团队的进度把控往往不会是大问题，但供应商的时间我们很难控制，所以在项目实施计划中明确把他们的时间也加入进来，确保客户、供应商和我们能对系统实施过程中的系统集成环节达成高度一致是项目计划管理的一个难点。项目计划中没有考虑供应商的时间安排，导致研发团队的开发节奏被供应商的不合理计划所打断的情况并不少见。
三．项目计划的过程改进
项目计划可以说是一个不断变化的过程，因为项目的不同特点很难做到统一的模式，也很难做到计划就等于现实。但我们要有计划管理的方法论，从问题的分析和梳理入手，对项目计划过程改进的切入点包括：
1. 关注信息传递过程
在项目计划乃至整个项目管理过程中，我们和客户之间的信息传递都要形成这样一种效果：我们和客户之间有一张纸，这张纸具有一定的透明度，客户能透过这张纸看到纸后面有一个杯子，杯子里有水，但客户去看不清楚这个杯子里到底有多少水。研发团队就是这杯水，而我们的项目计划就是这张纸。我们通过项目计划而进行的信息传递就决定了这张纸的透明程度。
2. 关注计划分解和粒度
计划的制定基于范围分解，分解的关键在于粒度，上面提到项目实施计划和项目研发计划应该保持时间上一个数量级别的差距，一般前者以周为单位，后者以天为单位是一项比较好的实践。同时项目实施计划由于面向客户，应该围绕项目全生命周期展开分解并确保为后续的项目监控提供合适的计划视图。
3. 关注团队参与
项目计划的制定需要团队参与，对计划有关的项目、销售、研发、市场、运营等各个角色都应该对计划有明确的认识，其中两种计划的决策者、参与者、知情者都有其获取或制定项目计划的最佳时机。
针对上述切入点，我们梳理项目启动过程改进的模式和实践包括：
1. 建立项目线和研发线分离机制
项目线和研发线分离是控制信息传递过程的第一步，项目线和研发线分离之后直接的效果就是两条线有各自的计划，这两份计划之间确保有一定的信息不对称。工作机制上，项目线对于任何一项计划上的决策都应该先于研发线，项目线的决策通过一定的信息不对称处理之后再抛给研发线。在项目管理上，个人认为项目线工作的最大难度和挑战莫过于屏蔽来自客户和外部干系人的输入，确保研发线能够集中精力进行系统研发工作。
2. 建立项目全生命周期模型和范围分解模板
项目范围分解模板用于指导项目计划中的WBS创建工作，对于同类型的项目实施而言，模板都是应该事先去梳理的，无论是项目线上的模板还是研发线上的模板。项目范围模板通常基于特定的项目全生命周期模型进行内容组织，项目全生命周期模板包含了项目实施的各个环节和阶段，是项目实施计划的基础。
3. 召开项目计划评审会议
项目实施计划和项目研发计划都需要评审，尤其是项目实施计划，因为项目实施计划一旦定稿往往很难变动，项目实施计划的变动就是项目计划变更，我们会在项目监控改进域中展开讨论。所以项目实施计划的评审通常需要项目线、研发线的负责人或资深人员参与，对于初创型项目计划，建议至少进行初稿、修订稿两轮的评审；如果项目实施过程已经成熟，则一轮评审没有大问题即可通过。如果项目实施计划评审落实到位，项目研发计划评审主要是对实施计划中开发测试部分的分解，一般不会有太大的问题。
四．项目计划的过程资产
1. 项目实施计划
项目实施计划主要包括以下要点：
- 项目实施全生命周期阶段，从项目启动到项目验收的所有阶段
- 以周为单位的时间安排，一般以甘特图的形式进行展现
- 主要里程碑，系统上线等的重要里程碑节点
- 第三方供应商计划，需要在项目实施计划中以一定形式展现给相关干系人
2. 项目研发计划
项目研发计划主要包括以下要点：
- 系统功能模板，对系统所需开发模块的梳理
- 开发模型及其表现，对于开发过程模型（如瀑布、敏捷等）在计划中的体现，表现为开发顺序、测试时机、系统集成方案等各个方面
- 研发人员安排，结合项目人力资源计划安排研发人员
3. 项目人力资源计划
项目人力资源计划主要包括以下要点：
- 项目管理团队的成员安排
- 项目研发团队的成员安排
4. 项目范围分解模板
项目范围分解模板主要包括以下要点：
- 标准的项目实施生命周期
- 标准的系统功能模块，以及对系统功能分解的方法和分解后的结果
五．小结
项目计划是项目管理的第二个改进域，一方面对项目启动做项目实施计划上的支持，另一方面为后续项目监控和需求管理提供进度管理上的依据。实际上，进度管理是项目管理中最本质也是最可以发挥的部分，项目计划贯穿整个项目管理过程，好的项目计划和差的项目计划对项目实施会造成完全不同的效果，这也是我们要把项目计划作为一个改进域来关注的原因。下一个关于项目管理类的改进域是需求管理。