软件开发一直以来都是一项花费较多且存在风险的业务。Standish Group在其Chaos Manifesto 2013中指出在调查期间，不到三分之一的项目按时且按预算成功完成。在2015年，Standish Group一项研究的结果也显示了相同的数字，也就是说只有29%的项目被认为是成功的。这是什么造成的呢？

在业务发展迅猛的世界里，不可否认的是，每家企业都需要优秀的产品负责人。产品负责人负责控制混乱，管理风险，提前思考，扭转中断，解决利益相关者之间的冲突，并为他们支持的团队提供明确的方向。

从2001年以来，敏捷作为传统瀑布方法的替代方法出现，瀑布方法已被证明很难在现代软件工程中实施。但是，敏捷一直是被误解的。

许多敏捷方法的新手试图通过将敏捷和瀑布方法结合，删除某些敏捷实践来实施，但他们却认为自己成功实施了敏捷方法。对于敏捷的常见误解之一是产品负责人在团队中扮演的角色，这也是本文的主题。

所以产品负责人的存在意义是什么？为什么会有这样一个职位存在？

谁是产品负责人（PO）？

简单来说，产品负责人就是拥有产品的人。他负责的是产品，不仅仅是功能、特性或是文档，他与整个产品相关。产品负责人是敏捷团队的决策者。用Midtrans公司CEO Ryu Kawano Suliawan的话来说：“产品负责人就相当于小型CEO。”他或她通过指导开发团队产出最大、最好的结果，对管理的产品的成功负最大责任。

产品负责人至少要完成这些任务：

1.在产品积压列表中创建可以理解的、可行的故事。

2.根据优先级调整产品积压列表中的故事完成顺序，以最好地实现设定的目标。

3.优化并最大化scrum团队的输出。

4.通过尽可能整理清楚团队内外事物来管理混乱。

5.帮助团队计划迭代。

6.参加所有scrum会议，尤其是站会和回顾会议。

7.为产品定义验收标准和/或关键性能指标。

产品负责人也可以选择完成通常由产品经理完成的任务。因为不是所有公司都同时拥有产品负责人和产品经理。

产品负责人职位描述中最重要的方面是，管理混乱。

产品负责人需要完成的重要任务

了解业务和团队

作为产品负责人，对于公司的业务和团队本身必须有深入的了解。因此，当需要修改一些业务需求或是对产品有新的改进的时候，要询问产品负责人完成这样事情的可能性，提供的解决方案是否能改善整体体验，比如是否可以帮助缩短时间等等，产品负责人还需要给出如何最好地解决问题的建议或方法。

做团队和利益相关者之间的桥梁

产品负责人最主要的工作是帮助团队和业务利益相关者直接沟通。在联系所有相关人员方面，他需要起到如虎添翼的作用。因此，产品负责人扮演敏捷团队中利益相关者的代理人是非常常见的。

然而，准确来说利益相关者扮演了什么角色呢？产品负责人可以代理利益相关者的这些角色：

1.管理角色

2.相关领域专家

3.终端用户

4.评估审计员

5.支持团队

其他相关的产品负责人角色

维护并准备积压列表

只要有产品，就有积压列表。在Agile lingo中，积压列表只是简单的待办事项。列表中的每一项都叫一个故事。每个故事都有类型，它可能只是零星事项，也可能是需要开发的功能。每个故事通过估计其难度（估计工作在sprint计划阶段由工程师完成）来“规划大小”，同样重要的是需要详细描述故事就绪阶段和完成阶段的标准。

在工程师可以开始处理故事之前，故事必须先放到积压列表中，并在sprint计划活动中被选为这个sprint的积压故事。因此，积压列表的优先级选择必须权衡以下方面：

1.客户价值（解决正确的问题）

2. 业务价值（产生的收益）

3. 技术价值（可以促进学习，减少风险，有牢靠的解决方案和智能工作流）

4. 质量价值（缓解风险）

同样值得注意的是，利益相关者不应该强迫产品负责人承担故事。产品负责人必须充分评估故事，了解将故事包含在迭代中的风险。

设置并维护sprint

如果你会说：“嗯好的，我们还有这么多故事要处理，但我们只剩下四个月了。所以我希望你们在这次sprint结束能完成四分之一的产品积压列表。”，那你就不是很好的服务型领导，而服务型领导是成为优秀的产品负责人需要扮演的关键角色。

