迭代规划流程与规范：实施团队需求排期协同管理关键指标

去年秋天，我帮一家做制造业 MES 实施的团队复盘他们连续三个迭代的延期问题。团队 34 人，8 个实施顾问同时跟进 11 个在建项目。他们的迭代计划表做得很漂亮：每个迭代 10 个工作日，每个顾问排 8 天任务，留 2 天缓冲。但实际结果是，三个迭代的平均按时完成率只有 51%，而顾问们在复盘会上给出的原因高度一致，“客户那边没确认”“现场临时出了问题”“销售又插了一个需求进来”。

我把他们三个迭代的全部任务记录拉出来，按“任务处于等待状态的天数”重新统计了一遍。结果很反常识：这 34 个人在三个迭代里的平均有效工作时间占比是 41%，也就是说近六成的工作时间花在等确认、等接口、等环境、等排期上，而不是花在做不完的活上。他们的迭代规划流程并不缺，缺的是把“等待”这件事显性化的机制；他们的需求排期协同管理也不缺会议，缺的是能对抗“感觉排得下”的关键指标。

这篇文章讲的就是这件事：一套实施团队真正能跑起来的迭代规划流程与规范，以及三个足以支撑决策的关键指标。我会先给结论，再拆开讲背景、误区、判断逻辑、我实际落地的案例数据，最后给不同规模团队的行动建议和取舍清单。全文基于我跟踪过的 6 家实施交付团队（合计约 420 人，行业覆盖制造业软件实施、政企项目交付、SaaS 客户成功交付）的脱敏观察，其中部分对比区间为样本推演，我会明确标注。

一、核心结论：迭代规划的本质是约束显性化，不是排期表美化

先把结论摆出来，后面所有内容都是对这五条结论的展开和证明。如果你只想要一个能立刻用的判断，看这一节就够了。

1. 排期崩盘的根因在输入不稳定，不在执行不力

绝大多数实施团队在复盘延期时，会把原因归到“执行力”“责任心”“沟通不到位”。但从我拉过的十几份任务流水看，真正的原因分布完全不同：需求在迭代中途变更、需求在进入迭代前就没定义清楚、跨团队依赖没有被提前锁定，这三类“输入问题”通常占延期原因的一半以上，而纯粹的“做不完”“做慢了”占比不到三成。

这意味着一个很硬的判断：如果你的迭代规划流程只在“排期会议”这一环做优化，投入产出比极低。真正该做的是在需求进入迭代之前就把它卡住，让不合格的输入进不来。规划流程的价值 80% 发生在会议之前，而不是会议之中。

2. 协同效率取决于等待时间，不取决于工作时长

实施团队有一个非常特殊的结构：一个人同时挂在 3 到 6 个项目上，每个项目都有自己的客户节奏、自己的验收节点、自己的对接人。这种结构下，一个人的日历是被切碎的，而被切碎的时间里，最贵的不是碎片本身，是碎片之间的等待和切换。

我在统计时用了一个简单的口径：任务从“开始”到“完成”的日历天，减去实际投入的工时，剩下的就是等待与切换成本。这个数字在中大型实施团队里普遍占到 45% 到 60%。所以迭代规划要优化的核心对象，是等待，而不是工时。

3. 关键指标三个就够，多了必然失真

我见过太多团队的度量看板，十几张图，二十多个指标，最后没人看。原因很简单：指标一多，每个指标都可以被解释掉。延期了可以说因为插单多，插单少了可以说因为需求质量高，需求质量高了可以说因为客户配合，最后谁都不用负责。

我的判断是，实施团队的迭代规划只需要三个能相互对抗的指标：计划兑现率（做得准不准）、需求流转周期 P85（快不快）、插单占比（稳不稳）。这三个指标彼此制约：只追兑现率会把周期拉长，只追周期会牺牲承诺质量，只追插单占比会拒绝一切客户响应。三个一起看，才构成一个无法自我解释的闭环。

