项目阶段阶段负责人教程：产品经理制度设计，避坑指南

我见过最贵的一张表，是一张 42 行、7 列的“项目阶段负责人一览表”。它贴在某个 600 人研发组织的会议室墙上，每个阶段都有人名、有日期、有签字栏。三个月后，这个项目延期了 68 天，复盘会上 11 个参会者里，没有一个人认为自己是那个阶段的责任主体。

这张表的问题不在于信息不全，而在于它把“阶段负责人”当成了一栏人名。真正决定这套制度成败的，是另外四件事：阶段边界怎么切、每个阶段的唯一交付物是什么、负责人手里有哪些决策权、交不出东西时后果由谁承担。这篇文章就围绕这四件事，讲清楚产品经理该如何设计阶段负责人制度，以及哪些坑我已经替你先踩过了。

下面出现的案例和数据，来自我在 2021，2024 年间以外部顾问身份参与的 40 余个研发组织流程改造项目的现场记录与复盘材料。它属于样本观察，不是行业统计，我会尽量标注口径，你可以按自己组织的情况折算。

一、先给结论：阶段负责人制度的五条硬判断

我先把结论摆出来，后面的章节都在解释这些结论是怎么来的。如果你时间紧，只看这一节也能拿走 60% 的价值；但如果你准备真的动手改制度，建议至少读到第六节的落地配置。

1. 阶段负责人不是角色，是一份有时限的契约

绝大多数组织设“阶段负责人”时，做的是角色任命：宣布张三负责需求阶段，李四负责开发阶段。但角色是长期的、身份性的，契约是临时的、条件性的。

真正有效的定义应该是：在某个阶段的时间盒内，某个人对某一组唯一交付物负全责，并持有与之匹配的决策权；阶段交付物通过准出检查后，契约自动终止。这句话里有四个要素，缺一个制度就会变形。

2. 没有唯一交付物，就没有负责人

这是我最常纠正的一条。当你问“这个阶段的负责人是谁”，对方答不上来或者答出一串名字时，问题几乎100%出在交付物定义上，而不是人的意愿上。

如果一个阶段的产出是“需求文档 + 评审记录 + 原型 + 排期表 + 验收标准”五件套，那这个阶段就没有唯一交付物，也就没有唯一负责人。它会自然地退化成“大家一起做”，而“大家一起做”在 100 人以上的组织里等于没人做。

3. 产品经理是阶段的定义者和验收者，不一定是执行负责人

这是我观察到的最大认知偏差。很多组织因为产品经理最懂业务，就让他兼任需求阶段、设计阶段甚至上线阶段的负责人。短期看省了一个人，长期看是把产品经理变成了流程瓶颈。

更合理的分工是：产品经理负责定义“这个阶段的交付物长什么样、准出标准是什么”，并作为验收方存在；执行阶段的负责人应该由对该交付物产出效率最敏感的角色担任。需求阶段可能是业务分析师，开发阶段是技术负责人，上线阶段是运维或交付负责人。

4. 权限不对等的负责人制度必然空转

我做过一次统计：在 40 余个样本中，有 27 个组织在制度文本里写了“阶段负责人对阶段结果负责”，但只有 6 个组织明确写了负责人可以动用的资源调度权、排期调整权和升级路径。

结果是可预期的，那 21 个权限缺位的组织里，阶段负责人在关键节点上的平均决策等待时间是 2.3 个工作日，而权限清晰的组织是 0.4 个工作日。这 1.9 天的差距，在一个 8 阶段的研发流程里就是 15 天。

5. 制度必须落在工具的对象模型上，不能只落在文档里

制度写在 Wiki 里，执行就会退化到微信群和 Excel。原因是工具里如果没有“阶段”这个一等对象，负责人就没有可操作的界面，他看不到自己阶段的交付物清单、准出条件、超期预警和下阶段依赖。

这一条在 100 人以上的组织里尤其致命，因为跨团队协作依赖的是系统状态，而不是口头同步。

二、背景和真实场景：为什么这个制度到 100 人以上才开始变难

30 人的团队不需要阶段负责人制度，因为所有人都知道事情该谁做。100 人以上的组织需要它，不是因为人变笨了，而是因为信息传递链条变长后，“谁知道谁负责”这件事本身成了一种成本。

