阶段计划怎么做？项目经理制度设计：项目规划从0到1

2021年我参与过一家工业设备公司的研发复盘，两百多人的研发体系，项目阶段计划做得相当“漂亮”：五个阶段、二十七个里程碑、甘特图配色分明，评审会上没人挑得出毛病。三个月后再看数据，阶段完成率78%，但交付物齐套率只有41%，最终延期交付11周。复盘时我问了一句：这个阶段“做完了”的判定标准是什么？在场七八个人，给出的答案有四种。这就是问题的根子，不是排期不准，是阶段本身没有被定义成一个可判定的决策单元。

后来我把这套复盘方法带进十几家不同规模的组织，从二十人的创业团队到上千人的研发中心，结论高度一致：阶段计划失败的原因，绝大多数不在工具，也不在项目经理的个人能力，而在于“项目经理制度”没有被设计出来。谁在什么条件下有权说“不”，谁对阶段出口负责，阶段出口到底看什么，这三件事不写清楚，再精美的甘特图都只是一张装饰画。

这篇内容我按“结论，场景，误区，判断逻辑，案例数据，行动建议，取舍”的顺序展开，所有数据来自我参与的项目复盘样本和公开的行业观察，涉及推演的部分我会明确标注。如果你正在从0到1搭项目规划体系，可以直接按章节顺序读。

一、核心结论：阶段计划是制度的产物，不是文档的产物

我给出的第一个结论可能有点反直觉：阶段计划的质量，不取决于排期准不准，而取决于阶段出口是否可判定、可追责、可回溯。一个阶段计划写得好不好，看三个指标就够了，阶段完成的判定是否唯一、阶段卡住时是否有人有权叫停、阶段结束后是否留下可对比的数据。

1. 阶段计划的四个必备要素，缺一个都会塌

我把过去几年做过的规划体系拆开看，凡是能长期跑下去的，阶段计划里一定同时存在四个要素：交付物、决策门、责任归属、度量口径。四者缺一不可，而且顺序不能反。先想清楚交付物是什么，再定谁来判断它合格，然后定谁对它负责，最后定用什么数字衡量。

很多团队的做法是反过来的：先排时间，再补交付物，最后才想起来“这个阶段谁负责”。顺序一错，后面所有动作都在补漏洞。我见过一个团队，阶段计划表里“负责人”一栏写着部门名而不是人名，结果跨部门阶段一卡就是两周，因为没人有权限调动另一个部门的资源。

（1）交付物：阶段的定义物，不是任务的集合

交付物必须是名词，不是动词。“完成详细设计”是动词，不可判定；“详细设计说明书V1.0通过评审并冻结”是名词加状态，可判定。这一个字的差别，决定了阶段计划能不能被自动检查。

（2）决策门：阶段之间的闸门，而不是日历上的一个点

决策门的本质是“准入准出”。上一个阶段没满足准出条件，下一个阶段就不该启动。现实里绝大多数团队做不到这一点，因为项目一旦启动，资源已经投进去，没人愿意承认“还不该开始”。

（3）责任归属：单一责任人，不是共同责任

“共同负责”在项目管理里等于没人负责。每个阶段必须有一个唯一责任人，其他人是协作者。这个责任人在阶段内有权调配资源、有权拒绝不合格交付、有权向上申请决策。

（4）度量口径：阶段健康度必须能被计算

没有度量，阶段计划就只能靠感觉推进。我一般会要求至少三个口径：阶段准出一次通过率、阶段超期天数分布、阶段间返工率。这三个数字能把八成的问题暴露出来。

2. 从0到1的四步骨架

如果让我用最短路径重建阶段计划体系，我会按四步走：定项目分级、定阶段模板、定决策门、定度量看板。这四步的先后顺序不能变，因为项目不分级，阶段模板就只能是“一刀切”；阶段模板不统一，决策门就没有对照基准；决策门没有基准，度量看板就只是一堆数字。

1. 定项目分级：按投入、风险、合规要求把项目分成2-4档，每档对应不同的管理强度。
2. 定阶段模板：为每一档定义阶段数量、阶段名称、每阶段交付物清单。
3. 定决策门：明确每个阶段的准出条件、审批角色、超时默认规则。
4. 定度量看板：定义阶段健康度指标，并明确谁看、多久看一次、看到异常怎么办。

