“ Product Owner（PO）其实是敏捷交付里面最重要的角色之一，然而也是最难的角色。”

曾经在Facebook担任过产品经理的马丁内斯在他的书《混乱的猴子》里写到：

“在Facebook，产品经理产品经理就是一把大便伞，就是那把挡住脏东西的伞。因为Facebook内部的干扰信息太多了。比如，部门和部门之间互相排挤，层级制度太复杂，审批决策的周期太长，等等。有些需求，从作者提出想法，到最后扎克伯格拍板，前后用了一年多的时间。这个缓慢的节奏，还有复杂的外部信息，对开发人员的干扰太大了。所以，作为产品经理，他必须要把所有的坏消息都挡在外面，让技术人员安心搞开发。所谓大便伞，就是一个坏消息的屏障。”

这也许就是对类似产品经理这样的PO的角色的最生动的描述。

作为交付团队，我们都期望有PO帮我们挡“大便”，但这样的超人很难在现实中存在。

01

—

“我们什么都想要”

受到疫情影响，A公司的业务受到较大打击。由于第一季的收入锐减，业务部门也要大幅削减IT的支出。IT部门因此受到牵连，要收缩人员编制。

由于IT的人手变少了，年头计划的项目很多都无法继续，需要业务部门决定在现有预算下，把资源集中投放到哪些项目。

然而经过几周的讨论，业务依然无法给出清晰的决定。“所有项目对我们都很重要，我们都想要。”但对于IT部门来说，巧妇难为无米之炊。双方卡死了。

02

—

PO的窘境

如果业务部门连在预算有限的情况下，做哪些项目、不做哪些项目这么大的决定就难以做出，那么可以想象，要PO对产品、项目里更具体、更细节的需求或用户故事做决定，就更难了。

Product Owner（PO）是代表业务或产品、项目干系方，要为产品、项目中的需求或用户故事根据其业务价值做出优先级排序这样的业务决策的角色。

这个业务决策看似简单，实则不然。主要的困难就在于业务干系人可能来自不同部门、不同地区，他们都有各自的利益需要维护，因此难以达成统一的优先级。

我们期望有一个人可以挡在交付团队前，摆平各个业务部门和干系方，让交付团队聚焦在排序好的有限需求中，踏踏实实地完成交付。然而现实中这样的期望往往会落空。

得到的结果，往往也是什么都要做，使得交付团队疲于奔命。在这种情况下，产品、项目交付哪有不翻车的道理？可以说，优先级不清晰，或者优先级经常变化，是所有交付问题的万恶之源。

03

—

解决之道

对于这一难题，其实我也没有什么标准答案。这里只能抛砖引玉，以供大家一起探讨。

我想到的解决之道有三个：

重新定义业务产品

PO难的其中一个原因是对接的业务干系人众多，“众口难调”，而且他们之上又没有一个绝对的领导掌握这些细节作出决策。

我们需要和业务部门重新定义业务产品，满足以下三个条件：

1. 抛开现有组织架构、系统架构的限制，对接目标客户，简化决策关系；

2. 新的业务产品要能建立共同的使命和愿景；

3. 新的业务产品必须有一个绝对领导，这个领导的利益是和这个产品紧密捆绑的，TA也掌握大部分细节。

这个过程，主要就是要重塑权力关系、简化决策。

当这些新的业务产品定义好后，IT团队和系统架构也要进行重构，以实现与业务产品对齐，逐步与相关业务人员形成跨职能的自组织团队，实现产品化交付。

量化业务价值

也就是计算“延迟成本（Cost of Delay）”——计算每个请求如果逾期会造成的损失，折算成金钱，这样便可以量化所有请求的优先级。

延迟成本可以量化所有请求，从而基于它对所有请求进行排序，得到一个大家都必须认可的总列表。当然延迟成本的计算和校验并不容易。有成功实践的朋友可以在留言区分享。

服务等级

对于不同的请求类型，赋予不同的服务等级，区别处理。

在看板方法中，可以结合请求的服务等级做出不同的响应。常见的服务分类有：

1. 加急类（Expedite）——常见于一些时效性特别强的需求，或者对产品重大缺陷的修复。这一类请求将被视为最高优先级，因此可以无视最大在制品数（WIP）的限制，直接进行作业。然而这样的请求，很容易对看板的正常工作造成冲击，因此加急类的任务个数，通常都仅设置为1。

2. 固定交付日期类（Fixed Delivery Date）——推荐安排一定的产能，来处理一些固定交付日期的请求。对于这一类的请求，需要交付团队在开发之前对请求的工作量进行估算，并与PO确定目标交付日期，在开发过程中定期的确认进度。一旦发现进度落后到有可能无法完成的情况，则需要交付团队对请求重新进行评估。如有必要，这类请求可以升级为加急类。

3. 标准类（Standard）——最普通的请求。推荐大部分的产能都应用于此类请求。交付团队无需对请求的工作量进行估算，直接按照先进先出的顺序进行处理。但对于超过两周工作量的请求，建议先进行拆分。

4. 无形类（Intangible）——主要针对一些用户价值有限的附加功能。推荐安排在此类任务上的产能应该低于标准类。

这里重点在固定交付日期类，交付期限可以作为一个优先级排序的重要参考因子。

04

—

总结

客户和业务总是“贪婪”的。业务部门、PO不肯做决定，对所有项目、需求采取“不抛弃、不放弃”的原则是各种交付问题的“万恶之源”。业务部门组织关系复杂，利益不统一是其中一个重要原因。

重新定义业务产品，重塑权力关系是一个解决之道；通过计算每个需求的延迟成本，量化业务价值，是一个方法；在看板上建立服务等级，以目标交付期限作为优先级参考，也是一条出路。

近期必读：

为什么软件开发很难外包

以不变应万变——复杂系统回归测试新思路

为什么每个软件人都要懂点系统架构？

关于作者

刘华（Kenneth）

• 就职于世界500强银行，负责基金服务业务软件开发与交付

• 敏捷、精益、DevOps专家

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书

小说体敏捷/DevOps转型教科书

和实战经验分享

购书指南

—

纸质书、电子书在京东、当当、亚马逊、微信读书等渠道已全面上架，搜索关键字“猎豹 敏捷”即可找到。点击阅读原文可直接购书。

有声书已登录喜马拉雅、微信读书，适合路上听书的你。

关注公众号看其他原创作品

敏于思 捷于行

坚持每周输出一篇高质量文章

觉得好看，点个“在看”或转发给朋友们，欢迎你留言。