B5.14.2Cost of Defects设计研究
同一缺陷的修复成本随开发阶段推进而上升
别名: 缺陷成本 · 阶段成本 · 早期发现
概念解释
同一个可用性缺陷（如「用户找不到导出入口」），在草图阶段改动的成本是一支笔的时间，在设计评审阶段是一轮方案，在开发后是代码与测试，在上线后是发版、迁移、客服与用户重新学习——成本沿开发阶梯逐级放大。这是「尽早做可用性」最硬的经济理由。
机制
成本上升来自依赖累积：每往下一个阶段，缺陷就被更多已完成的工件引用——设计文档、代码、测试用例、文案、已发布的帮助内容、用户的习惯。修复不再只改缺陷本身，还要连锁修订所有下游工件，并支付协调成本与再学习成本。上线后还叠加发现成本（缺陷经由用户行为才被确认）。放大倍数各家估计不同（软件工程经典的 10–100 倍说法针对的是代码缺陷），但方向在可用性缺陷上同样成立且常更陡，因为交互模型渗入的范围比代码更深。
怎么研究
缺陷成本曲线可用组织内部数据实证：按发现阶段统计同类缺陷的修复工时（需求期/设计期/开发期/上线后），画出阶段-成本曲线。研究要点是控制缺陷复杂度——不同缺陷的固有难度不同，跨阶段比较要匹配类型。结果可直接进入经济论证：早期可用性评估的投入成本对比其拦截缺陷的后期修复成本估计，形成「检查成本 < 修复成本」的证据。
边界
曲线不是定律而是强烈倾向：轻量迭代与特性开关能压平部分后期成本；有些缺陷只有真实用户才能暴露，早期无法发现，其「早期修复成本」无从谈起。放大倍数严重依赖组织流程（发布周期、测试覆盖、客服容量），不能直接搬用他人数字。曲线支持「尽早评估」，不等于「无限前置评估」——评估本身有成本，存在最优检查密度。
怎么落地
- 在流程的关键闸口（需求冻结前、设计评审、开发中期）安排低成本评估（走查、快速测试），把缺陷拦截在低价阶段。
- 缺陷跟踪系统加「发现阶段」与「修复工时」字段，积累自己的成本曲线数据。
- 论证早期可用性预算时用本组织的曲线数据，而不是引用文献倍数。