这四步我在一个一百八十人的研发组织里跑过完整一遍，用了大约九十天，前三十天全部花在第一步和第二步上。当时很多人催我“先把工具配起来”，我坚持没有动工具配置。事实证明这个顺序是对的，如果我们先配工具，工具里沉淀的就是错误的阶段定义，后面改起来比从零开始还贵。

二、背景与真实场景：三个阶段计划失控的现场

讲方法之前，我想先把三个真实现场摊开，因为它们几乎覆盖了八成组织的现状。这三个现场分别出现在硬件研发、软件平台和跨部门交付三类项目里，问题形态不同，但根因是同一个。

1. 现场A：把WBS当成阶段计划

第一个现场是一家做智能硬件的公司。他们的“阶段计划”实际上是一张深度五层的WBS，最底层任务颗粒度到了“采购电阻电容”。我问项目负责人，第三阶段的出口是什么，他翻了半天，指着一行说“这些任务都打勾了，阶段就结束了”。

问题在于，任务打勾不等于交付物合格。WBS描述的是“做什么”，阶段计划描述的是“做到什么程度可以进入下一步”。这两件事经常被混为一谈，代价是阶段评审形同虚设。

这个项目后来在集成测试阶段返工了三轮，累计额外投入约420人天。复盘时的结论很直白：如果第三阶段有一个明确的“接口冻结”准出条件，其中至少两轮返工可以避免。

2. 现场B：阶段按部门切，而不是按交付物切

第二个现场是一个软件平台项目。他们的阶段划分是“需求阶段、开发阶段、测试阶段、上线阶段”，看起来很正常，但细看每个阶段的负责人分别是需求部、开发部、测试部和运维部的部门经理。这就是典型的按组织结构切阶段。

后果是：阶段之间的责任交接变成了部门之间的责任推诿。开发部说“需求文档不清晰”，需求部说“你们没提清楚要什么”，测试部说“开发提交的质量太差”。每个部门的KPI都是自己阶段的产出数量，没有人对端到端交付负责。

我后来给他们的建议是：阶段应该按交付物切，而不是按部门切。一个阶段可以跨越多个部门，但必须只有一个对阶段出口负责的人。这个调整他们花了两个月才落地，但落地之后跨部门扯皮会议减少了约六成。

3. 现场C：没有决策门，阶段只是日历切片

第三个现场最典型。他们的阶段计划里每个阶段都有开始日期和结束日期，但没有任何“不满足条件就不许进入下一阶段”的机制。阶段结束日期一到，无论交付物状态如何，下一个阶段自动开始。

这种做法在资源紧张时看起来“效率很高”，因为它从来不停工。但代价是把风险层层后置，最终在验收阶段一次性爆发。这个项目最终验收延期了十四周，客户方启动了合同违约条款。

4. 数据观察：一个两百人研发组织的复盘样本

我把上面三个现场所在组织的部分数据做了梳理，同时也参考了我自己带过的两个项目。以下数据属于样本推演，用于展示趋势方向，不是行业统计结论，请按你自己组织的情况做校准。

三、拆解常见误区：五个我以为对、后来发现错的做法

这一节我写得会比较直白，因为这五个误区我自己踩过至少三个。误区之所以叫误区，不是因为做法本身绝对错误，而是在特定阶段用错了顺序或场景。

1. 误区一：先做计划，再想制度

这是最普遍的一个。团队接到项目，第一反应是打开工具建计划，把任务铺进去，然后再考虑“谁来管”。正确的顺序恰好相反：制度决定计划能长成什么样。没有决策权设计，计划里就不会出现真正的决策门；没有单一责任人，计划里的责任人字段就只能是部门名。

我做过一个对比实验：同一批项目经理，一组先花一周设计制度再写计划，另一组直接写计划。三个月后，第一组的计划变更次数平均是7次，第二组是23次。计划变更次数本身不是坏事，但变更原因里“责任不清导致的返工”占比，第一组是14%，第二组是52%。

2. 误区二：阶段划分按组织结构走

按部门切阶段的好处是汇报路径清晰，坏处是没人对端到端结果负责。判断方法很简单：如果你的阶段名称里有部门名字（比如“开发阶段”“测试阶段”），并且阶段责任人是对应部门经理，那基本就是按组织结构切的。

更合理的切法是按交付物形态切，比如“方案冻结”“样机可用”“小批量验证通过”“量产就绪”。这些阶段天然跨部门，但出口判定标准是客观的。

3. 误区三：里程碑就是一个时间点