4. 规范的作用是让例外可见，不是消灭例外

实施团队的业务天然充满例外：客户临时要上线、监管要求变、销售签了个不可能的时间点。你写再厚的规范也挡不住这些。规范真正的价值，是把例外从“隐性的日常”变成“显性的、有代价的决策”。

所以我在设计规范时，从不去写“禁止插单”，而是写“插单必须触发一次容量置换，必须写明被挤出的任务”。前者一定会被绕过，后者会让人在插单前三思。这个转变，是整套流程能不能活过三个月的分水岭。

5. 规划的颗粒度应该停在“可判断”，而不是“可追踪”

很多团队把任务拆到 4 小时粒度，理由是“好追踪”。但实施类工作的不确定性极高，拆得越细，估算误差的绝对值越大，团队花在维护任务状态上的时间也越多。我的经验值是：单个任务 0.5 到 3 人天，一个迭代一个人的任务条目控制在 6 到 12 条。低于这个量级说明拆过头了，高于这个量级说明规划还停留在愿望层面。

二、背景与真实场景：实施团队为什么比产品团队更难排期

产品团队的迭代规划有相对稳定的输入：一个产品负责人，一个需求池，一套优先级规则。实施团队面对的是完全不同的结构。不理解这个结构差异，任何从产品团队照搬过来的敏捷流程都会水土不服。

1. 需求来源的三方拉锯，让优先级失去唯一解释权

在实施型团队里，需求至少有三个来源：客户现场提出的（往往最紧急）、售前为了签单承诺的（往往时间点最死）、产品与内部优化提出的（往往最容易延期）。这三方各有各的合理性，也各有各的施压渠道。

我跟踪过的一家政企交付团队，做过一次为期 8 周的来源标注统计。结果是：客户现场提出的需求占了条目数的 47%，但消耗了 61% 的产能；售前承诺的需求只占 18%，却因为时间点刚性，抢走了 24% 的关键资源窗口；内部优化需求占 35%，实际完成的只有 12%。这不是优先级失效，是优先级根本没有被量化过。

2. 时间结构被现场切碎，日历不等于产能

实施顾问的一周通常是这样：周一到周三在一个客户现场，周四回公司处理配置和文档，周五又被叫去另一个项目救火。表面上看他一周有 5 天可排，实际上真正能用于计划内任务的可能只有 2.5 天。

这就是我在前面提到的“日历不等于产能”。很多团队的迭代容量是按“人数 × 天数”算的，这个算法在实施团队里的误差可以达到 40% 以上。正确的做法是按“可用专注时段”算容量，而不是按出勤天数算容量。

3. 一次真实的排期崩盘：三个迭代的连锁反应

回到开头那家 MES 实施团队。他们的崩盘过程非常典型，值得完整讲一遍。第一个迭代，销售签下一个客户要求 6 周上线的合同，团队在迭代中途插入了 4 个该客户的需求，挤掉了原本计划的接口开发。第二个迭代，接口开发的延期导致另外两个项目的联调无法开始，这两个项目的顾问进入等待状态，等待时间累计 67 人天。第三个迭代，为了追回进度，团队同时启动了三个项目的上线，结果 QA 资源被拉爆，缺陷逃逸到客户现场，产生了 23 个紧急工单。

这个故事里没有任何一个人是不负责任的。销售没错，客户要的就是 6 周；顾问没错，他们已经很努力地在等；QA 没错，他们被同时塞了三倍的工作量。错的是流程：没有任何一个环节，把“插入 4 个需求”和“挤掉接口开发”这两件事在同一个界面上摆出来给人看。

4. 把看板搬到线上，为什么没解决问题

这家团队其实早就用了项目管理工具，看板、任务、工时全都在线上。但工具只承载了“记录”，没有承载“约束”。任务可以随便建，优先级可以随便改，工时想填就填，插单不需要任何人批准。线上的看板只是把线下的混乱照了一遍相。

