[内容提要] 软件项目进行中，项目经理需要与各个层面的人进行大量的沟通，对象可能从程序员直到CEO。作为项目的“指挥官”，项目经理不但要知道项目的整体进展和趋势，还要知道细节上的难点。某种意义上说，如果“如果3分钟之内还说不清项目的情况，说明你的管理还不到位”。其实，“说清”的前提是“看清”、“理清”项目各个层面的信息。本文介绍的“三层计划”管理方法，是神州数码西安开发基地在实践中逐步总结和积累的出来的一种分层管理方法，希望对读者有所帮助

一、“三分钟”能说清楚项目进展吗?

项目经理的一个重要任务就是要不断地进行沟通，特别是在很短的时间内说清、或者获取关于项目执行状况的信息。

案例：笔者在负责管理神州数码西安开发基地的时候，公司CEO董其奇先生经常到基地检查工作，了解项目的进展情况。当时，基地大大小小有好几十个同时进行的项目，而且分别处于不同的阶段，因此每个项目经理一般仅有几分钟的时间说明项目进展。

身为高层领导，董其奇一方面要求看到项目的宏观进展和趋势，另一方面还非常关注细节，甚至可能问到类似“某人某天在做什么?他遇到了什么困难”这样的问题。这样的汇报方式项目经理非常不适应，特别是那些管理着上百人的项目经理尤其感觉“头疼”。

老实说，刚开始笔者本人也觉得这样的要求过于苛刻。为了提高沟通效率，曾经把解决问题的关键放在了提高项目经理的沟通技巧上，包括统一的汇报模板、演讲技能培训，但是效果有限。

原因很简单，虽然表达能力达到了很大的改进，但是一旦被问及很多执行层面的具体问题时，项目经理仍不能准确提供信息。而领导的想法也非常有道理，如果一个项目经理不能说出问题出在那个“点”上，又怎么采取正确的措施控制好项目呢?也就是说，“如果你几分钟之内还说不清项目的情况，说明你的管理还不到位”

仔细想想领导的话，“说不清楚”的原因其实不是表达能力的问题，而是不知道该从那个层面上进行沟通问题;更深一层，是一个项目经理不知道该在那个层面(或者那几个层面上)管理项目。

二、怎样才能从“全局”看到“个体”?

项目管理的核心是计划，而计划是有层次的。举个最简单的例子，很多项目一开始就会有一个“主计划”(神州数码内部称之为高层计划)，并得到客户和公司高层的认可，轻易不能更改。而各个项目小组需要据此制定一套自己的详细的计划。理论上，可以逐层把计划分解到每个人每天做什么这样详细的程度，但在大项目中这样做有很大的困难，原因之一就是软件项目的“不确定性”。

我们知道，软件项目的周期一般比较长，过程中项目的需求、功能甚至目标都可能变化;其次，各种突发事件、项目问题、各种变更，都能导致计划在执行中的变动;第三，开发人员的个体能动性、情绪对项目的进展也有直接的影响，基于预测的估算本身就有误差。在这样的情况下，试图将计划分解“每人每天”做什么，一方面计划会庞大无比，另外也缺乏实际指导意义。因为，想将“3个月后某人某天在干什么都能够清晰计划出来”的计划，基本上是在试图精确预测未来;实际执行中，项目经理可能将所有时间都放在计划上的维护上，也难以跟上“变化”。

其实，一个大型项目好比一场战役，计划好比是作战地图，项目经理好比是指挥官。制定作战计划时，指挥官要对全局进行考虑，在地图上说明每个团的作战任务，之后每个团再确定下属各连队的战斗任务。作战中，情况经常变化，团长为了完成任务可以调整连队的部署，连队也要动态指挥单兵作战。而指挥官首先需要战场全局的态势，然后才会关注哪个团没有完成任务，进一步聚焦到某个“英雄连”的战斗情况，或者某个“尖刀班”突击进展。