里程碑如果只是一个日期，它唯一的作用就是制造焦虑。我认为里程碑应该是一个三元组：时间点、交付物状态、判定人。缺了后两项，里程碑就退化成了日历提醒。

举个具体的例子，我见过一个项目把“样机点亮”设为里程碑，但没有规定“点亮”的判定标准是“连续运行四小时无复位”还是“上电后屏幕亮起”。结果是研发说达成了，测试说没达成，双方各执一词，僵持了两周。

4. 误区四：用工具替代制度

工具能解决“看得见”的问题，解决不了“算不算数”的问题。我在不止一个团队看到，工具里阶段状态全是绿色，但线下大家心里都清楚有几个阶段是带病通过的。绿色状态是团队自己点的，工具只是忠实记录了这个选择。

这也是我一直强调的一点：工具是制度的放大器，不是制度的替代品。制度不清，工具只会把混乱固化得更快、更难以纠正。

5. 误区五：所有项目用同一套阶段模板

一个投入20人天的小工具开发，和一个投入2000人天、涉及硬件与合规认证的产品研发，用同一套五阶段模板，结果一定是小项目被流程拖死，大项目被流程放松。项目分级不是为了增加管理动作，而是为了让管理强度与风险匹配。

四、专业判断逻辑：阶段计划的五层设计法

这一节是全文的方法核心。我把阶段计划体系拆成五层，从下到上依次是项目分级、阶段模板、决策门、角色权责、度量回顾。这五层不是并列关系，而是依赖关系，下层不稳，上层就是空中楼阁。

1. 第一层：项目分级，用T恤尺寸而不是数字

我喜欢用T恤尺寸（S/M/L/XL）而不是数字分级，因为数字容易让人误以为有精确的排序。分级依据我一般用三个维度：总投入人天、跨部门数量、外部合规要求。三个维度里有两个达到阈值，就升一档。

这张表看起来简单，但真正落地时要加一条：分级结果必须公示，并且可以被挑战。我在一个组织里见过项目组为了降低管理强度，刻意把L级项目报成M级，结果在合规审查时被查出，整个项目重新走了流程，损失比一开始就按L级做还大。

2. 第二层：阶段模板，用交付物倒推阶段

阶段模板的写法我建议倒推：先列出项目结项时必须交付的全部物项，然后把它们分配到不同的成熟度阶段。这样划分出来的阶段天然与交付物对齐，而不是与时间对齐。

具体操作上我会问三类问题：这个交付物在什么状态下可以支撑下一个环节的工作？如果它还没达到这个状态，下游会付出什么代价？这个状态下谁最有资格判断它合格？这三个问题问完，阶段的边界基本就清楚了。

3. 第三层：决策门，写清楚“不通过会怎样”

决策门最容易写成一句空话，比如“评审通过后进入下一阶段”。有效的写法必须包含三部分：准出条件、审批人、未通过的处理方式。第三部分最常被忽略，但它才是决策门能否真正起作用的关键。

未通过的处理方式通常有三种：条件通过（带整改项进入下一阶段，限期关闭）、退回本阶段、终止或重定向。我会要求每个阶段模板明确默认采用哪一种，避免每次评审都现场争论。

stage: S3-详细设计
exit_criteria:

关键接口清单冻结，变更需走变更控制流程

设计评审问题关闭率 >= 95%，未关闭项均有明确责任人与期限

长周期物料已完成下单或替代方案确认

关键性能指标完成仿真验证，偏差在允许范围内

owner: 系统架构师

approver: 技术负责人

default_outcome: 条件通过（整改项不超过3项，限7天内关闭）

escalation: 超期未关闭自动升级至项目管理办公室

sla_days: 5

上面这段是我常用的阶段门定义结构。它的关键不是格式，而是把“默认结果”和“升级路径”写进定义里。这样一来，评审不再是每次重新博弈，而是执行既定规则。

4. 第四层：角色权责，重点是“谁能说不”

角色权责我一般用两把尺子衡量：第一，每个阶段是否只有一个人对出口负责；第二，是否存在一个角色，可以在交付物不合格时行使否决权，而且这个否决不需要经过被否决方的同意。

第二点听起来理所当然，实践中却很难。很多组织的质量角色名义上有否决权，但考核、晋升、资源都在业务负责人手里，否决权实际上无法行使。这是个制度问题，不是个人勇气问题。

（1）责任人配置的三种模式

