做PO难,难于上青天

发布于: 2020 年 05 月 31 日
做PO难,难于上青天

 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转型教科书和实战经验分享

购书指南:

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

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

发布于: 2020 年 05 月 31 日 阅读数: 4
用户头像

刘华Kenneth

关注

敏捷、精益、DevOps专家 2017.10.19 加入

著有《猎豹行动:硝烟中的敏捷转型之旅》一书;敏捷、精益、DevOps专家;公众号“敏于思 捷于行”博主;曾在国内多个大型论坛发表过主题演讲;就职于世界500强银行。

评论

发布
暂无评论
做PO难,难于上青天