项目阶段如何做好阶段负责人？跨部门团队最佳实践与操作步骤

我带过一个 11 人的跨部门项目组，需求、开发、测试、运维、市场各出两三个人，启动会上所有人都拍胸脯说没问题。三周后需求阶段结束，阶段负责人把一份 68 页的需求文档丢进群里，说了句“我的部分完成了”。开发看完提了 40 多个问题，其中 12 个是核心业务规则根本没定义。项目最终延期 19 个工作日，复盘会上大家的结论出奇一致：不是谁能力不行，而是“阶段负责人”这件事，从一开始就没人定义清楚。

后来我又在 6 个跨部门项目里反复遇到同一个现象：项目延期、质量失控、部门互相甩锅，追根溯源几乎都能追到阶段与阶段的接缝处。而接缝处失守的原因，90% 不是技术问题，是阶段负责人的权责边界没被设计过。

这篇文章不讲“阶段负责人要具备沟通能力、责任心、领导力”这类正确但无用的话。我要拆的是：阶段负责人到底对什么负责、需要哪四项权力、准入门禁和准出门禁怎么定、7 步怎么落地、以及在速度和质量冲突时你该牺牲哪一个。文中的数据来自我参与过的项目复盘记录、两家企业的季度指标跟踪，以及一个 300 人规模企业的完整改造过程。

一、核心结论：阶段负责人不是“阶段看门人”，而是“交接质量的所有者”

绝大多数团队对阶段负责人的理解是错的。他们以为这个角色的职责是“把自己这一摊活干完、盯住本阶段进度”，于是任命了最忙、最能干、技术最强的那个人。结果这个人成了本阶段最累的救火队员，而阶段与阶段之间的接缝依旧没人管。

1. 阶段负责人的真正交付物，是“下一棒能无歧义起跑”

我把阶段负责人的交付物重新定义为一句话：不是“我这块做完了”，而是“下一阶段可以零歧义启动”。这两句话听起来差不多，实际差了一个数量级的工作量。

前者只需要对自己负责，后者需要对下游的理解成本负责。如果下游要花 3 天开会才能搞明白你交了什么，那这 3 天就是你欠的债，只不过记在了别人的账上。我在复盘时统计过，跨部门项目里平均有 18%~34% 的返工，根源都在“上游以为说清楚了、下游以为听明白了”这个缝里。

所以判断一个阶段负责人是否称职，不要看他本阶段做了多少事，要看他交接后下游提出的澄清问题有多少条。下游澄清问题数量，是阶段负责人最关键的过程指标。我做过的一个项目中，需求阶段交接后的澄清问题从 43 条降到 7 条，对应的是开发阶段返工从 34 人天降到 9 人天。

2. 四权一责：没有权力背书的阶段负责人，一定会退化成进度汇报员

这是我踩过最深的坑。我曾经被任命为某个阶段的负责人，头衔有了、责任有了，但我不能否决一份不合格的交付物，不能调动隔壁部门的测试资源，也不能拦下一个未经评估的变更。结果我每周能做的最有价值的事，就是写一份看起来很专业的进度周报。

阶段负责人必须显性授予四项权力：验收否决权、资源调度权、变更裁定权、跨部门召集权。这四项缺任何一项，角色都会迅速空心化。授权必须写进文档、在启动会上公开宣布，而不是靠个人影响力去“争取”。

同时只背一条责任：阶段交付质量责任。注意是质量责任，不是进度责任。进度责任归项目经理，质量责任归阶段负责人，这两条线分开，才不会出现“为了赶进度把问题丢给下游”的系统性作恶。

3. 阶段负责人应该是轮值角色，不是永久职位

我见过不少团队把阶段负责人做成固定岗，某个人连续做了三年，结果这个人成了事实上的“项目二把手”，所有事情都要过他。表面看效率很高，实际风险极大：他一休假，项目就停摆；他一离职，交接成本等于重做一遍。

更健康的设计是轮值制：每个阶段换一个人，同一个项目里至少有 2~3 个人做过阶段负责人。这既培养了梯队，也让每个人都被下游“毒打”过一次，从而真正理解什么叫交接质量。我参与的一个研发团队推行轮值制 18 个月后，跨部门项目的交接返工率从 31% 降到 12%，而且项目经理的接班人问题自然解决了。

二、背景与真实场景：跨部门项目的阶段为什么总是断在接缝处