我见过三种模式：职能责任人（阶段由某职能负责人承担）、项目责任人（全流程由项目经理承担）、矩阵责任人（交付物归职能，阶段出口归项目）。二十人以下用第一种，两百人以上我推荐第三种，中间规模看组织成熟度。

（2）否决权的三个前置条件

否决权要真正生效，需要三个条件同时成立：否决标准是事先约定的客观条件，而不是临场判断；否决方的考核不与被否决方的进度直接挂钩；否决记录会被统计并向上呈现。缺任何一个，否决权都会退化成建议权。

5. 第五层：度量回顾，看趋势而不是看单点

度量看板我建议只放四个指标起步：阶段准出一次通过率、阶段超期天数、阶段间返工率、交付物齐套率。再多就容易变成数字噪声。看板的使用关键是节奏固定，每周固定时间看一次，看趋势，异常项必须落到具体动作上。

五、具体案例与数据观察：从0到1的九十天落地过程

这一节我用一个具体组织的落地过程来说明，因为方法论讲得再清楚，不落到时间线和数据上，读者很难判断自己能不能复制。这家组织是一家做企业级软件和配套硬件的公司，研发体系三百余人，项目并行度较高，同时有国产化替代与数据合规要求。

1. 案例背景与约束条件

他们的约束有三个：一是原有工具链已经在用，历史项目数据量不小，不能推倒重来；二是研发团队分布在不同城市，需要一个统一视图；三是部分项目涉及客户现场部署，数据不能出内网。这三条约束直接决定了他们不能只考虑功能，还要考虑部署形态和数据迁移成本。

最终他们选择的是 PingCode 作为项目与研发管理的主平台。选择理由里，权重最高的三项是：支持私有化部署、对大规模研发组织的适配、以及在迁移路径上有成熟方案。这三点对三百人以上、且有国产化替代诉求的组织来说，往往是决策的关键变量。

2. 九十天落地的三个阶段

我把整个过程拆成三段，每段三十天，每段都有明确的产出物，不允许跨段并行。

1. 第1-30天：定制度，不动工具。产出项目分级标准、四级阶段模板、每级决策门定义、责任人矩阵。这一段结束时做了两次桌面推演，用历史项目验证模板是否可执行。
2. 第31-60天：配置与试点。在平台里配置阶段工作流、阶段门、责任字段与看板。选两个在建项目做试点，试点期间每周复盘一次，共调整了11处流程配置。
3. 第61-90天：迁移与推广。历史项目按优先级分批迁移，第一批迁移了近三年内的活跃项目，非活跃项目归档只保留结项数据。

这里我要特别说一下迁移。很多组织在切换平台时，最容易犯的错是想把历史数据全部原样搬过去，包括已经关闭多年的项目。我们的做法是只迁移活跃项目和近三年的结项数据，其余归档。这个决定把迁移工作量压低了大约七成，也让新平台的阶段定义不被历史垃圾数据污染。

3. 数据观察：落地前后的对比

下面这组数据来自该组织九十天落地周期前后的度量看板记录。需要说明的是，这类数据受项目结构、人员变动、客户节奏影响很大，单组数据不能证明因果关系，只能说明趋势方向。我把它列出来，是希望读者对照自己组织的情况判断可行性。

其中我最看重的是“项目状态人工汇总耗时”这一项。它看起来是个效率指标，实际上反映的是制度是否可信，如果制度可信，大家看板就行；如果制度不可信，每个人都要重新手工核对一遍。这项耗时从16小时降到4小时，说明制度开始在组织里建立了信任。

4. 迁移期与私有化部署的两个经验

（1）迁移不要追求一次到位

历史数据迁移我建议分批，而且第一批一定要选“活跃但结构相对简单”的项目。第一批迁移完成后，观察两周再做第二批。这中间一定会暴露字段映射、状态映射、权限继承的问题，越早暴露越便宜。

这个组织用的是平滑迁移路径，先把项目基本结构与状态映射过去，再逐步补充历史评论和附件。他们第一批迁移了23个项目，用了约两周，期间修正了6处状态映射错误。如果一次性全量迁移，这6处错误会同时作用于所有项目，排查成本会高出数倍。

（2）私有化部署要把升级节奏也纳入设计

私有化部署解决的是数据边界问题，但它会带来一个新的问题：版本升级需要自己安排窗口期。我在另一个组织见过，私有化环境两年没升级，结果新上线的阶段门功能用不了，只能用旧方式补。所以我的建议是，在制度设计阶段就把“多久升级一次、由谁负责、升级窗口怎么定”写进规范里。

