项目阶段如何做好阶段负责人？项目经理落地方案与操作步骤

我复盘过近三年经手的 41 个项目，其中 27 个出现过程度不一的阶段延期。真正因为技术难题卡死的只有 4 个，剩下 23 个的根因都指向同一件事：阶段交界处没有人真正对结果负责。项目经理把阶段任务拆得很细，里程碑排得很漂亮，可一旦进入某个阶段，整个项目就变成”我推一下、大家动一下”的状态。这篇文章我想回答一个非常具体的问题：项目阶段里，怎么把”阶段负责人”这件事做对、做实、做成一套可复制的动作。

先给一个我自己踩过的坑。2019 年我负责一个 11 人月的交付项目，需求阶段由产品经理牵头，开发阶段由开发组长牵头，测试阶段由测试主管牵头。听起来权责清晰，结果在需求转开发那一周，三方各说各话：产品认为需求文档签完字就算交接完，开发认为接口细节没对齐根本没法开工，测试认为自己还没进场不该背锅。项目最终延期 19 天。

那次之后我意识到一个很朴素但很少被写进方法论的事实：阶段负责人不是”阶段里资历最高的人”，而是”这个阶段结束时，唯一需要站出来解释结果的人”。谁来解释结果，谁就该被提前授权、提前喂信息、提前绑定激励。这也是本文要展开的全部逻辑。

一、先给结论：阶段负责人是项目里最小的”可授权单元”

在展开操作步骤之前，我先把三条核心结论摆出来。这三条是我从 41 个项目、上百次阶段交接里提炼的，不是从教科书上抄的。你可以不同意，但建议先看完再判断。

1. 结论一：阶段负责人是”阶段交付物的唯一责任人”，不是协调员

绝大多数项目经理在指定阶段负责人时，默认的潜台词是”帮我盯着这个阶段”。这是一个致命的降级。协调员对过程负责，责任人对结果负责。

差别体现在哪？协调员会说”我把问题反馈上去了”；责任人会说”这个阶段的交付物我保证在 X 日达到 Y 标准，做不到我提前 3 天告诉你，并给出备选方案”。前者把风险转嫁给项目经理，后者把风险消化在自己这里。

所以我给阶段负责人的定义是一句话：对某个阶段的交付物、进度偏差和风险升级负有第一解释责任的人。注意是”第一解释责任”，不是”唯一执行人”。他可以不动手，但他必须解释清楚为什么是这个结果，以及下一步怎么办。

2. 结论二：阶段负责人的有效性，大约七成取决于授权，三成取决于能力

这个比例不是精确统计，是我自己在复盘时会做的一个粗略归因。23 个失败案例里，我能明确识别出”人挑错了”的只有 6 个，剩下 17 个都是”人挑对了，但没给权、没给信息、没给激励”。

换句话说，项目经理最常犯的错误不是选错人，而是选对了人之后什么都没给。让一个开发组长当阶段负责人，却不给他跨组调人的权力；让一个测试主管负责质量门禁，却不让他看到上游需求变更记录，这种情况下，换谁来都做不好。

3. 结论三：阶段负责人要在阶段启动前 3 到 5 天指定，不是开始后

很多团队的做法是”阶段开始了，看谁有空谁上”。这是典型的被动指定。我的经验值是提前 3 到 5 天，理由有三点：

• 预留信息接收时间：阶段负责人需要提前阅读上游交付物、参与上游评审，而不是等交接单甩过来。
• 预留资源协商时间：跨部门借人、申请环境、协调外部依赖，这些事在阶段开始当天做，至少浪费 2 到 3 天。
• 预留心理承诺时间：人在被正式告知”这个阶段你负责”之后，需要一个消化过程，才能从”我配合”切换到”我负责”。

提前 5 天以上也不是好事。太早指定，人还没从上一个阶段抽身，容易两头挂着，反而两头都做不好。3 到 5 天是我试过比较舒服的窗口。

4. 阶段负责人、项目经理、技术负责人的边界到底在哪

这三个角色经常被混为一谈，尤其在中小团队。我用一张表把边界拆清楚，你可以直接拿去在启动会上对齐。

