在软件开发中，技术债务是指当开发人员实施更快，更短期的解决方案而不是更优化（但更劳动力更强的）解决方案时积累的工作量。
技术债务使用金融隐喻来说明今天如何短期的决定，如利息借款，在未来可能会产生放大效应，比如由于很多利息，被剥夺额外信贷，损害你的信用评分等等。看起来像是一个好主意，可以得到这笔贷款，并把这辆新车从今天推出，但前提是你可以始终如一地付款。否则，在路上会给你造成很大的麻烦。
技术债务也是如此。这并不总是一件坏事，这当然不是“懒惰”开发商“走捷径”的结果。通常，技术债务可能是一个很好的方式，让一个MVP出门，击败竞争对手的市场。 也许你今天没有实现最优雅的解决方案，但是你可以更快地创造收益，并且可以在未来挖掘时间来解决和修改这些问题。
技术债务也往往是由于对开发团队不切实际的时间或资源限制而产生的。如果你给开发者一个或两个星期的冲刺来完成一个月的工作，你就要为自己的技术债务（可能还有一群愤怒的开发者）做好准备。
所以，作为一名产品经理，如何避免不必要的债务和谈判现有的债务，而又不放慢速度或拖延创新？这里有一些提示来帮助。
1.将技术债务作为与开发人员进行每次对话的一部分。
赔率是你的开发团队非常熟悉现有的技术债务。他们也很有可能提供债务相关的见解，这些见解可以帮助您权衡当前正在制定的规划决策的利弊。
这个：
“让技术债务成为与开发人员进行每一次谈话的一部分。”
在计划会议中使技术性债务成为谈话中反复出现的话题，有助于将重点放在长期改进，灵活性和可扩展性上。问工程问题这些类型的问题将帮助您决定何时承担额外的债务，或者何时投入更多的资源来削减现有的债务以及其他的发展活动：
现在这条捷径能拯救我们什么？
我们今天选择了一个不太理想的解决方案，从而获得了什么？
这会给我们什么样的挑战或限制呢？
我们是否完全明白了为什么我们今天不能解决这个问题呢，还是在未来重做或重构之前需要进一步调查？
我们是否完全理解这个解决方案所涉及的依赖关系？它会不仅影响桌面上的功能？
如果我们承担这笔债务，未来的影响是什么？
这个时间表是否与其他版本计划，功能更新等相冲突？
我们可以把这个关闭多久？
我们是否因为一个战略原因而放弃这个，也就是说，如果我们等待，我们是否怀疑会有更好的方法来解决这个问题呢？
一旦你实现了一个工具，建立一个框架等，它立即开始变得过时。有些债务是可以预料的，这很好-你需要了解的是你在做任何决定时妥协的东西，以及这个合理的时间有多长，即代码有点难看，但是我们需要一个新的组件图书馆，这可能是解决这个问题的好时机。
2.成为维护组织的倡导者。
将一些具体的开发时间百分比用于一切照常的活动，包括错误修复，系统维护和技术债务是一个相当明显的解决方案，但需要一些组织的支持才能使其成为文化的标准部分。
技术债务充其量是一个永远的提醒，说：“嗨，我在这里，记得当你选择这个快速解决？我也是。如果有时间的话，请在一定程度上帮助我。“最糟糕的是，技术债务是一个噩梦，会影响到您的开发团队的梦想，并且不断影响应用程序的稳定性。但是，这并不意味着利益相关方想要听取关于为什么要优先考虑一些基础架构更新的解释，而不是让他们更加兴奋的新功能。
建立与债务相关活动的热情的一个策略是花时间来说明如果不解决技术债务会发生什么情况。根据我们的经验，如果每个人都同意需要解决债务问题，那么90％的时间是因为您无法在当前现状下添加新功能，或者如果现在解决问题，开发工作将以指数方式更快。
作为一名产品经理，您可以主张为债务相关的项目划分开发时间的重要性。在您的产品和工程设计路线图上构建一个专门用于错误修复，日常维护以及逐步消除技术债务的泳道，将确保您在推进产品的同时削弱其弱点和弱点。这种持续的方法可以帮助您避免在某个无法启动新功能的地方打墙，因为您的架构不够稳定，无法支持。
3.开发与基本产品预期相关的KPI。
帮助确定解决技术债务工作优先级的一种方法是在您的产品性能或开发速度方面具有关键绩效指标（KPI）。在ProductPlan中，我们将NPS反馈细分，以了解用户对产品Web体验满意或不满意的地方。我们已经采取了一些措施来提高我们NPS评分的这个要素，并且可以用它作为客观的方式来评估框架改变的优先级。
对于一个网站来说，您可能会在加载时间或其他指标方面有具体的目标，只能通过解决技术债务来改善。例如，我们最近进行了一个升级，涉及到我们的应用程序在Web浏览器中的功能。之前的框架工作正常，但是我们意识到如果事情没有更新，我们正在准备的新功能将会遇到一些动荡。所以我们更新了它们。
如果你要面对一种并不特别重视技术债务管理重要性的文化，那么作为一名产品经理，你还可以优先考虑取决于某些技术债务的与功能相关的工作。例如，您可以包含一个要求，即您的应用程序的特定部分显示更快，知道特定速度问题与潜在债务相关联。
4.鼓励你的开发团队跟踪其他开发项目的技术债务。
一个清单来统治他们。有了技术债务，你现在基本上获得了一些直接的好处，并把一个更大的项目转移到未来。这里的想法是，这些任务实际上是在积压的地方结束，在那里可以跟踪和优先处理其他活动。如果他们在其他地方登录，他们不太可能完成，并且在规划期间不太可能被考虑。
在您的积压项目上保留技术债务还有另一个好处，即强调解决这些问题与解决新的开发任务一样重要。换句话说，没有“重要的新功能积压”和“不重要的技术债务积压”。把所有东西都放在一个地方，有助于确定优先级过程。你想避免一个特定的物品通过裂缝下降，直到有什么事情发生之前保持未被发现的情况。
这个：
“鼓励你的开发团队跟踪跟踪其他开发项目的地方的技术债务。”
另一种防止债务脱落的方法是将其作为史诗的一部分进行追踪，并与开发人员定期合作。这与我们在第一个提示中提到的问题之一有关，因为有时技术性债务本身已经过时。作为项目A的一部分被提到，但是由于项目B的工作，这不再是一个问题。或者更新部分产品A非常重要，但是，例如，您已经将许多底层基础架构迁移到了AWS，所以现在实际上并不是问题。重要的是记录债务并追踪它;把它放在某个地方，以确保对话是积极的，但保持清洁。
5.帮助开发者围绕技术债务做一些情况规划。
作为一名产品经理，您经常可以进行情境规划，确定工作的优先顺序，以及处理“如果”情景。技术债务是帮助您的开发团队参与类似活动的绝佳工具。把它作为你的计划活动的一部分，让你的开发团队提出请求，建立一个愿望清单，等等。你一直在做你的客户和他们的功能需求的这种练习。如果开发商为了解决债务而给予了X个冲刺或数月的话，他们会做什么？这将如何立即改变产品的性能？这些变化将如何影响产品路线图？
您可能会意识到，在开始实施一系列新功能并对现有产品路线图进行更改之前，解决基础架构级项目会带来巨大的好处。你可能不会。但是，与开发者分享你的路线图，同时分享他们对债务相关优先事项的思考，是将这些潜在问题直接与你的路线图（以及收入，客户增长等战略目标）联系起来的好方法。这也是一个很好的机会开发人员如何考虑优先级，解决问题等等。像这样的活动可以帮助产品经理发展更多的同理心，并加强产品工程关系。
6.规划合理的冲刺工作量。
正如我们在介绍中提到的，积累技术债务的最简单方法是在太短的时间内向开发者提出太多要求。在开发产品路线图时与工程师协商，以确保您对时间表的期望与其带宽合理匹配。
有时，承担技术债务是不可避免的（而且这绝对不是一件坏事），但作为产品经理，你的工作的一部分就是确保你的产品持续健康。
如果技术债务开始失控，那么你最终会和客户和开发团队一起感到痛苦。如果您可以将技术债务视为您产品和开发团队的组织价值，那么您应该能够更好地确保产品的长期灵活性和健康。这有助于促进产品和工程之间更好的沟通，同理心和透明度。
作为产品经理有更多关于管理技术债务的想法吗？分享他们在下面的评论。