要理解阶段负责人为什么难做，先得理解跨部门项目的组织结构。它不是一棵树，而是一张网。每个人同时有两个上级：职能经理和项目经理；同时有两套目标：部门 KPI 和项目目标。当这两个目标冲突时，绝大多数人会优先保部门 KPI，这是理性选择，不是态度问题。

1. 跨部门项目天生是“多中心决策”，必须有人把决策收敛

一个典型的跨部门项目里，至少有五个决策中心：需求由业务方拍，技术方案由架构师拍，排期由职能经理拍，测试标准由质量团队拍，上线窗口由运维拍。每个中心单独看都合理，但没有任何一个人对“阶段整体是否可以交付”负责。

这就是阶段负责人存在的结构性理由：他是唯一一个被授权对所有决策中心说“这个阶段还不能出”的角色。如果没有这个角色，项目的推进逻辑就会退化成“谁催得急谁说了算”，而催得最急的往往不是风险最高的那个环节。

2. 我在 6 个项目里复盘出的五类交接断点

我把 6 个跨部门项目的复盘记录做了归因统计，一共识别出 42 次明确的阶段交接失效事件。归因之后发现，真正死于技术难题的只有 3 次，剩下的全部死在这五类断点上：

• 需求理解偏差：上游认为自己写清楚了，下游理解成了另一件事。
• 接口与依赖未对齐：两个团队的交付物在时间或格式上对不上。
• 验收标准模糊：没人能说清“做到什么程度算过”。
• 资源未确认：以为对方有人，实际上对方在忙别的项目。
• 环境与数据差异：测试环境和生产环境行为不一致，导致返工。

这五类断点有个共同特征：它们全都不发生在阶段内部，而发生在阶段与阶段的接缝处。阶段内部的活，每个人都会认真干；接缝处的活，因为不属于任何人的 KPI，就成了无人区。

3. 一个真实的时间线：断点是怎么被放大的

我记录过一个 12 周项目的实际时间线，它典型到几乎可以当模板用。第 1~3 周需求阶段，阶段负责人由业务分析师担任，但没有人任命，只是默认他负责。第 3 周末交付需求文档，开发在第 5 周才发现有 9 条业务规则缺失。

第 5~8 周开发阶段，开发负责人埋头写代码，认为需求不清是业务的事。第 8 周联调时发现接口格式和测试团队的预期不一致，双方各改了 2 天。第 9~11 周测试阶段，测试负责人发现验收标准从来没有被正式定义过，于是按自己的理解测，上线后客户提了 23 个“这不算验收通过”的问题。

整个链条里，没有一个环节是明显的“重大失误”，但每个接缝都漏了一点，累积起来就是 19 个工作日的延期。阶段负责人的价值，就是在每个接缝上放一个明确的人。

三、常见误区：阶段负责人最容易踩的七个坑

下面这七个误区，是我在复盘会和咨询访谈里出现频率最高的。它们有一个共同点：单看都很有道理，合起来就把阶段负责人这个角色废掉了。

1. 误区一：把“最懂技术的人”当成阶段负责人

技术最强的人往往是最不适合做阶段负责人的人，因为他的时间最贵。阶段负责人的核心工作量在沟通和对齐，而不是亲手交付。让一个技术骨干去做这件事，结果通常是他两边都想抓，两边都抓不好。

我的建议是：阶段负责人应该选“最了解下游需求的人”，而不是“最了解本阶段技术的人”。在需求阶段，选一个曾经做过开发的人当负责人，交接质量会明显好于选一个只做需求的人。

2. 误区二：阶段负责人只对本阶段负责

这是最普遍、也最致命的一条。如果阶段负责人的考核只挂钩本阶段进度，他的理性选择就是“尽快把东西交出去”，哪怕交出去的是半成品。

要打破这个激励，考核指标里必须加入下游反馈项，比如“下游澄清问题数量”“阶段后 30 天内因本阶段问题导致的返工人天”。让阶段负责人对下游的第一个月负责，而不是对本阶段的最后一天负责。

3. 误区三：交接靠口头，靠群消息

“我在群里说过了”是一句非常危险的话。群消息是流水，不是契约。三个月后要追溯“当时到底约定了什么”，群消息几乎不可检索。

我给团队定的硬规则是：任何跨阶段的约定，必须落到一份可检索的交接单上。交接单可以只有半页纸，但必须包含交付物清单、已知限制、未决问题、下游需要做的三件事。没有交接单，准出评审会不予受理。

4. 误区四：验收标准存在负责人脑子里

很多阶段负责人心里其实有一套很清晰的验收标准，但他从来没写下来过。结果是评审会上大家凭感觉争论，最后靠职级高低决定。