重要的是要记住产品负责人永远不能在团队的讨论中表现出他或她的话语是最重要的、最值得关注的。他们甚至没有强制要求下个sprint要完成多少故事的权力。

然而，他有维护sprint的权力。所以在sprint中，产品负责人可以在和工程师团队协商之后，决定从当前部署计划中移除故事。产品负责人是团队中唯一决定什么可以得到部署的人。

比如说，如果这个功能需要其他团队的工作优先完成后才能开始处理，而其他团队还在处理这个功能，那么就理应不把这个功能包括进去。再举个例子，比如说一个功能所依赖的第三方产品还没实现，那也应该排除出去。

其他产品负责人经常要做的事

设计关键绩效指标（KPI）

利益相关者想知道产品取得了怎么样的成功。是否表现良好？这个产品如何帮助使用它的人？使用起来是否足够快？

产品负责人必须提供可测量的KPIs列表，通过列表可以判断产品是否良好运行。产品负责人监控这些KPIs，并通过它们提供的反馈调整积压列表。

测试并验证需要部署的故事

一旦工程师将一个故事标记为准备测试，产品负责人就要负起该产品各方面被彻底测试的责任。他们需要在将该功能添加到部署包之前，努力找出不合常规的、奇异的问题和错误。他们需要和测试工程师以及用户代表一起工作，来保障测试。

保障有凝聚力的工作环境

嗯，很明显，她需要保证每个人正常工作，保证scrum master有所帮助，保证工程师各司其职，保证团队是有凝聚力的和愉快的。这并非易事，而是必须有人认真处理并安排的工作。如果失败，团队也会失败，然后会一片混乱，失去了原来的工作效率。

发表发布日志

好的，那在每次部署之后，哪些功能得到了部署？发生了什么改变？新构建的产品会对客户和业务产生什么影响？如果可能的话，它怎么帮助事情变得更好、更快，并让工作变得更少？

建议产品负责人发表“发布日志”，或是简单地在公司内部或向外界发表发布的简单介绍。他可以使用Slack、Email或whatnots发布合适的发布说明。

分享产品会议

产品负责人可能需要做demo演示产品如何运作。这就是为什么产品负责人要先自己测试产品，了解其局限性以及预期的性能等等是非常重要的。

招聘

团队的产品规模可能会扩大。在这种情况下，产品负责人需要和人力资源部门联络，咨询他想给团队添加一名新成员的事宜。

然而，决定是否要招聘某人不是由产品负责人决定的，而是由工程副总裁、CTO或是其他类似角色决定的。产品负责人还要保证万一有人离开团队，团队工作不会中断，团队还能正常运作。

产品负责人 vs 产品经理

印度尼西亚工作目录网站Karir.com的CTO Sky Kok说，产品经理是更加以市场为中心的角色。他们通常和市场团队紧密合作，有时候直接和首席市场官合作。

传统上，产品经理负责的工作包括：

1.通过找寻新的方法提升产品整体体验开发业务案例。

2.认真倾听，扮演市场和客户的专家。不要负责寻找解决方案，因为这是工程团队的工作。

3.定义产品年度或季度的路线图。

4.管理产品的定价、销售和营销。

5.获取、购买或建立决策。

但是在Scrum Guide中没有提到产品经理，因此在采纳scrum的组织里，产品经理的角色可能更偏向于利益相关者。实际上，采纳scrum的团队可能根本没有产品经理这个职位，因此这个角色和解决方案部门、业务开发部门和产品负责人有所区别。

“作为产品负责人，我……”

你可能来自任何背景：

1.业务利益相关者

2.IT部门

3. 业务分析师

4.产品经理

5. 甚至是：新雇员

我曾经看到过来自以上列出的任何背景中的产品负责人对团队产生非常积极的影响。尽管传统来说，产品负责人更可能来自于业务分析团队，但是没有哪种背景会更加适合，要成为产品负责人的愿望都与想要采纳并接受相关的新挑战的愿望有关。

传统上，许多产品负责人拥有业务分析的背景是因为，业务分析团队通常介于技术和业务人员之间，所以他们对考虑中的产品有更多的认识。然而，只要你了解你期待的事情、你的存在意义，你完全可以相信自己能做好产品负责人，并实现以上提及的所有角色条件。