产品负责人（Product Owner）的6大职责以及与产品经理区别

敏捷开发中，Scrum 是这样的人：保证团队一起顺利工作，迅速清除挡路石，团队有效地朝着目标前进。而 Product Owner 是保证团队瞄准正确目标的人。优秀团队需要这两个角色才能取得成功：Product Owner 为团队指出正确的目标；Scrum Master 帮助团队尽可能有效地达到目标。

一、什么是 Product owner

Product Owner 是敏捷开发中的核心角色之一，每个敏捷团队有且仅有一个 Product Owner ，他是有授权的产品领导力核心，组成 Scrum 团队三个角色之一。在开发中，Product Owner 很多时候担任的是产品经理的角色，作为确保团队做出正确产品，以便帮公司得到最高投资回报，所以这个角色在 Scrum中负责“做什么”的问题。

不同公司，不同部门，不同团队的 Product Owner 的具体职责也不尽相同。总体上来说，Product Owner 要负责产品的愿景和边界。而具体来说，Product Owner 的工作是为客户的需求提出正确的解决方案和确保解决方案被正确“制造”。

Scrum组织中项目管理职责的映射

二、Product Owner 的职责是什么？与产品经理有什么区别

1、Product Owner 的职责

Product Owner 的核心职责包括：对产品的ROI负责、梳理产品待办列表，确定优先级、参与规划开发活动、定义完成标准等。

• 对产品的 ROI 负责：ROI = profitability of the product，ROI 即为产品的盈利负责，或考虑产品的投资回报率。
• 梳理产品列表，确定产品功能：Product Owner 负责梳理产品列表，包括PBI的建立、细化、估算和排列优先级顺序。在估算期间负责澄清需求。
• 参与规划活动：Product owner 是做组合规划、产品规划、版本规划和 Sprint 规划的重要参与者。
• 定义接收标准并验证工作成果：Po 负责为每一个 PBI 定义验收标准，只有达到这些条件才确信功能需求和非功能需求已经满足。
• 与开发团队合作：Product Owner 必须经常与开发团队保持紧密合作，每天参与到团队活动中， Product owner 与开发团队一起确定 Sprint 目标。
• 与利益干系人合作：Product owner 与利益干系人一起制定产品愿景，以及确定下一个版本的内容。内部利益干系人：业务系统负责人、行政管理人员、项目管理人员等外部利益干系人：客户、用户、合作伙伴等。

Product Owner 的技能包括：

• 领域技能：有预见性，且知道有些事无法预见，具备业务和领域相关知识；
• 人际交往能力：具备良好的沟通能力，能和利益干系人搞好关系，促成谈判达成一致意见；有正能量，让团队保持热情；
• 决策力：获得授权，有决断力，敢于制定决策；能够从经济的视角权衡业务/技术问题；
• 责任心：承担产品责任、由团队意识、参与 Scrum 团队活动；

2、Product Owner 和产品经理的区别

很多年了，人们一直在讨论产品经理和 Product Owner 角色之间的区别。这两个角色是否可以共存，以及应该使用哪一个角色。这一小节谈谈对这个问题的一些想法。

大家都遇到什么问题了呢？

您可能知道，Product Owner 源自 Scrum，其最大的职责是“最大化产品的价值”。听起来像是教科书上产品管理的职责范畴。尽管如此，Product Owner 经常被认为是一个战术角色，负责管理 Product Backlog，细化产品需求、以及和开发团队进行协作，那这样的职责定义到底是怎么来的呢？

这些困惑至少部分是自于 Scrum 本身，Scrum 是一个关注在帮助团队开发软件的简单框架。 整个过程并不包含大家所熟悉的产品管理实践，例如产品战略，产品规划、路线图，以及成本预测，并且只介绍了唯一的一个产品管理工具——Product Backlog（产品待办列表）。

另外，像 SAFe 这样的一些方法，考虑到大规模的敏捷，采用了独立的产品经理和 Product Owner 角色。使用战略产品角色和战术产品角色是大规模敏捷的一个常用的实践。但在我看来，把 Product Owner 只作为一个战术角色是一个错误：因为在 SAFe 中的 Product Owner 并不等同于 Scrum 中的 Product Owner。存在两种不同的 Product Owner 角色会让大家更加的混淆。

那么我们该怎么办呢？那为什么 Scrum 需要引入一个 Product Owner 的角色？

