之前讲到了关键路径，讲到了对于每个活动级别的任务进行估算。这个工作都是为最终的项目计划做准备。项目计划包括哪些信息呢？

1. 整个项目的日程（Schedule）

2. 主要里程碑。

3. 各个阶段的准入准出条件。

接下来我们就来分别讲述如何得到这些产出物。

《一》整个项目的日程（Schedule）

这个时候，先看看我们手上有什么?

1. 基于活动的工作分解结构 WBS。

2. 基于活动的三点估算结果。

3. 识别出来的关键路径以及活动拓扑图。

首先第一步，将活动拓扑图按照活动的前置后置条件，填写到MS Project中。没有MS project的可以用Excel代替。

下图是之前例子中项目的关键路径以及拓扑图。

然后我们根据上面的图，从最早开始时间的任务开始进行填写，然后得到下图：

一般包涵以下信息：编号，任务名称，开始时间，结束时间，前置条件，资源以及完成度。

就像一个树一样，最根节点就是项目名称，编号为1.这个和完整的关键路径节点的编号是一一对应的。然后慢慢下坠，得到每个子任务的开始结束时间，以及根据拓扑图可以知道每一个任务的前置任务分别是哪些。

值得注意的是，每个任务的前置条件不一定只有一个，可能会有多个。

而资源这列，由于之前计算的关键路径的时候，是按照1个BA，2个测试，1个前端开发，1个服务层开发，一个数据库开发，一个CM来计算。所以大致的资源是已经知晓的。如果当下知道项目组成员名字，可以直接填入，如果还未决定，可以先根据职能填入。于是补充完资源信息后，得到下面信息如图：

等到相关的资源确定后，在替代掉即可。

从上图中，可以看到粒度比较粗的项目计划。而真正的项目计划，需要继续细分。原因在于：

1. 保证每个任务都是有唯一一个资源负责。避免踢皮球的现象发生。如：1.4.1撰写测试用例这个任务，当前归属是Tester1和Tester2，那么如果需要写5个测试用了，他们如何去分配呢？

2. 将过于粗的任务细分，便于及时追踪完成进度。如1.1.1 需求分析文档，计划是一个星期完成。当过去一半时间的时候，去问BA1，完成的怎么样了，得到的回答很可能是差不多。而这个差不多每个人的理解有不同，如果任务够细，从项目任务中就可以看到当前完成了多少个需求文档还有多少个，是否能够按时完成。

于是，继续将任务细化，得到如下图的项目计划：

蓝色底部分任务为细化的任务。这里注意一下，1.1.1任务原先是持续一个星期的，细化之后，增加了三个子任务，可以从每个任务的开始结束时间中清晰的看到每一天需要完成任务是什么。方便跟踪进度。

而1.4.1的任务原先的资源是Tester1 和Tester2.细化之后，将三个不同的测试用例根据估算的时间，分别分配给了不同的测试人员。从而保证了专人做专项任务。

由此得到了整个项目计划日程（Schedule)

《二》主要里程碑

项目的主要里程碑其实之前已经获取到了，而从项目计划中，也可以体现。我们将细分任务收拢，得到1.X编号的任务。如下图：

即是该项目的主要里程碑。

《三》各个阶段的准入准出条件

从以上里程碑中，明确的将项目分成了需求分析，设计，开发，测试，部署5个阶段。对于每一个阶段，都需要有明确的准入，准出条件。如果前一阶段未达到条件就进入后一阶段，会造成后一阶段无法继续，并且将人力浪费在等待中。

所以在项目计划中明确各个阶段的准入准出条件是尤为重要的。

还是上面这个项目的例子，以下是定义的各个阶段的准入准出条件。供大家参考。

记住，定义准入准出条件的目的是为了避免不达标的向下一阶段迁移，造成资源浪费的情况。

如上图中测试的准入条件是冒烟测试通过。原因就是在于如果冒烟测试对于基本的功能流程都无法保证，那么测试花再多时间测试，也只能是出现成堆的缺陷。

这只能说明开发交付的成果不达到标准。而在不达到标准的成果上反复测试无疑是对资源的浪费。尤其是在多团队协同工作的情况下，这点尤为重要。