这张表里最关键的一行是”结果解释”。当阶段出问题时，第一个被问的人应该是阶段负责人，而不是项目经理。如果反过来，说明阶段负责制根本没建立起来。

二、真实场景：阶段交界处到底在掉什么链子

要解决问题，得先看清楚问题长什么样。我把这三年的观察浓缩成几个典型现场，你可以对照自己的项目看看中了几个。

1. 三种最常见的”掉链子”现场

现场一：交接单签字了，理解没有对齐。上游把文档一交，下游签个字，双方都认为完成了交接。但下游实际上没读懂关键约束，等真正动手时才发现缺一个接口定义。

现场二：阶段负责人是”挂名”，实际决策还在项目经理手里。名义上指定了负责人，但每次排期调整、每次优先级变更，大家还是来找项目经理拍板。阶段负责人逐渐变成会议纪要的记录者。

现场三：阶段间的质量门禁形同虚设。明明定义了”单元测试覆盖率不低于 70% 才能进入测试阶段”，但为了赶进度，先放行再说。结果测试阶段变成第二个开发阶段，负责人的权威被彻底击穿。

这三种现场有一个共同结构：责任被分配给了一个没有能力、没有权力、也没有信息去履行它的人。这是一个典型的组织设计问题，靠喊口号解决不了。

2. 一次延期 19 天的完整复盘

我被问过最多的问题是：”阶段负责人制度听起来很对，但落地之后好像没什么变化。”问题往往不在制度，而在制度被建立成了形式。

回到前面提到的那个延期 19 天的项目，我把 19 天拆开做过归因：需求交接不清导致开发返工 6 天，环境准备延迟 4 天，接口联调时发现双方对数据格式理解不一致 5 天，测试阶段回归量大爆发 3 天，剩下 1 天是等待决策。

真正值得注意的不是这 19 天，而是其中 15 天本可以在阶段内被负责人消化。返工 6 天如果在开发阶段初期被发现，成本可能只有 1 到 2 天；环境准备如果阶段负责人提前 3 天启动，完全可以不占关键路径。

3. 一个数据观察：阶段负责人是否明确，结果差异有多大

我从归档项目里挑出 18 个规模相近、业务复杂度相近的项目做了对比。其中 8 个在阶段启动前就明确了阶段负责人并出具了书面授权，另外 10 个是”边跑边定”或”名义指定”。

结果差异比我预想的更明显。明确授权的 8 个项目，阶段按时完成率是 82%，平均阶段延期 1.8 天；另外 10 个项目，按时完成率只有 47%，平均延期 6.3 天。这个样本量不足以支撑严谨结论，但方向足够清晰到值得你做出管理动作。

三、拆解六个常见误区

在做阶段负责人这件事上，我看到的问题高度重复。下面六个误区，几乎每个团队都会踩两到三个。

1. 误区一：把阶段负责人当成传声筒

最典型的表述是”你帮我盯着点”。这句话一出口，阶段负责人就降级成了信息中转站。他会把团队的问题收集上来交给你，再把你决策传下去。

正确做法是反过来：给他一个可以在阶段内自行决策的边界，边界内的事不要报给你。比如”阶段内任务顺序调整、3 人天以内的工时再分配、非关键路径的资源借用，你自己定，不用报我”。边界越具体，他越敢拍板。

2. 误区二：只加责任不加权限

我见过最离谱的一次，是让一个测试主管负责质量阶段，但这个人在组织架构上不管理任何开发人员。质量阶段需要推动开发修缺陷，他没有考核权、没有人事权、甚至连优先级都排不动。

这种情况下的阶段负责人是”背锅位”。要么给他权限，要么把质量阶段的负责人换成有权限的人。责任和权力必须挂在同一个人身上，这是组织设计的基本约束。

3. 误区三：阶段负责人等于技术最强的人

很多项目经理下意识会选技术最强的人当阶段负责人，因为”他懂，出问题能兜住”。但阶段负责人需要的是另一种能力组合。

技术强的人往往倾向于自己动手解决问题，而不是推动别人解决。当一个阶段有 8 个人的时候，他一个人再强也顶不了 8 个人的产出。这个阶段真正需要的是能够把问题分派出去、把风险提前挖出来、把跨方协调推下去的人。技术深度是加分项，不是决定项。