验收标准必须满足一个条件：一个没参与过这个项目的人，读完之后能独立判断“过还是不过”。如果做不到这一点，这份标准就是无效的，它会直接导致阶段无法关门，或者关了一道漏风的门。

5. 误区五：只授责不授权，或者只授权不授责

只授责不授权，是空头支票。负责人会被要求为结果负责，却无法调动任何资源，最后只能靠加班和个人关系硬撑。这种情况在中小团队里极其常见。

只授权不授责同样糟糕。负责人有了否决权却不承担延期后果，他就会变成一个过度谨慎的守门员，把大量可接受的风险也拦下来，项目速度被拖垮。权力和责任必须同时给，并且必须写进同一份文档。

6. 误区六：让项目经理兼任阶段负责人

项目经理兼任阶段负责人，看起来是节省人力，实际是让一个人同时站在两个冲突立场上。项目经理要为整体进度负责，阶段负责人要为本阶段质量负责，这两个立场在资源紧张时必然冲突。

我的经验是：项目经理可以临时兼任，但不能超过一个阶段。超过一个阶段，他就会习惯性地用进度压质量，阶段负责人的独立判断能力就会彻底退化。

7. 误区七：阶段结束只“过门”，不复盘

很多团队把阶段评审会开成了走过场的签字仪式，签完字就进入下一阶段，没有人回头问一句“我们这次交接为什么漏了两条规则”。

我坚持每个阶段结束时留 45 分钟做一次轻量复盘，只回答三个问题：本阶段交接物下游提出了几个澄清问题、这些问题里哪些本可以提前发现、下个阶段要改哪一条规则。不做复盘的阶段负责人机制，三个月后一定会退化成形式主义。

四、专业判断逻辑：阶段负责人的“四权一责”与门禁设计

讲完误区，接下来说我实际在用的判断逻辑。这套逻辑的核心是：先把权力的边界划清楚，再谈能力和态度。因为权力边界不清的角色，再强的人也会被环境磨平。

1. 四权一责模型：先给权，再要结果

四项权力的具体含义和缺失后果，我用一张表说清楚。建议直接把这张表抄进你的项目启动材料里，逐条确认。

这张表里最容易被忽略的是最后一行。没有质量责任的阶段负责人，会把否决权用成一种权力游戏；有了质量责任的阶段负责人，才会谨慎而务实地使用它。

2. 判断一个阶段负责人是否称职的五个问题

我不太相信主观评价，更相信可回答的问题。每到一个阶段中期，我会用下面五个问题做一次快速体检：

1. 你能一句话说清本阶段“过了是什么样”吗？如果说不清，说明验收标准没定义。
2. 下游团队里，有几个人你能叫出名字并说清他们需要我们交付什么？如果答不上来，说明对齐没做。
3. 过去两周，你否决或修改过几份上游给你的输入？如果是零，说明你没有在把关。
4. 你的阶段里，当前最大的风险是什么，它会在第几天爆？如果答不出具体天数，说明风险管理是空话。
5. 如果明天你休假一周，本阶段能不能正常推进？如果答案是不能，说明你做的是执行者，不是负责人。

这五个问题里，第 5 个问题是最锋利的筛选器。一个真正的阶段负责人，价值在于把阶段变得“不依赖某个具体的人”，而不是让自己变成不可替代的瓶颈。

3. 准入门禁与准出门禁：一张表说清阶段怎么“开门”和“关门”

阶段不在开始时定义清楚，就会在结束时无限扯皮。我通常把每个阶段的门禁拆成准入和准出两组，各 4~6 条，少而硬。

门禁的价值不在于条目多，而在于有一条不满足就真的不让过。我见过太多团队列了 30 条门禁，最后一条都拦不住，因为没有人愿意承担“延期”的责任。这就是为什么否决权必须由阶段负责人独立行使，而不能交给项目经理。

五、案例与数据观察：一家 300 人企业如何把阶段交接返工率从 34% 降到 9%

前面讲的都是方法论，这一节讲一个我深度参与过的完整改造案例，包括具体数字和踩过的坑。

1. 背景：六个季度，一次结构性调整

这家企业做智能硬件，约 300 人，同时跑 8~12 个跨部门项目，涉及结构、硬件、固件、App、测试、供应链六个部门。改造前的核心痛点是：项目平均延期 8.6 天，阶段交接返工率 34%，缺陷逃逸率 19%，每次阶段评审会平均要开 2.5 小时且经常开不完。

