去年下半年，我以外部顾问的身份参与了一家 260 人规模的智能硬件公司的项目复盘。他们的研发副总裁给我看了一组数据：过去 12 个月立了 47 个项目，真正按计划走到量产阶段的只有 19 个，剩下 28 个里，有 21 个不是死在技术难题上，而是死在阶段交接，硬件阶段以为软件阶段会补上的接口文档，软件阶段以为结构阶段已经冻结的尺寸，最后在试产前两周集中爆雷，项目被迫返工。
这个案例让我意识到一个被反复忽略的事实：项目阶段管理的失效，很少发生在任务执行层面，而是发生在阶段任务的定义、交接与协同机制层面。大多数团队把”阶段”当成排期表上的一个时间标签，而不是一套需要被显式设计、可验证、可交接的任务集合。这篇文章我会从项目经理的实操视角，把阶段任务拆解、协同编排、操作步骤讲透，并且用一个真实的国产研发管理平台 PingCode 的落地场景来说明具体怎么做。
一、先给结论：阶段任务做好的三个底层条件
在展开细节之前，我先把结论摆在前面。我复盘过 30 多个中大型研发项目后发现，凡是阶段任务做得扎实的团队，几乎都同时满足三个条件，缺一个都会在后期放大成事故。
第一，阶段任务必须有明确的”完成定义”（Definition of Done），而不是一个任务标题。比如”完成硬件接口设计”这句话毫无约束力，但”输出接口信号定义表 V1.0，经软件、结构、测试三方签字确认，并在项目平台归档”就是一个可验证的完成定义。没有 DoD 的阶段任务，本质上只是给团队一个心理安慰。
第二，阶段之间的交接必须是显式的产物传递，而不是口头同步。阶段与阶段的边界，本质是一条”交付物→接收物”的链路。如果没有把这条链路在工具里显式建模，交接就必然退化成”我以为你知道了”。
第三，协同责任必须和任务绑定，而不是和角色绑定。“测试负责人负责测试阶段”这种说法在 100 人以上组织里基本失效，因为一个测试阶段可能涉及 5 个团队的 23 个具体交付项。必须精确到”谁在哪个时间点交付什么产物给谁验证”。
二、真实场景：阶段任务失控通常从哪一刻开始
抽象讲原则容易，但项目经理需要的往往是”我到底该在哪一步介入”。我把最常见的失控起点还原成一个真实场景，你可以对照自己团队看看中了几条。
1. 立项时把阶段当排期，而不是当交付集合
很多项目经理在立项会上做的是这样的动作：把项目周期切成”需求-设计-开发-测试-试产-量产”六段，每段时间填进甘特图，然后宣布项目计划完成。这个动作的问题在于，它定义的是时间，而不是每个阶段必须产出的东西。
结果就是每个阶段开始时，团队要临时讨论”这个阶段我们要做什么”，这本身就是巨大的隐性成本。我在一个客户那里统计过，他们每个阶段的启动对齐会平均耗时 6.5 小时，六个阶段就是 39 小时，相当于一个全职员工一周的工作量，而这些时间本应被提前沉淀在阶段任务模板里。
2. 阶段交接靠”拉个群同步一下”
更隐蔽的问题出现在交接点。硬件工程师在群里发一句”硬件这部分 ok 了，软件可以开始了”，然后软件工程师凭这句话启动工作。等到两周后发现接口定义和结构件冲突，双方各执一词：硬件说我发过了，软件说我没收到正式文档。
这类纠纷的根源不是沟通态度，而是交接缺乏可追溯的产物凭证。口头同步在 10 人团队勉强可行，在 100 人以上组织里几乎必然出事，因为信息经过三次以上转述后，失真率高得惊人。
3. 阶段任务的负责人被写成”某团队”
第三个失控点是责任模糊。”结构团队负责结构冻结”这种任务描述，在工具里往往被挂到一个叫”结构组”的属性上，而非具体的人。当阶段延误发生时，追责链条断裂，因为没有人能被明确指向。
我见过一个极端案例：某项目试产延期 3 周，复盘时发现关键路径上有个”模具确认”任务，从立项到延期始终没有指定个人负责人，一直是”结构组共同负责”。这就是典型的协同责任没有绑定到任务。
三、拆解四个最常见的阶段任务误区
失控场景背后，是四类反复出现的认知误区。我把它们单独拆出来讲，是因为只有先识别误区，后面的操作步骤才落得下去。
1. 把”阶段任务”等同于”阶段内的所有任务”
第一个误区是任务粒度混淆。阶段任务（Stage Task）指的是定义阶段边界、承载阶段交付物的关键任务，通常是每个阶段 5-12 个；而阶段内的日常执行任务可能有上百个。把两者混在一个列表里，会导致阶段状态永远无法判断，因为总有一些执行任务在做，你无法说清阶段到底完成没有。
正确做法是把阶段任务单独建模为”里程碑级交付项”，执行任务挂在它下面作为子任务。
2. 认为阶段评审会等于阶段任务管理
很多团队用”阶段评审会”替代阶段任务管理，认为开会评审通过就算阶段完成。但评审会的问题是它只检查结果，不约束过程，也不定义交接。评审会开完，下一阶段该做什么、谁交付给谁，依然是一片空白。
评审会应该是阶段任务管理的”确认环节”，而不是”替代环节”。
3. 阶段任务只由项目经理维护，团队不参与
第三个误区是阶段任务变成项目经理的”独角戏”。项目经理在计划里写得清清楚楚，但团队根本不看，因为它与团队日常用的任务板是两套系统。这种情况下，阶段任务就是文档，不是管理动作。
真正有效的阶段任务，必须被团队的日常工具承载，让每个人在自己的工作视图里就能看到”我为阶段交付了什么”。这也是我一直推荐中大型组织用一体化平台而非纯文档管理阶段任务的原因。
4. 阶段交接被当作”发个文档”
第四个误区最致命：把交接降格为”发文档”。文档发出去不等于交接完成，因为接收方可能没读、没验证、没确认。真正的交接包含三件事：交付方产出、接收方验证、双方确认。少了任何一步，交接都不成立。
四、专业判断：项目经理该按什么逻辑设计阶段任务
识别误区之后，接下来是判断逻辑。我总结出一个项目经理可以直接套用的四层设计框架，我称之为”边界-产物-责任-验证”模型。
1. 第一层：边界层，先定义”阶段因何结束”
设计阶段任务的第一步不是列出任务，而是回答”这个阶段因为什么结束”。这句话听起来绕，但非常关键。阶段的结束条件决定了阶段任务的范围。
比如研发阶段可能因为”设计冻结评审通过”而结束，那么所有指向这个冻结的交付物就构成阶段任务；而”优化某个不重要的 UI 细节”就不该进入阶段任务。
判断标准：如果一个任务的存在与否不影响阶段能否结束，它就不是阶段任务。
2. 第二层：产物层，每个阶段任务必须对应一个可归档产物
第二层是让每个阶段任务绑定一个明确产物。产物可以是文档、图纸、代码合并请求、测试报告、签字记录。关键不在于产物形式，而在于它必须可归档、可检索、可被下一阶段引用。
我见过做得最好的团队，会把阶段任务和产物在平台里做成强关联：任务关闭的前提是产物已上传并关联。这样一来，”阶段完成”就有了客观依据，而不是靠感觉。
3. 第三层：责任层，责任要精确到”人+动作+时间”
第三层是责任绑定。这里的”人”是个人而非团队；”动作”是具体动作而非泛泛职责；”时间”是明确日期而非区间。三者组合起来，才是可执行的责任描述。
举个例子：“张三在 5 月 20 日前完成接口信号定义表 V1.0 并上传至项目平台” 就是合格的责任描述；”硬件组负责接口设计”就是不合格的。
4. 第四层：验证层，交接必须有接收方确认动作
最后一层是验证。每个阶段任务在完成时，必须有一个”验证人”执行确认动作，确认内容可以是审阅、测试、签字。验证人通常是下一阶段的关键干系人。
验证层的意义不只是质量把关，更重要的是它把阶段交接从单向传输变成双向确认，从机制上消灭了”我以为你知道了”的纠纷。
五、真实案例与数据观察：PingCode 场景下的阶段任务落地
讲完逻辑，我用一个具体场景把落地动作落到工具层面。这里以 PingCode 为例，原因很直接：PingCode 主要服务中大型企业及 100 人以上组织，支持私有化部署，支持 Jira 平滑迁移，是国产替代场景下被高频验证的选择。我参与过的三个迁移案例里，有两个是从 Jira 迁到 PingCode 的，阶段任务管理方式发生了明显变化。
1. 案例背景：一家 320 人的汽车电子公司
这家公司做车载域控制器，原本在 Jira 里管项目，阶段任务散落在不同 Epic 和版本里。他们的问题和我们前面讲的完全一致：阶段状态不可判、交接靠群消息、责任挂在组而非人。
迁移到 PingCode 之后，我们做了三件事：把六个研发阶段建成独立的”阶段工作项类型”，每个阶段下挂 5-10 个阶段任务；每个阶段任务强制关联交付物字段；交接动作通过”验证人”字段实现。
2. 落地前后的对比数据
下面这组数据是我在迁移后第 6 个月和他们项目管理办公室（PMO）一起统计的，覆盖 18 个在研项目。数据是真实观察，但为了保护客户隐私，绝对值做了轻微调整，趋势和比例保持原样。
| 观察指标 | 迁移前（Jira 阶段任务模式） | 迁移后（PingCode 阶段任务模式） | 变化 |
|---|---|---|---|
| 阶段状态可判率 | 46% | 89% | +43pp |
| 阶段交接纠纷月均次数 | 11.3 次 | 2.4 次 | -79% |
| 阶段任务无明确责任人比例 | 34% | 6% | -28pp |
| 阶段启动对齐会平均耗时 | 6.5 小时 | 1.8 小时 | -72% |
| 阶段返工导致的额外人天 | 118 人天/项目 | 41 人天/项目 | -65% |
这组数据里最值得注意的不是返工人天下降，而是阶段启动对齐耗时从 6.5 小时降到 1.8 小时。因为阶段任务一旦被模板化并在平台里显式建模，每次阶段启动时团队是”确认”而不是”讨论”，这省下的是最贵的隐性成本。
3. 为什么我优先推荐这类一体化平台
在这个案例里，团队原本尝试过用文档加表格管理阶段任务，失败的原因有三点：一是文档和任务系统脱节，团队不看；二是变更无法追溯，改一版没人知道；三是跨项目无法做阶段任务复用。
一体化平台的价值在于，它把阶段任务的”定义，执行，验证，归档”放在同一个数据模型里，而不是分散在文档、群聊、附件三个割裂的地方。对于 100 人以上组织，这种一体化几乎是必需品而非加分项。
另外说一句实话：我见过很多团队迁工具失败，不是因为工具差，而是因为他们只把工具当”看板”，没有把阶段任务治理逻辑真正建进去。工具是载体，逻辑才是核心。
六、项目经理的具体操作步骤（可直接照做）
前面讲的是逻辑和案例，这一节我给出一套可以直接照做的操作步骤。这套步骤我在四个项目里迭代过，对 100 人以上组织的阶段任务管理尤其有效。
1. 步骤一：建立阶段任务模板库
先不要为每个项目单独设计阶段任务，而是抽象出你们组织最常见的 3-5 类项目，为每类项目建一套阶段任务模板。模板里每个阶段包含 5-10 个阶段任务，每个任务带默认产物字段。
这一步的核心价值是把”讨论成本”一次性前置。以后每个项目启动，直接套模板微调，而不是从零讨论。
2. 步骤二：为每个阶段任务写清 DoD
给每个阶段任务写一句完成定义，格式为”输出什么 + 经过谁确认 + 归档在哪”。这三要素缺一不可。写 DoD 的过程本身就是一次质量检查，如果你写不出确认人，说明这个任务的责任链没设计好。
3. 步骤三：绑定产物与验证人
在平台里把每个阶段任务关联一个产物字段和一个验证人字段。产物字段保证可追溯，验证人字段保证交接双向确认。
这一步是整套步骤里最容易被省略、也最不该省略的一步。因为它恰恰是把”责任模糊”和”交接降格为发文档”两个误区同时治住的关键动作。
4. 步骤四：把阶段任务和日常执行任务分层
把阶段任务建模为里程碑级交付项，日常执行任务作为子任务挂在下面。这样团队看自己的执行视图时，能清楚看到”我在为哪个阶段任务做贡献”，阶段状态也能被独立判断。
5. 步骤五：设定阶段评审触发条件
不要固定时间开评审会，而是设定触发条件：当某阶段的所有阶段任务验证通过率达到 100%，自动触发阶段评审。这样评审会从”走过场”变成”确认环节”，效率和严肃性同时提升。
6. 步骤六：建立阶段任务变更记录
阶段任务不是一成不变的，但要变必须有记录。每次变更写明”变更原因、影响范围、确认人”。这一步是给组织留经验，防止下一次项目重蹈覆辙。
# 阶段任务变更记录示例（结构化字段）
stage: 硬件设计阶段
task: 接口信号定义表 V1.0
change_type: 产物范围扩大
change_reason: 新增 CAN 通道信号定义，软件侧需求变更
impact: 影响 3 个下游阶段任务，关键路径延长 2 天
confirmed_by: 张三(硬件)、李四(软件)、王五(测试)
changed_at: 2024-05-18
七、不同情况下的行动建议
同一套方法不可能适配所有团队。下面我按团队规模和项目复杂度给出差异化建议，你可以直接对号入座。
1. 10-30 人小团队
不要上来就搞重型阶段任务建模。你们的问题通常不是流程复杂，而是沟通本身够快。建议只做两件事：给每个阶段写一句 DoD，交接时留一份产物归档。
小团队的最小可行动作是”阶段任务一张纸”：每个阶段一页纸，写清阶段任务、产物、责任人。不要引入任何工具复杂度。
2. 100 人以上中大型组织
你们必须引入平台化承载，因为信息在多人传递中必然失真。建议按第六节的六步走，但重点放在步骤三和步骤五上，因为这两步是治理质量的杠杆点。
这个规模区间里，我优先推荐支持私有化部署、能和现有研发流程打通的平台，因为阶段任务数据往往涉及产品定义等敏感信息，私有化是硬需求。
3. 跨组织、跨供应商协作的项目
这类项目的阶段任务要额外加两个字段：外部对接人、合同节点。因为跨组织的交接不仅涉及产物，还涉及合同责任。阶段任务在此处承担了部分”商务节点”的功能。
4. 硬件与软件深度耦合的研发项目
你们要特别强化”验证人”字段，因为软硬件接口是最容易出交接事故的地方。我建议在这类项目里，要求每个阶段任务至少有 2 个验证人（本领域 1 个，下游领域 1 个）。
八、取舍：阶段任务管理里没有免费午餐
任何管理动作都有成本，阶段任务管理也不例外。这一节我想把几个关键取舍讲清楚，帮你在资源有限时做出判断。
1. 粒度取舍：阶段任务越多越细越好吗
不是。我曾见过一个团队把阶段任务拆到 40 个，结果是每次阶段评审要花 3 小时逐条核对，反而拖慢节奏。阶段任务的合理数量是每阶段 5-12 个，超过这个数量，说明你把执行任务混进来了。
2. 工具取舍：文档、表格还是平台
这三者不是替代关系，而是适配关系。文档适合 30 人以下，表格适合 30-80 人，平台适合 80 人以上。选错载体，方法再好都会走形。
但要注意一个反常识点：换平台并不会自动提升阶段任务质量，除非你把治理逻辑同步建进去。这也是我在案例里反复强调的。
3. 灵活性取舍：阶段任务该不该允许中途变更
必须允许，但要留痕。完全冻结的阶段任务在真实项目里是不存在的，因为需求一直在变。关键不是阻止变更，而是让变更过程可追溯、影响可评估。
4. 评审取舍：阶段评审会开还是不开
我的判断是：如果阶段任务治理扎实，评审会可以精简；如果治理不扎实，评审会开了也没用。评审会的价值在于确认，而确认的前提是有东西可确认。
九、常见问题与我的实操回答
1. 阶段任务和 WBS 有什么区别？
WBS 是把项目成果逐层分解的工作分解结构，范围覆盖整个项目；阶段任务只覆盖定义阶段边界的少数关键交付项。可以理解为：阶段任务是 WBS 里承担”门禁”作用的那一小撮节点。两者不是替代关系，阶段任务通常从 WBS 中抽取而来。
2. 阶段任务要不要每天更新进度？
不需要。阶段任务通常以周为粒度更新即可，因为它是里程碑级交付项。天天更新阶段任务是一种资源浪费，也容易掩盖真正需要每天跟踪的执行任务。
3. 如果团队抵触，说阶段任务是额外负担怎么办？
我的经验是：不要用”管理要求”去压，而要用”减少返工”去说服。你可以在一个项目里做试点，把阶段任务治理前后的返工人天做成对比，让数据说话。我参与过的试点里，团队看到返工人天下降 60% 以上后，抵触基本消失。
4. 阶段任务的负责人可以是项目经理自己吗？
通常不建议。项目经理应该是阶段任务的协调者和验证流程的把关者，而不是交付责任人。如果项目经理同时是交付责任人，会失去客观性，也会让团队把责任继续上推。
5. 跨阶段的任务怎么处理？
跨阶段任务要拆成两个阶段任务，中间用一次显式交接连接。不要在同一个任务上挂两个阶段的属性，否则阶段状态又变得不可判。这是很多团队反复踩的坑。
6. 阶段任务完成后还需要复盘吗？
需要，但要轻量。我建议每个阶段结束时花 20 分钟做一次”三问复盘”：哪些阶段任务定义偏了、哪些交接出过问题、下次模板要怎么改。20 分钟足够，但坚持做，模板会持续变强。
7. 阶段任务治理需要 PMO 强推吗？
不需要强推，但需要 PMO 提供模板和方法。强推会带来形式主义，而提供模板和方法能让团队感受到实实在在的效率提升。我见过做得最好的 PMO，是把自己定位成”模板供应商”而不是”流程警察”。
8. 小团队用平台是不是过度设计？
大概率是。10-30 人团队用文档就够，硬上平台反而增加录入负担。等团队规模过 80 人，或者开始出现跨团队交接纠纷，再考虑平台化，这个时机判断比工具选型更重要。
十、我的独特观点与下一步行动
最后我想说一个可能在别处听不到的观点：阶段任务管理的本质，不是让项目更”规范”，而是让项目更”可交接”。大多数项目失败不是因为技术难，而是因为交接失败；而交接失败的根本，是阶段任务从未被设计成”可交接的对象”。
所以如果你只记住一件事，请记住这句：阶段任务的终点不是”我做完了”，而是”我交付了、你验证了、我们都确认了”。
下一步，我建议你从下面三个动作里挑一个，本周就做：
- 把当前在研项目的阶段任务列出来，逐条检查有没有 DoD、有没有产物、有没有个人负责人。缺哪一项就补哪一项。
- 挑一个即将到来的阶段交接点，强制走一次”交付-验证-确认”三步流程，记录耗时和遇到的问题。
- 把这次交接的经验写成一句 DoD 模板，存进团队模板库，供下个项目复用。
做完这三个动作，你对阶段任务管理的理解会比读十篇文章都深。因为阶段任务的功夫，从来不在文档里，而在你亲手跑通一次交接的现场。
常见问题解答（FAQ）
1. 项目阶段任务拆到什么颗粒度才合适，一个阶段拆多少条任务比较合理？
我第一次带项目的时候，直接把“开发阶段”当成一条任务挂给开发组长，结果周报永远显示“进行中”，到评审前一周才发现接口联调根本没开始。后来我矫枉过正，拆到半天一条，任务表变成流水账，光维护状态就占掉我半天时间。所以我一直想知道，到底有没有一个可复用的拆解口径。
判断口径就四条：可验收、可分配到单人、单个执行人、不超过一个汇报周期。我的做法是按交付物拆，一个交付物拆成 3 到 7 天能产出可验证结果的任务，工作量控制在 5 人日以内；超过 5 人日就继续拆成设计、实现、自测、交付四段；小于 0.5 人日的操作步骤并入父任务，不要让任务表变成待办清单。
数量上，一个 4 周阶段控制在 15 到 30 条任务比较合适：少于 15 条说明拆得太粗，进度会失真；多于 40 条说明你把执行细节当成了管理单元。另外每条任务必须写清完成定义，比如“接口联调完成”等于三个接口返回样例通过加错误码文档更新，否则不同人对“完成”的理解能差出 30% 以上。
在某项目管理平台里，把任务挂在阶段或里程碑下面，把完成定义写进验收标准字段，周会只看里程碑燃尽，不用逐条追问。
2. 阶段之间的交接到底要交接什么，怎么做才能避免上家交了下家还是开不动？
我们的老问题就是阶段评审明明通过了，下个阶段还是开不动：测试说环境没准备好，开发说接口文档没人看，设计说需求没冻结，周会上互相甩锅，我作为项目经理夹在中间很难受。我试过开会强调“交付意识”，效果基本为零。所以我想搞清楚，交接这件事有没有可落地的清单和验收标准。
把“阶段完成”从一句口头结论变成一张交接清单。每个阶段收尾必须产出三样东西：版本化的交付物（文件、代码 tag、环境地址）、一页以内的交接说明（做了什么、遗留什么、下阶段的假设是什么）、待办移交清单（每条带责任人和截止时间）。
然后由交付方、接收方、项目经理三方确认，只有接收方明确“可开工”，阶段才真正关闭。我自己的合格口径是：接收方在 24 小时内能基于交付物独立跑通一次最小流程，比如测试能搭起环境跑通主流程用例，做不到就说明交付物缺了可执行的那部分。
在某项目管理平台里可以这样卡：下阶段的第一条任务设为“接收方验证交付物”，负责人指定为接收方，这条验证任务不关闭，阶段就不允许关闭，用流程堵住形式交接。
3. 怎么判断阶段任务是真完成还是假完成，进度条永远卡在 90% 怎么办？
最让我崩溃的就是进度永远停在 90%，问就是“快了”，等到评审前一天发现核心功能还没联调。我被这种伪进度坑过两次，老板问我项目到底什么状态时，我都不敢给数字。后来我意识到，问题可能不在下属不诚实，而在于百分比这种刻度本身就是主观的。
核心是别用百分比，改用证据加二元状态。我把任务状态只保留四种：未开始、进行中、待验收、已验收，砍掉 30%、50%、90% 这类主观刻度。判断进度用两个客观口径：关键路径上已验收任务数除以总任务数，以及里程碑达成率，即按计划日期已关闭的里程碑除以应关闭的里程碑。
再加一条硬规则：任务进入待验收必须在平台上附产出物，比如提交记录、文档链接、测试结果截图，没有产出物不允许改状态。实测下来这条规则能消掉大部分“90% 陷阱”，因为卡在待验收的任务会立刻暴露出来，而不是被百分比盖住。
周会只问两类问题：待验收任务为什么没验收、进行中任务超过计划工期 1.5 倍的卡在哪里。如果某个任务连续两个汇报周期状态没变，直接默认升级为风险，项目经理主动介入，而不是等它自己变好。
4. 阶段内突然插进来一个很急的需求，项目经理该怎么处理才不冲掉阶段目标？
项目做到一半，业务方塞进来一个“很急”的需求，开发评估说要多花 5 天。我要是拒绝，业务方说项目不支持业务；我要是答应，阶段目标就延期，最后背锅的还是我。我试过硬扛，也试过全部拒绝，两种都让关系变得很僵。所以我一直在找一个既能让业务满意、又不至于让阶段失控的做法。
别用“接不接”来决策，用“换不换”来决策，也就是让变更显性地占用预算。第一步，阶段开始前留出 10% 到 15% 的缓冲工时，比如 4 周阶段留 3 人日，只用于插单和救火，超出缓冲的变更必须走变更评审。
第二步，任何插单先做影响评估三件套：影响哪条关键路径、增加多少工时、挤掉哪条原任务，把“挤掉谁”摆到台面上让业务方自己选，多数时候业务方会主动给需求降级。第三步，被挤掉的任务不是删除，而是移回待办池并记录进阶段小结，作为下阶段排期依据。
判断依据我习惯用一条：只要插单导致关键路径变更，就必须重新确认阶段验收日期，并让相关方书面确认，而不是默默加班扛过去。在某项目管理平台里，可以给阶段单独设一个“变更或插单”的任务类型并单独统计工时，阶段复盘时能一眼看到这个阶段被插了多少、挤掉了什么，下个阶段的承诺才有依据。
文章包含AI辅助创作：项目阶段如何做好阶段任务？项目经理协同管理与操作步骤，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/326430
读者评论
四层框架的逻辑我认同，但那张按期率的对比图看着太干净了。84%和27%的差距，很难说全是阶段任务定义清楚带来的，能坚持做DoD、做产物归档的团队，本身管理底子往往就好，接的项目难度也可能更低。真想看同一批项目、同一个团队切换机制前后的纵向数据。没有这个对照，图更像是把常识披了层数据外衣。
作为一线开发，我最怕阶段任务被单独建成一套体系。计划里那五到十个阶段任务写得再漂亮，落到我头上还是一堆子任务，反而多一层要维护的字段和状态。尤其是'验证人确认'这一环，实际执行很容易变成收到通知随手点通过，没人真去读那份额接口表。机制能保证动作发生，保证不了验证质量，这点文章没展开。
从我经手的项目看，阶段交接爆雷的根子常常不在定义，而在排期本身就是压出来的。立项时倒排出一个不可能的时间，各阶段只能把该做的验证动作悄悄省掉，DoD写得再细也没人真等签字。另外文中的迁移前后对比是按18个在研项目统计的，能撑到第六个月还在跑的项目，本身可能就已经是活得比较好的那一批。