根本不存在所谓的“技术任务”：技术任务就是产品任务

所谓“技术任务”比如测试、交付流水线、重构等本质上都应该服务于业务目标。真正有价值的技术工作能够提升产品的可靠性、可扩展性和可维护性并直接影响团队的研发效能和交付能力。如果不能像管理其他产品工作一样管理这些技术任务团队的持续交付能力迟早会受到影响。你是如何处理技术任务的我们都经历过类似的场景开发团队坚持要重写测试、重构某个模块或者自动化某条交付流水线。我们也都熟悉“技术债”这个概念甚至可能已经默认它是产品持续演进过程中不可避免的副产物。在现实中团队通常会用以下几种方式处理这类技术工作。随机加入技术任务。开发团队会根据需要把一些任务加入待办列表比如更新依赖库、清理旧代码、扩展集成测试等。团队通常会在“真正的”用户故事之间抽空处理这些任务。设立技术类史诗。团队会按照产品领域对任务进行分组比如围绕某个用户流程进行重构。在一些更糟糕的情况下他们还会按照技术组件来分组。划分固定时间。产品经理顺应开发人员的诉求允许他们拿出一定比例的时间专门处理“技术任务”。至于这些时间具体怎么用则由开发人员自行决定。维护单独的待办列表。技术任务被放在独立的看板、列表或文档中与面向用户的功能需求分开管理。无论采用哪种方式团队似乎都在负责“水管”和“电路”确保这座房子能够正常运转。这样大家就都满意了吗其实你知道并不是而且你也知道原因如果一项工作没有明确的业务价值它就不应该被执行。上述做法的核心问题在于我们始终没有真正对“技术任务”进行优先级排序。产品需求总是层出不穷面向用户的功能往往能对产品指标产生更直接、更可见的影响相比之下更新依赖库看起来就没那么重要。结果就是大量技术任务长期停留在待办列表底部而产品的核心能力却在这个过程中被慢慢侵蚀。这些做法还会带来另一种反模式团队把精力投入到并非最有价值的事情上。此时技术任务并没有像用户故事一样被评估优先级也没有被衡量其价值。我们见过一些开发团队在完成用户故事细化后又另起炉灶讨论如何用技术任务填满剩余产能。产品经理并不总是理解开发人员的决定甚至未必能看到这些决定而开发人员也不需要为这些工作的业务价值负责。那么我是在说你完全不应该重写测试、不应该更新依赖库、不应该重写旧代码吗当然不是。为什么说技术任务也是产品任务我们通常会把用户故事与业务目标联系起来更精准的搜索带来更多销售额全新的注册流程提升转化率更快的加载速度带来更高的用户满意度和更多推荐。那么我们是否也可以把同样的逻辑应用到技术任务上作为产品团队衡量成功的标准不只是业务影响还包括我们能否快速、稳定、可靠地创造这种影响。新功能上线后能够带来更多用户或更高转化率当然是一件好事但如果它需要六个月才能交付呢如果它导致系统长期不稳定呢你需要像对待用户故事一样根据关键成功指标来确定技术工作的优先级。这意味着要把这些工作与具体的业务目标、研发效能指标和价值指标联系起来。扩展自动化测试意味着团队可以更有信心地频繁发布版本。建立健康的持续交付模式能够缩短发布周期并改善反馈循环。更新旧代码和依赖项可以减少意外故障和安全风险。重构能够降低产品扩展过程中的维护成本。拆分服务则可能同时带来上述多种收益并让团队能够在边界清晰的范围内更自主地开展工作。但问题是我们如何判断这些工作的业务价值这就需要把相关影响因素放在一起综合评估。从业务目标、用户价值和交付能力出发下次进行待办事项讨论时你可能会看到新的功能需求、现有功能的迭代、一两个 bug以及若干个所谓的“技术任务”。这时该怎么办最好的做法是先从业务目标以及团队实现这些目标的能力出发对所有事项进行统一梳理和排序。在这一过程中研发管理工具的价值也会变得更加明确。例如团队可以借助智能化研发管理工具将团队目标、客户反馈、需求清理、评审排期、开发、测试、发布和知识沉淀串联起来让技术任务不再游离于产品目标之外而是和业务目标、研发效能指标、交付过程数据一起被管理和衡量。海外某些团队常用四项关键交付指标来衡量这种能力例如发布频率、交付周期、变更失败率和故障恢复时间。前面提到的各类工作都可能对这些指标产生影响从而帮助我们量化团队交付成果的方式。这样一来技术工作就更容易与用户故事放在一起进行优先级排序。本质上这些指标帮助我们回答一个问题这项工作是否能帮助我们更可靠地交付更多价值同时这四项关键交付指标也与业务成果高度一致。发布周期更短、变更失败率更低、故障恢复更快的团队能够更快地学习更快地响应用户反馈提升用户满意度并最终推动业务增长。我们必须停止把技术任务与产品待办事项割裂开来。我们所做的一切工作都应该指向更好的业务成果并增强团队持续交付这些成果的能力。将所有待办事项放在同一套目标框架下意味着团队不仅对目标成果形成共识也对实现这些成果所需的工作形成共识。结语用产品思维管理技术任务技术任务不应该被视为产品工作之外的“额外事项”。测试、重构、依赖更新、持续交付流水线优化等工作只有与业务目标、用户价值和交付能力建立联系才能真正体现其价值。当团队用产品思维管理技术任务时技术债不再只是开发团队自己的问题而会成为整个产品团队共同管理、共同取舍、共同负责的一部分。