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