第二步，各个小组在项目经理的指导之下制定自己的中层计划，也就是以“任务”和 “约束”为基础，围绕如何按期到达里程碑制定详细计划。中层计划必须明确每个任务的起止时间，任务的先后次序（也就是任务之间的依赖关系），以及任务的负责人。虽然不同的阶段允许不同的详细程度，但一般的颗粒度要求是每个“小组”“每周”的工作内容。

　　因为中层计划一般会有多人参加执行，比如一个“储蓄业务组”,所以如果条件允许话，尽量让小组成员一起参与制定过程。这样好处是可以直接获得小组成员对于计划的“承诺和认可”.小组在制定过程中，一定要与项目经理反复沟通，不要猜测，有问题就问。

　　当各个小组完成了自己的中层计划之后，由项目经理负责汇总成为整个项目（到这个阶段）的完整中层计划。

　　第三步，是非常重要的一步，应将汇总之后的完整中层计划给所有的小组（至少是各个组长）讲解和确认。一般由项目经理负责介绍，让参会人员确认所有的任务都被说明了，没有被忽略的内容，工作量的估算是否准确和合理，各个小组是否清楚相互的约束关系。这个过程其实也是一个检查和评审过程。

　　一般中层计划中任务的颗粒度应该以天为单位计算，即这个任务需要A工作三天，那个任务需要B工作5天。以差异分析阶段的中层计划为例，比如对应“储蓄业务组”高层计划的任务--完成 “差异分析文档”,中层计划分解结果可能是： “确定交易清单”,“确定差异讨论会议计划”,“开户业务差异讨论”、“存款业务差异讨论”、……、“差异文档汇总”、“差异文档评审”等工作内容。

　　中层计划制定完成之后，应该张贴出来，让所有的人员都能看到。中层计划的推荐使用的工具是MS Project,一是方便进行版本控制，可以管理多个基准并进行回溯；二是能够比较方便地进行任务跟踪。在西安开发基地使用的VP系统，能从组织级集中管理所有项目的中层计划，并且很好地嵌入了MS Project,在VP系统中点击就可以直接查看，使用起来比较方便。

　　3 底层计划的制定

　　中层计划的完成，标志着已经明确了每个“小组”“每周”的任务。一旦这些任务被委派给了确定的“责任人”之后，个人就可以着手制定底层计划。

　　底层计划是将中层计划中任务分解为执行中的“关键步骤”或者“关键要素”.关键步骤是管理的最小颗粒单位，只有“完成”和“未完成”二种状态。例如对于上面的“开户业务差异讨论”任务，分解成为关键步骤包括：“确定会议的参加人员”,“确认会议的日程安排” “准备演示系统的环境和数据”,“锁定差异和解决方法”,“整理差异纪要”,“确认差异纪要”.对于一个需要持续几天的任务，底层计划分解的颗粒度要能够清晰地说明任务的状态，并比较准确地评估任务是否可以按时完成。

　　当然，一旦任务分解到这样的颗粒度，执行中变数就大大增加了。考虑到底层计划的变动频率，一般只需要提前1-2周滚动制定即可，3周之后的底层计划一般没有必要提前制定。实际操作中，一般是每个小组在周末，根据中层计划的任务和本周底层计划的完成情况，制定下周的底层计划。

　　管理工具的选择，在西安开发中心尝试过Project、Excel等多种手段，但效果均不好。原因一是底层计划变化频度非常高，经常需要调整；二是软件工具的“公示效果”不好，修改之后其他人不知道。经过摸索，最后选择的是最简单的工具--白板，却取得了意想不到的效果。

　　因为白板修改方便，信息的发布非常的透明和及时。任何时候，大家不但知道自己在做什么，而且还知道其他人在做什么。后来，西安基地的所有墙壁上都覆盖了白板，把每个小组的底层计划都明确写在白板上，左侧显示的就是墙壁上整块的白板，上面就是底层计划。

　　底层计划在白板上的格式参见图 3,上面不但可以写上每个成员本周的工作（一行表示一个成员一周的每天的工作），还可以记录有什么问题、目前项目所处的阶段、任务完成情况的统计信息。为了对底层计划进行跟踪和统计，并积累宝贵的原始数据，配合用Excel表制作了一个《完成度矩阵》，在后续的章节进行介绍。

　　四、三层计划的跟踪和管理

　　参见图 1的三层计划管理框架，其制定的过程是“自顶向下”的，但是跟踪过程则是“自底向上”的。根据计划的不同层次，计划的跟踪和管理主要包括以下三种方式：

　　1.各个小组每天早晨的晨会

　　2.项目组每周的周例会

　　3. 组织层面的里程碑评审。

　　其中，后面的两种跟踪方式一般的项目经理都比较熟悉，只作简单说明。这里重点介绍一下“底层计划”的跟踪和管理方法。

　　底层计划的管理不仅为中层计划提供了基础信息，也是项目管理落地的基石。前面提到，底层计划在白板上上公示，但小组长还需要配合使用一个管理底层计划的关键工具--《完成度矩阵》。完成度矩阵用Excel表开发，是连接底层计划中层计划的桥梁。它成上下两个部分：上半部分为“底层计划”,下半部分左面为“任务”栏，右面为“关键步骤”栏，记录了每项“任务”分解成“关键步骤”的过程。

