瀑布顺序开发的稳定性，可以拆成四个可复算的指标：阶段返工率、评审缺陷遗漏率、变更冲击率和阶段周期偏差率。四项指标按同一时间窗、同一工作量单位分阶段统计，再组合解读，比单看某一个数字更能说明阶段产出是否被反复推翻、评审是否拦住了缺陷、变更是否受控。下面给出公式、取数口径、计算步骤和一个完整算例。
要点总览（TL;DR）
- 瀑布顺序开发的稳定性用四项同口径指标组合衡量：阶段返工率、评审缺陷遗漏率、变更冲击率、阶段周期偏差率，按同一时间窗和同一工作量单位分阶段统计。
- 阶段返工率＝该阶段返工工作量÷该阶段总工作量；评审缺陷遗漏率＝后阶段发现的前阶段缺陷数÷该阶段评审已发现缺陷总数；变更冲击率＝变更引起的返工工作量÷该阶段总工作量；周期偏差率＝（实际工期−基准工期）÷基准工期。
- 组合判断比单指标更有意义：返工率与遗漏率同时偏高提示评审有效性不足，变更冲击率偏高提示变更控制薄弱，周期偏差大要结合前两项区分内部返工与外部变更。
- 分母为零或样本过小时不计算比率，改看绝对数并标注样本量；数据缺失标记缺失，不按零处理，否则会系统性低估返工和遗漏。
- 指标反映过程现象，不直接证明原因；不设通用达标线，阈值应结合项目基线与历史数据确定，用于阶段复盘而非团队绩效排名。
评估目标：稳定性要回答哪三个问题
在瀑布语境下，稳定性指阶段交付物一次通过的程度、缺陷被前移到早期拦截的程度，以及变更对已确认产出的扰动程度。它衡量的是单项目按顺序推进时，前一阶段的结论能否被后一阶段稳定承接。度量对象是单个项目的瀑布顺序开发过程，不涉及组织级流程制度设计，也不讨论敏捷框架下的迭代度量。
围绕这个定义，稳定性度量要回答三个问题：
- 阶段产出是否被反复推翻。表现为同一阶段的工作被重做、已确认的交付物被退回修改，对应阶段返工率。
- 评审是否拦住了缺陷。表现为本应在评审阶段发现的问题，拖到后阶段才暴露，对应评审缺陷遗漏率。
- 变更是可控还是失控。表现为已批准的需求或设计变更引发了多少返工，对应变更冲击率。
阶段周期偏差率作为辅助指标，回答“进度是否按基线推进”，并帮助判断周期拉长是内部返工造成还是外部变更造成。三个问题各有对应指标，任何一项单独偏高都不足以判定项目不稳定，需要放在同一时间窗内横向比较。
指标与范围：四个核心指标及统计边界
四个指标都采用比率形式，分子是“非预期投入或非预期事件”，分母是“该阶段的总量”。统一口径是可比的前提：工作量统一用小时或人天，选定后全项目不混用；时间窗按阶段划分，每个阶段从进入评审到阶段关闭为一个统计窗口。
| 指标 | 公式 | 分子 | 分母 | 时间窗 | 单位 |
|---|---|---|---|---|---|
| 阶段返工率 | 该阶段返工工作量 ÷ 该阶段总工作量 | 因本阶段产出被退回、重做而消耗的工时 | 该阶段全部投入工时 | 阶段开始至阶段关闭 | 百分比（工作量统一为小时或人天） |
| 评审缺陷遗漏率 | 后阶段发现的前阶段缺陷数 ÷ 该阶段评审已发现缺陷总数 | 在后阶段才暴露、归属前阶段的缺陷数 | 该阶段评审中已发现的缺陷总数 | 该阶段评审结束至项目测试结束 | 百分比（按缺陷条数） |
| 变更冲击率 | 变更引起的返工工作量 ÷ 该阶段总工作量 | 已批准变更导致的重做工时 | 该阶段全部投入工时 | 变更批准至阶段关闭 | 百分比（工作量单位同上） |
| 阶段周期偏差率 | （实际工期 − 基准工期）÷ 基准工期 | 实际工期与基准工期之差 | 已批准的基准工期 | 阶段开始至阶段关闭 | 百分比（工期单位统一为天或小时） |
统计范围需要事先约定。阶段纳入需求、设计、开发、测试四个主要阶段，各项目可按实际阶段划分调整，但同一项目内保持一致。变更只纳入已走完审批、正式生效的变更，口头调整不计入。缺陷只纳入有明确阶段归属的记录。
排除项同样要写清楚：非本阶段责任引起的返工不计入该阶段返工率，例如上游设计错误导致开发重做，应记在设计阶段的遗漏或返工上；需求新增属于范围变化，与缺陷修复分开统计，只有引发返工的变更才进入变更冲击率的分子；缺陷修复本身是正常工作量，不重复计入返工，除非修复过程又引发了返工。
数据口径与证据：从哪些记录取数、如何保证可比
指标能否复算，取决于取数记录是否完整、字段是否一致。建议为每项指标固定数据来源和必填字段，并在统计前做一次口径校验。
| 指标 | 数据来源 | 关键字段 | 校验要点 |
|---|---|---|---|
| 阶段返工率 | 任务或工单记录、工时记录 | 返工标记、所属阶段、实际工时、返工原因 | 返工标记与工时记录一一对应，避免同一任务重复计工时 |
| 评审缺陷遗漏率 | 评审记录、缺陷单 | 缺陷发现阶段、缺陷归属阶段、缺陷状态 | 同一缺陷只计一次，归属阶段按引入环节判定 |
| 变更冲击率 | 变更申请单、影响范围评估记录、工时记录 | 变更类型、批准时间、影响工作量、关联任务 | 变更影响工作量与返工工时对应，需求新增单独归类 |
| 阶段周期偏差率 | 项目计划、基线记录 | 基准开始与结束时间、实际开始与结束时间 | 基准取自已批准版本，实际工期按阶段关闭时间计算 |
口径校验重点做三件事。第一，工作量单位统一，所有工时按同一单位折算，人天与小时的换算比例在项目内固定。第二，阶段归属规则统一，缺陷和返工按“引入环节”而非“发现环节”归属，避免后阶段把问题都算在自己头上。第三，同一事件不重复计数，一个缺陷既被记为评审遗漏又引发返工，应分别进入不同指标的分子，但不能在同一指标内重复累加。
数据缺失时标记为缺失，不按零处理。缺失比例较高的阶段，比率结果只作参考，并在报表中标注缺失条数。把缺失当零会系统性低估返工和遗漏，让稳定性看起来好于实际。
计算与评估步骤：从取数到组合判断
计算按阶段逐个推进，每个阶段完成四项指标后再进入下一阶段，最后横向比较。
- 确定统计窗口。为每个阶段设定开始与关闭时间，锁定该窗口内的工时、缺陷和变更记录。
- 计算阶段返工率。汇总该阶段带返工标记的工时，除以该阶段总工时。
- 计算评审缺陷遗漏率。统计该阶段评审已发现缺陷数，以及后阶段发现且归属该阶段的缺陷数，后者除以前者与后者之和，或按约定口径除以评审已发现总数，口径一旦确定不中途更换。
- 计算变更冲击率。汇总已批准变更引发的返工工时，除以该阶段总工时。
- 计算阶段周期偏差率。用实际工期减基准工期，再除以基准工期。
- 绘制分阶段趋势。把四项指标按阶段排列，观察哪一阶段返工和变更冲击集中。
组合判断遵循几条规则。返工率高且评审遗漏率同时偏高，提示评审有效性不足，问题在评审环节而非执行环节；返工率高但遗漏率低，更可能是需求理解或任务拆分问题。变更冲击率高，提示变更控制薄弱或影响评估不充分。周期偏差大时，结合前两项判断：返工和遗漏高说明是内部返工拖长周期，变更冲击高说明是外部变更所致。
分母为零或样本过小时不计算比率。某阶段没有评审记录，遗漏率无意义；某阶段变更只有一两条，比率波动极大。这类情况改看绝对数，并在结果旁标注样本量，避免用一个小样本比率下结论。
例子：一个四阶段项目的稳定性测算
以下数据为演示用途，不代表行业基准。假设某项目分需求、设计、开发、测试四个阶段，工作量统一用人天。
| 阶段 | 总工作量（人天） | 返工工作量 | 评审已发现缺陷 | 后阶段发现的前阶段缺陷 | 变更引发返工 | 基准工期（天） | 实际工期（天） |
|---|---|---|---|---|---|---|---|
| 需求 | 40 | 4 | 20 | 6 | 2 | 10 | 11 |
| 设计 | 60 | 9 | 30 | 12 | 3 | 15 | 18 |
| 开发 | 200 | 30 | 50 | 10 | 20 | 40 | 46 |
| 测试 | 120 | 12 | 40 | — | 6 | 25 | 27 |
逐项代入公式：
- 需求阶段返工率 = 4 ÷ 40 = 10%；遗漏率 = 6 ÷ 20 = 30%；变更冲击率 = 2 ÷ 40 = 5%；周期偏差率 =（11 − 10）÷ 10 = 10%。
- 设计阶段返工率 = 9 ÷ 60 = 15%；遗漏率 = 12 ÷ 30 = 40%；变更冲击率 = 3 ÷ 60 = 5%；周期偏差率 =（18 − 15）÷ 15 = 20%。
- 开发阶段返工率 = 30 ÷ 200 = 15%；遗漏率 = 10 ÷ 50 = 20%；变更冲击率 = 20 ÷ 200 = 10%；周期偏差率 =（46 − 40）÷ 40 = 15%。
- 测试阶段返工率 = 12 ÷ 120 = 10%；变更冲击率 = 6 ÷ 120 = 5%；周期偏差率 =（27 − 25）÷ 25 = 8%。测试阶段作为末段，遗漏率不适用。
解读结果：设计阶段最不稳定，遗漏率 40% 为四阶段最高，返工率 15% 也偏高，说明设计评审没有充分拦住问题，缺陷被推到开发和测试才暴露。开发阶段变更冲击率 10% 明显高于其他阶段，结合其 15% 的周期偏差，周期拉长部分来自变更引发的重做。需求阶段各项指标相对平稳，但 30% 的遗漏率提示需求评审仍有改进空间。测试阶段指标较低，与其作为缺陷汇聚点的角色有关，不宜简单视为质量最好。
解读与限制：指标能说明什么、不能说明什么
四项指标反映的是过程现象，不直接证明原因。返工率高可能是评审不严，也可能是需求本身模糊或人员能力差异，需要结合具体返工原因字段和复盘讨论判断。把比率直接当作因果结论，容易误判改进方向。
不同项目之间的比率可比性有限。项目规模、复杂度、技术栈和团队经验都会影响分母和分子，一个 40 人天的小项目和一个 400 人天的大项目，同样的返工率含义并不相同。跨项目比较时应先确认阶段划分、工作量单位和缺陷归属规则一致，否则只做趋势参考。
不设通用达标线。返工率多少算高、遗漏率多少算合格，取决于项目基线、历史数据和业务容错要求。建议先用三到五个历史项目建立基线区间，再据此设定观察阈值，并随项目类型调整。阈值用于触发讨论，不作为硬性考核标准。
避免用单一指标评价团队绩效。返工率低可能是返工没有被如实标记，遗漏率低可能是缺陷归属记录不全。指标用于阶段复盘和改进讨论，帮助定位问题集中的环节，不适合直接用于排名或奖惩。当指标与考核挂钩时，记录的真实性会下降，度量的价值也随之减弱。
在取数与留痕环节，如果项目使用 ONES，可以用项目计划按阶段建立工作分解结构，用里程碑和基线记录基准工期，通过基线对比查看计划与执行偏差并追溯变更细节；工时记录和缺陷跟踪为返工工时、缺陷阶段归属提供原始数据，成员工时报表和多维度统计可用于分阶段汇总。具体指标是否以预置报表形式提供，需按项目实际配置确认，上述四项比率通常需要在导出数据后按本文口径计算。
常见问题
阶段返工率的分母用阶段总工作量还是阶段计划工作量，两种口径结果差异大吗？
两种口径都能用，关键是全项目统一并写进统计说明。用阶段总工作量（实际投入工时）作分母，反映返工在实际投入中的占比，适合评估阶段内部的消耗结构；用计划工作量作分母，反映返工相对计划的偏离程度，适合对照进度基线看影响。当阶段实际投入明显超出计划时，两种口径的结果会拉开差距，此时建议同时保留两个数值，并在报表中注明分母口径，避免跨阶段比较时混用。
缺陷在评审时没发现、到测试阶段才暴露，应该算哪个阶段的遗漏？
按“引入环节”归属，而不是按“发现环节”归属。一个需求描述不清导致的缺陷，即使在测试阶段才暴露，也应记入需求阶段的遗漏分子；设计接口定义错误引发的缺陷记入设计阶段。这样统计才能反映各阶段评审的实际拦截效果。执行时需要缺陷单具备引入阶段字段，并在缺陷关闭前由责任人确认归属，否则后阶段容易把问题都算在自己头上，导致遗漏率失真。
需求新增和需求变更都会引发重做，变更冲击率要不要把需求新增算进去？
建议分开统计。需求新增属于范围变化，通常伴随计划和工作量的正式调整，把它计入变更冲击率会放大“失控”的信号；变更冲击率更适合统计已批准变更对已确认产出的扰动。操作上可在变更申请单里设置变更类型字段，将范围新增、需求修改、设计调整分类，只有引发返工的需求修改和设计调整进入分子。若项目希望观察整体扰动，可以另设一个“范围变化影响率”并列展示，两个指标不混算。
项目历史数据很少，还没建立基线，阈值该怎么定？
先用三到五个已完成项目的数据算出各阶段指标的实际分布，取中位数附近作为观察起点，把明显偏离的阶段挑出来做复盘，而不是先定一个合格线。数据不足时优先看趋势和绝对数：同一阶段连续几个项目返工工时上升，比一个孤立的比率更有信息量。随着项目积累，再逐步收紧观察阈值，并按项目类型（规模、复杂度）分组维护，避免用一套阈值套所有项目。
四项指标算出来之后，怎么落到阶段复盘的讨论里而不变成追责？
把指标当作定位问题的入口，而不是结论。复盘时先看哪一阶段返工和遗漏集中，再调取该阶段的返工原因字段和缺陷记录，讨论具体是哪类问题反复出现，例如评审检查项缺失、需求确认不充分或变更影响评估不到位。讨论对象是流程环节和记录质量，不落到个人排名。当指标与奖惩挂钩时，返工标记和缺陷归属的记录真实性会下降，度量的参考价值也随之减弱，这一点在推行前需要和团队达成共识。