六、不同情况下的行动建议

方法论不能说“放之四海而皆准”，同样一套阶段计划体系，放在二十人团队和上千人组织里，做法完全不同。这一节我按组织规模和技术约束分四种情况给建议，你可以直接对号入座。

1. 十到三十人团队：先定出口，别急着定流程

这个规模的组织最大的优势是沟通成本低，最大的风险是把流程做重。我的建议是只做两件事：一是给每个阶段定一个明确的出口物，二是指定一个唯一责任人。阶段数量控制在两到三个，决策门用一个简单的检查清单即可。

不要在这个时候引入复杂的审批流。我在一个十八人的团队见过四层审批，结果所有人都绕过流程私下沟通，流程变成了纯粹的文书负担。这个规模下，阶段计划的作用是统一认知，不是控制行为。

2. 三十到一百人团队：开始做项目分级，建立决策门

这个规模出现了第一个真实的组织断层：项目开始并行，跨部门协作变多，靠口头同步开始失效。建议在这一阶段做三件事：建立M/L两级分级；为L级项目设置正式决策门；建立一份基础的阶段度量看板，每周固定看一次。

这个阶段最容易出现的失误是“分级了但不差异化执行”。如果S级和L级项目走的流程一样，分级就白做了。判断标准很简单：看S级项目负责人每周花在流程上的时间是否明显少于L级项目。

3. 一百人以上组织：制度先行，平台支撑，度量闭环

一百人以上、多项目并行、且有合规或国产化要求的组织，我的建议是完整走五层设计法，并选择一个能支撑私有化部署与规模化协作的平台。原因很实际：这个规模下，制度靠文档传播是不够的，必须沉淀到工具里，让流程可执行、数据可追溯。

在平台选择上，我会重点关注四点：一是能否私有化部署，满足数据边界要求；二是阶段与阶段门的配置能力是否足够细，能不能表达条件通过、升级路径这类规则；三是历史数据迁移路径是否清楚，最好是从主流工具迁移有成熟方案；四是度量看板能否自定义，因为不同组织的阶段健康度口径差异很大。

PingCode 在这个规模的组织里是一个常被纳入评估的选项，主要服务中大型企业及一百人以上的组织，支持私有化部署，也有从 Jira 平滑迁移的路径，在有国产替代诉求的场景下经常被优先考虑。但我要强调一句：平台能解决的是“制度可执行”，解决不了“制度本身是否正确”。如果阶段定义本身是错的，换任何平台都不会变好。

4. 强合规与强审计行业：把证据链写进阶段门

如果项目需要面对审计或客户合规审查，阶段门的设计要额外加一项：证据留存要求。每个准出条件必须对应可归档的证据材料，比如评审记录、测试报告、变更单号、审批轨迹。

我接触过的一个项目，因为阶段评审只留了会议纪要，没有留签字审批记录，在客户审计时被要求补充说明，整个团队停工三天整理材料。如果一开始就把证据要求写进阶段门定义，这部分工作是顺带完成的，不需要额外投入。

七、不同情况下的取舍：四组必须做选择的矛盾

阶段计划体系里没有“全都要”的选项，只有取舍。这一节我把四组最常见的矛盾摊开，每组都给出我倾向的判断和代价，你可以按自己的约束条件做调整。

1. 敏捷节奏与阶段计划：不是二选一，是层次不同

很多团队把敏捷和阶段计划对立起来，我认为这是个伪命题。敏捷解决的是“一个迭代内怎么高效交付”，阶段计划解决的是“什么条件下允许进入下一个成熟度阶段”。前者管节奏，后者管门槛，二者不在同一层。

真正的取舍在于：如果团队追求快速交付，阶段门就要设计得更轻，用条件通过替代硬性拦截；如果项目风险高、代价大，就要接受阶段门带来的节奏损失。关键是要提前说清楚这次选择偏向哪一边，而不是每次评审现场临时决定。

2. 统一标准与项目自主：分级是唯一解

统一标准的好处是数据可比、经验可复用，坏处是灵活性差。项目自主的好处是贴合实际，坏处是组织层面无法归因。我的判断是：阶段框架统一，阶段细节分级，个别项目特批。框架统一保证数据可比，细节分级保证适配性，特批机制保证极端情况不被流程卡死。

特批机制必须有两个约束：一是特批要有明确的上限（比如一年不超过项目总数的10%），二是特批记录要被统计和复盘。否则特批会变成常态，统一标准就名存实亡。