4. 误区四：用会议代替授权

“我每周开一次阶段对齐会，不就等于阶段负责人在履职了吗？”不是。会议是同步机制，授权是决策机制。

如果每一件事都要等到周会才能决策，那么阶段负责人实际拥有的决策周期是一周。而项目里大部分问题需要当天决策。会议越频繁，越说明授权不到位。

5. 误区五：阶段目标没有”可交付物定义”

这是最隐蔽的一个误区。阶段目标写成”完成核心模块开发”，这句话没有验收标准，等于什么都没定义。

好的阶段目标必须包含三件事：交付物名称、验收标准、验收时间。比如”完成订单模块开发，接口联调通过率 100%，单元测试覆盖率不低于 70%，X 月 X 日前提交测试环境”。这样的目标才可被阶段负责人承接，也可被客观检验。

6. 误区六：要么从不换人，要么频繁换人

两个极端都有问题。从不换人，遇到明显不胜任的阶段负责人也硬扛，结果整个阶段被拖垮；频繁换人，团队每天都在适应新负责人的节奏，执行层彻底失焦。

我的判断标准是看”是否可干预”：如果问题出在信息和资源上，换人没用，要补资源；如果问题出在判断力和推动力上，且已经给了两次明确反馈仍无改善，就该换。

四、专业判断逻辑：阶段负责人的四维选任模型

选人是阶段负责制里最难标准化的一步，但并非不可结构化。我用的是一个四维模型，每个维度打 1 到 5 分，总分低于 14 分的人不建议独立负责关键阶段。

1. 四个维度分别看什么

维度一：交付掌控力。他能不能把一个模糊的目标拆成可执行的任务清单？能不能在资源不足时提出替代方案？这个维度看的是”把事做成”的能力，不是”把活干好”的能力。

维度二：跨角色影响力。他推动其他部门的人做事时，对方配不配合？不是看他职位高低，而是看他在组织里的实际信任度。这一条经常被忽略，但它往往决定阶段能不能顺利跨部门推进。

维度三：信息完整度。他对这个阶段所依赖的上游信息掌握多少？如果一个人对上游需求完全不了解，他就无法判断下游的偏差是正常波动还是重大问题。

维度四：激励匹配度。这个阶段做成了，他能得到什么？如果做好了没奖励、做砸了要背锅，理性的人都不会真投入。这一条最容易被项目经理忽略，因为它不在项目经理的职权范围内，但至少要识别出来，并在授权书里写清楚你能承诺的部分。

2. 打分卡长什么样

我把打分卡做成了一个可以直接用的表。注意，打分不是目的，打分的价值在于让选人这件事从”凭感觉”变成”可讨论”。

3. 什么时候可以降低标准

不是所有阶段都值得用满分标准选人。我的判断规则是：

• 关键路径上的阶段：总分不低于 18 分，且交付掌控力单项不低于 4 分。
• 非关键路径、可复制的阶段：总分 14 分以上即可，主要看执行力。
• 探索性、不确定性高的阶段：降低信息完整度要求，提高交付掌控力要求，因为这类阶段本身就是边做边明确。
• 强合规、有外部审计的阶段：提高信息完整度权重，因为需要完整的证据链。

五、落地方案：项目经理的六步操作步骤

下面这六步是我在实际项目里反复使用并迭代过的版本。每一步都有明确的产出物，你可以直接照着做，也可以按自己的项目裁剪。

1. 步骤一：画阶段责任地图

不要上来就选人，先画图。责任地图的作用是把”这个阶段到底需要谁负责什么”拆清楚，避免选完人之后才发现有些事情没人管。

具体做法是列三张清单：

1. 交付物清单：这个阶段结束时必须产出什么，包括文档、代码、环境、数据、审批件。
2. 依赖清单：这个阶段的推进依赖哪些外部输入，来自哪个角色，什么时候必须到位。
3. 决策清单：这个阶段会遇到哪些需要拍板的事，谁拍，多久拍一次。

三张清单拉完，阶段负责人的职责范围就自然浮现出来了，而不是靠感觉划。责任地图是选人的前提，不是选人的结果。

