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



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



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



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



01“我们什么都想要”



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



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



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



02 PO的窘境



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



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



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



03 解决之道



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



重新定义业务产品



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



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

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

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



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



量化业务价值



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



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



服务等级



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



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



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



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



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



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



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



04 总结



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



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



分割线 卡通

近期必读：



为什么软件开发很难外包



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



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



关于作者





刘华（Kenneth）



• 敏捷、精益、DevOps专家

• 公众号“敏于思 捷于行”博主

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

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

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





小说体敏捷/DevOps转型教科书和实战经验分享



购书指南：



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

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