升华产品管理以提高业务敏捷性

业务敏捷性与我们在团队层面观察到的敏捷性类似——它帮助工作单元更快地交付、更快地学习，并更快地适应变化，但正如名字所暗示的，它跨越了整个业务。

大多数公司的目标是尽可能长时间地超越竞争对手，并与客户和利益相关方保持紧密联系。业务敏捷性的承诺就像生命的灵丹妙药，对于防止停滞和促进复兴至关重要。

一旦掌握了业务敏捷性，组织就能够流畅且不费力地了解市场趋势的变化，迅速抓住选择的机会，而且不会增加额外的成本——在这个词语最广泛的意义上做到敏捷。

这篇文章描述了如何实现与产品经理和产品负责人工作相关的业务敏捷性。Org Topologies 地图帮助我们理解这一概念，并指导我们走上正确的道路。

"产品(Product)"与"产品(products)"之间的差异 ?

大型、复杂的产品(Products)确实如其名，它们庞大且复杂。我们想要将它们拆分成更小的部分，因为管理更小的产品(products)看起来更容易。所以，通常大型组织所认定的产品，实际上是漏斗中的步骤、用户旅程的一部分、特性、应用程序或组件……它们是更大产品的一部分。

这些较小的产品通常不被客户和业务利益相关者充分理解。这些子产品是更大整体的一部分。只有当这些整体被组合在一起时，我们才能满足客户需求，实现商业模式，产生真正的影响，并从投资中获得回报。

"把一头大象分成两半，不会得到两头小象。" —— 彼得·圣吉，《系统思考法则》

请注意上述段落中大写"P"的"Product"和小写"products"之间的区别。我们将在本文中始终使用这种大写方式。"Product"和"product"之间的区别至关重要。Org Topologies 将这种区别定义为“产品差距”。

这通常会让人感到惊讶，但组织中的产品差距的大小深刻影响着整个组织、其设计和运营模式。换句话说：

产品差距是组织设计的主要特性。

在行业中，通常认为整体的每一部分（每个子产品）都需要一个"负责人"。这可能是因为 Scrum 的流行。让我们稍微不同地解释一下这个观点：

大多数组织拥有的产品负责人太多了！

那么，这些产品负责人(product owners)究竟“拥有”什么呢？

所有权是什么？

当所有权意味着拥有整个产品时，产品负责人可以产生的影响可以通过该产品随时间的改进来度量。如上所述，一个产品被开发出来是为了解决客户需求并实现商业模式。因此，产品负责人的影响也必须以这些条件来度量。他们的工作成果对业务利益相关者和客户是可见的，并且可以被度量和优化。

但是，当整个产品被拆分成部分，并且是这些部分被拥有时，会发生什么呢？那么，产品负责人(product owners)的工作影响就与业务利益相关者和客户理解和关心的东西联系不那么紧密了。结果变得更难观察，影响更难度量，努力和投资也更难证明是合理的。

单独处理各个部分并不能保证对整体产生有意义的积极影响。因此，当只拥有一部分时，预测和度量回报和利润是困难的，甚至是不可能的。

当单独拥有各个部分时，更容易观察和度量的是努力和成本。这比听起来更危险。

大型组织区分“利润中心”和“成本中心”。遗憾的是，许多产品负责人及其团队在业务利益相关者和会计眼中只是单纯的"成本中心"。

如果你被视为成本，你将被最小化。

遗憾地说，确实如此。

在没有致力于外部焦点（例如，产品对客户需求的影响、商业模式）的情况下，拥有产品部分(product part)通常归结为一系列内部焦点的活动：准备工作、分割工作、详细规划工作、分配工作、跟踪工作、协调工作……工作，工作，工作。产出，产出，产出。

这是产品管理的一个明显缺陷。产品管理的崇高目标是最大化成果并最小化产出，当部分被分开拥有时，这变得具有挑战性。