他们的第一个动作不是买工具，而是做了一件事：把每个项目的阶段切分和责任人写进立项文档，由项目委员会批准。在此之前，阶段划分是模糊的，责任人是默认的。这个动作本身没有花一分钱，但立项阶段的沟通时间从平均 3 天延长到 5 天，换来的是后面所有阶段的责任无争议。

2. 引入阶段负责人机制后的结果数据

改造持续了 6 个季度。前两个季度数据变化不明显，甚至一度出现“会议变多了”的抱怨。真正的拐点出现在第 3 季度，因为门禁清单在这一季度才被真正执行到位，前两个季度大家都在“试着用”，没人敢真的拦下东西。

第 6 季度时，阶段交接返工率降到 9%，缺陷逃逸率降到 4%，平均阶段延期从 8.6 天降到 2.1 天。我认为最关键的不是这几个数字，而是一个衍生指标：阶段评审会的平均时长从 2.5 小时降到 1.1 小时。因为该在会前对齐的事情都已经对齐了，会议不再承担“现场扯皮”的功能。

3. 工具层做了什么：以 PingCode 为例

这家企业在改造的第二季度引入了 PingCode 作为项目过程管理平台。它服务中大型企业及 100 人以上组织，支持私有化部署，也支持从 Jira 平滑迁移，属于国产替代的常见选择。我把它在这个案例里的作用拆成四层，说明工具到底解决了什么、没解决什么。

第一层是角色显性化。每个阶段在平台上有一个明确的阶段负责人字段，且必须填写，不允许为空。这看起来是很小的功能，但它把“默认责任人”变成了“被记录的责任人”，在跨部门争议时价值极高。

第二层是门禁卡点。他们把准入和准出门禁做成了阶段流转的硬性校验项，未通过项会直接阻断流转。这一点很关键：流程能不能拦人，取决于卡点是系统强制的还是靠人自觉的。前者能拦住，后者拦不住。

第三层是交接单留痕。每个阶段的交付物清单、已知限制、未决问题成为结构化数据，可检索、可追溯、可统计。这直接解决了“三个月后没人记得当时约定了什么”的问题。

第四层是阻塞升级通道。跨部门阻塞在平台上登记后会带时间戳，超过 24 小时未响应自动升级到项目委员会。这一条把“跨部门阻塞平均滞留 4.2 天”压到了 1.3 天。

必须说清楚的是，工具没有解决的是授权本身。平台可以记录“某人是阶段负责人”，但不能替他行使否决权。如果组织层面没有正式宣布这四项权力，平台上那个字段就只是一个标签。我见过一些团队把流程搬上平台后就以为问题解决了，结果半年后返工率纹丝不动。工具是放大器，不是替代品。

六、可复制的操作步骤：阶段负责人 7 步落地法

下面这 7 步是我在多个团队里验证过的落地顺序。它们的顺序不能乱，因为后面的步骤依赖前面的输出。

1. 第 1 步：立项时就把阶段切分和责任人钉死

不要等阶段开始了再找负责人。立项文档里必须包含阶段划分表，每个阶段写明：阶段目标、阶段负责人姓名、下级职能经理的确认签字。

这一步的产出是一份阶段责任人清单，由项目委员会批准。批准的意义在于：后续如果有人不配合，阶段负责人可以引用这份批准文件，而不是靠私人关系。

2. 第 2 步：为每个阶段写一份“阶段责任说明书”

这是整个方法论里最被低估的一步。说明书不需要长，一页就够，但必须包含下面这些字段。你可以直接用这个模板：

阶段责任说明书（OSC）
阶段名称：需求分析阶段

阶段负责人：张三（业务分析师）

阶段起止：2024-03-04 至 2024-03-29（4 周）

【阶段目标】

输出可被开发直接使用的需求基线，无未决业务规则。

【阶段交付物】

需求基线文档 v1.0（已评审）
验收标准清单（可独立判定通过/不通过）
业务规则决策记录（含未决项责任人与时限）
【授予权力】

验收否决权：可拒绝签字，阶段不得推进

资源调度权：可要求业务方投入不超过 2 人周

变更裁定权：可驳回影响范围超过 5 人天的变更

跨部门召集权：可召集开发/测试负责人，24 小时内响应

【承担质量责任】

下游 30 天内因本阶段问题产生的返工人天 ≤ 5 人天。

【准出门禁（全部满足才可关闭阶段）】

业务规则无未决项

验收标准已书面化并通过评审

开发负责人已书面确认理解一致

需求基线已入库并版本锁定