我后来总结了一句话，团队负责人很认同：工具不会自动带来规范，工具只能放大你已经有的规范。你有多强的准入规则，工具就能帮你守住多强的准入规则；你没有规则，工具就帮你更快地制造混乱。

三、常见误区拆解：六个把排期做废的动作

在讲正确做法之前，先把错误做法拆干净。下面这六个误区，我在至少四家团队里同时见过。它们单独出现时危害有限，叠加出现时基本等于宣判迭代规划死刑。

1. 误区一：把“承诺”当成“计划”

计划和承诺是两件事。计划是“在给定假设下最可能的路径”，承诺是“对外给出的确定性保证”。很多团队把两者混为一谈，结果是对内失去了调整空间，对外失去了可信度。

具体表现是：迭代计划一旦排定就冻结，中途发现明显排不下也不调整，最后要么延期，要么半成品交付。正确的做法是把迭代内容分成“承诺区”和“弹性区”：承诺区不超过总容量的 60%，必须完成；弹性区 40%，可以顺延。这个比例我在多个团队验证过，60/40 是兼顾可信度和灵活性的较优区间。

2. 误区二：用需求条目数衡量产能

“上个迭代做了 28 个需求，这个迭代目标 32 个。”这句话在任何实施团队里说出来都是有问题的。需求条目的颗粒度差异可以到 10 倍以上，一个“改个字段标签”和一个“对接客户 ERP 主数据”都算一条。

更麻烦的是，这个指标会反向塑造行为：团队会倾向于把大需求拆成很多小条目，让数字好看。用条目数衡量产能，最终得到的一定是被优化过的数字，而不是被改善的交付。

3. 误区三：用“人天”做统一货币

人天看起来是最公平的度量单位，实际上是最容易失真的。原因有三：不同人的一天不等价；同一个人在不同项目状态下的一天也不等价；人天的估算在实施类工作里的系统性偏差通常是低估。

我的做法是把人天降级为“参考值”，把“容量点”升级为“结算单位”。容量点由团队自己标定，比如“一个标准配置任务 = 2 点”，点的绝对值不重要，重要的是同一团队内部的相对比例稳定。一旦比例稳定，容量预测的准确度会明显高于人天。

4. 误区四：把“插单”当纪律问题

插单几乎在所有实施团队里都被当成纪律问题处理：开会强调、写进制度、要求审批。效果通常维持两到三周。因为插单的根源不是纪律，是销售和交付之间缺少一个共同的、量化的容量视图。

销售看不到交付的真实余量，只能凭感觉判断“应该能挤出一点”。交付看不到销售承诺的完整清单，只能被动接受。这个信息差一天不补，插单就一天不会消失。

5. 误区五：把指标用来考核个人

这是最致命的一个。一旦“计划兑现率”变成个人 KPI，团队会立刻学会两件事：把估算放大，把任务拆小。三个月后你会得到一个兑现率 95%、实际产出下降 20% 的团队。

过程指标只能用于改进，不能用于考核。如果要考核，考核结果指标（客户验收通过率、缺陷逃逸率、项目毛利），过程指标留给团队自己做复盘用。这条线一旦模糊，整套度量体系就会在两个月内失去可信度。

6. 误区六：规范越写越厚，执行越来越薄

我见过一份 47 页的迭代管理规范。这份规范唯一的作用是让新人在入职第一周产生畏难情绪。规范的厚度和执行率成反比，这是我在所有团队都观察到的规律。

我的建议是一页纸原则：任何一条规范，如果不能用一句话说清“做什么、什么时候做、谁来判断”，就不要写进去。真正的规范应该只有三到五条硬规则，其余全部交给团队自主判断。

四、专业判断逻辑：把迭代规划拆成四层输入与三个闸门

讲完误区，我需要给出一个可操作的框架。这个框架我在四家团队落地过，核心思路是把“排期会议”这一个动作，拆成“四层输入”的准备和“三个闸门”的把关。

