Luna职场 | PSPO II(敏捷开发产品负责人)

April 6, 2023 字数 1850 4 min


0. 前言

最近的工作和学习重心都放在了 Product Owner(敏捷开发产品负责人)这个角色上,从决定考 PSPO II 的证书开始到拿到证书,大概花了两个月的时间。

今天这篇文章来总结一下我学到的知识以及认知上的一些变化。


1. Product Owner 的核心价值

为什么要有 PO?

我第一次接触 Product Owner 这个词,大约是一年前准备 Scrum Master Certificate 考试的时候。

敏捷开发团队有三个角色:

  • Scrum Master
  • Product Owner
  • Developers

当时我对 Scrum 的认知,仅限于在每天早上雷打不动的 Daily Scrum 回答三个问题。

有了知识框架之后再回看我和同事们的职责,遗憾的是,我找了一圈也没找到 Product Owner 的角色。

产品负责人(PO)的核心职能之一是提供愿景和方向,可想而知,在一个没有 PO 的团队里,大家虽然天天在干活,但没有人能回答这些问题:

  • 干这些活是为了什么
  • 干这些活能产生怎样的影响
  • 干完了这些活之后再干什么?

Scrum Master 是 Scrum Facililator 的角色,主要职责是提升 Scrum Team 的协作效率,但是没有目标和方向,团队依旧无法把效率转化为价值。

所以,PO 很重要。

PO 的核心职责

  • The Product Owner is the person responsible for representing the interests of the stakeholders and for prioritizing the items on the product backlog.

  • The Product Backlog is an emergent, ordered list of what is needed to improve the product.

每一个产品都应该有一个产品负责人,不论这个产品是由一个敏捷团队开发,还是多个敏捷团队同时开发。

每一个产品都有大方向,PO 要把长期目标拆解成一个个小目标,跟 Stakeholders 和 Developer 沟通,厘清依赖关系,排好优先级。

每一个产品都有其单独(且唯一)的 Product Backlog,即使是多个团队同时开发。

如果用一个词来描述 PO 的职责,就是 “Value Maximizer”。

PO 所做的一切,都是为了达成一个最终目标 —— 提升客户对产品的满意度。

想要提升客户对产品的满意度,就必须持续为客户提供价值。

做 IT 产品往往伴随着巨大的不确定性(尤其是在产品刚起步的时候),PO 想要进行价值最大化,就必须采取「小步快跑」的策略,确定一个目标(假设),用 2-4 周的时间进行开发,然后发布产品,收集用户的使用数据来检验假设。

PO 是 Scrum Team 不可或缺的一员。

PO 需要跟 Developer 沟通,讨论想法的可行性,了解开发工作量,跟 Developer 一起制定 Scrum Plan,更重要的是在开发过程中根据 Developer 新发现的一些信息来做出投资回报率最高的决策。


2. 我做 PO 踩过的坑

我大约是在去年 9 月开始承担 PO 相关的职责的,到现在大半年了。

站在当下回想,如果我能回到过去,我会提醒自己注意以下四个陷阱:

1. 独立决策 or 集体决策?

PO 需要做很多决策,但绝大部分的决策都要依赖团队成员提供的信息和经验,结合自己的判断来做。

一开始做 PO 的时候,我认为我需要把所有的细节都想清楚,写出清晰的需求文档才能让程序员开工。

后来我慢慢意识到,我可能只需要有一个大方向(我想要达成什么目标)就可以跟程序员开会讨论细节了,决策也并不是我一个人做的,而是在讨论中达成的共识。

在决策过程中最重要的是搞清楚「问题」和「目标」,集体讨论时必须要先把这两点厘清对齐,接下来的讨论就会集中在「如何解决问题,达成目标」上。

2. 传话筒 or 产品负责人?

PO 还有一个坑,就是把自己看成 Stakeholder 和 Developer 之间的传话筒,这样的 PO 很难凝集人心,而且,久而久之 Developer 会直接跳过 PO 去跟 Stakeholder 沟通(这样效率更高)。

做 PO 必须对自己负责的产品有足够的热爱和激情,有愿景,有坚守,有勇气,有担当,有智慧,否则会非常没有成就感,也无法激发团队的潜能。

3. 程序员 or 用户?

PO 在某种程度上是用户的代言人,所以 PO 需要非常了解产品所提供的功能和用户的痛点,PO 必须是产品的「超级用户」。

这一个坑我其实过了蛮久才反应过来的,我很长一段时间都把自己当成了 PO + Developer,以为只有亲自去做一些技术工作才能了解产品,但后来我才发现,我应该把自己当成用户和测试员去体验产品。

4. 粉饰太平 or 直面现实?

PO 要有勇气面对现实,即使现实很丑陋。

这一点在跟 Stakeholder 沟通的时候尤为重要,我觉得一个好的 PO 是现实的乐观主义者,TA 不会回避产品目前存在的问题,不会回避团队存在的问题,TA 甚至不会回避自身的有限性——「我知道这个问题存在,但我目前没有一个好的解决方案,我需要帮助」。

PO 也许会有短暂的迷茫期,但 PO 不会轻言放弃,TA 是一个探索者,尝试者。

PO 会通过「假设——做——检验」这个闭环来快速学习和试错,最小化风险,确定产品下一步要怎么走。

当 Stakeholder 提出不切实际的需求时,PO 要有勇气 say no(并且给出理由),因为 PO 的核心职责是提升用户满意度,让产品价值最大化,减少资源浪费,而不是无条件满足 Stakeholder 的需求。


3. 结语

PO 这个角色,可以划水,也可以尽职,可以清闲,也可以忙碌,可以甩锅,也可以诚实面对。

有时候一天忙下来,心力交瘁,扪心自问:我为什么做 PO?

也许是因为,我能看到一个比现在美好很多倍的未来,所以我希望带着大家一起去看看吧。


Talk to Luna


Support Luna