2. 步骤二：用四维打分卡选人

有了责任地图，再用上一节的打分卡去筛人。这里有一个实操细节：不要只找一个候选人，至少找两个。找两个人的目的不是备胎，而是让你的选择过程可被讨论、可被质疑。

如果团队里只有一个人能选，那说明组织在人才储备上有问题，这个风险要单独记录，而不是靠降低标准掩盖过去。

3. 步骤三：签一份阶段授权书

这是我强烈建议每个项目经理都做的一件事。授权书不需要多正式，一页纸就够，但必须书面化。口头授权在项目压力下会迅速失效，因为大家会默认”还是项目经理说了算”。

一份可用的阶段授权书大致包含以下字段，我给出一个模板：

阶段授权书（模板）
阶段名称：订单模块开发阶段

阶段周期：2024-03-11 至 2024-04-19

阶段负责人：张三（开发组长）

签署人：项目经理 李四

签署日期：2024-03-06

阶段交付物

订单模块可运行代码（合并至主干，代码评审通过）
接口联调报告（通过率 100%）
单元测试覆盖率报告（不低于 70%）
测试环境部署包与部署说明

自主决策边界（边界内无需上报）

阶段内任务顺序调整
单人 3 人天以内的工时再分配
非关键路径的资源借用
不影响交付物范围的实现方案调整

必须升级的情形

出现影响交付时间的偏差超过 2 天
需要跨部门新增资源
交付物范围发生变化
关键路径上出现无法自行解决的技术阻塞

升级时限约定

阶段负责人发现升级情形后 4 小时内上报
项目经理 24 小时内给出决策或明确下一步动作
超时未决策，阶段负责人有权按最保守方案执行

权限说明

可调用阶段内人力资源，优先级由阶段负责人排定
可要求上游角色在 2 个工作日内澄清需求疑问
可拒绝不符合验收标准的交付物进入下一阶段

验收方式
由项目经理、下游阶段负责人、质量负责人三方共同验收

这份模板我用了三年，最有效的是第四条”升级时限约定”。它把压力反向传导给了项目经理，让阶段负责人知道自己不是一个人在扛，上报之后一定会得到响应。

4. 步骤四：开一场 90 分钟的阶段启动会

阶段启动会不是宣讲会，是一场对齐会。我把它固定在 90 分钟，议程如下：

请注意议程的分配比例：阶段负责人主责的环节占了 35 分钟，项目经理占 35 分钟，剩下的用于交互。这个比例是刻意的。如果启动会上项目经理讲了 80 分钟，那这场会就已经失败了，因为它传递的信号是”这个阶段还是我说了算”。

5. 步骤五：建立阶段运行节奏与升级机制

阶段启动会之后，真正决定成败的是日常运行。我用的是一套简单的三层节奏：

• 日层：站会 15 分钟。由阶段负责人主持，只讲三件事：昨天完成了什么、今天做什么、有什么阻塞。
• 周层：阶段周会 45 分钟。看交付物进展、看风险变化、看资源是否够用。不做进度汇报，只做偏差分析。
• 事件层：升级机制。触发升级条件时按授权书约定的时限上报，不得因为”怕麻烦”而延迟。

升级机制里最关键的是时限表。我建议把升级情形分成三档，对应不同的响应时限：

这套时限表的真正作用不是约束阶段负责人，而是约束项目经理的响应速度。我见过太多情况是阶段负责人已经报了，项目经理三天没回，等回过头来问题已经无法挽回。

6. 步骤六：阶段收尾与交接

阶段收尾是最容易被草草了事的一步，但它决定了下一个阶段能不能顺利起跑。我的收尾清单固定包含五项：

1. 交付物逐项对照验收标准确认，不留”基本完成”这种表述。
2. 未完成项、已知缺陷、技术债务形成书面清单，明确承接方。
3. 下一阶段依赖的输入全部确认到位，没到位的写清补位时间。
4. 阶段负责人口头交接 30 分钟，下一阶段负责人可以任意提问。
5. 阶段复盘 30 分钟，只讨论两件事：哪些做法值得复制，哪些做法必须改。

