深度指南
技术债务速度损失模拟器：返工让您的工程团队付出什么代价
行业管理层分析
技术债务是走捷径所累积的成本：能运行但难以修改的代码、缺失的测试、纠缠不清的依赖，以及无人理解的老旧系统。它很少出现在预算中。相反，它表现为一种感觉：一切都比过去花更长的时间。估算不断延期，小改动会弄坏无关的东西，团队把迭代花在不创造任何新东西的工作上。这笔债务的账单不是以费用的形式到来，而是以同样的薪资下每月交付的功能数变少的形式到来。
这个问题的结构是对产能征收的一种税。如果每个迭代的五分之一都花在变通方案和返工上，团队的表现就好像小了五分之一，而薪资却丝毫未变。债务还会复利累积。在不稳固的基础上构建的每个新功能都会增加更多复杂性，所以除非投入一些精力偿还，损失的比例就会不断增大。还债现在要牺牲产出，所以人们总是很想推迟，这也是这个决策值得用数字来衡量的原因。
多米诺模型追踪这些损失。被债务占去的迭代比例减少了可用于新工作的产能，从而减少了交付的功能。功能变少，每一元薪资交付的价值就变少，而返工、救火和人员流动的负担随债务增长。最后一个框把交付的价值与团队的真实成本相比较。债务的小幅上升就可能把健康的回报变成亏损，因为薪资是固定的，而价值却不是。
冰山图展示了薪资那一行所隐藏的东西。可见的是薪资本身。水面之下，是花在返工上的那部分薪资、债务在生产环境中引发的救火、厌倦了陈旧代码库的工程师所造成的人员流动，以及从未开发的功能的价值。最后一项是永远不会出现在账目中的机会成本，却往往是最大的一项。请用模拟器找出团队不再能自负盈亏的债务水平，并测试还债方案是否值得。
公式与方法论蓝图
该模型是对产品团队的月度视图。薪资等于工程师人数乘以综合成本。迭代的一部分用于债务，一部分用于刻意还债，其余的用来开发新功能。交付的功能数等于工程师人数乘以每位工程师的功能数再乘以剩余的比例，按每个功能的价值估值。债务还会引发故障（按返工成本的一定比例）并提高人员流动，每次替换按四个月的综合薪资计价。在推演中，除非为还债提供资金，否则债务每月都会上升。
- 开发占比
- b = 1 − 债务 − 还债
- 迭代中投入新功能的部分。
- 交付的功能
- F = 工程师 × 每位工程师功能数 × b
- 一个月交付的新功能。
- 返工成本
- W = 薪资 × 债务
- 没有买到任何新价值的那部分薪资。
- 人员流动成本
- A = 工程师 × (1% + 0.06% × 债务点数) × 4 个月 × 成本
- 替换工程师的预期月度成本，随债务上升。
- 净结果
- 净额 = F × 价值 − 薪资 − 0.15 × W − A
- 交付的价值减去团队的真实成本。临界点就是它达到零的位置。
层层传导的弹性
债务占比是弹性最大的输入，因为它同时减少产出并增加故障和人员流动成本。每个功能的价值和每位工程师的功能数放大整个回报。薪资成本之所以重要，是因为它是价值必须超过的固定基数。
三个真实案例研究
白手起家的初创者
代码库干净的小团队
一个三人团队保持低债务，快速交付，并且相对于薪资，对每个功能的估值很高。返工很少。加载这个案例，可以看到干净基础的早期优势，以及只需要多少债务就会开始侵蚀它。
处于扩张期的中型市场企业
投入还债的大型团队
一个四十五人的团队背负着适度的债务，但从每个迭代中留出十分之一用于清理。功能以良好的速度交付，故障保持在低位。加载这个案例，可以看到为什么有纪律的还债能够规模化。
黑天鹅危机
无人能改动的高速增长代码库
一个二十五人的团队继承了多年的捷径。每个迭代超过一半的时间花在返工和故障上，人员流动率很高，还债时间为零。加载这个案例，可以看到庞大的薪资却产出甚微，以及哪个杠杆能让当月恢复。
行业基准矩阵
| 指标 | 危险区 | 行业平均 | 前 10% 的佼佼者 |
|---|---|---|---|
| 被返工占去的迭代比例 | 高于40% | 15–25% | 低于10% |
| 留给还债的时间 | 零 | 5–10% | 有需要时15–20% |
| 每一元薪资交付的价值 | 低于1.0 | 1.2–1.6 | 高于2.0 |
| 工程师月度流动率 | 高于2.5% | 1–1.5% | 低于1% |
| 故障工作占返工成本的比例 | 高于25% | 10–15% | 低于8% |
变量与杠杆
团队中的工程师
从事该产品的开发人员，按全职当量计算。
杠杆: 不要先给债务沉重的团队增加工程师，因为每位新人都要背上同样的拖累，并拖慢上手进度。
每位工程师每月综合成本
一位工程师一个月的薪资加上税费、福利、设备和管理开销。
杠杆: 薪资保持在市场水平，但削减隐性开销，因为每一个耗在债务上的小时都按全额综合费率支付。
被债务和返工占去的迭代
工程时间中花在变通方案、修复缺陷、缓慢的构建和与旧代码纠缠上而不是新功能上的比例。
杠杆: 让债务可见：列出最糟糕的模块，估算返工工时，并先修复涉及功能最多的那些。
每位工程师每月功能数（无债务）
如果没有时间损失在债务上，一位工程师一个月会交付多少个有意义的功能。
杠杆: 消除构建、测试和评审中的摩擦，因为开发者体验决定了一个人能交付多少功能。
已交付功能的月价值
一个典型功能上线后每月增加的收入、节省或留存，按您自己的估计。
杠杆: 交付能推动收入或留存的功能；如果交付的价值很低，再高的速度也无法让团队盈利。
投入还债的迭代
刻意用于减少债务的迭代比例。它现在会牺牲产出，但会在之后减少债务。
杠杆: 在每个迭代中固定留出一部分，通常是百分之十到二十，用于阻碍后续工作的债务。
如何使用本模拟器
- 1从“现实”预设开始，或输入您的团队规模、综合成本和估算的返工比例。
- 2查看五个多米诺框，看看是速度还是债务负担先变红。
- 3点击“找出我的临界点”，查看使团队无法盈利的债务占比。
- 4在24个月的图表上，将当前方案与还债方案进行比较。
- 5测量几个迭代的返工情况，并每季度重新审视该模型。
应避免的错误
- 因为薪资是固定的，就把耗在债务上的时间当作免费的，而实际上每一个小时都承担着全额的综合成本。
- 给一个缓慢的代码库增加工程师，并指望速度按比例提高。
- 计划一次大规模重写，而不是在债务阻碍后续工作的地方稳步还债。
- 忽视人员流动，它是令人不快的代码所带来的真实且反复出现的成本。
常见问题
如何估算被债务占去的迭代比例？
在几个迭代中，给属于返工、缺陷修复或变通方案的工单和拉取请求打上标签，然后用这部分时间除以总工程时间。再请团队给出一个大致的数字作为交叉检验。
所有技术债务都是坏事吗？
不是。为了更快学习或赶上截止日期而走捷径，可以是一笔好交易，前提是您追踪它并且偿还它。债务变成问题，是在它无人管理并且不断复利累积的时候。
我们应该花多少时间还债？
这取决于债务水平和即将到来的工作。稳定的百分之十到二十很常见，但应把它花在阻碍计划中功能的债务上，而不是为清理而清理。
如何给一个功能估值？
估算它每月增加的收入、留存或成本节省，哪怕只是粗略的。如果做不到，可以用平均收入增长除以已交付的功能数作为起点。
如何找到使团队亏钱的债务水平？
点击“找出我的临界点”。该工具会把每个输入向更差的一端移动，并报告使月利润归零的数值。
这有多准确？
这是一个带有明确假设的教学模型，不构成管理建议。真实的工程成果取决于许多因素。请用您自己的数据替换输入。
这是一个带有明确假设的教育性规划模型，不构成财务、税务或法律建议。请将输入替换为您自己的数据，并就重要决策咨询合格的专业人士。