对于大多数转向敏捷方法的公司而言，产品所有者 (Product Owner) 是新的东西。但是，每个月您都会看到产品所有者需求的显着增长。为什么？我们将在本文中讨论它，更多地关注产品所有者在软件开发项目中的角色。
谁是产品所有者？
一个伟大的产品负责人基本上是他的产品的企业家。PO 是敏捷团队的成员，负责提供高质量的数字产品。简而言之，PO 定义用户故事并优先处理积压 (Backlog)，同时保持团队功能的概念和技术完整性。
敏捷产品负责人在质量控制方面的作用是巨大的。PO 是一个关键成员，他接受完成后的故事。根据我们的经验，与不同行业的公司合作，如果公司没有采购订单，那么在大多数情况下，如果没有达到最后期限并且产品交付的功能不是真正需要的，那么开发过程会变得混乱。
但是，我不得不说要完成敏捷软件开发项目中需要完成的所有工作，在我看来，产品负责人应该有一些技术知识才能更有效。为什么？因为产品所有者应该能够与技术团队交谈并理解对推进项目至关重要的概念。此外，PO 应该能够向其他利益相关者解释技术概念。PO 就像开发团队和利益相关者之间的中间人。但是，除了掌握技术知识外，PO 应该从最终用户的角度对产品有所了解。这意味着 PO 也应该有业务背景。
不幸的是，现在世界上很少有人真正符合这个“理想的候选人”标准，因此许多大学和学院开始开设课程来培养产品所有者。如果您想听取我们的意见，那么我们认为将技术人员，开发人员或 CTO 转换为 PO 比商务人员容易得多。
让我们来看看 PO 的主要责任范围。
软件开发项目中的产品负责人角色
创建和维护产品 Backlog 在软件领域，没有什么是不变的，产品负责人必须根据客户和市场需求调整产品 Backlog。此外，好的 PO 知道何时以及如何说 NO。这可能是最明显但也是最难掌握的人。对新想法或功能说“是”很容易，这只是产品积压的另一个项目。但是，良好的积压管理包括创建可管理的产品积压，其中的项目可能会实现。在积压的情况下添加项目，知道什么都不会发生，只会造成“浪费”和错误的期望。为了避免整个开发过程花费太长时间的情况，项目失去了重点，而开发的解决方案可能无法真正解决业务问题，PO 应该对某些功能和变更说“不”。但在这些情况下，
根据业务价值或 ROI 确定积压的优先级 每个用户故事必须按相对重要性排序。不应该有 5 个高优先级。重要的是要知道哪个用户故事是#1，哪个是#2 等。这不仅仅是从业务角度来看，PO 应该考虑到开发部分以及在做 X 之前根本无法开发的一些功能任务。因此，PO 应该从双方分析需求，并提出最佳解决方案，最佳优先级，从一开始就为产品增加更多价值。
用户故事 PO 应该知道如何编写用户故事。简单的例子是：作为用户，我想 < 某个目标或目标 >，以便 <benefit，value>。这里有一篇文章解释用户故事。
在每个 Sprint 开始时传达愿景和目标 这有助于保持团队的正常运转。产品负责人代表客户发表意见，并与利益相关方共同创造产品愿景。每个决定都考虑到产品愿景。这确保了可持续的产品开发，为开发团队提供了清晰度，并增加了产品成功的机会。
吸引客户和利益相关者以确保团队正在构建正确的产品 开发团队不应该花时间向客户解释技术问题，这是 PO 的工作。换句话说，产品负责人是团队对外界的代言人，应该确保所有沟通渠道都是开放的，并且项目需要适当的支持才能取得成功。PO 负责定义实现目标的边界和约束。它们可以包括截止日期完成日期，成本限制，内存限制和最低速度。
参加每日 Scrum 会议，Sprint 计划会议以及 Sprint 评审和回顾。对于产品负责人而言，拥有能够适应不同团队和个性类型的良好沟通技巧尤为重要。产品负责人应根据当前状态，进展，可能的斗争和问题更新利益相关者。
质量保证 通常情况下，PO 是唯一可以接受故事的团队成员。这包括验证故事是否符合验收标准并具有适当的，持久的验收测试，并且它符合其“完成定义”
投资回报率 产品所有者负责提供最佳投资回报。他们对 sprint 的发布和产品级别的所有经济决策负责。预算，时间和质量可根据需要进行调整，每个产品的成本和收益积压也可用于确定用户故事的优先级。
解决冲突 任何无法处理冲突的人都不应该是产品所有者。在数字产品开发中，拥有强大的冲突解决技能对于阻止争议升级并专注于真正重要的事情非常重要。有时，PO 必须经历一些冲突才能达成解决方案。
准时交货 产品负责人负责确保团队满足截止日期和目标。PO 负责根据里程碑提供最佳工作软件。
如果您喜欢本文关于软件开发中的产品负责人角色，您可能会喜欢：
Scrum 的基本功 – 集合中英文版本 (Scrum 事件)
Scrum 的基本功 – 集合中英文版本 (Scrum 工件)
Scrum 的基本功 – 集合中英文版本 (基础篇)
Scrum 的基本功 – 集合中英文版本 (角色和责任篇)