---

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？

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