scrum 角色_产品负责人是Scrum中最容易被误解的角色

scrum 角色

Scrum is all about creating products of the highest value in complex product environments. Here’s why:

Scrum致力于在复杂的产品环境中创造最高价值的产品。 原因如下：

“In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done.” — The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka

“在当今商业新产品开发节奏快，竞争激烈的世界中，速度和灵活性至关重要。 公司越来越意识到，旧的顺序开发新产品的方法根本无法完成工作。” —竹内弘孝和野中郁次郎的新产品开发新游戏

If you are unfamiliar with this quote, then it may surprise you that it is from 1986. It is 34 years old. It comes from the paper that introduced the first concepts of Scrum: The New New Product Development Game.

如果您不熟悉此报价，那么您可能会惊讶于它始于1986年。 它已经34岁了。 它来自介绍Scrum的第一个概念的论文： 新产品开发新游戏 。

Since then the world only became vastly more fast-paced, more unpredictable, more complex. Products that used to be popular last year have become obsolete by now. What will be successful next year, nobody knows. With that, long term detailed planning is ineffective. The sequential approach to developing new products has become even more nonsensical than in 1986.

从那时起，世界变得更加快节奏，更加不可预测，更加复杂。 去年流行的产品现在已经过时了。 明年什么会成功，没人知道。 因此，长期的详细计划是无效的。 与1986年相比，采用顺序开发新产品的方法变得更加荒谬。

Still, many organisations have not come to realise this. They have tailored Scrum to fit into their traditional processes. The role that suffers the most from this is the Product Owner. Development Teams can have some sort of autonomy in their Sprint bubbles. But Product Owners often are a mere mixture between a Project Manager and a Business Analyst. They ensure that the Development Team knows what to do and aim to follow the Product Roadmap. Rather than actively working to create a product that fulfils the needs of the stakeholders, the Product Owner follows a roadmap defined by others.

尽管如此，许多组织仍未意识到这一点。 他们量身定制了Scrum以适应其传统流程。 受此影响最大的角色是产品负责人。 开发团队可以在其Sprint气泡中拥有某种自主权。 但是产品所有者通常只是项目经理和业务分析师之间的混合体。 他们确保开发团队知道该怎么做，并致力于遵循产品路线图。 产品负责人没有积极致力于创建满足利益相关者需求的产品，而是遵循其他人定义的路线图。

By performing these activities, the Product Owner role becomes diluted. As a result, it is a shadow of what it should be. The Product Owner role entails far more responsibilities than many companies believe.

通过执行这些活动，产品负责人角色将被淡化。 结果，这是它应有的影子。 产品负责人的职责比许多公司认为的要多得多。

Scrum指南含糊不清 (Scrum Guide ambiguity)

It doesn’t help that the Scrum Guide is ambiguous about the Product Owner role. It starts well:

Scrum指南对产品负责人的模棱两可并没有帮助。 它开始良好：

“The Product Owner is responsible for maximizing the value of the product …” — Scrum Guide 2017

“产品负责人负责最大化产品的价值……” — Scrum指南2017

But then it adds:

但随后添加：

“… resulting from work of the Development Team.” — Scrum Guide 2017

“……来自开发团队的工作。” — Scrum指南2017

This is where the confusion starts. What does this phrase even mean? It is easy to read this as ‘making sure that the Development Team delivers according to a roadmap defined by others, translating the roadmap into the Product Backlog.’ Many organisations work this way. A Product Manager determines the product roadmap. Product Owners update their Product Backlogs to feed their teams with items for their component. They don’t own a product, they manage a component.

这就是混乱的开始。 这个短语甚至意味着什么？ 这很容易理解为“确保开发团队根据其他人定义的路线图进行交付，将路线图转换为产品待办事项列表”。 许多组织以这种方式工作。 产品经理确定产品路线图。 产品负责人更新了他们的产品待办列表，以向其团队提供其组件的项目。 他们不拥有产品，而是管理组件。