第五条我想多说一句。复盘不要做成绩汇报，也不要做责任追究，只做方法论沉淀。一个阶段复盘如果能产出一条可复用的检查项，这个复盘就是值得的。

六、用工具把阶段负责制固化下来

讲完流程，必须讲工具。原因很现实：阶段负责制依赖大量细颗粒的责任划分、权限控制、进度追踪和证据留存，靠文档和会议撑不过两个迭代。

1. 为什么阶段负责制最后一定会落到工具上

三个绕不开的现实压力：权限需要被系统固化，进度需要被客观呈现，责任需要有迹可循。如果阶段负责人的权限只写在授权书里，但系统里他还是和普通成员一样，那授权就是纸面的。

这也是我在给中大型团队做方案时，会把工具选型放在比较靠前位置的原因。工具不是替代管理，而是让管理动作有承载体。

2. 阶段负责制在工具里需要被固化的四件事

以 PingCode 为例，我在实际配置阶段负责制时会重点做四件事。PingCode 主要服务中大型企业及 100 人以上组织，在角色权限和项目集管理上的颗粒度比较适合这种场景。

第一件：把阶段做成独立的工作项层级。不要把所有工作项平铺在一个列表里，而是按阶段建立层级结构，每个阶段下挂对应的需求、任务、缺陷。这样阶段负责人在系统里的视野边界，和他实际的责任边界是一致的。

第二件：用角色权限固化授权边界。阶段负责人需要能调整阶段内任务顺序、能指派任务、能查看阶段内全部工作项，但不能修改阶段范围。把这些映射成系统角色，授权就从”靠人情”变成”靠配置”。

第三件：把升级机制做成字段和自动化规则。在阶段工作项上加”偏差天数””升级档位””上报时间”三个字段，配合自动化提醒，让升级不再依赖人的自觉。

第四件：把交付物验收做成质量门禁。阶段交付物在系统中设置必须满足的条件，不满足则无法流转到下一阶段。这一步是阶段负责人权威的最后保障。

3. 一次从 Jira 迁移到 PingCode 的实际过程

去年我参与过一个 300 人规模的研发组织的工具迁移。他们原来的项目数据分散在多个 Jira 实例里，阶段责任划分完全靠线下文档，权限体系也没有和阶段绑定。

迁移过程本身比我预想的顺利，PingCode 支持 Jira 的平滑迁移，历史项目、工作项、附件、评论关系都能保留下来，这减少了很多”历史数据丢失”的扯皮。但真正花时间的不是数据迁移，而是责任模型的重新梳理。

我们花了大约三周做三件事：把原来的项目结构重组成”项目集，项目，阶段，工作项”四层；把 12 类角色权限重新定义；把线下运行的阶段验收清单搬到系统里变成流转条件。三周之后，阶段负责人在系统里”能做什么、不能做什么”变成了明确的可查配置。

另外值得一提的是部署方式。这个组织有数据合规要求，最终选择了私有化部署，PingCode 支持私有化部署这一点在选型阶段是硬性门槛。对于有国产替代诉求的团队来说，这也是一个相对低风险的选择路径。

4. 阶段负责制的四个观测指标

工具上线之后，我固定看四个指标，每个月看一次趋势，不看单点值：

• 阶段准时率：按期或提前完成的阶段数 ÷ 已完成阶段总数。
• 风险提前暴露率：在造成实际影响前被记录的风险数 ÷ 总风险数。
• 升级响应及时率：在约定时限内得到响应的升级次数 ÷ 总升级次数。
• 阶段负责人自主决策占比：阶段内自主决策事项数 ÷（自主决策 + 升级决策）总数。

第四个指标最容易被忽略，但它是阶段负责制是否真实运行的直接证据。如果自主决策占比长期低于 50%，说明授权基本没生效。

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

阶段负责制不是一套通用模板，它必须按组织规模和项目类型调整。下面是我给不同类型团队的建议，你可以直接对号入座。

1. 二十人以下的小团队

小团队的资源很少，不需要复杂的授权书和角色权限体系。我的建议是把阶段负责人和实际执行者合并，一个阶段一到两个人负责，重点是把交付物和验收标准写清楚，其余流程能省就省。

