Ste*_*ins 18 technical-debt roi
我目前正在使用一种相当古老的产品,这种产品背负着来自糟糕的程序员和过去糟糕的开发实践的大量技术债务.我们开始变得更好,技术债务的创造已经大大减缓.
我已经确定了应用程序中处于不良状态的区域,我可以估算修复这些区域的成本,但我很难估计投资回报率(ROI).
代码将更容易维护,并且将来更容易扩展,但我怎样才能在这些代码上加上一个美元数字呢？
一个好的起点就像回到我们的错误跟踪系统并根据与这些"坏"区域相关的错误和功能来估算成本.但这似乎很耗时,可能不是最有价值的预测因素.
有没有人过去做过这样的分析,对我有什么建议？
管理者关心通过增长实现增长(首先是例如吸引新客户的新功能)和(第二)通过优化流程生命周期.
看看你的问题,你的建议属于第二类:这无疑会落后于目标#1(因此即使可以节省资金也可以优先考虑...因为省钱意味着花钱(至少大部分时间; - )).
现在,在"糟糕的技术债务"上加上一个数字可以转变为更积极的旋转(假设以下情况适用于您的情况):"如果我们投资重新组合X,我们可以更快地引入特征Y,从而得到更多的客户".
换句话说,评估技术债务的成本与失去的商业机会的成本.