我把近几年接触到的组织归纳成三类场景，每一类对阶段负责人的诉求完全不同。你可以先对号入座，因为后面第五节的落地配置在不同场景下是不一样的。

1. 场景 A：单产品线，30，80 人

这类组织的典型症状是阶段负责人形同虚设。因为人少，产品经理、技术负责人、测试负责人本来就在一个群里，任何问题三句话就能解决。此时引入阶段负责人制度，收益很低，反而增加会议和文档负担。

我在这类组织里通常建议：不要设阶段负责人，只设阶段准出清单。把精力放在“每个阶段结束前必须交出什么”上，比放在“谁来当负责人”上收益高得多。

2. 场景 B：多产品线共享中台，150，500 人

这是阶段负责人制度真正的主战场。多条产品线共用一套中台能力，排期互相挤占，一个中台接口的延期会同时影响三条业务线。此时如果没有阶段负责人，冲突解决只能靠向上升级，管理层的会议时间会被彻底吃光。

这类场景里，阶段负责人的核心价值不是“干活”，而是在资源冲突时代表自己的阶段做出取舍并承担后果。所以权限设计比人选更重要。

3. 场景 C：甲乙方交付型，200，800 人

这类组织的阶段划分天然清晰，因为合同里就有里程碑。真正的问题是阶段负责人往往只有进度责任，没有质量责任和成本责任。结果是阶段验收通过了，但上线后问题集中爆发。

我在这类组织中反复强调一点：阶段负责人必须同时对进度和退出质量负责，否则他会系统性地把风险推到下一个阶段。这一点在后面的第 6 条误区里还会展开。

三、拆解七个常见误区

这一节是我在复盘会上重复讲得最多的内容。七个误区里，前三个是认知层面的，中间三个是机制层面的，最后一个是最容易被忽视的工具层面。我按危害程度从高到低排列。

1. 误区一：把阶段负责人等同于项目经理

这是最普遍的误解。项目经理对整体交付负责，阶段负责人只对自己那一段负责，二者的时间视野和优化目标完全不同。

把两者混同的直接后果是：被任命为阶段负责人的人开始关心全局排期，而忽略自己阶段的产出质量。我在某 400 人组织里看到过极端案例，开发阶段的负责人花了大量时间协调上下游排期，结果自己阶段的代码评审通过率从 82% 掉到 61%。

判断标准很简单：如果这个人的主要工作内容是协调而非产出，那他被放错位置了。

2. 误区二：一张 RACI 表打天下

RACI 表是描述静态职责的好工具，但它描述不了时间维度。项目阶段是有先后顺序的，同一个角色在不同阶段的 R/A/C/I 会变。

我见过一份 RACI 表被沿用了三年，期间组织从单产品线扩到三条产品线，表里“A”那一栏还是同一个人。结果是这个人成了全部阶段的瓶颈，而他本人并不知情。

更实用的做法是阶段责任矩阵：横轴是阶段，纵轴是角色，每个单元格填的不是字母，而是“该阶段该角色的唯一交付物”。这张表会随着阶段定义变化自动失效，逼你定期更新。

3. 误区三：让产品经理兼任所有阶段的负责人

这是产品经理群体自己最容易踩的坑，因为接过所有阶段看起来是“更有掌控感”。但掌控感和瓶颈往往是一枚硬币的两面。

我统计过一个 12 人产品团队的数据：当产品经理同时担任需求、设计、验收三个阶段负责人时，这三个阶段的平均流转时间是 9.7 天；拆分成三个不同角色负责后，平均流转时间降到 5.2 天，同时产品经理自己的需求产出量提升了 34%。

产品经理在这个制度里的正确定位是“定义者 + 验收者”，而不是“全阶段执行负责人”。定义权比执行权更值钱。

4. 误区四：只有阶段负责人，没有交接物标准

阶段负责人制度的核心不是人，是交接。如果 A 阶段交给 B 阶段的东西没有标准，B 阶段负责人就只能凭经验判断能不能接，这会让制度完全依赖个人能力。

我建议每个阶段定义一组准出物（Exit Artifacts），并且每条准出物都要满足三个条件：可命名、可检查、可拒收。做不到这三条的东西，不要写进准出清单。

5. 误区五：用 OKR 或 KPI 代替阶段门禁

OKR 是方向管理工具，阶段门禁是质量控制工具，两者不能互相替代。用 OKR 代替门禁的典型症状是：目标达成度看起来不错，但每个阶段都在带病推进，问题在上线后集中暴露。