1. 四层输入：需求池、约束池、能力池、风险池

迭代规划做不好，九成是因为只准备了需求池，另外三个池子空着。四个池子缺一个，规划就变成了拍脑袋。

需求池装的是“要做什么”。关键不在于有多少条，而在于每条有没有达到“可进入规划”的门槛：有明确的验收标准、有明确的提出方、有明确的截止约束（如果有的话）。

约束池装的是“不能动的东西”。合同节点、监管时限、客户停机窗口、第三方接口的可用时间。这一层最容易被忽略，但它是排期的硬边界。我通常要求团队把未来 8 周的所有硬约束提前录入，形成一张时间轴。

能力池装的是“真正可用的人和时段”。注意不是人数，是可用专注时段，要扣掉现场支持、值班、培训、休假。这一层的数据质量直接决定规划精度。

风险池装的是“可能发生但还没发生的事”。第三方接口延期、客户关键人休假、环境不到位。每一条风险要标注概率和影响面，规划时预留对应的缓冲。

2. 三个闸门：准入闸门、承诺闸门、变更闸门

1. 准入闸门：需求进入待规划列表前，必须由需求提出方补齐三项信息，验收标准、提出方、时间约束。缺一项不进入规划。这一步不需要开会，用工具里的必填字段和状态流转就能卡住。
2. 承诺闸门：进入迭代的条目必须做一次容量校验，承诺区不超过可用容量的 60%。校验结果要能被所有人看到，尤其是销售和客户成功。
3. 变更闸门：迭代中途的任何插入或替换，必须同时指定被挤出的条目。这个动作看起来只是个流程要求，实际效果非常强，它会自动提升插单的质量。

三个闸门里，准入闸门是防守，承诺闸门是平衡，变更闸门是止损。我建议的落地顺序是先做变更闸门（效果最快，一周可见）、再做准入闸门（需要两到三周形成习惯）、最后做承诺闸门（涉及跨部门共识，最慢）。反过来做，很容易在第一周就推不动。

3. 关键指标的选取逻辑：为什么是这三个

指标选取有一个很朴素的判断标准：这个指标变差时，会不会有人不舒服。如果一个指标变差对任何人都不产生压力，它就不是指标，是装饰。

计划兑现率变差，交付负责人会不舒服，因为它直接关联客户满意度和验收节点。需求流转周期变差，销售会不舒服，因为它意味着客户要等更久。插单占比变差，所有人都会不舒服，因为它意味着计划被外部力量随意改写。

这三个指标刚好覆盖了“准、快、稳”三个维度，而且两两之间存在张力。这就是我选它们的全部理由。

4. 度量口径必须先定义清楚，否则一定吵架

我见过太多团队在指标定义上扯皮：什么算“完成”？提测算还是上线算？跨迭代的任务算在哪个迭代？这些不提前定义，第一次复盘就会变成定义之争，而不是改进之争。

五、案例与数据观察：一套在 34 人实施团队跑通的方案

这一节讲我在开头提到的那家 MES 实施团队，是怎么在 12 周里把三个指标拉回健康区间的。我尽量把配置动作和数据变化都写清楚，方便你对照自己的团队。

1. 起点：三个必须先量出来的基线

改造前我们先做了两周基线采集，不做任何干预。结果是：计划兑现率 51%，需求流转周期 P85 是 47 个日历天，插单占比 38%。这三个数字放在一起看，问题非常清楚，插单占比 38% 意味着每三个任务里就有一个是计划外的，那么 51% 的兑现率其实是合理的，不是执行问题。

这一步很关键。如果不先量基线，你永远无法说服团队“问题不在你们”。而团队一旦认为问题在自己身上，他们就会本能地防御，任何流程改造都推不动。

2. 工具侧：用 PingCode 承载三个闸门