　　通过一些简单的开发，《完成度矩阵》可以根据“关键步骤”的分解结果自动导出上半部分“底层计划”,还可以根据“底层计划”的进展状态，自动计算出每个“任务”的完成比例。后来还增加了《个人周报》自动导出功能，直接根据“底层计划”导出每个成员的工作任务，减少小组长的工作量。

　　底层计划采用晨会的方式进行跟踪，晨会一般在15分钟左右，要求小组所有成员站在白板前面完成。晨会的步骤如下：

　　第一步，小组长与项目组成员逐个确认昨天任务的完成情况，并进行标注。确认任务的完成情况不涉及执行细节，仅需要回答：“Yes/No”.一般任务按时完成用“√”别时，未按时完成用“○”;对于昨天未完成但是今天完成的任务，在原来“○”的基础上增加一个“√”,将任务的完成情况分成三类：“按期完成”,“延迟完成”和“延迟中”,并进行汇总统计。这样，只要看到“底层计划”（图 3）模版左上角的统计数字，就可以对于小组的工作状态有了大概的了解。

　　第二步，组长根据昨天任务的完成情况和今天的任务要求，对“底层计划”进行适当调整，布置当天每个人的工作任务。会后，再将进展和计划的调整信息更新到《完成度矩阵》中（几分钟应该就可以完成）。

　　第三步，组长收集执行过程中遇到的问题（这时，成员可以说明没有完成任务的原因是什么），记录到白板上，并审核以前的问题的状态。除非简单可以当场解决的问题，此时仍不要对问题展开讨论，只要记录到白板的问题栏。会后，对于这些问题再作进一步讨论，或另行安排相关各方碰头协调。

　　鉴于底层计划的颗粒度已经到了每人每天的工作，一般变动比较频繁。但是，小组长还是要尽量将变动减少到最小，太多变更不仅浪费小组的工作时间，而且每个成员切换工作内容、进入工作状态都会降低工作效率。

　　底层计划如果不会影响到中层计划的进展，组长可以直接调整底层计划，而不需要通知PM或者架构师。但是，如果底层影响到了中层计划，则应该通知PM和架构师，并说明变更的原因。项目管理团队可以据此评估对于后续计划的影响，并采取适当的措施进行管理。如果需要，还应该跟其他小组沟通中层计划的变化。进一步，如果变化影响到了高层计划的里程碑，则应该作为重大变更，由项目经理迅速汇报到项目总监层面，讨论具体对策并采取措施。

　　有了底层计划的管理基础，中层计划的管理效率会提高很多。中层计划采用周例会方式管理，基本上是汇总每个小组的底层计划的完成情况并局部进行调整的过程。主要任务包括：组长首先根据上周底层计划完成状态，更新《完成度矩阵》中各项任务的完成情况；然后，项目经理根据各小组长的提交的《完成度矩阵》，更新《中层计划》中的任务完成情况；最后，项目经理和小组长一起制定下周工作计划。周例会的跟踪方法参见笔者的另一篇文章《项目经理怎么知道每天该干什么》中的范例，这里不作赘述。

　　高层计划的控制点在里程碑，但是有了中层计划的信息基础，其实每周、甚至每天都可以知道是否可以按期到达里程碑。里程碑评审是确认上个阶段的完成、批准下个阶段开始的过程。具体的任务包括：交付物纳入基线并完成审计；项目经理对于里程碑完成进行说明，对于进度、成本、范围的度量数据进行分析；对项目团队进行评估；对于客户反馈进行分析；评估风险及应对措施；质量经理评估项目质量状况、交付物缺陷修改情况、阶段审计不符合项的修改情况。最后，由项目总监根据项目的状况，批准本阶段结束和进入下一阶段。

　　五、 实践效果总结

　　三层计划的管理方法的核心，是对应项目组、小组和个人的组织结构，将项目计划分成高层计划、中层计划、底层计划三个层次，并采用滚动更新、分段制定的方法，随着工作的进行逐步细化计划。这样的管理方法，可以帮助项目总理理清层次，从宏观到微观的逐层聚焦，不仅能够看到项目的整体趋势，还可以深入查出问题“点”.因此，可以与各个层面进行清晰的沟通，能够“3分钟说清项目状况”。

　　针对“底层计划”变动频繁、要求“响应速度快、公示性强”的特点，采用“白板”动态跟踪每个人的工作情况，逐层向上汇总以获取项目的整体进展的信息。基于白板的底层计划管理，还为CMMi4评估积累了宝贵的度量数据，“白板”文化在评估过程中获得了主任评估师的赞赏。

　　但是，这种方法也有一定的适用条件。第一，需要有比较明确的“实施方法论”,即每个阶段工作流程、任务比较清晰；其次，在规模比较大时才有必要，对于仅有一二十人的小型软件项目来说，可以直接管理到底层计划；第三，在基地化的开发的模式下比较有效，因为项目组有比较大自主权，受外界的影响比较小。

　　最后，分享一点个人体会。在选择底层计划管理工具的过程中，尝试过多种选择。首先想到的是Project,但很快发现如果要分解到底层计划的层次则过于庞大，很难管理；其次，想到了 Excel,尽管其项目管理功能非常有限，但用来开发一些类似《完成度矩阵》的小工具非常有效；最后，选择的却是最简单、最不自动的白板，但发挥了意想不到的作用。因此，软件开发中“人”才是最重要的，如果没有“人”的能动性，再高级的工具也难以发挥作用-- “开着夏利还撞墙呢，难道换成奔驰就不撞了”?