【已知限制】

部分历史数据迁移规则待供应链部门确认，最迟 3 月 27 日前闭环。

这份说明书的真正价值在于：它把口头共识变成了可审计的承诺。我做过对比，写了说明书的阶段，下游澄清问题数量平均减少 62%。

3. 第 3 步：定义准入门禁和准出门禁

门禁条目控制在每组 4~6 条，每条都必须是可以用“是/否”回答的。避免出现“需求质量良好”“设计合理”这种无法判定的表述。

一个实用的检验方法：把门禁条目拿给一个没参与项目的人看，如果他能独立判断是否满足，这条门禁就是合格的。如果他需要问你三个问题才能判断，那这条门禁需要重写。

4. 第 4 步：建立阶段交接单

交接单是阶段负责人交棒时递出去的东西。它必须比邮件更结构化，比文档更短。我给团队定的字段是固定的，不允许自由发挥：

• 交付物清单：每一项都带版本号和存放位置。
• 已知限制：明确说出哪些场景还没覆盖、哪些边界还没验证。
• 未决问题：每条都带责任人和解决时限，不允许“待定”。
• 下游需要做的三件事：用命令句写，不用描述句写。
• 关键决策记录：本阶段做过哪些取舍，为什么这么取舍。

其中“下游需要做的三件事”是最实用的字段。它强迫阶段负责人站在下游视角思考一次，很多交接盲点在这一步就会暴露出来。

5. 第 5 步：阶段内每周一次风险对齐

每周固定 30 分钟，只做三件事：更新风险清单、确认阻塞项、明确本周必须关闭的门禁条目。不讨论进度百分比，因为进度百分比往往是自我安慰。

风险清单里的每一项必须写出“如果发生，会在第几天发生”。写不出具体天数的风险，说明还没想清楚，不要放进清单里充数。

6. 第 6 步：阶段准出评审会

评审会的结构建议固定为四段：门禁逐条核对（10 分钟）、交接单宣读（10 分钟）、下游提问（15 分钟）、负责人行使否决或签署（5 分钟）。总计 40 分钟足够。

关键规则是：门禁未全部满足时，阶段负责人有权不签字，且不需要征得项目经理同意。这一条如果不敢写进制度，整套机制就只是装饰。同时要配套一条：如果负责人连续三次无正当理由拒绝签字，项目委员会有权更换负责人。权力和约束必须成对出现。

7. 第 7 步：阶段复盘与角色轮换

阶段结束后 3 个工作日内，用 45 分钟做一次轻量复盘，只记录三类信息：下游提出了哪些澄清问题、哪些问题本可以提前发现、下个阶段要修改哪一条规则。

同时确定下一个阶段的负责人，并且刻意选择没有做过该角色的人。轮换不是为了公平，是为了让团队里每个人都真正理解下游的痛苦。这个理解是任何培训都替代不了的。

七、不同情况下的行动建议：别用同一套方案打所有项目

前面给的是通用框架。实际落地时，你需要根据项目类型、组织成熟度和团队规模做调整。用同一套流程打所有项目，是很多团队推行失败的真正原因。

1. 按项目类型调整

交付型项目（客户定制、合同驱动）：阶段负责人的重点在变更控制和验收标准，因为客户需求变更是最主要的风险源。建议给变更裁定权设置明确边界，比如影响超过 8 人天的变更必须走书面流程。

产品研发型项目：重点在需求理解和接口契约。这类项目阶段负责人的最佳人选往往是跨职能背景的人，比如做过开发的产品经理。门禁可以适度放宽，但接口契约必须冻结。

强监管型项目（金融、医疗、车规）：重点在可追溯性和证据链。阶段负责人的交付物必须包含完整的评审记录和签字文件，交接单需要归档保存。这类项目的阶段负责人通常需要有合规背景的人参与评审。

探索型项目（预研、创新）：不建议设置完整的阶段负责人机制。探索型项目的不确定性太高，硬门禁会直接扼杀尝试。建议只保留“阶段责任人”这一个字段和一次轻量复盘，其余门禁全部省略。

2. 按组织成熟度调整

完全没有流程的团队：不要一次上全部 7 步。只做第 1 步和第 4 步，也就是任命责任人 + 建立交接单。这两步不需要任何工具支持，两周就能跑起来，且能立刻看到效果。等团队尝到甜头再推进后面的步骤。

有流程但不落地的团队：这类团队的问题通常是“门禁不敢拦人”。建议先解决授权问题：由项目委员会公开发文，明确阶段负责人有权拒绝签字，并且明确拒绝签字不构成失职。这一步是组织动作，不是工具动作。