为什么在 Scrum 不直接使用产品经理这个术语？ 让我们回到 Scrum 开始创建的上世纪九十年代， 那个时候产品的管理和当今是截然不同的。产品经理经常做的市场调研，产品的规划和需求的定义。大多数人把需求文档交由项目经理管理，因为项目经理和开发团队工作密切且负责最后上线的测试。 产品经理的职责只是修改需求或者帮助产品发布。

这与敏捷流程中的工作方式形成了鲜明对比，在敏捷环境下，产品人员需要和开发团队持续合作，同时也不能忽视市场和公司内部的相关干系人。

其次， Scrum 应用于产品开发和商业软件产品领域之外。 许多使用Scrum的组织如银行，零售企业和媒体公司，这些公司传统上没有产品管理，因此也没有产品经理。 但他们确实拥有数字化产品，用于帮助市场营销和销售产品（比如手机银行应用），或是他们开发实现业务流程自动化的软件，以提升生产效率和减少成本。

通过设立 Product Owner 的角色，这些组织可以以敏捷的方式开始工作，却不用立即建立产品管理团队或者在进行组织流程变革。相反，来自业务部门的人通过参加一些培训和指导可以担任 Product Owner 角色。但长远来看， 建立一个产品的管理职能是会带来更多好处的。

那我们该何去何从呢？

我的想法是：我们不要纠结一直在产品经理和 Product Owner 里找不同点，我们不如统称他们产品人员。在短期内， 我们应当明确 Product Owner 是一个产品管理的职责， 只有具备相关产品技能的人才能胜任这个职位。 就像 Mary Cagan 和其它人曾经指出， 2天的培训是不足以培养一个有竞争力的 Product Owner 的，产品管理很复杂， 需要的知识面很广，需要较长的时间和精力才能掌握。

此外，我们建议不论设置产品经理或者 Product Owner 的角色，必要时要让他们具备相关资质。例如，可以聘用高级或者初级的产品经理/Product Owner，以及战略产品经理/Product Owner 和战术产品经理/Product Owner。其实，重要的不是工作角色和头衔，关注用户和我们的业务发展才更好。

三、Product owner 一天中的工作内容

一天：

• 每天一开始都要检查 Sprint 待办列表里的条目和相应的任务情况，如果有任何关于进度的疑问都需要追踪。
• 协助团队成员解决问题，澄清需求。
• 尽早评审已经开发完成的功能，确认功能是否是期望的。如果不是则需要决定是否要在本个迭代做出更改，或者可以放到下个迭代继续完成，或者需要创建新的用户故事。
• 编写新的用户故事来完成更多的功能，并且向团队澄清新的用户故事。
• 编写史诗级用户故事（如果功能太大，单个用户故事无法承载的话）。
• 报告任何你发现的软件问题。
• 参加每日站会（如果你和你的团队认为这样有助于完成迭代目标）。
• 听取并且回答每日站会的三个标准问题。
• 发现需要你进一步跟进的任务。
• 和团队分享有用的信息。

一个迭代：

1、准备计划会议：

收集足够数量的待办列表项以便团队在计划会议上评审，并且按优先级排好顺序。

• 要以商业价值作为排序的依据，同时考虑到风险、潜在失败的可能性和其他相关的因素。
• 列表项的信息里要包含它与其他列表项之间的依赖关系。

2、计划会议中：

• 和研发团队、ScrumMaster 一起使计划会议变得更有效。
• Product owner 必须参加计划会议。
• 回答问题以澄清和解决有可能影响实施和估算的问题。
• 如果需要的话，需要更新用户故事的主题和描述以避免歧义和误解。
• 如果需要的话，重新更改用户故事的排序以便Sprint可以更有效。

3、评审会议中：

评审团队在过去的一个迭代中提交的功能是否符合期望，确认是否接收团队提交的潜在可发布增量。

4、回顾会议中：

ScrumMaster 主持会议，团队共同决定 Product owner 参与该会议是否对团队实现目标更加有帮助。

毫不夸张地说，Product owner 是 Scrum 团队最重要的一个角色。Product owner 的工作直接影响团队最后的成果。一个好的 Product owner 不仅需要是一个好的产品经理，他／她还需要项目管理，沟通，甚至是技术方面的多种能力才能完成好自己的工作。

以上就是关于 Product Owner （产品负责人）主要职责，以及与产品经理区别的全部内容，希望对你有所帮助。

参考文献：

1.《天天学敏捷：Scrum团队转型记》

2、产品经理