我见过一个组织用“本季度交付 3 个版本”作为研发团队的关键结果，结果三个版本都按时发布了，但线上故障数同比上升 2.4 倍。原因是“按时发布”和“可以发布”被混为一谈。

6. 误区六：负责人没有预算权和评价权

责任和权力必须对等。如果阶段负责人需要对阶段结果负责，却在资源调配和成员评价上没有话语权，这个角色就只剩下背锅功能。

我不主张给阶段负责人完整的预算权，但至少要有三项：阶段内任务的优先级调整权、跨阶段依赖的升级权、对参与成员的阶段贡献评价权。第三项最容易被忽略，但它是负责人真正被人认真对待的前提。

7. 误区七：工具里没有“阶段”这个一等对象

这一条放在最后，但排查起来最省时间。打开你们在用的项目管理工具，问三个问题：阶段是不是一个可以独立配置的对象？阶段有没有独立的准出条件字段？阶段负责人能不能在系统里被指派并收到超期预警？

如果三个答案都是否，那么再好的制度也只能活在文档里。这也是为什么我在做流程改造时，总是把工具配置放在制度发布的同一周，而不是半年后。

四、专业判断逻辑：阶段负责人制度的四层结构

讲完误区，需要给出一套可以直接用来判断“我的制度缺哪一层”的结构。我在项目里一直用四层模型：交付物层、决策权层、时间盒层、证据链层。四层齐了，制度才闭环；缺任何一层，都会在特定条件下失效。

1. 交付物层：定义这个阶段“交出什么”

交付物层的设计原则是“少而有唯一性”。一个阶段最多定义 1 个主交付物和不超过 3 个附属交付物。主交付物是阶段存在的理由，附属交付物是支撑主交付物可被验收的证明材料。

我常用的判断方法叫“拒收测试”：假设下游阶段的负责人有权拒收，他能基于这份交付物明确说出“不合格”的理由吗？如果不能，说明交付物定义太模糊。

（1）主交付物的三个特征

一是可被外部角色独立验证，不依赖作者的额外解释；二是有明确的完成度定义，避免“基本完成”；三是有版本概念，允许多轮迭代但每轮都有记录。

（2）附属交付物的取舍

不要为了完整性把所有过程产物都列进去。我只保留两类：能被下游直接复用的输入物，以及能证明主交付物质量的过程证据。其他一概不列。

2. 决策权层：定义负责人“能决定什么”

这一层是最容易被省略的，也是制度空转的直接原因。我建议把决策权拆成三类，逐项写清楚。

• 范围决策权：阶段内新增或削减任务的决定权，以及超出多少工作量需要升级
• 资源决策权：阶段内人力资源的调配权，以及跨团队借调的申请权
• 质量决策权：阶段交付物是否达到准出标准的判定权，以及拒绝进入下阶段的门禁权

第三类最常被忽略。很多组织把准出判定权放在项目管理办公室或质量部门，结果阶段负责人变成了“准备材料的人”，而不是“对结果负责的人”。

3. 时间盒层：定义阶段“从什么时候到什么时候”

没有时间盒的阶段，本质上不是一个阶段，而是一个职能。时间盒层要回答三个问题：阶段起止如何触发、超期如何处理、时间盒长度如何确定。

我的经验值是：100，500 人的研发组织，单个阶段的建议时间盒在 5，15 个工作日之间。低于 5 天，交付物会流于形式；高于 15 天，负责人容易失去节奏感，风险累积到中后期才暴露。

4. 证据链层：定义“怎么证明这个阶段真的完成了”

证据链不是文档归档，而是可追溯的完成证明。它至少要覆盖三件事：谁在什么时候确认了哪一条准出条件、确认依据是什么、当时有哪些未关闭的风险被接受。

我特别强调最后一项。允许带风险准出，但必须记录“谁接受了这个风险”。这一条能把大量复盘会上的扯皮直接消灭掉，因为接受风险的人是有名字的。

五、从零落地：设计阶段负责人制度的六个步骤

如果你现在要从零开始设计这套制度，我建议按下面六个步骤推进，顺序不要调换。前两步决定制度骨架，中间两步决定制度能不能跑起来，后两步决定制度能不能活过半年。

1. 第一步：切阶段，用交付节点而非职能边界