小团队最大的风险是阶段负责人频繁更换，因为人少，谁忙谁上。建议三个月内保持阶段负责人相对稳定，哪怕阶段性任务变化，也尽量让同一个人连续负责相邻阶段。

2. 一百人以上、多项目并行的组织

这个规模的组织里，阶段负责制必须制度化，否则一定会退化成”项目经理救火”。建议做三件事：建立阶段负责人的能力基线、把授权写进流程规范、用工具固化权限。

这也是 PingCode 这类面向中大型组织的平台能发挥价值的地方。多项目并行时，阶段负责人的权限边界、升级路径、验收门禁如果不落到系统里，靠人是管不过来的。

3. 强监管、需要交付审计的项目

这类项目的核心诉求是证据链完整。建议在阶段授权书之外，额外增加三项要求：阶段负责人变更必须书面记录并说明原因；阶段验收必须留痕且可追溯到具体版本；升级与决策过程必须归档。

在这些项目里，我通常会把阶段负责人的信息完整度权重提高到 35%，因为审计场景下”不知道”和”做错了”一样致命。

4. 外包与联合交付场景

外包场景下的难点是权限穿透。外部团队的人当阶段负责人，往往调不动甲方资源。建议采取”双负责人”结构：外部负责交付执行，内部负责资源协调与验收，两人各自有明确的授权边界。

这种结构会增加沟通成本，但比责任真空的代价低得多。关键是两个人之间必须有固定的同步节奏，不能只在出问题时才沟通。

八、不同情况下的取舍

做阶段负责制，最难的不是知道该做什么，而是知道该放弃什么。下面四组取舍是我在实战中反复面对的。

1. 授权速度与控制强度之间的取舍

授权越充分，决策越快，但失控风险越高；控制越严，风险越低，但决策越慢。我的经验法则按阶段风险分层：低风险阶段大胆授权，高风险阶段收窄授权但缩短响应时限。

换句话说，不要用统一标准对待所有阶段。高风险阶段的正确做法不是收回权力，而是让权限边界更清晰、升级更快，而不是让负责人等审批。

2. 专职与兼职之间的取舍

阶段负责人是专职还是兼职，取决于阶段的关键程度和复杂度。关键路径上、跨越三个以上角色的阶段，我建议至少半专职，也就是负责人本人可以承担执行任务，但不超过 30% 的工作量。

如果负责人 80% 的时间还在写代码，那他实际上只是”带任务的执行者”，不可能有精力做风险识别和跨方协调。这一点在我前面那张时间分配图里体现得很清楚。

3. 换人与稳定之间的取舍

阶段负责人频繁更换的代价被严重低估。一个人接手新阶段，光是了解上下文、建立信任、摸清依赖，通常需要 3 到 5 天。如果阶段本身只有四周，这个成本占比就超过 15%。

所以我的取舍逻辑是：能用补资源解决的问题，不换人；只能用换人解决的问题，尽早换。拖到阶段中后期再换，成本会成倍上升。

4. 工具投入与流程改造之间的取舍

经常有人问，是先上工具还是先改流程。我的答案是：先想清楚责任模型，再决定工具。责任模型没想清楚就上工具，只会把混乱搬到系统里，让人更难识别问题。

但反过来，责任模型清楚了却不上工具，也会很快退回到线下。我的建议是责任模型基本成型后，立刻用工具固化，不要等流程”完美”再上。流程是在工具使用中迭代出来的，不是设计出来的。

九、怎么验证阶段负责制是否真的生效

推行三个月之后，一定会有人问：”这东西到底有用吗？”这时候如果只能回答”感觉顺畅了一些”，那这套机制很快会被质疑并放弃。你需要能拿出证据。

1. 先看四个先行指标，再看结果指标

结果指标（比如阶段准时率）通常滞后两到三个周期才明显变化，而先行指标会更快反应。我建议重点看四个先行指标：

• 风险提前暴露天数：风险首次被记录的时间，比它造成实际影响的时间早多少天。
• 阶段启动会产出物完整率：六项议程产出物中，实际形成书面材料的有几项。
• 升级响应及时率：这个指标反映的是项目经理侧的履约情况。
• 阶段负责人自主决策占比：反映授权是否真的落地。