与此类似，项目大了之后，如果项目经理仍试图在一张地图中标注每个单兵的任务，就会使得地图秘密麻麻、极其繁杂，不但无法执行，而且也看不出战局的整体态势。因此，“说不清”的核心问题在于缺乏系统的方法分层计划、分层管理。

“怎样划分层次?何时进行细化?怎样进行管理?”才能保证项目经理从全局到个体都能看清楚呢?结合国外同行的先进经验，西安开发基地通过实践逐步形成了一套“三层计划”的管理方法，其核心是：

1.将项目计划分成高层计划、中层计划、底层计划三个层次，分别对应项目组、小组和个人的管理结构;

2. 采用滚动更新、分段制定的方法，随着工作的进行逐步细化计划;每层计划的细化频率和颗粒度要求不同

3. 采用白板记录和更新底层计划，动态跟踪每个人的工作任务完成情况，逐层向上汇总并确定项目的整体状况

通过这种方法，项目经理可以看到项目的当前状况和整体趋势，还可以逐级向下追踪，直到发现有问题的“点”。

三、三层计划的管理框架

对应于一般的软件开发项目的组织结构，“项目计划”一般可以分为三个层次：高层计划，中层计划和底层计划。西安开发基地使用的三层计划的管理框架参见图 1所示。区分不同层次的原则，一是对于不同层面管理的颗粒度要求不同，二是对于不同的沟通对象、沟通的信息层面不同。但无论从哪个层面的计划，都必须回答的核心问题是：“现在进展如何”，“下面将会怎样”。

图 1：三层计划框架

高层计划主要的沟通对象为客户或公司高层，具体可能包括CEO、CIO、CFO、CTO、项目出资人，或者其他高层人士;所以，高层计划有时也被形象地称为“C-计划”。高层计划作用是快速、清晰地给高层一个项目“快照”，说明“项目目前处于什么阶段，在这个阶段预计还需要多长时间?”，以及“刚刚到达的里程碑是什么?下一个里程碑是什么?”，而这正是高层管理人员第一时间最想得到的信息。

中层计划的使用者和沟通对象是项目中的执行人员，包括项目经理，小组长和项目成员，它说明了“为了完成项目，必须完成那些任务”，“这些任务正在(或者将会)被谁执行”。中层计划的主要作用是确保项目经理能够密切跟踪项目任务的完成情况，因此沟通的主题是“哪些任务应该被完成?什么时候能完成。”。

另外，中层计划还应该说明任务之间的依赖关系，确保不同项目小组之间的有效沟通。沟通的主题是“这个任务应该在那个任务之前完成;或者，这个任务必须和那个任务同时执行”。项目经理最关注的是中层计划中任务的开始和结束时间，而不是执行的细节。中层计划一旦引起高层计划延期的时候，可以迅速追踪到“哪个任务出问题了”。

底层计划也是分层管理方法的核心之一，用来确定任务的负责人该如何工作，因此主要是被组长和具体责任人使用。底层计划作用是将中层计划的任务进一步分解为“关键步骤”或“关键要素”，确保的执行者在非常详细(每人每天)的层面上计划和沟通，沟通的主题应该是“这个任务已经走到哪一步了?”。底层计划不但能保证对中层计划的有效跟踪和清晰度量，而且在任务分解的过程中，可以发现原来对于周期或者工作量的估算偏差，为项目组提供一个“中层计划估算是否恰当”的快速反馈。

1 高层计划的制定

一般地商务活动中，在签约之前的方案论证阶段，客户就会提出项目的整体工期要求，有时招标书中也有明确的时间要求。参见图 1，高层计划以里程碑为基本元素将项目划分成若干个阶段，并明确每个里程碑对应的标志性事件、交付物、时点和关闭条件。