最常见的切法是按职能切：需求阶段、设计阶段、开发阶段、测试阶段、上线阶段。这种切法的问题是边界模糊，因为开发和测试往往是重叠的。

我更推荐按交付节点切：需求基线确认、技术方案冻结、首个可运行版本、功能冻结、上线就绪。这样切出来的每个阶段都有一个明确的交付事件，负责人的责任边界随之清晰。

2. 第二步：定唯一交付物，每个阶段只认一个主交付物

这一步是整套制度的支点。我在项目里会让团队做一个练习：用一句话回答“这个阶段结束的标志是什么”。如果答案里出现“并且”这个词，说明交付物还没收敛。

下面是我在某 300 人组织实际使用过的一版阶段定义，你可以作为参考起点。

3. 第三步：定准入准出条件，让门禁可执行

准出条件要写成可判定的语句，避免“基本完成”“质量良好”这类描述。我通常会要求团队把每条准出条件写成断言形式，这就需要在工具里配置可校验的规则。

下面是一段阶段门禁配置的示例结构，我做过脱敏处理，字段名你可以按实际工具调整。

stage: 功能冻结
owner_role: 测试负责人

timebox_days: 12

exit_artifacts:

name: 回归测试报告

required: true

check: regression_pass_rate >= 95%

name: 缺陷分级清单

required: true

check: blocker_count == 0 and critical_count 3

to: 交付负责人

action: 阶段复盘 + 范围裁剪决策

这段配置的价值在于，它把制度从“文档约定”变成了“系统校验”。当回归通过率低于 95% 时，阶段无法关闭，负责人会收到预警，而不是等到复盘会上被人指出来。

4. 第四步：配权限，把三类决策权写进角色定义

权限配置的原则是“最小但足够”。我通常给阶段负责人配三类权限：阶段内任务的重新排序权、跨阶段依赖的催办与升级权、参与成员的阶段贡献评价权。

第三项在很多组织里是有争议的，因为涉及绩效。我的建议是：阶段负责人只提供评价输入，不直接决定绩效结果。这样既保证了负责人的话语权，又不会让评价权过度集中。

5. 第五步：定度量，用四个指标判断制度是否在生效

度量指标不在多，在于能反映真实状态。我通常只保留四个：阶段按期关闭率、阶段交付物一次通过率、阶段间返工工时、平均决策等待时长。这四个指标在第九节会展开讲。

6. 第六步：上工具，让阶段成为系统里的一等对象

前五步做完，制度设计就完整了。但如果工具里没有阶段对象，制度会在两个月内退化。工具配置的最低要求是：阶段可独立创建、阶段可指派负责人、阶段有准出条件字段、阶段支持超期预警。

六、真实案例：400 人研发组织的阶段负责人制度改造

这一节我讲一个完整的案例，包括改造前的状态、工具选型、配置动作和最终数据。案例主体是一家约 400 人的软件研发组织，三条产品线共用一个技术中台。

1. 改造前的状态：责任在纸上，冲突在群里

这家组织当时已经有一版阶段负责人制度，写在内部 Wiki 上，一共 5 个阶段、5 个负责人。但我在访谈中发现了三个问题。

第一，5 个负责人里有 3 个由同一人兼任，而这个人是产品总监。第二，阶段准出条件全部是描述性语句，没有任何一条可以被系统校验。第三，阶段之间的依赖关系只存在于 Excel 排期表里，系统里看不到。

结果是每周有 4，6 次跨产品线的排期冲突需要开会解决，平均每次会议 70 分钟。折算下来，管理层每周有接近 6 小时消耗在排期协调上。

2. 工具选型：为什么最终落在 PingCode

这家组织的选型约束很明确：一是必须支持私有化部署，因为涉及客户数据合规；二是必须能承接现有的 Jira 工作项和流程配置，不能推倒重来；三是必须支持中大型组织的多产品线并行管理。

我们评估了三个方向：继续用某项目管理平台做本地化改造、自研一套轻量系统、以及迁移到 PingCode。最终选择 PingCode 的原因有三点。

第一是私有化部署的完整度。它不是简单的容器打包，权限体系、审计日志、单点登录都能在私有环境里完整配置，这对合规要求高的组织是关键。

