向业务解释重构，不必先承诺“效率提升三倍”。更可靠的方式是固定观察周期，把投入、可归因收益和剩余风险摆在同一张表里。

时间单位先统一

假设一个教学项目预计投入12个人日，未来六个月每月节省3个人日，维护新增成本每月0.5个人日。六个月净收益是15个人日，扣除初始投入后剩3个人日。不能拿六个月成本配一年收益，再给出漂亮回报率。

investment = 12.0 months = 6 saved_per_month = 3.0 extra_per_month = 0.5 benefit = months * (saved_per_month - extra_per_month) roi = (benefit - investment) / investment payback_months = investment / (saved_per_month - extra_per_month) assert benefit == 15 assert roi == 0.25 assert payback_months == 4.8 print({"six_month_roi": roi, "payback_months": payback_months})

图中展示需要纳入评估的情景项；残余风险应从原风险收益中扣除，不作为正收益相加。

这些数值是假设，用于核对公式，不是业务预测。人日也不是现金：节省的时间是否能投入有效工作，需要另行确认。项目取消、需求变化和学习成本都可能改变结果。

风险收益必须减掉残余风险

例如原方案某类故障的六个月期望损失为10万元，新方案估计为4万元，那么可讨论的是6万元差额，再扣实施和运行成本。不能把原本10万元全部当成“避免损失”。概率与损失若高度不确定，给出区间比精确小数更诚实。

还要防止重复计算：减少故障后节省的处理人日，可能已经包含在故障损失中；若再列一遍，会把同一收益算两次。类似地，从8天降到2天是周期变为四分之一，不能随手写成提升三倍而不说明计算口径。

用可撤回的试点减少争论

先选择一个边界清楚、重复发生的痛点，记录改动前后的相同事件口径，同时保留未改动的相近流程供参考。变化不一定由重构造成，发布节奏、需求难度和团队人员都可能影响结果。

DORA强调在应用或服务语境下理解交付表现。把这点用在重构评估里，就是先解释哪一条等待、失败或返工链路会改善，再决定观察哪些信号。本文算术已经可独立复算，真实收益仍需要试点数据，不能由公式自动证明。

参考

• DORA交付指标与使用语境