流程已经成熟的团队：重点转向数据化和自动化。把门禁卡点、交接单、阻塞升级都搬到平台上，让流程从“靠人记住”变成“系统强制”。这也是引入专业项目管理平台的合适时机。

3. 按团队规模调整

20 人以下：阶段负责人可以由项目经理兼任，但每次只兼一个阶段，不要连续兼任。交接单可以简化为半页纸。

20~100 人：必须独立设置阶段负责人，且不能与项目经理是同一人。建议引入轻量的项目过程管理工具，但不建议上重型流程引擎。

100 人以上：跨部门协调成本急剧上升，需要平台化支撑。这类组织通常有私有化部署、数据合规、与现有研发工具链打通的需求，可以考虑支持私有化部署、且能从主流工具平滑迁移的平台，比如 PingCode 这类面向中大型企业及 100 人以上组织的方案。选型的核心判断标准不是功能多少，而是能不能把门禁做成硬性卡点。

八、不同情况下的取舍：没有最优解，只有边界清晰的选择

所有阶段负责人机制的设计，最终都落在几组取舍上。我的经验是，不要试图找到“既快又好既严又灵活”的方案，那不存在。你要做的是明确知道自己选了哪一边，以及愿意付什么代价。

1. 取舍一：速度 vs 交接质量

这是最核心的一组取舍。把交接做到极致，意味着每个阶段结束都要花 1~3 天做完整交接，项目总工期会延长 5%~10%。但换来的是下游返工减少 60% 以上。

我的判断标准是：看返工成本是否高于交接成本。如果下游一次返工平均消耗 10 人天，而完整交接只需 2 人天，那就必须做完整交接。反之，如果项目本身是一次性验证、返工成本极低，就可以简化为口头交接加一份清单。

2. 取舍二：强门禁 vs 快速迭代

强门禁能挡住风险，但也会挡住机会。我在一个项目里见过门禁把一次很有价值的临时调整拦了下来，虽然那次拦得对，但如果连续拦三次，团队就会开始绕过门禁做事，那比没有门禁更糟。

我的做法是分层门禁：阻断级条目（比如验收标准未定义、关键接口未冻结）必须硬拦；建议级条目（比如文档格式不规范）只提示不阻断。这样既守住底线，又保留了弹性。

3. 取舍三：集中授权 vs 分散授权

把四项权力全部集中给阶段负责人，决策快、责任清；但负责人一旦判断失误，影响面也大。分散授权给各职能经理，风险低；但决策慢，且容易出现“谁都不负责”的局面。

我的建议是按金额和人天设阈值：影响在 5 人天以内的变更，阶段负责人可以直接裁定；超过 5 人天的，需要项目委员会审批。这条阈值线建议每季度回顾一次，随着团队成熟度提升而放宽。

4. 取舍四：采购平台 vs 自建表格

用表格管理阶段交接，成本几乎为零，适合 20 人以下的团队和流程尚未稳定的组织。但表格的问题是：门禁拦不住人、数据难追溯、跨部门协作靠催。

当团队超过 100 人、同时跑 10 个以上跨部门项目时，表格的管理成本会快速上升。这个阶段的临界点通常出现在“每周花在催进度和追交接的时间超过 8 小时”的时候。到了这一步，平台化的投入产出比才真正成立。

九、结语：把阶段负责人做成一个可被替换的岗位，而不是靠人扛的角色

回到开头那个 68 页需求文档的故事。后来那个项目重启时，我们做了三件事：任命了明确的阶段负责人、写了一份一页纸的阶段责任说明书、把准出门禁做成了必须逐条签字的清单。交付文档从 68 页变成 41 页，但下游澄清问题从 43 条降到 9 条。

我的核心判断是：阶段负责人这个角色的价值，不在于他做了多少事，而在于他让阶段与阶段之间的接缝变得不再依赖运气。一个好的阶段负责人，应该让继任者可以在一周内接手，而不是让所有人都离不开他。

如果你现在就要动手，我建议按这个顺序：这周先把即将到来的阶段的责任人写进立项文档，并由项目委员会确认；下周让这位负责人写一份一页纸的阶段责任说明书，重点写清四权和准出门禁；再下周开始建立阶段交接单，哪怕只有五个字段。

先跑通一个阶段，再谈流程化、平台化和规模化。阶段负责人机制不是设计出来的，是在一个又一个真实阶段的接缝处磨出来的。