产品经理拥有广泛的知识，能够接触到公司的不同部门和利益相关者。这使得他们处于一个理想的位置，可以围绕预防和应对技术债务创造一种工作文化。我们提供了一些有用的策略。

根据Gartner的2019年产品经理调查，只有55%的产品发布如期进行。这对于按时发布产品的产品经理来说意义重大，因为他们更有可能在发布一年内达到内部目标。在45%的延迟发布的产品中，平均有20%无法达到内部目标。

未能在计划的时间范围内发布产品可归因于许多因素，包括缺乏正规的发布流程、产品开发的延迟（错误、故障、功能蔓延）、未能满足客户的要求、产品质量，甚至供应问题。另一个原因是技术债务。技术债务不仅让开发人员感到沮丧，还会导致一系列相关问题：未修补的错误意味着客户不满意。客户留下负面的产品评论，给营销团队带来挑战。不稳定的架构延迟了新特性的发布。销售周期受到影响。高级管理层和投资者对此会提出质疑。

产品经理在促进产品成功方面扮演着关键角色：愿景、特性、战略、产品发布、市场定位、竞争对手以及路线图。产品经理位于工程、销售、支持和营销互相交叉的十字路口，这意味着他们处于解决技术债务问题的独特位置。这里有一些会起到帮助的可行策略。

一、建立同盟关系

产品经理的职责应该包括与技术主管、首席技术官和其他部门主管建立牢固的关系。Gartner的调查发现，78%的产品经理将改善内部协作视为他们的三大任务之一，他们的产品失败率较低。花点时间定期与技术负责人交谈，共同了解公司内部技术债务的程度，并承诺予以解决。开发团队（不一定是管理层）中是否有任何拥护者愿意处理技术债务？避免让人们觉得技术债务是罪魁祸首。

相反，把注意力集中在解决债务对你的产品、公司和客户的积极意义上。鼓励管理层为减少技术债务提供激励措施，例如休息一天或外出娱乐活动。

二、让技术债务公开透明

技术债务无处不在，应该成为每一次产品会议的一部分。

让它成为一个可操作的项目，并寻求定期更新。

为了避免看起来仅仅像一个把关者，要努力让开发人员参与解决问题，并为解决技术债务这项工作设定优先级。

要清楚以下问题：

• 开发人员更喜欢在冲刺中还是专门的时间来解决技术债务？
• 哪个人负责哪块工作？
• 每个人目前工作量是多少？
• 是否需要更多员工？

三、进行必要的提问

产品经理的工作是一场在任务和时间线之间不断转换语境的战斗。产品经理可能是整个组织中对此最为擅长的人，他们对一个项目的方方面面都有过人的眼光。解决技术债务意味着战略和承诺，但首先需要确定问题的现实性。

以代码错误为例，它会延迟产品发布。理想情况是，组织正在跟踪和监控技术债务，并提供一个渐进的行动项目列表。

如果情况并非如此，提出开放性问题可以让你对问题的严重程度、潜在后果有一个现实而清晰的理解，并就前景展开对话。

玩个游戏吧，任何回答“视情况而定”的人都需要往罐子里放一美元。

询问内容示例如下：

• 是否有战略上的理由推迟解决方案（例如等待所使用的特定软件的技术升级）？
• 是否存在不需要修复的技术债务（如过时的产品供应）？
• 修复这段代码需要多少工作？
• 我们能承诺以后会修复这个代码吗？
• 谁将负责任何修复，时间表是怎样的？
• 此时间表是否与其他发布计划、功能更新等相冲突？
• 不修复此代码对当前客户和未来版本有何影响？
• 在我们致力于未来的返工或重构之前需要做些什么？

四、将技术债务的补救列入路线图中

将技术债务嵌入到路线图时间表中。分配任务和时间来进行Bug修复、代码审查、维护，以及全面减少现有债务，以构建更强大、更具弹性的产品。

让路线图尽可能地开放和可见，这样开发团队和其他同事就会觉得他们是产品循环的一部分。路线图应该是灵活多变的，但也应该包括一些应对技术债务的硬性截止日期。

记住：不是所有的东西都需要重构，你的目标是确定你在这个Sprint、一个月或一个季度所要做的事情的交集，以及你的代码库中有技术债务的部分。

要在这些交集点解决技术债务，而不是在交集之外解决。

五、参考技术债务制定KPI

将消除技术债务作为跟踪组织内成功的方式。

围绕具体参考技术债务的产品性能和开发速度创建KPI。

如果您的公司使用净推荐值（NPS，可反映口碑）来衡量客户忠诚度，这可能包括有关产品修复延迟、漏洞等的反馈。有时直接从终端用户那里获得反馈确实会看出问题。

六、考虑如何预防技术债务

与技术负责人探讨什么样的战略可以纳入项目过程，以减少技术债务。

这可能包括指导、团队培训和结对编程，了解这些是否可以包含进产品预算。找出将修复代码的责任全部放在一个人肩上的技能差距。

七、细心对待文档

一些开发团队努力创建一种机会主义重构的文化，在这种文化中，无论何时何地，只要代码需要清理，就会进行代码修复——不管是谁。

虽然这听起来很理想，但在工作量大的高峰时期不太现实。确保你的公司记录债务和清理债务的责任。

这应该是一份经常提及并付诸行动的“活”的文件。在团队成员发生变化的组织中，这一点尤为重要。