技术债务和产品成功

与经历财务债务的公司类似，产品可能会产生“技术债务”：如果采用错误或次优的架构，技术和编码决策，就会发生这种情况。 因此，该体系结构可能没有应有的松散耦合，并且代码可能是混乱的，而不是干净的。 本文解释了为什么产品人员应该关心技术债务并提供了解决该问题的策略。

为什么技术债务对产品人员很重要

作为产品负责人，您可能不必担心代码的简洁性和结构性。 但是您的产品质量很重要：它直接影响您实现战略性产品目标和使您的产品成功的能力：技术欠债使得难以尝试新想法，发布新功能并快速响应用户反馈。 [1]

代码越杂乱，架构的模块化程度越低，花费的时间越长，更改产品的成本就越高。 在最坏的情况下，您必须进行重写练习，其中某些部分甚至整个产品都需要重新开发。 这类似于金融债务：当债务没有偿还时，利息支付会成倍增加，并最终使业务瘫痪。

技术债务和您的产品

要了解您的产品是否受到技术债务的影响以及在何种程度上受到技术债务的影响，例如，在下一个Sprint回顾中与开发团队联系。 我发现开发团队成员通常对架构和代码中的问题有很好的了解。

此外，考虑要求团队收集数据，以表明存在多少技术债务，债务位于何处以及债务有多严重，例如，通过使用代码复杂性，依赖性，重复性和测试覆盖率作为指标。 有许多可用的代码分析工具可以收集适当的数据，并显示体系结构的适应性以及代码的干净程度。 [2]

了解产品中技术债务的数量和严重性后，请与开发团队一起分析其对达到产品目标和取得产品成功的影响。 考虑到延迟的成本，即不立即解决技术债务而是将其延迟到未来某个时间点的成本。 例如，您是否应该在接下来的六个月中继续向产品添加新功能，然后计划进行更大的技术改进工作？ 还是现在解决最坏的债务会更好？

此外，请考虑产品的生命周期阶段。 技术债务对新产品和新产品尤其不利：如果您的产品具有紧密耦合的体系结构且具有很多依赖性，如果产品缺乏（自动）测试和文档，或者如果产品中包含意大利面条代码，则尝试使用新的想法并使产品适应用户反馈和新趋势将是困难且耗时的。 同样，如果要延长其产品生命周期 ，则可能必须先消除（部分）技术债务，然后才能进行必要的更改并添加新功能或创建变体。

话虽如此，这是发布最低可行产品（MVP）的有效策略，只要其质量，质量足以使产品适应市场需求，就可以缩短其产品的结构，技术和代码，以缩短上市时间。早期市场的反馈。 但是，请谨慎应用此策略：您将不得不花时间解决所产生的技术债务，并将产品置于坚实的技术基础上。 这应该在达到产品市场适应性之前完成，否则您将难以扩大规模并保持产品增长。

但是，如果您的产品已到期（甚至下降），并且您不打算延长其生命周期，而是专注于最大程度地提高其产生的业务收益，则您可能希望尽可能少地进行债务清算工作。

消除技术债务的选项

一旦确定了多少技术债务以及需要解决的时间，您将面临两种选择：您可以花时间进行专心的工作，并花一定的时间清除债务，或者可以进行与增强产品和添加新功能并行进行的工作。

每当您面对构成创新障碍的大量技术债务时，都应该选择一个专门的期限将其删除。 苹果使用Mac OS X Snow Leopard做到了这一点，该产品经过近两年的工作于2009年发布。 尽管Snow Leopard没有提供任何新功能，但它例如通过提高性能和减少操作系统的内存占用量为将来的发行版奠定了基础。

我并不是建议您一定要像苹果那样花一年或更长时间来重构产品。 但是，集中精力并花费几个月或至少一两个冲刺来清理软件可能会更有效，而不是在多个发行版本中滴加它。 可以说，您有意放慢速度，然后再加快速度。

如果重构版本对您来说是正确的方法，那么您的产品路线图应该反映出这一点：它应该显示一个专门用于对产品进行过时验证并进行必要的技术更改的版本。

但是，如果技术债务不那么重要并且不需要紧急解决，则应及时计划在每次冲刺中消除一些债务，同时继续改善用户体验并添加或增强功能。 您可以通过在产品待办事项列表中添加技术债务补救项目来实现。 这使必要的工作可见，并允许您跨冲刺和发行版进行跟踪。 但是，请确保确实进行了必要的工作，并且要求更多功能不会阻止技术债务的消除。 （我的文章“ 通过创新和维护获得成功 ”讨论了如何同时修复错误和添加新功能。）

防止技术债务

故意破坏代码质量以发布版本并接受技术债务都是好事，只要您在事后真正消除债务即可。 但是，根据我的经验，技术债务常常是无意中造成的。

数字产品需要持续关注其体系结构和代码。 否则，产品质量将变差，从而导致技术债务增加。 这非常类似于定期保养自行车，理想情况下是每次骑车之后。 而且，您对自行车的依赖程度越高，您就应该更多地关心，清洁和修理或更换有故障的零件。 挑战是要花时间进行必要的清理和维护工作，并将其视为自行车骑行经验的一部分，而不是琐事。

数字产品也是如此：有些团队感到非常仓促和压力，以至于他们屡屡偷工减料，没有采用良好的软件Craft.io实践，例如演化架构，测试驱动的开发，结对编程和持续集成。 但是，这些做法不仅有助于创建适应性强的体系结构和简洁的代码库。 如果使用得当，它们将加快开发速度，并允许您更快而不是更慢地发布新功能，在我的经验中，后者是普遍的误解。 反之亦然：如果开发团队没有采用正确的做法和工具，则该软件可能会很脆弱，不柔软且难以延展。

如果您想避免未来的技术债务，请给您的开发团队时间学习，应用和改进正确的开发实践 。 实际上，您应该期望开发团队以适当的质量创建产品增量。 做到这一点的一种好方法是采用“完成的定义”，该定义规定了代码复杂度限制和测试覆盖率目标，并且仅接受满足该定义的工作结果。

笔记

[1]技术债务最初是由沃德·坎宁安 （ Ward Cunningham）提出的，而马丁·福勒 （ Martin Fowler）对此做了很好的解释。 感谢Yves Hanoulle鼓励我写这本书。

[2]我建议您将软件质量添加到KPI中并定期进行跟踪。 质量是领先的指标：如果质量下降，那么您知道更改产品将变得越来越困难，除非您对此有所行动。 知道是否累积了多少技术债务可以帮助您积极主动并避免令人讨厌的意外。

翻译自: https://www.javacodegeeks.com/2018/12/technical-debt-product-success.html