有些项目在合同(或方案建议书)中专门有一个章节，说明项目的“实施方法”，这可能是客户与公司的技术专家(例如架构师)、咨询顾问和项目总监在项目的早期阶段共同完成的，可能直接转化为高层计划。另外一些项目，在商务谈判的过程中会确定工作范围，包括每个阶段的时间段和必须完成的工作，这样的“工作范围”也可以非常方便地转换成为高层计划。

以神州数码西安开发基地的“客户化”项目为例，其运作模式是先在基地开发一个标准的基本版本，然后根据不同客户的需求差异进行客户化。因此典型的阶段划分为“原型培训，差异分析，功能定义，客户化开发，出厂测试，试运行和投产”。每个阶段的大致时间范围和必须完成的工作都比较确定，这样“方法论”就可以方便地转换成为高层计划。

高层计划的详细程度取决于项目的不同需求。一般对于项目周期为3-9个月项目的来说，里程碑的时间跨度应该在2-4周之间;每个阶段内，任务颗粒度应该是以周为单位进行计算的。如果其中有一些以“日”为单位计算的任务非常关键，虽然可以将其包含在以周为单位的任务里，但建议直接放在高层计划里，以突出其重要性。如果一个项目的周期非常长，里程碑的时间跨度应该是4-6周之间，但不要超过6周。时间跨度和颗粒度的确定原则，是方便项目经理进行沟通和和管理。

在项目组内，高层计划可以使用Excel表格进行管理。在组织层面，西安开发中心使用视锐达公司的VP系统集中管理所有项目的高层计划，其中有专门的高层计划管理工具。

2 中层计划的制定

高层计划完成之后，标志着项目有了清晰的里程碑，这时就可以开始制定中层计划。中层计划的实质，就是将高层计划中的任务分解为以 “小组”为单位的任务集合，其制定过程需要项目经理、架构师、质量经理以及各个小组长密切配合。

正如前面所说的那样，虽然项目一开始就可以定义详细的中层计划，但鉴于项目变化频繁，一般情况下建议在进入某个阶段之前，再详细定义中层计划。换言之，“上个阶段”的重要工作之一就是完成“下个阶段”中层计划。结合高层计划例子，在进入“差异分析”阶段之前，就要详细定义“差异分析”的中层计划，即明确必需完成任务和以及它们依赖关系;同样地，在“差异分析”阶段的快要结束的时候，应该根据“差异分析”的结果制定“功能定义”阶段的中层计划。将上个阶段的产出作为下一个阶段的计划依据，这样的过程不断滚动进行。

中层计划的制定是项目管理团队的职责。如果计划开始之前发现某种原因造成项目角色不明，或者组织结构不清晰，最好尽快明确组织结构和职责。这样就可以保证以“团队”方式共同制定计划，项目经理也可以与关键角色或者负责人直接讨论，避免“闭门造成”。具体制定计划的步骤如下：

第一步，为提高效率，可以先由项目经理和架构师完成初始的任务分解和工作量估算，将高层计划分解为每个小组“任务”和“约束”：包括每个小组的工作范围(需要完成的任务)，小组对外依赖关系，完成任务所需要的资源(每个小组需要多少人，关键素质是什么)，下一个里程碑的要求(交付物，时间和关闭条件)。一般需要召开一个会议，并请小组长以上成员参加。

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

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

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

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

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

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

3 底层计划的制定

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

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

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

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

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

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

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

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

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

2.项目组每周的周例会

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

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

底层计划的管理不仅为中层计划提供了基础信息，也是项目管理落地的基石。前面提到，底层计划在白板上上公示，但小组长还需要配合使用一个管理底层计划的关键工具——《完成度矩阵》。

参见图 4，完成度矩阵用Excel表开发，是连接底层计划中层计划的桥梁。它成上下两个部分：上半部分为“底层计划”，下半部分左面为“任务”栏，右面为“关键步骤”栏，记录了每项“任务”分解成“关键步骤”的过程。

图4：完成度矩阵

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

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

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

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

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

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

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

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

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

五、 实践效果总结

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

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

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

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