更糟糕的是，团队很快就会习惯于他们“乐于助人”和“随叫随到”的产品负责人。团队开始期望并依赖他们来做所有这些准备和协调工作。这不可避免地只会让下降螺旋更加恶化。在这种环境中，真正的影响力所有权被管理工作和产出所取代。

产品负责人(product owners)变成了项目经理、需求工程师和团队协调员的同义词。

他们实际上是团队产出的所有者。

所有权的层次

在课程中有一个练习，会展示一幅图片（如下所示），并要求学生们根据不同的所有权层次定位自己。

大多数参加此类课程的产品负责人会将自己定位在这幅图片的左侧，作为“记录员”和“代理人”。

对部分的所有权确实深深植根于我们如今做事的方式（至少在软件行业是这样）。通常，这样的产品负责人要么专注于任务，要么专注于功能，并被分配到一个单一的开发团队合作。

通过 Org Topologies，我们将这种层次的产品所有权映射到地图的下部（Y 级和 A 级）。他们是以产出为导向的。

Output vs Outcome

Ownership levels

业务敏捷性无法实现..

... 当没有业务参与时

“产品负责人(Product Owner)”这一角色大约在 30 年前被发明，是为了应对一个普遍问题——在大多数组织中，业务与产品开发（IT、研发）是分开的。业务人员既不参与，也没有在适当的细节层面上控制软件产品开发的投资。

这造成了组织功能障碍的巨大沼泽，例如内部固定范围的项目、IT 的年度预算、无数被遗弃的产品，这些产品曾经有人请求过，但没有人真正想要。

通过将产品负责人的角色赋予业务利益相关者，我们将业务和 IT 更紧密地结合在一起，并教会他们在一个双赢的游戏中合作。在这种设置中，业务和 IT 每天一起工作，以最大化价值（更多的成果）并最小化未完成的工作量（更少的产出）。

这就构成了业务敏捷性的首要障碍：产品负责人(product owners)的角色对于业务人员来说可能看起来并不吸引人。记住：产品负责人拥有产品的一部分：漏斗中的一个步骤、用户旅程的一部分、一个特性、一个应用程序、一个组件。而商业人士对局部的战术管理不感兴趣，而是对整体的战略管理感兴趣。因此，在许多组织中，实际上产品负责人的角色将由 IT 人员而非业务代表来担任。

本质上，在大多数组织中，产品负责人是团队级别的业务分析师，他们负责处理细节，以便团队不会因编码而分心。

现在我们又回到了原点：业务保持在外，不积极参与创造产品，不参与也不控制投资。

最终，在这样的环境中，业务唯一能够控制任何事物的方式，就是退回到老旧且经过考验的管理实践——威胁和贿赂（截止日期和奖金）。

再见了，业务敏捷性！

... 当没有专注于整个产品时

当缺乏对整个产品的专注时，我们来认识一下 Billy，她是计费引擎的产品负责人，并且与计费引擎团队合作。

当有关于计费引擎的工作时，Billy 可以优化她团队的产出。这是她的专注点。她在组织中寻找对计费引擎有益的工作，并将其带给她的团队。如果没有外部工作进来，她会根据自己的清单，找出需要在计费引擎中改进的地方。

（Billy 有时会为了保持团队忙碌而创造工作吗？她不会同意这种说法。所以，我们假设这种情况从未发生过……）

Billy、计费引擎和计费引擎团队形成了一个紧密的组合。Billy 负责计费引擎，而计费引擎团队专门处理这方面的工作。他们相互依赖，他们的世界虽小，却很舒适。他们可以专注于自己的领域，并且当涉及到计费引擎的变更时，他们可以非常高效。

请注意，这些并不是普遍的法则：没有人天生就拥有和了解计费引擎。这是某个时候组织中的决策者所做出的决定。这些原则构成了组织的运作方式。“通过专业化提高效率”和“专注等于效率”是公司价值观的一部分，它们被写在走廊的墙上。

