Scrum只有三个正式角色：Scrum Master、产品负责人和团队。对于程序员、测试人员、数据库工程师、分析人员、设计人员等角色，并不加以区分。
例如，测试人员也只是团队成员之一。测试人员与其他团队成员共有同一个职责：在冲刺结束时开发一个潜在可发布产品增量，以实现冲刺目标。
在每位团队成员帮助团队实现这一目标的方式方法上，会存有差异。测试人员会尽可能地从冲刺待办列表中选取测试工作，而设计人员则会选取设计工作。
但在一个优秀的Scrum团队中，每个人都应竭尽所能地帮助团队实现目标。
Scrum中的专家角色
与团队角色相对的，是产品负责人和Scrum Master角色。这两个角色可以被视为专家角色。
无论是产品负责人，还是Scrum Master，都没有在冲刺期间直接参与开发潜在可发布产品增量的职责。在许多团队中，他们可能会提供帮助，但这并非Scrum的本意。
为何这两个角色就能这么特别？
产品负责人和Scrum Master角色到底有何独特之处，得以成为与测试人员、程序员等人截然不同的角色？
许多团队已经在尝试多个团队成员间轮值Scrum Master职责。而另一些团队则将其视为团队成员该承担的另一组职责。
但是，绝大多数Scrum团队仍然存有独立的产品负责人角色，由一名代表组织或干系人利益的专职人员来担任。
有趣而又诱人的未来设想
我有一个有趣而又诱人的未来设想——产品负责人角色可能会消失。就像今天测试职责已被分担一样，今天的产品负责人职责在明天也将会被整个团队分担。
我坚信产品负责人角色中不存在任何阻碍其无法被团队共担的固有要素。
正如今天测试职责已经在优秀地敏捷团队中被整个团队共担一样，产品决策也将会由他们共同承担。
在面临架构选择时，团队已被要求自组织地作出正确决策。可以预期，未来的产品决策也将会是这样。
当面临之前由产品负责人做决定的决策时，将改为由团队成员共同讨论和决策。
这事实上与团队成员正在进行的架构决策并没有什么区别。
虽然团队已不再拥有一名专职的产品负责人，但却可能会存在一名更有专业知识的团队成员来作出产品级的决策。但这与存在一名更有测试经验的团队成员并没有什么不同——他虽然喜欢测试但却愿意从事任何工作。
有效运作必须具备什么？
要使其有效运作，某些事情是必须具备的。
首先，开发人员需要超越之前自视为程序猿的想法。他们不能只是工作时才出现并宣称：“任何您想要的东西我都能编写出来，但请准确地告诉我它到底是什么。”想要使整个Scrum开发团队都参与到这一级的事务中，这就要求团队成员们必须投入所有的心思和激情。
其次，产品负责人们要抛弃产品级决策就该由其全权决定的想法。就像Scrum团队中的测试人员可能喜欢测试超过了其他任何活动，但这并不意味着测试人员们可以自行作出所有的测试决策。
这些变化意味着将由整个团队来对所分配的任何重大目标实现结果负责。设想一下，这将导致不会再有将产品所有者称为“唯一可拧断的脖子”的说法。（译者：“可拧断的脖子”指对错误决策负责的人。）
谁会因此而出现在团队中？
在我正描述的以及我在少数几个组织中经历过的情况中，除了一个团队外，其他团队都一直存活到现在。在这些团队中，产品负责人职责由整个团队协作完成，而不存在一个通常认为的、分离于团队的专职产品负责人（正如《Scrum指南》定义的那样）。
组织可能会把具有产品管理经验的人员分配到团队中。但这无异于今天将具有测试经验的人员分配到团队。
虽然被期望能领导或者知道产品管理决策，但此人的主要手段是向团队伙伴们兜售决策意见的好处，而非直接告诉他们决策结果。
顺理成章的事情
我反对任何会将团队割裂成我们/他们的事情。我以前阐述过将产品负责人纳入每日立会和回顾会的重要性，我也阐述过让团队成员参与创建产品待办列表的重要性。
随着团队更深入地拥抱团队思维，角色间差异将更多地被视为是人为产物，即使这些角色中的个人在从事着更加高度专业化的工作。
我相信我们已从许多组织对Scrum Master的看法中看到了这一点：在未来的几年里，团队思维扩展到产品负责人角色将会是一件顺理成章的事情。
团队中会存在某个干系人或业务代表，但这个人不会像今天这样对产品决策全权负责。相反，团队将共同协作来做出决策，并共享职责。
你怎么看？
你如何看待取消明确的产品负责人角色这一事情？如果今天你们的产品负责人被更多地当成是团队的普通一员，并且只能依靠兜售他或她想法的正确性而不是直接判定结果，会导致更好的决策结果吗？请在下面的评论中分享你的想法。
作者：Mike Cohn
译者：李洁（Jerry Li）
原文链接：
https://www.mountaingoatsoftware.com/blog/is-it-time-to-do-away-with-scrums-product-owner-role