如果这四个指标在第二个周期就开始改善，即使阶段准时率还没动，也说明机制在生效，值得继续投入。很多团队在第三个月放弃，恰恰是因为只看了滞后的结果指标。

2. 一个季度评估表

我每季度会做一次评估，用下面这张表。注意最后一行是”机制有效性判断”，它把前面所有指标综合起来，给出一个是否继续、调整还是重构的结论。

十、常见问题

1. 阶段负责人和项目经理的职责会不会重叠？

会有重叠，但重叠点是设计出来的。重叠发生在”目标设定”和”结果解释”两个环节，这是刻意的：项目经理定最终目标，阶段负责人确保目标被承接；出问题时阶段负责人先解释，项目经理再判断是否需要干预。

不重叠的部分是资源分配权和范围变更权，这两项必须留在项目经理手里。如果阶段负责人能自行改范围，阶段负责制就会变成失控。

2. 阶段负责人能不能由项目经理兼任？

短期可以，长期不建议。兼任的代价是失去了”责任分层”这个最重要的收益。当项目经理同时是阶段负责人时，阶段出了问题没人能站在更高一层做判断，风险会被掩盖到无法掩盖为止。

如果团队实在没人，我建议至少让另一个人担任”阶段副负责人”，承担风险登记和进度跟踪职责，形成一个最低限度的责任分层。

3. 阶段负责人不配合、推不动其他部门怎么办？

先判断是能力问题还是权限问题。如果他在组织内信任度低、推动力弱，那是选人问题；如果他有推动力但推不动，那是权限问题。

权限问题的解法只有一个：由项目经理在公开场合明确背书授权边界，并且在他按边界行事时公开支持。只要有一次”负责人按授权做了决定，结果被项目经理推翻”，他的权威就会瞬间清零。

4. 小项目有没有必要设阶段负责人？

两周以内的项目，可以不设正式阶段负责人，但必须明确”每个阶段结束时由谁解释结果”。这句话比职务名称重要得多。哪怕只有一个人，也要让他知道这个阶段出了问题他要第一个回答。

5. 阶段负责人的激励怎么做才有效？

我的经验是把手里的资源分成三类：阶段复盘时的公开认可、下一个关键阶段的优先选择权、与绩效关联的阶段成果记录。其中第二项往往比第一项更有效。

因为它们传递的是同一个信号：做好阶段负责人这件事，在这个组织里是被看见、被记账、被回报的。如果没有这个信号，任何授权书都只是一张纸。

6. 工具选型上有什么硬性标准？

我会看四条：能不能按阶段做工作项分层、能不能按阶段配置角色权限、能不能做阶段质量门禁、能不能导出阶段维度的度量数据。这四条缺任何一条，阶段负责制都很难在系统层面闭环。

对于有数据合规要求或国产替代诉求的中大型组织，还要额外确认是否支持私有化部署、是否支持从既有工具平滑迁移。这两条在选型阶段容易被忽略，但一旦进入实施就会变成硬约束。

写在最后

关于阶段负责人，我最想留下的一句话是：它不是一个职务安排，而是一次责任转移。项目经理真正要做的，不是找到一个能干活的人，而是把”这个阶段的结果由谁解释”这件事，在一个具体的人身上、一个具体的时间点之前、用一份具体的书面约定落地。

我见过太多团队把阶段负责制做成了形式：名义上指定了人，实际上还是项目经理在扛。区别就在于有没有做到三件事，提前 3 到 5 天书面授权、写清自主决策边界、约定升级响应时限。这三件事都不难，难的是坚持做，并且容忍阶段负责人在边界内做出和你不一样的决定。

如果你准备下一步动手，我的建议是按这个顺序推进：先用一周时间画完阶段责任地图，再用四维打分卡选出两个阶段的负责人，然后把这篇文章里的授权书模板改成适合你团队的一版，签下去。跑完一个完整阶段后，拿第九节的季度评估表复盘一次，看看四项先行指标有没有变化。

如果只有时间做一件事，那就做”提前 3 到 5 天书面授权”这一件。它是我见过投入产出比最高的管理动作，没有之一。