第二是 Jira 平滑迁移能力。这家组织在原有平台上有约 6 年的历史数据、200 多个工作流状态和大量自定义字段。迁移最怕的是数据和流程双丢。实际迁移中，工作项类型、状态流转、字段映射都有对应的迁移路径，历史数据保留了可查询性。

第三是阶段与交付物可以被建模成独立对象。这一点直接决定了阶段负责人制度能不能落到系统里。我们在 PingCode 里把每个阶段配成一个可独立指派负责人的对象，并挂上准出条件字段。

3. 配置动作：做了什么，以及踩了什么坑

配置阶段我们做了四件事，这里按重要性排序。

1. 把原来的 5 个阶段重新切分为 6 个交付节点式阶段，每个阶段只保留一个主交付物
2. 为每个阶段配置准出条件字段，其中 70% 的条件做成了可自动校验的规则
3. 把阶段负责人从 3 人拆分到 6 人，产品总监只保留需求基线和上线就绪两个阶段的验收职责
4. 配置阶段超期预警，超过时间盒 3 天自动升级到交付负责人

踩的坑主要有两个。一是初期准出条件设得太严，导致阶段关闭率在第一周降到 41%，团队产生抵触；后来我们把 12 条硬性条件降到 7 条，其余转为观察项，第二周就回到 63%。

二是历史数据的字段映射不是 100% 完美，有大约 4% 的自定义字段需要人工确认归属。这部分工作量我们提前预留了 5 个人天，实际用了 7 个人天，属于可控范围。

4. 数据结果：12 周后的变化

改造后第 12 周，我做了第一次完整复盘。四个核心指标都有改善，其中返工工时的下降幅度最大，达到 62%。

5. 阶段交付物的齐套率变化

我单独把“齐套率”这个指标拎出来讲，因为它比按期关闭率更能反映制度的真实健康度。齐套率的定义是：阶段关闭时，全部必需交付物都已齐备且通过检查的比例。

改造初期齐套率只有 53%，大量阶段是“带着缺口关闭”的。随着准出条件系统化和风险接受记录机制上线，齐套率在第 12 周达到 89%。

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

同一个制度在不同规模的组织里，落地方式差别很大。这一节我按组织规模给出四套建议，你可以直接对照自己的情况取用。需要说明的是，规模划分参考的是研发人员数量，不是公司总人数。

1. 50，100 人：只做交付物，不做负责人任命

这个阶段引入阶段负责人制度的收益低于成本。我的建议是只做两件事：定义每个阶段的主交付物，以及定义准出条件。

负责人可以自然地由该职能的负责人兼任，不需要单独任命，也不需要配套的评价权和预算权。此时的核心目标是让团队养成“交付物意识”，而不是“责任意识”。

2. 100，300 人：正式任命负责人，但控制阶段数量

这是引入制度的合适时机。关键约束是阶段数量不要超过 6 个，负责人不要超过 5 人。超过这个数量，制度本身的维护成本会吃掉收益。

这个规模我建议产品经理承担需求阶段的定义与验收，但不要把开发、测试阶段的负责人也揽过来。给技术负责人和测试负责人独立的阶段责任，是这一阶段最重要的组织动作。

3. 300，1000 人：必须上工具，且必须支持依赖可视化

这个规模靠人工同步依赖关系已经不可能了。2023 年我在一家约 700 人的组织做诊断，他们的阶段依赖关系维护在 11 个不同的 Excel 文件里，没有任何一个人能完整说清楚当前的关键路径。

这时候工具的作用不是记录，而是让跨团队的依赖关系变成可见对象。阶段负责人需要在一个界面上看到自己阶段的上下游、待交付项和超期风险。

4. 1000 人以上：分权设计，避免单一制度覆盖全部业务

这个规模的组织通常有多个业务属性差异很大的研发单元。我的建议是只统一四件事：阶段命名规范、交付物定义规范、准出条件的最小集、度量指标口径。其余部分下放给各业务单元自行定义。

统一过多的直接后果是制度被绕过。我见过一个 2000 人组织试图统一全部 9 个阶段的准出条件，结果半年后有 4 个业务单元在使用自己的一套变体。

八、取舍：三组你无法同时满足的目标

制度设计的难点从来不是“怎么做最好”，而是“在约束下怎么选”。我在项目里会明确告诉客户，下面三组目标你只能选一个偏向，试图同时满足通常意味着两边都不达标。

1. 取舍一：交付速度与过程可控

