去年 11 月，我帮一家 600 人规模的智能硬件公司做交付复盘，翻完 43 个在研项目的里程碑记录后发现一个反常识的结论：真正因为技术难题延期的只有 5 个，剩下 28 个延期项目的会议纪要里，反复出现同一句话，“这个阶段到底谁签字？”这不是执行力问题，而是项目阶段负责人全流程没有定义清楚。项目经理在群里催进度，硬件负责人在等结构件确认，测试负责人在等验收标准，谁都在忙，谁都不对最终结果负责。
我把这类问题统称为“阶段负责人真空”：项目被拆成了启动、规划、执行、监控、收尾五个阶段，却没有为每个阶段指定唯一的对结果负责的人，也没有约定阶段出口的验收物和决策权。本文会把这套流程从结论、背景、误区、判断逻辑、真实案例、行动建议到取舍完整讲清，你可以直接拿去改自己团队的流程。
一、先给结论：项目阶段负责人全流程只有四件事
先给结论。所谓“项目阶段负责人全流程”，本质上是四件事的组合，而不是一张组织架构图。任何一家企业如果只做了其中一两件，流程都会在某个阶段塌掉。
1. 阶段边界：不是按时间切，而是按决策接口切
大多数团队划分阶段的方式是“前两周做需求、中间八周开发、最后两周测试”。这种按时间切法看起来整齐，实际执行时几乎必然失控，因为时间是连续流动的，而决策是离散发生的。
我建议的切法是以决策接口为边界：需求基线冻结是一个决策点，技术方案评审通过是一个决策点，测试准入达标是一个决策点，上线放行是一个决策点。每个决策点之前的所有工作，属于同一个阶段；跨过决策点，责任主体就该交接。
这样做的好处非常直接：阶段交接不再依赖日历，而依赖可验证的条件。一个阶段是否结束，不取决于“到了周三”，而取决于“需求基线是否已冻结并有签字记录”。
2. 负责人唯一性：一个阶段只能有一个 A
我见过太多团队写“需求阶段由产品部和业务部共同负责”。共同负责在中文语境里几乎等于无人负责。当出现延期时，产品说业务需求变得太频繁，业务说产品理解得不到位，最后只能由项目经理兜底。
每个阶段必须且只能有一个对结果负责的人，其他人只能是参与者、被咨询者或被通知者。这个人在该阶段拥有召集会议、调配资源、叫停工作的权力，同时承担该阶段延期的第一责任。
3. 决策权匹配：没有决策权的负责人等于传声筒
这是最容易被忽略的一条。很多团队确实指定了阶段负责人，但没有给他对应的决策权。比如指定了一位技术负责人负责开发阶段，但范围变更要经过三层审批，资源调配要业务线老板点头，那他在实际执行中只是一个“进度汇报员”。
我的判断标准很简单：如果这个人在本阶段无法独立做出至少三类决策，就不该让他挂负责人的头衔。三类决策通常是范围边界、资源优先级、质量准入。
4. 交付物验收标准：阶段出口的物理门禁
阶段出口必须有可核查的交付物，而且交付物的验收标准要提前写清，不能到验收时再讨论。我见过最典型的事故是测试阶段快结束了，才发现“性能指标”从来没有被量化定义过，于是双方对“是否达到上线标准”各执一词。
我把这四个要素的成熟度做成了一个雷达图，你可以对照自己团队的位置。
二、背景与真实场景：为什么 100 人以上组织会突然失控
阶段负责人这件事，在 30 人以下团队几乎不需要制度。老板一句话就能决定谁负责，所有人的信息都在同一个空间里，项目延期是可见的。但当组织跨过某个规模拐点，事情会突然变难。
1. 三个规模拐点
根据我过去八年做 PMO 和流程咨询的观察，至少存在三个明显的拐点。第一个拐点在 50 人左右，跨职能沟通开始需要会议而不是工位旁的一句话；第二个拐点在 150 人左右，中层管理者出现，信息开始经过二次转述；第三个拐点在 400 人左右，同时进行的项目超过 20 个，资源冲突从偶发变成常态。
拐点之后，“谁知道这件事”和“谁有权决定这件事”开始分离。这正是阶段负责人真空的温床。
2. 我亲历的一次 43 个项目复盘
回到那家 600 人的智能硬件公司。43 个在研项目中，有 33 个至少延期一次。我把延期主因做了归因统计，结果如下表，这也是我后来做流程诊断的标准模板。
| 延期主因 | 涉及项目数 | 占比 | 典型现场表现 |
|---|---|---|---|
| 需求与范围变更 | 11 | 33% | 阶段负责人无权拒绝插入需求 |
| 阶段负责人不清晰 | 8 | 24% | 交接会上无人接单，空转两周 |
| 资源冲突 | 5 | 15% | 同一测试工程师被 4 个项目共享 |
| 验收标准模糊 | 4 | 12% | “性能达标”从未被量化 |
| 外部依赖不可控 | 3 | 9% | 供应商样件延期无预警机制 |
| 其他 | 2 | 6% | 人员离职、政策变动 |
把这张表按项目数排序后画成帕累托图，会更清楚地看到问题集中度。
3. 信息在传递链条上的衰减
还有一个更隐蔽的问题：即使阶段负责人指定清楚了，信息在阶段之间传递时仍会衰减。我在同一家公司做过一次小实验，把一个“电池续航需在 -10℃ 下保持 85%”的需求，从业务方口头传达给产品、产品写进文档给开发、开发转述给测试，最后测试用例里只剩下“低温续航正常”。
这不是个例，而是口头传递 + 阶段交接不清的必然结果。我用一个漏斗图刻画了这种衰减。
三、拆解七个常见误区
在给十几家企业做流程诊断的过程中，我总结出七个反复出现的误区。它们往往单独看都很合理，组合起来就导致流程空转。
1. 误区一：把阶段负责人当成阶段联系人
“阶段联系人”只负责传话，不负责结果。很多团队在项目立项表里写的是联系人字段，却在复盘时按负责人标准追责。这种错位会让被指定的人本能地回避责任，因为他知道自己没有相应的权力。
2. 误区二：用项目经理补齐所有阶段的责任
这是最常见的兜底方式。项目经理被默认为“所有阶段的最终负责人”，结果是他一个人背着五个阶段的风险，而各阶段专业负责人退化成执行者。项目经理应该负责流程的完整性，而不是替各阶段负责结果。
3. 误区三：阶段交接靠会议而不是靠门禁
交接会开完，大家点头，但没有明确的准入条件。下一阶段开始时，上一阶段的遗留问题被带进来，逐渐累积成技术债和范围债。会议可以用于对齐，但不能替代门禁。
4. 误区四：验收标准写在验收前的那一刻
标准的价值在于前置。如果验收标准是在验收会上才讨论出来的，那它实际上是一次谈判，而不是一次检验。我在一家企业见过测试团队为了“响应时间是否达标”争论了三天，最后发现双方对“达标”的口径根本不同。
5. 误区五：一个人可以同时是多个阶段的负责人
在小项目里这没问题，但在中大型项目里，同一个人兼任需求阶段和开发阶段的负责人，会导致自我验收。他既定义标准，又检验标准，风险敞口被系统性放大。
6. 误区六：只定义角色，不定义决策权
角色是名词，决策权是动词。流程文档里写满“XX 负责 XX 阶段”，却没有一句话说明他在这个阶段能拍板什么。这样的流程在纸面上完整，在执行中空转。
7. 误区七：用工具记录流程，而不是用工具约束流程
很多团队把流程写在文档里，把任务记在工具里，两者互不相通。于是流程成为“事后解释工具”，而不是“事前约束机制”。真正有效的方式，是让工具里的状态流转本身承载门禁逻辑。
这七个误区的代价可以用返工成本来量化。下面这张对比图来自我对三家企业的调研估算，其中部分为示意数据，用于说明量级差异。
四、专业判断逻辑：四件套怎么闭环
讲完误区，说说我的判断逻辑。我的顺序和大多数流程文档相反：先定决策，再定人，再定交付物，最后定阶段边界。原因在于，人是为了承接决策而存在的，反过来推容易失效。
1. 先定决策，再定人
具体做法是列出项目全生命周期中所有需要拍板的决策点，通常一个中大型项目会有 12 到 20 个。然后为每个决策点标注：决策内容、决策时限、决策人、被咨询人、被通知人。做完这一步，“谁负责哪个阶段”会自然浮现。
2. 用“单点 A”原则搭 RACI
RACI 矩阵本身没有错，错在很多人允许一个事项有多个 A。我坚持每个决策点只能有一个 A，其余全部归入 R、C、I。如果实在出现两个候选 A，说明这个决策点还没有被拆细，需要继续拆。
3. 阶段门禁的三种强度
不是所有项目都需要同等强度的门禁。我通常按三档设计，让团队根据项目风险等级自主选择。
| 门禁强度 | 适用项目 | 通过条件 | 不通过的处置 |
|---|---|---|---|
| 轻量门禁 | 内部工具、低风险迭代 | 负责人自检 + 书面记录 | 记录风险后继续推进 |
| 标准门禁 | 常规客户交付项目 | 交付物清单齐备 + 负责人签字 | 限期补齐，逾期升级 |
| 强化门禁 | 安全、合规、资金类关键项目 | 交付物齐备 + 跨部门评审通过 | 冻结阶段，不得进入下一阶段 |
4. 变更控制的分级授权
变更是延期的第一大诱因，处理方式不能一刀切。我的做法是按影响面分三级授权，把大部分小变更留给阶段负责人自己决定，只把真正影响基线的事项交给更高层。
| 变更等级 | 判断标准 | 决策人 | 响应时限 |
|---|---|---|---|
| 一级（轻） | 不影响基线、工期浮动 ≤ 2 天 | 阶段负责人 | 1 个工作日内 |
| 二级（中） | 影响阶段内里程碑、工期浮动 3-10 天 | 项目经理 + 阶段负责人 | 3 个工作日内 |
| 三级（重） | 影响项目基线、预算或上线日期 | 项目发起人 / 变更委员会 | 5 个工作日内 |
把决策权按角色分布画出来，能非常直观地看出流程改造前后的差别。下图中“无流程”状态下大量决策集中在发起人手里，而“有流程”后决策权下沉到阶段负责人。
还有一个常被引用来论证门禁必要性的经验规律：缺陷发现得越晚，修复成本越高。这条曲线在我的项目数据里基本成立，我把它画成阶梯线。
五、真实案例与数据观察：一家 400 人企业的 9 周改造
讲完逻辑，说一个具体案例。2023 年下半年，我以顾问身份参与了一家 400 人规模的软件企业（约 380 人研发，同时在研 26 个项目）的阶段负责人流程改造。整个过程 9 周，我把过程和结果都记录下来。
1. 改造前的四个症状
第一，26 个项目里只有 12 个项目能明确说出每个阶段的负责人，明确率 46%。第二，需求变更没有分级，所有变更都走同一条审批链，平均响应 4.7 天。第三，阶段交接靠周会，周会上讨论的 60% 内容是上周遗留问题。第四，项目经理每周花 6.5 小时在跨部门扯皮类会议上。
2. 我们做了什么
我们分三步走。第一步，用两周时间梳理全部 26 个项目的决策点，合并重复项后得到一份包含 17 个标准决策点的清单。第二步，按“单点 A”原则重新指定阶段负责人，把每个阶段的决策权写进项目章程。第三步，把流程落到工具里，让状态流转与门禁条件绑定。
第三步是关键。我们选用了 PingCode 作为落地平台。PingCode 主要服务中大型企业及 100 人以上组织，这正好匹配这家公司的规模和组织复杂度。我们在工作项类型里为五个阶段各自定义了必填字段和出口条件，只有交付物清单齐备、负责人签字确认后，状态才能流转到下一阶段。
同时，PingCode 支持私有化部署，这家公司因为涉及客户数据合规要求，选择了私有化方案，数据留在自有服务器上。另外，他们此前已经使用了多年 Jira，这次借助 PingCode 的 Jira 平滑迁移能力，把历史项目、工作项类型和自定义字段一并迁移过来，避免了历史数据割裂。
这里给出一个迁移映射的示意配置，展示阶段负责人字段如何随状态自动切换：
{
"work_item_type": "项目阶段",
"stages": ["需求基线", "方案评审", "开发执行", "测试准入", "上线放行"],
"stage_owner_field": {
"需求基线": "product_owner",
"方案评审": "architect_owner",
"开发执行": "dev_lead",
"测试准入": "qa_lead",
"上线放行": "release_manager"
},
"gate_condition": {
"开发执行": ["方案评审通过", "接口文档齐备", "排期确认"],
"测试准入": ["单元测试覆盖率>=70%", "冒烟用例通过", "缺陷清零至阈值"],
"上线放行": ["回归测试通过", "回滚方案确认", "变更审批完成"]
},
"change_approval": {
"level_1": ["stage_owner"],
"level_2": ["stage_owner", "project_manager"],
"level_3": ["project_manager", "project_sponsor"]
}
}
3. 9 周后的数据
改造在第 9 周完成全量切换。我在第 6 个月做了一次复检，把关键指标和改造前做了对比。以下数据来自该企业内部统计，我做了脱敏处理。
| 核心指标 | 改造前 | 改造后（第 6 个月） | 变化幅度 |
|---|---|---|---|
| 阶段负责人明确率 | 46% | 96% | +50 个百分点 |
| 需求变更返工率 | 31% | 14% | -17 个百分点 |
| 里程碑准时率 | 52% | 79% | +27 个百分点 |
| 项目平均延期天数 | 11.5 天 | 4.2 天 | -63% |
| 周报人工耗时（每人每周） | 1.8 小时 | 0.4 小时 | -78% |
| 跨部门扯皮会议时长（每周） | 6.5 小时 | 2.0 小时 | -69% |
我还对比了三个不同规模的团队，观察上线周期与流程执行率的关系，结果有点反常识：规模最大的团队上线周期最长，但执行率并不是最高。
4. 为什么中大型组织可以考虑 PingCode
我不做泛泛推荐，只说三点在本案例中真实起作用的因素。第一，能承载复杂的阶段状态机和门禁条件，而不是把所有阶段压成一张看板。第二，支持私有化部署，满足合规与数据主权要求，这对制造、金融、政企类客户是硬指标。第三，支持 Jira 平滑迁移，让历史数据和既有工作习惯可以延续，降低切换阻力。
对于正在做国产替代选型的中大型组织来说，这三点组合起来，是比较务实的考量维度。当然，工具只解决“流程能否被执行”，不解决“流程设计是否合理”，这一点必须先想清楚。
六、不同情况下的行动建议
流程设计没有万能解。下面按组织规模给出四档建议，你可以直接对号入座。
1. 50 人以下团队
不要做复杂制度。只做一件事：在项目启动时，用一张表写清五个阶段的负责人姓名和阶段出口条件。每周站会上花两分钟确认当前处于哪个阶段、谁负责、出口条件是否满足。这个阶段最大的风险是过度设计，流程一旦比业务还重，团队会立刻绕开它。
2. 100 到 300 人团队
这是流程建设性价比最高的区间。建议做三件事：建立标准决策点清单；按“单点 A”原则指定阶段负责人；把变更分三级授权。工具层面需要支持自定义工作项类型和状态流转，否则流程会重新退回到文档里。
3. 300 到 1000 人团队
这个区间需要专职流程角色，通常是 PMO。重点从“定义流程”转向“度量流程”。建议建立一组不超过 8 个指标的度量体系，比如阶段负责人明确率、里程碑准时率、变更平均响应时长、门禁一次通过率。指标过多会导致团队把精力放在填报而不是交付上。
4. 1000 人以上或多事业部组织
不要试图统一所有事业部的流程。我的建议是“统一骨架、放开肌肉”：决策点分类、阶段命名规则、门禁强度分档由总部统一；具体的评审形式、会议节奏、交付物模板由各事业部自行决定。分批推广，每批 2 到 3 个事业部，避免一次性切换带来的震荡。
下面这张气泡图展示了不同治理强度适合的组织规模，气泡大小代表年度项目数量。它可以帮助你判断自己该用多重的流程。
七、不同情况下的取舍
流程优化本质上是一连串取舍，没有只赚不赔的选项。我把四个最关键的取舍摆出来。
1. 治理强度 vs 交付速度
增加门禁一定会增加前置工时，这是确定的。但它减少的是后期返工，这是不确定的。我的经验是：在需求和技术方案两个阶段加强门禁，在开发和测试阶段适当放松。因为前两个阶段的缺陷修复成本是 1 到 3 倍，后两个阶段是 8 到 20 倍，把门禁放在杠杆最高的位置。
2. 工具统一 vs 团队自治
统一工具能带来全局数据可见性，代价是团队的个性化工作流被压缩。我倾向于“统一数据模型，放开视图层”：工作项类型、状态语义、字段定义统一，但看板视图、筛选器、报表由各团队自建。这样既保证了跨项目汇总能力，又保留了团队的操作习惯。
3. 私有化部署 vs SaaS
私有化部署的数据可控性更强，适合有合规要求、客户数据敏感的企业，代价是需要自建运维能力，升级节奏也相对慢。SaaS 上线快、维护成本低，但在数据主权和深度定制上受限。判断标准很简单：如果客户合同里出现了数据不得出境的条款，或者审计要求能追溯到数据物理位置，就选私有化。
4. 迁移成本 vs 长期可维护性
从旧平台迁移到新平台，短期一定会有摩擦成本。我的经验值是，400 人规模组织的完整迁移周期在 8 到 12 周之间，其中前两周是映射设计，中间四周是数据迁移与验证，最后四到六周是并行运行。这笔投入是否值得，取决于旧平台是否已经成为流程执行的瓶颈。如果瓶颈在流程设计而不在工具，换工具解决不了问题。
| 取舍维度 | 偏左选择 | 偏右选择 | 我的建议分界 |
|---|---|---|---|
| 门禁强度 | 全程强化门禁 | 只在关键阶段设门禁 | 需求 + 方案阶段强化，其余标准门禁 |
| 工具策略 | 完全统一 | 完全自治 | 统一数据模型，放开视图与报表 |
| 部署方式 | 私有化部署 | SaaS | 有合规条款即私有化，否则 SaaS 优先 |
| 平台迁移 | 立即整体切换 | 长期双平台并行 | 分批迁移 + 4-6 周并行，不长期双轨 |
把改造收益做一次拆解，更容易判断投入是否值得。下面这张瀑布图来自本案例的年度测算，其中部分为示意数据。
八、落地清单：30 天把阶段负责人流程跑起来
最后给一份可以直接执行的 30 天清单。我按周拆解，每一项都有明确的产出物。
1. 第 1 周：摸清现状
- 拉取近 6 个月所有延期项目，按前面那张归因表做分类统计。
- 对每个在研项目做一次“阶段负责人明确率”抽查，只问一个问题：这个阶段谁签字？
- 整理出你所在组织最集中的三个问题，形成一页纸的现状说明。
2. 第 2 到 3 周：定义规则
- 梳理标准决策点清单，目标控制在 12 到 20 个之间。
- 为每个决策点指定唯一 A，其余标注 R、C、I。
- 定义每个阶段的出口交付物和可核查的验收标准。
- 制定变更分级授权规则，明确三级变更的决策人。
3. 第 4 周：落到工具
- 在工作项类型中固化五个阶段的状态字段和必填项。
- 配置门禁条件，让状态流转受条件约束而非人工判断。
- 选择 2 到 3 个试点项目运行，收集一线反馈。
- 根据反馈调整规则，再逐步推广到全部在研项目。
4. 90 天后的复检指标
推广完成后，用 90 天做一次复检，只看五个指标：阶段负责人明确率是否达到 90% 以上；里程碑准时率是否提升 15 个百分点以上；变更平均响应时长是否缩短 40% 以上；门禁一次通过率是否稳定在 70% 以上；周报人工耗时是否降到每人每周 0.5 小时以内。
如果五个指标里有三个没有改善，问题通常不在执行，而在流程设计本身。这时候需要回到第四部分，重新检查决策点是否拆得够细、A 是否唯一、阶段负责人是否真的有决策权。
结尾：阶段负责人不是头衔，是一条可追溯的责任链
我做了八年流程，最深的体会是：项目阶段负责人全流程的价值，不在于把责任分清楚，而在于让责任可以被追溯、被验证、被提前暴露。一纸任命书解决不了延期，一套能约束状态流转的机制才能。
如果你现在就要动手，我建议从一件事开始：明天挑一个正在延期的项目，问三个问题，这个阶段谁签字？他能拍板什么？出口的验收标准写在哪？这三个问题的答案如果模糊，那么问题就不在团队执行力上。
把这三个问题在全部在研项目上问一遍，你就得到了自己组织阶段负责人流程的真实成熟度。剩下的，只是按本文的清单一步步补齐而已。
常见问题解答（FAQ）
1. 项目阶段负责人到底负责什么，和项目经理的职责边界怎么划？
我们公司刚推阶段负责人制，我被安排做项目经理，本来以为只是多设几个岗位，结果一落地就发现大家都在问：阶段负责人是不是就是阶段里干活最多的那个人？我自己也说不清楚，到底是管结果还是管过程，跟项目经理的权限又怎么区分。
先把边界用一句话钉死：阶段负责人对阶段交付结果负责，项目经理对项目整体目标负责。落地时我一般让双方各签三张清单。第一张是交付物清单，写清这个阶段必须产出的三到五件东西和各自的验收人；
第二张是决策清单，写清他在预算、人力、变更上能拍板的上限，比如单次变更不超过总工期的百分之五可自行决定，超过就必须上报；第三张是资源清单，写清他能调动谁、调不动时找谁。判断标准很简单：如果这个人不能对阶段交付物说不，他就不算负责人，只是个协调员。
这三张清单最好在阶段启动会上当场确认并留记录，后期扯皮能省掉大半。
2. 阶段负责人在项目管理工具里怎么配置才不会乱，报表和权限怎么设？
我们团队用的是某项目管理工具，一开始图省事，把阶段负责人填在自定义字段里，谁都能改。结果月底拉报表时发现同一个阶段有三个人填过负责人，权限也管不住，谁都能关别人的任务。我就想知道，这种角色到底该怎么在工具里落。
我的经验是，能用工具原生的层级关系就别用自定义字段。具体做法是让阶段本身成为一个可分配的对象，比如阶段、迭代或里程碑，把负责人设为必填字段，不填就不能进入下一状态。权限上给阶段负责人该阶段内的编辑权和关闭权，但不给跨阶段的删除权和归档权，避免误操作。
报表要按阶段负责人这个维度出三个数：阶段逾期率、阶段平均停留时长、阶段内返工次数。停留时长按工作日算，从阶段进入进行中到退出进行中，别用自然日，否则周末会把数据拉失真。字段必填加上报表可见这两件事做完，我们那边阶段负责人的实际填写率从三成左右提到八成以上，原因不是大家变自觉了，而是不填就走不下去。
3. 阶段负责人中途换人，交接怎么做才不丢事？
上个季度我们一个项目的测试阶段负责人突然离职，交接只留了一份文档，结果新人接手两周后发现三个待批决策和一个外部依赖全断了，项目直接拖了十天。我现在特别怕再遇到换人，想知道有没有一套标准动作。
交接别只交文档，要交四件套：未关闭的交付物和对应责任人、进行中的决策和待批事项、外部依赖和对接人、风险清单和触发条件。做法上，换人当天完成双签，原负责人和新负责人在同一张交接表上确认，同时在工具里把负责人字段改掉，历史记录不迁移，只在新负责人名下加一条交接备注，保证追溯链不断。
判断交接合不合格有一个很硬的标准：新人能不能独立主持一次阶段例会，并且对已登记风险的状态全部答得上来。做不到，就说明交接没完成，原负责人要留下来陪跑一次例会。
4. 阶段负责人怎么考核和激励，才不至于逼大家压测试时间？
我们之前的考核就是看阶段有没有按时结束，结果大家发现压测试时间最容易达标，缺陷哗哗地流到下一个阶段，最后修起来更贵。我现在想重新设计考核口径，但不确定该看哪几个数。
我建议用三正一反四个指标。正向是阶段按期达成率、交付物一次验收通过率、阶段内变更返工率；反向是缺陷逃逸到下一阶段的数量，越低越好。口径一定要提前定死：按期达成以阶段评审通过日为准，不是以最后一天提交日为准；一次验收通过率等于首次评审通过数除以总提交数，返工过一次就不算。
这样设计的好处是，压测试时间会让一次验收通过率和缺陷逃逸量同时变差，考核自己就把这个歪招堵住了。激励上，把阶段负责人的评价作为项目奖金池分配的权重依据之一，权重按阶段工作量和复杂度定，不按阶段时间长短定，否则又是在鼓励拖时长。
文章包含AI辅助创作：项目阶段阶段负责人全流程：项目负责人流程优化与一文讲清，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/334212
读者评论
我们公司去年做流程改造，也试过按决策接口切阶段，结果发现最难的不是定义决策点，而是怎么让业务方接受‘需求基线冻结后不接受插入’。文中把拒收需求的决策权列为延期主因第一项，这点很真实，但实际推动时往往卡在老板身上，工具再好也解决不了权力问题。
对‘一人不能兼任多个阶段负责人’这条有不同看法。我们做的都是中小型项目，总共就七八个人，需求开发测试全由一个人串起来反而快，硬拆开只会增加交接成本。可能文中说的中大型项目适用，但小团队照搬容易把流程搞得更重。
信息衰减那个漏斗图挺戳中我的。我们做工业设备的，客户口头说的工况条件传到测试那边经常只剩一句‘按常规环境测’。不过我觉得根子不完全在阶段负责人，而是缺少一个强制留痕的需求变更记录，光靠负责人盯也很难防住口头传递的损耗。