Billy 甚至可以使她的团队更有效率，实现接近百分之百的资源利用率。但这会让整个公司变得敏捷吗？敏捷到能够“流畅且不费力地吸收市场趋势的变化，迅速抓住选定的机会而不增加额外成本”？这其实是一个修辞问题。

组织中有多少像 Billy 这样有专门团队的产品负责人？五个、十个、二十五个、一百个？……所有这些产品负责人都像 Billy 一样，专注于他们所负责的产品部分。所有团队都在他们的产品部分上进行了深入的专业化。

“通过专业化提高效率”。“专注等于效率”。

想象一下，Billy 和她的同事产品负责人都需要为更大的业务创意、投资、目标、计划、项目、史诗（无论在那个组织中它们叫什么）做出贡献。这些举措通常由业务利益相关者创建和优先级排序。

在这个季度，有五个大型公司级投资。其中一个是“用户留存”项目，它位于其他事情的顶部。在这个目标的范围内：需要增加用户留存，而这些变化影响了目录（和目录团队）、产品搜索引擎（和产品搜索引擎团队）、计费引擎（和计费引擎团队）...

哪个团队将处理那个史诗级别的任务？

在任何人可以接手之前，它需要根据团队和他们的产品负责人的专业化和专注点被分解为工作任务。

例如，计费引擎团队必须接收到“用户留存”史诗中计费引擎变更的任务。产品搜索团队也是如此，以及其他团队。

再次，为什么会这样？因为“通过专业化提高效率”和“专注等于效率”。因为有人就是这样设计公司的。

这还不是唯一的项目。那个公司同时在处理多少其他项目？五个、十个、二十五个、一百个？

在那样的背景下：所有团队在下一个冲刺中一起开始并完成“用户留存”项目-史诗-创意-投资的可能性有多大？这个概率几乎为零。这样的组织不能作为一个整体工作，它们是碎片化的，看起来更像是一群小型销售船，而不是一个建造得很好的好看的游轮。

每个人都很忙，但一切进展缓慢。

显然，通过专业化和专注并不能实现业务敏捷性。这些做法甚至可能对其造成伤害。

业务敏捷性需要团队之间更强的凝聚力：共同的焦点和更广泛的专业化。

升华以弥合产品差距

以防你错过了，敏捷领域的最新热潮是关于产品的。许多人正在讨论产品管理、产品经理、产品负责人、被授权的产品团队等。所谓的“产品运营模型”是解决我们当前所有数字产品开发问题的最新承诺。

这是一个十分有前景的模型，我们期望看到它带来的希望。我们也相信文化遵循结构，特定的组织设计变化将使模型的应用更加成功。

Org Topologies 提供了一套被称为升华结构的指导和实践。在这个特定的背景下，我们正在讨论提升产品负责人和团队的地位。

升华产品负责人角色

许多意识到自己处于产品开发领域的组织都有一个既定的职位，称为产品经理(PM)。

产品经理具有相当全面的视野，并且使用客户和商业语言。我们可以说他们在公司的业务方面。他们必须具有远见，并负责交付一个满足真正需求并代表可行商业机会的产品。他们通过产品实施公司的战略，并从事与产品相关的任务，如定价、包装、发布、创新、品牌推广、广告等。

根据 Org Topologies 地图，产品经理位于地图的左上部分(C0/C1)——他们负责的范围很广。

但由于上述描述的产品负责(product owners)的功能障碍，这些产品经理在结构上与正在进行的产品开发分离了。他们没有推动功能开发。他们没有与团队合作。产品负责人占据了产品经理和团队之间的空间。

是时候改变这一点了。

为了弥合产品差距，我们需要将产品经理(PM)直接与团队联系起来。换句话说，就是移除产品负责人(product owners)，并让产品经理成为产品负责人(Product Owners)。

他们应该像小型 CEO 一样行事，并管理一个战略性的产品待办事项列表。在许多公司中，这样的待办事项列表已经存在，但有不同的名称（产品组合、公司投资列表、OKRs）。