这家团队原本的工单和任务散在三个地方，我们统一收口到 PingCode。选择它的原因很实际：它同时覆盖需求池、迭代计划、工时、测试和报表，而且权限和流程可以按团队粒度配置，不需要为了一个实施团队去改造整个公司的系统。对于 100 人以上、多项目并行的组织，这一点比单个功能的强弱重要得多。

具体做了四件事，我按落地顺序写：

• 需求池分级：把需求分成客户级、项目级、内部级三层，每层配置不同的必填字段。客户级需求必须填验收标准和提出方，内部级需求只需填价值说明。分级的目的不是管控，是让不同性质的需求走不同的通道，避免所有需求都挤在同一条评审队列里。
• 迭代容量视图：把顾问的可用专注时段录进去，节假日、现场支持、值班都提前扣掉。迭代计划页面直接显示“已排容量 / 可用容量”，超过 60% 变黄，超过 80% 变红。这个视觉提示比任何制度都有效。
• 插单审批与容量置换：任何迭代中途新增的条目，必须走一次轻量审批，并在提交时选择“本次插入将顺延哪一条”。这个字段是强制必填的，系统会自动把被顺延的条目通知到相关方。仅这一条，就把插单占比从 38% 降到了 17%，用时四周。
• 跨项目依赖登记：把架构、数据、第三方厂商的依赖单独建成一种工作项类型，指定负责人和预计就绪时间。依赖项进入阻塞状态超过 3 天，自动升级提醒。这一条对应的是前面帕累托里的第三大偏差来源。

需要说清楚的是，这四件事里没有一件是“高级功能”。它们都是基础能力的组合使用。差异不在工具，在于有没有人明确规定“必须这么用”。

3. 十二周的数据变化

改造从第三周开始，到第十四周结束。我把关键指标的变化列在下面。需要说明：这里是真实项目的脱敏汇总，某些细分指标因为采集口径调整，前四周的数据做过对齐处理，属于估算区间。

4. 十二周的过程曲线，比结果更值得看

结果指标容易被误读成“一次性提升”。实际过程并不平滑。第 4 到第 6 周有一次明显的回落：插单占比从 17% 反弹到 26%。原因是销售侧发现审批流程可以绕过，把需求拆成“缺陷”提报就不用走插单审批。

我们后来补了一条规则：缺陷类工作项必须由 QA 确认，不能被销售直接创建。反弹在两周内被压回去。这个故事说明一件事：任何流程规范在落地后的第一个月，都会被找到绕过路径。这不是团队不配合，是流程设计的必经阶段。

5. 我们踩过的三个坑

第一个坑是一开始就把指标挂到项目经理的绩效上。第三周就出现了估算普遍放大的现象，平均估算人天上浮了 22%。我们第二个月就把过程指标从绩效里摘出来了。

第二个坑是容量视图录入太细。最初要求顾问按小时填可用时段，填了两周就没人填了。后来改成按半天粒度，填报率从 40% 升到 92%。精度的边际收益远小于填报成本的边际损失，这个判断我在很多团队都验证过。

第三个坑是规范文档写成了 23 页。三个月后新入职的顾问没人读完。我们最后压缩成了一页 A4，只保留三个闸门和六条硬规则，执行率立刻上来了。规范的目的不是完备，是被执行。

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

前面讲的是一套完整方案。但完整方案不适合所有团队，规模、项目结构、客户类型不同，该做的事完全不同。下面分四类给建议，你可以直接对号入座。

1. 十人以下小团队：只做一件事，变更可见

小团队最大的优势是沟通成本低，最大的风险是流程负担重。这个阶段不需要容量视图，不需要复杂的需求池分级，甚至不需要正式的迭代计划。

唯一必须做的是让变更可见：任何计划外插入，在共享看板上标记出来，每周花 15 分钟看一次“这周计划外的事占了多少”。这个动作的成本几乎为零，但它会建立起团队对“插单有代价”的共识。这个共识是小团队未来长大的地基。

2. 三十到一百人中型团队：三个闸门全部上，指标只留三个

