产品经理领有宽泛的常识，可能接触到公司的不同部门和利益相关者。这使得他们处于一个现实的地位，能够围绕预防和应答技术债权发明一种工作文化。咱们提供了一些有用的策略。
依据 Gartner 的 2019 年产品经理考察，只有 55% 的产品公布如期进行。这对于按时公布产品的产品经理来说意义重大，因为他们更有可能在公布一年内达到外部指标。在 45% 的提早公布的产品中，均匀有 20% 无奈达到外部指标。
未能在打算的工夫范畴内公布产品可归因于许多因素，包含不足正规的公布流程、产品开发的提早（谬误、故障、性能蔓延）、未能满足客户的要求、产品质量，甚至供给问题。另一个起因是技术债权。技术债权不仅让开发人员感到丧气，还会导致一系列相干问题：未修补的谬误意味着客户不称心。客户留下负面的产品评论，给营销团队带来挑战。不稳固的架构提早了新个性的公布。销售周期受到影响。高级管理层和投资者对此会提出质疑。
产品经理在促成产品胜利方面扮演着要害角色：愿景、个性、策略、产品公布、市场定位、竞争对手以及路线图。产品经理位于工程、销售、反对和营销相互穿插的十字路口，这意味着他们处于解决技术债权问题的独特地位。这里有一些会起到帮忙的可行策略。
建设同盟关系
产品经理的职责应该包含与技术主管、首席技术官和其余部门主管建设牢固的关系。Gartner 的考察发现，78% 的产品经理将改善外部合作视为他们的三大工作之一，他们的产品失败率较低。花点工夫定期与技术负责人交谈，独特理解公司外部技术债权的水平，并承诺予以解决。开发团队（不肯定是管理层）中是否有任何拥护者违心解决技术债权？防止让人们感觉技术债权是罪魁祸首。相同，把注意力集中在解决债权对你的产品、公司和客户的积极意义上。激励管理层为缩小技术债权提供激励措施，例如劳动一天或外出娱乐活动。
让技术债权公开通明
技术债权无处不在，应该成为每一次产品会议的一部分。让它成为一个可操作的我的项目，并寻求定期更新。为了防止看起来仅仅像一个把关者，要致力让开发人员参加解决问题，并为解决技术债权这项工作设定优先级。要分明以下问题：开发人员更喜爱在冲刺中还是专门的工夫来解决技术债权？哪个人负责哪块工作？每个人目前工作量是多少？是否须要更多员工？
进行必要的发问
产品经理的工作是一场在工作和工夫线之间一直转换语境的战斗。产品经理可能是整个组织中对此最为善于的人，他们对一个我的项目的方方面面都有过人的眼光。解决技术债权意味着策略和承诺，但首先须要确定问题的现实性。以代码谬误为例，它会提早产品公布。现实状况是，组织正在跟踪和监控技术债权，并提供一个渐进的口头我的项目列表。如果状况并非如此，提出开放性问题能够让你对问题的重大水平、潜在结果有一个事实而清晰的了解，并就前景开展对话。玩个游戏吧，任何答复“视状况而定”的人都须要往罐子里放一美元。询问内容示例如下：
●是否有策略上的理由推延解决方案（例如期待所应用的特定软件的技术升级）？
●是否存在不须要修复的技术债权（如过期的产品供给）？
●修复这段代码须要多少工作？
●咱们能承诺当前会修复这个代码吗？
●谁将负责任何修复，时间表是怎么的？
●此时间表是否与其余公布打算、性能更新等相冲突？
●不修复此代码对以后客户和将来版本有何影响？
●在咱们致力于将来的返工或重构之前须要做些什么？
将技术债权的补救列入路线图中
将技术债权嵌入到路线图时间表中。分配任务和工夫来进行 Bug 修复、代码审查、保护，以及全面缩小现有债权，以构建更弱小、更具弹性的产品。
让路线图尽可能地凋谢和可见，这样开发团队和其余共事就会感觉他们是产品循环的一部分。路线图应该是灵便多变的，但也应该包含一些应答技术债权的硬性截止日期。
记住，不是所有的货色都须要重构，你的指标是确定你在这个 Sprint、一个月或一个季度所要做的事件的交加，以及你的代码库中有技术债权的局部。要在这些交加点解决技术债权，而不是在交加之外解决。
参考技术债权制订 KPI
将打消技术债权作为跟踪组织内胜利的形式。围绕具体参考技术债权的产品性能和开发速度创立 KPI。如果您的公司应用净推荐值（NPS，可反映口碑）来掂量客户忠诚度，这可能包含无关产品修复提早、破绽等的反馈。有时间接从终端用户那里取得反馈的确会看出问题。
思考如何预防技术债权
与技术负责人探讨什么样的策略能够纳入我的项目过程，以缩小技术债权。这可能包含领导、团队培训和结对编程，理解这些是否能够蕴含进产品估算。找出将修复代码的责任全副放在一个人肩上的技能差距。
仔细看待文档
一些开发团队致力创立一种机会主义重构的文化，在这种文化中，无论何时何地，只有代码须要清理，就会进行代码修复——不管是谁。尽管这听起来很现实，但在工作量大的顶峰期间不太事实。确保你的公司记录债权和清理债权的责任。这应该是一份常常提及并付诸行动的“活”的文件。在团队成员发生变化的组织中，这一点尤为重要。