产品负责人不再是扮演战术性业务分析师的角色，而是成为战略家。他们将大部分时间用于管理利益相关者和按价值优先排序。团队则可以学会直接与客户和利益相关者合作，收集他们需要的细节。

升华团队

升华后的产品负责人将拥有产品，而不是团队。这意味着产品负责人必须接受直接与多个团队合作的工作方式。

为了将团队置于产品负责人的可达范围内，我们必须通过创建具有业务问题范围的团队中的团队(team of teams)来升华团队。

每个业务问题范围都需要一个单一的产品负责人和一个团队中的团队(team of teams)。这样的组织结构可以被称为产品组。它是一个整体单位，对某种业务影响负有端到端的责任。

创建团队中的团队类似于在更高一层的抽象级别上创建跨功能团队，但涉及的是团队而非个人。我们不是将个人组合起来解决功能级别的问题，而是将团队组合起来解决业务级别的问题。每个团队中的团必须具备解决其共享所有权范围内任何问题的能力。

升华冲刺

拥有一个单一的业务级产品待办列表和团队中的团队为团队提供了放弃他们团队级别冲刺的孤立机会。业务级产品待办列表包含大型和重要的项目，这些项目最适合通过多个团队的协作来解决。他们以共享的节奏进行学习和工作 - 即产品冲刺。

我们都知道，“一个共同的目标”是一群人和一个团队之间最大的差异。通过同步工作，将独立团队之间的依赖性从中断变成了团队中的团队(team of teams)内协作的机会。

此外，每个冲刺交付的价值将是一个业务级别的成果。利益相关者将从参加整体冲刺评审中受益，以检查他们投资的回报。

Elevated System

升华工程实践

要想最大限度地发挥这种方法的优势，一个重要的先决条件是共享的多团队代码所有权。

这意味着我们需要打破团队与特性的耦合，并扩大团队的工作范围，从任务或特性扩展到整个公司领域。（如果公司太大，我们可以定义相互独立的业务领域部分）。

目标是所有开发人员都可以在许多组件上工作，理想情况下，他们可以更改所有代码。大多数人认为这是不可能的，也是不可取的，因为这将造成混乱。另一方面，私有代码所有权的结果也不尽如人意：代码复杂和标准化问题。那么，为什么不尝试一下呢？

共享代码所有权可以逐步且深思熟虑地实现。比如：将那些经常需要更改的仓库向大多数开发人员开放怎么样？

有许多方法可以使这个先决条件不那么可怕（共享标准、技术栈简化、自动化，仅举几例）。

那么，团队产出所有者呢？

根据这些人的技能和他们在新组织中想要做的事情，有很多选择。

但在大多数情况下，产品负责人(product owners)对某些特定产品部分拥有丰富的知识，他们理解某些业务流程的特定方面，知道如何分析和拆分大型需求，有些甚至仍然可以编写代码...

这会让他们成为很棒的团队成员，不是吗？

总结

业务敏捷性意味着公司能够在不增加额外成本的情况下，随时决定开始当时最重要的工作。

业务敏捷性可以通过以下结构性措施来实现：

1. 弥合“产品差距”

2. 将产品负责人升华到产品层面

3. 升华团队并形成团队中的团队(team of teams)

4. 升华冲刺阶段

5. 升华工程实践

6. 形成产品组，使人们共同应对产品(Product)的挑战 

© 2024, Roland Flemm and Alexey Krivitsky

致谢

本篇译文来自 ShineScrum 捷行译社翻译，未经许可不得私自转载。

译者：周菲(Fei Zhou)

专业认证：CAL1, CSP-SM, A-CSM, CSM.

审校：龚敏睿

专业认证：PMI 认证 ACP, CSP-SM, CAL1, Agile Team Facilitation, Agile Coach.

原文链接：https://www.orgtopologies.com/post/product-management-for-business-agility

如果大家对敏捷产品开发感兴趣，想进一步学习，欢迎报名 CSPO 和 A-CSPO 课程实操练习。