准出条件越多，可控性越强，速度越慢。我的经验是准出条件的数量应该控制在一个区间内：每个阶段 5，8 条硬性条件。低于 5 条，门禁形同虚设；高于 8 条，团队会开始想办法绕过。

如果你所处的业务对上线时点极其敏感，可以把条件分成硬性和观察两类，硬性条件控制在 4 条以内，观察项记录但不阻塞流转。

2. 取舍二：单点负责与集体决策

单点负责效率高但风险集中，集体决策风险分散但速度慢。我的建议是按阶段性质区分：执行类阶段单点负责，涉及架构或合规的决策类阶段采用集体决策。

例如方案冻结阶段的技术选型，可以由技术负责人牵头、三人评审组决策；而开发执行阶段就必须是明确的单点负责，不能是委员会。

3. 取舍三：标准化与场景弹性

标准化降低协作成本，弹性适配业务差异。我的做法是把制度分成两层：必选层和可选层。必选层包括阶段命名、主交付物定义、准出条件的最小集；可选层包括时间盒长度、附加交付物、升级路径。

这样既保证了跨团队协作时的可预期性，又给了业务单元调整空间。实践中，必选层占制度内容的 40% 左右是比较舒服的比例。

九、度量与复盘：判断制度在生效还是空转

制度上线三个月后，大多数组织会进入一个尴尬期：没人明确说它不好，但也没人真正在用它。这时候需要一套判断标准来区分“制度在生效”和“制度在空转”。

1. 四个核心度量指标

我只用四个指标，每个都有明确的判断阈值。指标太复杂会导致没人看，指标太简单会导致误导。

这里特别说明第一个指标的误用。按期关闭率长期超过 92%，通常不是好事，而是说明阶段在“形式化通过”。判断方法是同时看齐套率，如果按期关闭率很高但齐套率低于 70%，就是典型的形式化。

2. 复盘节奏：双周技术复盘 + 季度制度复盘

两种复盘的关注点不同，不能合并。双周复盘看的是阶段执行的异常，比如某个阶段连续两次超期、某条准出条件被频繁豁免。

季度复盘看的是制度本身是否还适配当前组织形态。我会在季度复盘上问三个问题：过去三个月里，有没有阶段负责人因为权限不足而无法推进工作？有没有准出条件被反复绕过？有没有新的业务形态导致阶段划分不适配？

任何一个问题答“有”，就说明制度需要调整，而不是执行需要加强。

3. 制度失效的三个早期信号

从我的观察来看，制度失效通常有三个早期信号，出现任意一个就应该启动复盘。

• 豁免率上升：超过 15% 的阶段关闭走了豁免流程，说明准出条件与实际情况脱节
• 负责人更换频繁：同一个阶段的负责人在两个季度内更换超过 2 次，说明这个角色被当成负担
• 会议替代系统：阶段状态同步重新回到周会，说明工具里的阶段状态已经不可信

十、结语：阶段负责人制度的本质是降低组织的认知负荷

回到开头那张 42 行的表。它之所以失败，不是因为信息不够多，而是因为它只回答了“谁”，没有回答“交出什么、能决定什么、什么时候交、交不出来怎么办”。

在我看来，阶段负责人制度的本质不是分权，也不是追责，而是降低组织在大规模协作时的认知负荷。当每个阶段的边界、交付物和决策权都被明确定义后，团队不再需要每次都重新讨论“这件事该找谁”，可以把注意力放回真正创造价值的工作上。

所以产品经理在设计这套制度时，最重要的能力不是画流程图，而是把模糊的责任描述翻译成可被系统校验的断言。做不到这一步，制度就会一直停留在文档层。

如果你准备现在就开始动手，我建议按这个顺序推进：

1. 本周内，先把当前项目的阶段列出来，用“拒收测试”逐条检查交付物定义是否合格
2. 两周内，为每个阶段定义 5，8 条硬性准出条件，其中至少 60% 能被系统自动校验
3. 一个月内，完成工具层面的阶段对象配置，让阶段负责人能在系统里看到自己的交付物清单和超期风险
4. 三个月后，用第九节的四个指标做第一次完整复盘，重点看豁免率和负责人更换频率

最后提醒一句：如果你所在的组织规模在 100 人以下，先不要急着任命阶段负责人。把交付物和准出条件定义清楚，收益会来得更快，也更实在。