这个规模是流程改造收益最大的区间。人数超过 30 之后，靠口头同步已经不可能，必须靠机制。建议按变更闸门 → 准入闸门 → 承诺闸门的顺序推进，总周期控制在 12 周内。

指标只留三个：计划兑现率、需求流转周期 P85、插单占比。每两周看一次，只看趋势不看单点。这个阶段最需要避免的是指标膨胀，一旦超过五个，团队就会开始选择性解读。

3. 一百人以上多项目并行：先统一口径，再谈优化

超过 100 人的组织，最大的问题不是流程缺失，而是流程分裂。三个事业部三套迭代节奏、三套工时口径、三套优先级规则，跨部门协作时全部对不上。

这个阶段的优先级是统一度量口径。什么算完成、工时怎么登记、迭代周期多长、需求状态怎么流转，这些必须在组织层面统一。统一之后再谈优化才有意义。像 PingCode 这类面向中大型组织的平台在这一步的价值会明显体现：它提供的是跨项目、跨团队的统一数据底座，而不是单个团队的工具。多项目并行的组织如果没有统一底座，做出来的报表永远无法横向比较。

同时要注意，100 人以上的组织不要试图一次推全套。建议按“一个试点事业部 + 三个指标 + 十二周”的节奏走，跑通之后再复制。复制的时候只复制机制，不复制具体数值区间。

4. 交付型与产品型混合：两套节奏，一套指标

很多中大型组织同时有交付型团队（按客户项目走）和产品型团队（按产品版本走）。强行统一迭代节奏通常失败，因为两类工作的不确定性结构完全不同。

我的建议是节奏分开、指标统一。交付型用两周迭代 + 30% 缓冲容量，产品型用四周迭代 + 15% 缓冲容量。但三个核心指标的口径完全一致，这样管理层可以做横向对比，团队之间可以互相参照。

七、取舍：你必须在四组矛盾里做选择

任何流程设计到最后都是取舍。我见过太多团队试图“既要又要”，结果是四组矛盾全部没解决。这一节把这四组矛盾摊开，给出我的倾向和适用边界。

1. 计划稳定性 vs 客户响应速度

这是实施团队最核心的矛盾。稳定性高了，客户临时需求响应慢，客户满意度下降；响应速度快了，计划经常被打断，交付成本和团队士气都受损。

我的判断是按客户价值分层，而不是按矛盾本身折中。战略客户、续约在即的客户、行业标杆客户，允许更高的响应优先级；长尾客户走标准排期。关键是这个分层规则要提前定、公开定，而不是每次插单时临时判断。临时判断的结果一定是嗓门大的赢。

2. 度量精度 vs 填报成本

精度越高，填报越重，填报越重，数据质量越差。这条曲线的拐点通常在“半天粒度”。按小时填，填报率会掉到 50% 以下；按天填，又会丢失现场支持这类半天级的工作。

我倾向核心指标高精度、辅助指标低精度。三个核心指标（兑现率、周期、插单）必须准确，可以要求更细的登记；工时统计、任务进度这些辅助数据允许粗粒度，甚至允许按周批量补填。不是所有数据都值得花同样的代价去采集。

3. 统一规范 vs 团队自治

统一规范带来可比性，团队自治带来适配性。这个矛盾在中大型组织里最尖锐。

我的划分方式是：度量口径必须统一，执行方式允许自治。什么算完成、周期怎么算、插单怎么定义，这些必须全组织一致；但每个团队用什么看板视图、开多久的规划会、任务拆到多细，交给团队自己定。这样既保证了横向可比，又保留了适配空间。

4. 短期交付压力 vs 长期产能建设

这一组最容易被忽略，也最贵。前面那家 MES 团队，内部优化需求占条目数 35%，实际完成只有 12%。长期下来，工具债、模板债、知识库债一起累积，最终表现为“同样的活越做越慢”。

