产品经理拥有广泛的知识,能够接触到公司的不同部门和利益相关者。这使得他们处于一个理想的位置,可以围绕预防和应对技术债务创造一种工作文化。我们提供了一些有用的策略。
根据Gartner的2019年产品经理调查,只有55%的产品发布如期进行。这对于按时发布产品的产品经理来说意义重大,因为他们更有可能在发布一年内达到内部目标。在45%的延迟发布的产品中,平均有20%无法达到内部目标。
未能在计划的时间范围内发布产品可归因于许多因素,包括缺乏正规的发布流程、产品开发的延迟(错误、故障、功能蔓延)、未能满足客户的要求、产品质量,甚至供应问题。另一个原因是技术债务。技术债务不仅让开发人员感到沮丧,还会导致一系列相关问题:未修补的错误意味着客户不满意。客户留下负面的产品评论,给营销团队带来挑战。不稳定的架构延迟了新特性的发布。销售周期受到影响。高级管理层和投资者对此会提出质疑。
产品经理在促进产品成功方面扮演着关键角色:愿景、特性、战略、产品发布、市场定位、竞争对手以及路线图。产品经理位于工程、销售、支持和营销互相交叉的十字路口,这意味着他们处于解决技术债务问题的独特位置。这里有一些会起到帮助的可行策略。
建立同盟关系
产品经理的职责应该包括与技术主管、首席技术官和其他部门主管建立牢固的关系。Gartner的调查发现,78%的产品经理将改善内部协作视为他们的三大任务之一,他们的产品失败率较低。花点时间定期与技术负责人交谈,共同了解公司内部技术债务的程度,并承诺予以解决。开发团队(不一定是管理层)中是否有任何拥护者愿意处理技术债务?避免让人们觉得技术债务是罪魁祸首。相反,把注意力集中在解决债务对你的产品、公司和客户的积极意义上。鼓励管理层为减少技术债务提供激励措施,例如休息一天或外出娱乐活动。
让技术债务公开透明
技术债务无处不在,应该成为每一次产品会议的一部分。让它成为一个可操作的项目,并寻求定期更新。为了避免看起来仅仅像一个把关者,要努力让开发人员参与解决问题,并为解决技术债务这项工作设定优先级。要清楚以下问题:开发人员更喜欢在冲刺中还是专门的时间来解决技术债务?哪个人负责哪块工作?每个人目前工作量是多少?是否需要更多员工?
进行必要的提问
产品经理的工作是一场在任务和时间线之间不断转换语境的战斗。产品经理可能是整个组织中对此最为擅长的人,他们对一个项目的方方面面都有过人的眼光。解决技术债务意味着战略和承诺,但首先需要确定问题的现实性。以代码错误为例,它会延迟产品发布。理想情况是,组织正在跟踪和监控技术债务,并提供一个渐进的行动项目列表。如果情况并非如此,提出开放性问题可以让你对问题的严重程度、潜在后果有一个现实而清晰的理解,并就前景展开对话。
玩个游戏吧,任何回答“视情况而定”的人都需要往罐子里放一美元。询问内容示例如下:
是否有战略上的理由推迟解决方案(例如等待所使用的特定软件的技术升级)?
是否存在不需要修复的技术债务(如过时的产品供应)?
修复这段代码需要多少工作?
我们能承诺以后会修复这个代码吗?
谁将负责任何修复,时间表是怎样的?
此时间表是否与其他发布计划、功能更新等相冲突?
不修复此代码对当前客户和未来版本有何影响?
在我们致力于未来的返工或重构之前需要做些什么?
将技术债务的补救列入路线图中
将技术债务嵌入到路线图时间表中。分配任务和时间来进行Bug修复、代码审查、维护,以及全面减少现有债务,以构建更强大、更具弹性的产品。
让路线图尽可能地开放和可见,这样开发团队和其他同事就会觉得他们是产品循环的一部分。路线图应该是灵活多变的,但也应该包括一些应对技术债务的硬性截止日期。
记住,不是所有的东西都需要重构,你的目标是确定你在这个Sprint、一个月或一个季度所要做的事情的交集,以及你的代码库中有技术债务的部分。要在这些交集点解决技术债务,而不是在交集之外解决。
参考技术债务制定KPI
将消除技术债务作为跟踪组织内成功的方式。围绕具体参考技术债务的产品性能和开发速度创建KPI。如果您的公司使用净推荐值(NPS,可反映口碑)来衡量客户忠诚度,这可能包括有关产品修复延迟、漏洞等的反馈。有时直接从终端用户那里获得反馈确实会看出问题。
考虑如何预防技术债务
与技术负责人探讨什么样的战略可以纳入项目过程,以减少技术债务。这可能包括指导、团队培训和结对编程,了解这些是否可以包含进产品预算。找出将修复代码的责任全部放在一个人肩上的技能差距。
细心对待文档
一些开发团队努力创建一种机会主义重构的文化,在这种文化中,无论何时何地,只要代码需要清理,就会进行代码修复——不管是谁。虽然这听起来很理想,但在工作量大的高峰时期不太现实。确保你的公司记录债务和清理债务的责任。这应该是一份经常提及并付诸行动的“活”的文件。在团队成员发生变化的组织中,这一点尤为重要。