This is also how it often works with SAFe and other similar scaling frameworks.

这也是SAFe和其他类似缩放框架经常使用的方式。

Companies that work like this ignore the very reason to use Scrum.

像这样工作的公司完全没有理由使用Scrum。

Scrum的核心 (The core of Scrum)

“The shift from a linear to an integrated approach encourages trial and error and challenges the status quo. It stimulates new kinds of learning and thinking within the organization at different levels and functions.” — The New New Product Development Game by Hirotaka Takeuchi and Ikujiro Nonaka

“从线性方法到集成方法的转变鼓励反复试验并挑战现状。 它激发了组织内不同级别和职能的新型学习和思考。” —竹内弘孝和野中郁次郎的新产品开发新游戏

This is another 34-year-old quote that captures the core of Scrum. Empiricism is the foundation of Scrum. This is directly related to ‘trial and error’. In the world of empiricism, there is no place for detailed and static long term roadmaps. Product Owners need to find other ways to feed the Product Backlog. They need to maximise the value of the product by making the right calls on what to work on next. Scrum’s empiricism is crucial here. Especially the feedback from stakeholders at the Sprint Review.

这是另一个34岁的报价，它抓住了Scrum的核心。 经验主义是Scrum的基础。 这与“试错”直接相关。 在经验主义的世界中，没有详尽的静态长期路线图的地方。 产品负责人需要找到其他方法来提供产品待办事项列表。 他们需要通过正确地呼吁下一步的工作来最大化产品的价值。 Scrum的经验主义在这里至关重要。 特别是利益相关者在Sprint评论中的反馈。

产品负责人的重要性 (The importance of the Product Owner)

In a complex environment, it is the Product Owner who processes all feedback on the product. She/he does so by translating feedback into a Product Backlog ordered by possible value. The Product Owner needs to ensure alignment with many different stakeholders. They can be customers, users, sales, operations, infrastructure, architecture. She/he also needs to review the timeline, budget, potential capabilities and marketplace of the product. The Sprint Review is the logical place to do all this, but the work of a Product Owner exceeds the world of Scrum.

在复杂的环境中，由产品负责人处理有关产品的所有反馈。 她/他通过将反馈转换为按可能的值排序的产品待办事项列表来进行操作。 产品负责人需要确保与许多不同的利益相关者保持一致。 他们可以是客户，用户，销售，运营，基础架构，体系结构。 她/他还需要检查产品的时间表，预算，潜在功能和市场。 Sprint Review是进行所有这些操作的合乎逻辑的地方，但是产品负责人的工作超出了Scrum的范围。

The Product Owner should drive the direction and growth of the product, with the help of the rest of the Scrum Team and the stakeholders.

产品负责人应在Scrum团队的其他成员和利益相关者的帮助下驱动产品的方向和发展。

组件所有者与产品所有者 (Component Owners vs Product Owners)

Earlier in the article, I mentioned how Product Managers create a product roadmap. The product roadmap is input for multiple Product Owners and their Scrum Teams. Each Product Owner works on a component of the product. This means that she or he is a Component Owner, not a Product Owner. This is a Scrum anti pattern.

在本文的前面，我提到了产品经理如何创建产品路线图。 产品路线图是为多个产品所有者及其Scrum团队输入的。 每个产品负责人都在产品的某个组件上工作。 这意味着她或他是组件所有者 ，而不是产品所有者。 这是Scrum反模式。

I already mentioned that this setup is ineffective in a complex product environment. You can’t make detailed long-term roadmaps. But there’s more to it. The Component Owners may have a good view of their component. But they don’t see the total picture of the product, the sum of the components. With that, they are not in a position to decide what item from the component is the most important compared to the other components, or for the product as a whole. Only the person that has the total oversight can do this. In this example, no-one has this oversight. The Product Owner responsibilities are split between the Product Manager and the Product Owners.