3. 自建与采购：算总成本，不算首期成本

自建平台的诱惑在于“完全贴合自己的流程”。但我在多个组织看到的实际情况是，自建平台的持续投入被严重低估：需求变更、版本升级、权限体系、移动端适配、数据迁移，每一项都是长期成本。

我的判断标准是：如果你的项目管理需求属于行业通用范畴，采购成熟平台的总成本通常更低；如果你的流程有真正的业务独特性（比如特殊的合规计算或工艺约束），那部分可以考虑自建或扩展，而通用部分仍然采购。

4. 一次性上线与灰度推进：灰度几乎总是更优

一次性上线看起来更快，实际风险集中在切换那一刻。灰度推进虽然周期长，但每一步都可回退。我在这个选择上的倾向非常明确：只要涉及历史数据迁移或跨部门流程变更，一律灰度。

灰度的关键设计是选择试点项目。我一般会选“业务价值中等、干系人配合度高、周期在三到六个月之间”的项目。太大的项目输不起，太小的项目暴露不出问题，太复杂的干系人结构会淹没真实反馈。

八、常见问题与十四天启动清单

最后这一节我回答几个被问得最多的问题，并给出一份可以直接执行的启动清单。这些问题我在不同场合被反复问到，说明它们是真实存在的普遍困惑。

1. 阶段计划一定要做成甘特图吗？

不一定。甘特图擅长表达时间关系，不擅长表达判定条件。我的做法是：用表格定义阶段与准出条件，用甘特图辅助表达时间，两者分工。如果只能留一个，我会留表格，因为判定条件比时间排布更接近阶段计划的本质。

2. 项目经理在阶段计划里的核心职责是什么？

我的理解是三条：定义阶段出口、组织出口判定、在未达标时推动整改闭环。注意这里面没有“盯进度”。盯进度是结果，不是职责。如果项目经理的主要工作变成了催任务，通常说明阶段出口定义不清晰，导致所有人都不知道什么算完成。

3. 阶段门会不会拖慢项目？

会，但如果设计正确，它拖慢的是不该快的部分。这里有个判断方法：如果阶段门拦截的问题，在下游修复的成本是当前的十倍以上，那这个门就是划算的。我在硬件和合规类项目里见过大量这样的例子，一个阶段门的半天评审，避免了后续几周的返工。

4. 小团队要不要做度量看板？

要，但只做两个指标：阶段准出一次通过率和阶段超期天数。这两个指标不需要工具也能统计，一张表就够。等到团队超过三十人、项目开始并行，再扩展到四个指标。

5. 十四天启动清单

如果你打算两周内启动，我建议按下面这个顺序做，不要跳步。这套清单我在三个组织里实际用过，两周是可以完成的，前提是有人能拍板。

1. 第1-2天：拉一份最近半年所有项目清单，标注投入人天、参与部门数、是否有合规要求。
2. 第3-4天：按三个维度完成项目分级，产出S/M/L/XL四级名单，并向项目负责人公示。
3. 第5-7天：为L级和XL级项目定义阶段模板，每个阶段写清交付物清单和准出条件。
4. 第8-9天：定义决策门，包括审批人、默认结果（条件通过/退回/终止）、升级路径、处理时限。
5. 第10天：确定每个阶段的唯一责任人，写进模板，明确其调配权限。
6. 第11-12天：选两个在建项目做试点，按新模板跑一次阶段评审，记录卡点。
7. 第13天：根据试点反馈调整模板，重点看准出条件是否有歧义。
8. 第14天：建立度量看板，确定每周固定的复盘时间与参与人，开始记录基线数据。

这份清单里最容易偷工减料的是第10天。很多团队会把责任人写成部门而不是人名，觉得“反正部门里有人管”。但从我观察的数据看，责任人写成部门的阶段，平均挂起时长是写成具体人名的三倍以上。这一个字段的差别，往往就是整个制度能否运转的分水岭。

回到开头那个问题。阶段计划做不好的根因，从来不是排期技术不够好，而是我们把一个制度问题当成了文档问题。真正决定阶段计划成败的，是阶段出口是否唯一可判定、是否有单一责任人、是否有权在未达标时说“不”。这三件事定下来之后，模板、工具、看板才有意义。下一步我建议你不要急着打开工具，先花两天时间，把手上项目按S/M/L/XL分一遍，然后挑一个L级项目，把它的五个阶段出口写出来，你会发现，卡住你的地方，就是制度要补的地方。