我的建议是把长期产能建设固化成容量配额，而不是靠自觉。每个迭代固定划出 10% 到 15% 的容量给内部优化，不参与任何插单置换，不接受业务侧调用。这个配额看起来是损失，实际上是唯一能守住的东西。

八、最小启动方案：两周能做完的事

如果你读到这里想立刻动手，我建议不要从“设计完整流程”开始。用两周做四件事，成本很低，效果可验证。

1. 第一周：量基线，不改任何东西

1. 导出过去两个迭代的全部任务记录，标注每条任务的创建时间、开始时间、完成时间、是否为迭代中途新增。
2. 算出三个基线数字：计划兑现率、插单占比、平均等待天数（完成日历天减实际投入工时）。
3. 把这三个数字和团队一起看一遍，不做评价，只问一句：“这个数字和你的感受一致吗？”

这一步的作用不是分析，是建立共识。数据只有在团队自己认的时候才有推动力，你讲一百遍不如让他们自己看到一遍。

2. 第二周：只上变更闸门

在工具里加一个必填字段：新增需求必须选择“本次插入将顺延哪一条”。同时把这周的插单条目和被顺延条目在周会上公开一次。

不要做审批流，不要做容量视图，不要改需求池结构。就这一条。我见过的团队里，单靠这一条，插单占比平均能在四周内下降 15 到 20 个百分点。

3. 后面十周：按顺序补齐，不并行

第三到第五周做准入闸门（三项必填字段）。第六到第九周做容量视图（按半天粒度录可用时段）。第十到第十二周做承诺闸门和跨部门容量同步。每一步跑两周观察期再进下一步。

并行推进是流程改造最常见的死法。三个动作同时上，出了问题无法归因，团队会把所有不适都归到“新流程”上，最后一起废弃。

4. 判断这套流程有没有真的跑起来

给你三个自查问题，两个月后问自己：

• 迭代规划会上，有没有人真的因为容量不够而把需求拿出去？（有，说明承诺闸门生效了）
• 销售或客户成功能不能自己看到交付的剩余容量，而不需要问项目经理？（能，说明容量可视化生效了）
• 插单的时候，有没有人主动说“那我先把 X 顺延”？（有，说明变更闸门生效了）

三个问题有两个能答“是”，这套流程就是活的。一个都没有，说明你上的还是记录工具，不是管理机制。

九、最后的判断：流程的价值在于让好决策变便宜

写到这里，我想回到最开始那个反常识的数字：34 个人的团队，有效工作时间占比只有 41%。这个数字背后不是懒，不是能力问题，是每一次排期决策的成本太高了。销售不知道交付还剩多少容量，项目经理不知道这个需求插进来会挤掉什么，顾问不知道自己下周到底在哪个项目上。每个人都在信息不完整的情况下做决策，做出来的决策自然是互相打架的。

迭代规划流程与规范的全部价值，就是把这些决策变便宜。当容量是可见的，插单的成本是一眼能算出来的，依赖是提前被锁定的，那些原本需要开三次会才能谈成的事，变成了一次点击就能判断的事。这才是流程存在的理由，不是增加控制，是降低决策成本。

至于关键指标，我一直坚持一个观点：指标不是用来证明团队做得好的，是用来暴露团队在哪一环被卡住的。计划兑现率低，说明承诺机制有问题；周期长，说明等待环节有问题；插单多，说明容量信息不对称。三个数字各自指向一个具体的、可改的环节，这才是指标该有的样子。

如果你现在就要动手，我的建议是按这个顺序：今天先导出过去两个迭代的数据，算出三个基线；这周找团队一起看一遍数字，只讨论感受不讨论责任；下周只上一条规则，插单必须指定被顺延的任务。两周之后你会有一个明确的判断：这套东西在你们团队到底跑不跑得动。

如果跑得动，再往下走三步。如果跑不动，问题通常不在流程设计，而在你有没有先让团队相信“延期的原因不在他们身上”。这一点没解决，任何流程都只是又一份没人读的文档。