我已经提到过，此设置在复杂的产品环境中无效。 您无法制定详细的长期路线图。 但是还有更多。 组件所有者可以很好地了解其组件。 但是他们看不到产品的总图片，组件的总和。 这样一来，他们就无法决定与其他组件相比，还是与整个产品相比，组件中的哪个项目最重要。 只有受到全面监督的人才能做到这一点。 在此示例中，没有人对此进行监督。 产品负责人的职责在产品经理和产品负责人之间分配。

产品负责人角色与产品负责人功能 (Product Owner role vs Product Owner function)

Scrum introduced a couple of roles, the Product Owner and the Scrum Master. Quickly organisations started to create job functions called Product Owner and Scrum Master. On a small scale, role and function are often the same. But things often go wrong on a larger scale when more than one team works for the same product. There are two ways to wrongfully creating a Product Owner function. Often you see a combination of the two:

Scrum引入了两个角色，即产品负责人和Scrum主管。 组织很快开始创建称为“产品负责人”和“ Scrum Master”的职务职能。 在小规模上，角色和功能通常是相同的。 但是，当一个以上的团队为同一产品工作时，大范围的事情往往会出错。 有两种错误地创建产品所有者功能的方法。 通常您会看到两者的组合：

• Some organisations believe that every Scrum Team should have a Product Owner. They have multiple Product Owners per product. Together, they own the product.
  一些组织认为，每个Scrum团队都应该有一个产品负责人。 每个产品有多个产品负责人。 他们在一起拥有产品。
• Other organisations have a Product Manager for the end responsibility and Product Owners on ‘Scrum level’. Here Product Owners don’t even have the final say over their Product Backlogs. This is the Product Manager’s call.
  其他组织有负责最终责任的产品经理和“ Scrum级别”的产品负责人。 在这里，产品负责人甚至没有关于他们的产品积压的最终决定权。 这是产品经理的电话。

Both adaptions of the Product Owner function invalidate the Product Owner role. In the first example, there should be only one person responsible for the product:

产品所有者功能的两种调整均会使产品所有者角色无效。 在第一个示例中，应该只有一个人负责产品：

“The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.” — Scrum Guide 2017

“产品负责人是一个人，而不是委员会。 产品负责人可能代表了产品待办事项列表中委员会的要求，但是那些想要更改产品待办事项项目优先级的人必须解决产品负责人。” — Scrum指南2017

Note that there is only one Product Backlog for a product and one person should have end-to-end accountability. One person should have the role of Product Owner.

请注意，一个产品只有一个产品积压，一个人应该具有端到端的责任。 一个人应该扮演产品负责人的角色。

In the second example, there’s one person in a position to have the end responsibility. The Product Manager should understand that she/he should embrace the Product Owner role. The people with the Product Owner function are important members of the Development Team. They translate the needs and expectations of product into a language understandable for the Development Team. But they don’t have a Product Owner role.

在第二个示例中，只有一个人可以承担最终责任。 产品经理应该明白，他/她应该包括产品负责人的角色 。 具有产品负责人职能的人员是开发团队的重要成员。 他们将产品的需求和期望转换为开发团队可以理解的语言。 但是他们没有产品负责人的角色 。

结合Sprint评论的力量 (The power of the combined Sprint Review)

There’s another related and important topic, the Sprint Review. This is the event where Scrum Teams and stakeholders discuss the current state of the product. This results in clear directions on what to do next. When 10 teams all help to create a product, how are you going to reach all your stakeholders with 10 Sprint Review events? The simple answer is: you won’t.

还有另一个相关且重要的主题，即Sprint评论。 这是Scrum团队和利益相关者讨论产品当前状态的活动。 这样可以为下一步的工作指明明确的方向。 当有10个团队共同帮助创建产品时，您将如何通过10个Sprint审核活动与所有利益相关者接触？ 简单的答案是：您不会。

Instead, the 10 teams should have a combined Sprint Review, guided by the person with the true Product Owner role. In my example, this is the person with the Product Manager function. At such a Sprint Review, all teams together discuss with stakeholders.

相反，这10个团队应该在真正的产品负责人的指导下进行合并的Sprint审查。 在我的示例中，这是具有产品经理职能的人。 在这样的Sprint审查中，所有团队一起与利益相关者讨论。

Only a complete Increment — the latest state of the Product — is valuable to inspect. Also, findings from stakeholders are easily shared and discussed with all involved development teams. 10 separate Sprint Reviews that all tackle specific components can’t be this powerful. Also, having one event discussing the product is bound to draw key stakeholders more than the ones touching only aspects of it.

只有完整的增量(产品的最新状态)才能检查。 此外，利益相关者的发现可以轻松地与所有相关的开发团队共享和讨论。 10个单独的Sprint评论(这些功能都可以解决特定的组件)不能这么强大。 同样，举办一次讨论该产品的活动势必会吸引关键的利益相关者，而不仅仅是那些涉及产品各个方面的人。

重视产品负责人！ (Value the Product Owner!)

In complex product environments, a Product Owner and the Development Team(s) should be working together to maximise the value of the product by creating an Increment and inspecting it, learning from it. This does not come across well enough in the Product Owner section of the Scrum Guide. If you isolate this section, you miss out on empiricism completely. What’s more, if you only take into account the Product Owner passages of the Scrum Guide, you won’t find entries discussing empiricism, the heart of Scrum.

在复杂的产品环境中，产品负责人和开发团队应共同努力，通过创建增量并对其进行检查并从中学习来最大化产品的价值。 在《 Scrum指南》的“产品负责人”部分中，这还不够好。 如果您将本节孤立，您将完全错过经验主义。 而且，如果仅考虑《 Scrum指南》中的“产品负责人”段落，您将找不到有关经验主义(Scrum的核心)的条目。

The Product Owner role is open for multiple explanations. As a result, some Product Owners only manage the Product Backlog while other Product Owners are responsible for the product vision and strategy.

“产品负责人”角色处于打开状态，有多种解释。 因此，某些产品负责人仅管理产品待办事项，而其他产品负责人负责产品的愿景和策略。

A major issue arises when bringing traditional product delivery methods into the mix. Conventional delivery methods do not cater to complexity. It is dangerous to assume that portions of these methods mix with Scrum. Instead, they can lead to disastrous side-effects.

将传统的产品交付方式纳入组合时会出现一个主要问题。 常规的递送方法不能适应复杂性。 假设这些方法的某些部分与Scrum混合使用是危险的。 相反，它们可能导致灾难性的副作用。

For Scrum to work, realise why it exists. It is there to create products of the highest value in complex environments. To succeed, a Product Owner should be the one with the final voice on what should happen next to the product utilizing a Product Backlog. The Product Owner should own the complete product, not components of the product.

为了使Scrum正常工作，请了解它为什么存在。 它可以在复杂的环境中创造最高价值的产品。 要取得成功，产品负责人应该是利用产品待办事项表对产品旁边应该发生的事情有最终决定权的人。 产品负责人应该拥有完整的产品，而不是产品的组件。

The Product Owner will get the best results in a Sprint Review with all the Scrum Teams working on the product. Such an event will inspect the complete and integrated product Increment. This allows for high-value discussions and decisions.

所有Scrum团队都在产品上进行工作，产品负责人将在Sprint审查中获得最佳结果。 此类事件将检查完整的集成产品增量。 这样可以进行高价值的讨论和决策。

The Product Owner role is very much misunderstood and misapplied. It is the most underrated role within Scrum. This is a role that in theory entails far more responsibilities than what you see happening in practice.

产品负责人的角色非常容易被误解和误用。 这是Scrum中最被低估的角色。 从理论上讲，这一角色比您在实践中所承担的责任要多得多。

Do you want to write for Serious Scrum or seriously discuss Scrum? 您要为《严重的Scrum》撰写文章还是认真讨论Scrum？

翻译自: https://medium.com/serious-scrum/product-owner-is-the-most-misunderstood-role-in-scrum-137eb65be73e

scrum 角色