产品负责人是否应该管理多个产品？

Question

在Scrum或敏捷团队中，产品负责人参与多个产品是否明智？企业系统有一个产品负责人，而该系统的组件有一个“子”产品负责人，这样好吗？例如，在零售商中，您是否会为企业系统提供采购订单，以驱动零售、供应链和制造等领域的“子”采购订单？

关注其他人如何在企业环境中与Scrum团队打交道，企业环境中有许多利益相关者在功能筒仓中。

Answer 1

In a Scrum or Agile team is it advisable for a Product Owner to be involved in more than one product?

首先，你必须明白在Scrum中你不会有一个客观的答案。你将不得不检查和适应。在Scrum指南(由Scrum的发明者编写)中没有提到PO不应该处理超过2个产品，但他们确实提到，为了使PO成功，他必须承担产品的全部责任，组织必须尊重POs decision.The PO是产品积压的“猪”，无论是1个或2个或更多产品，如果PO和利益相关者可以处理这一点，我会说尝试，并检查和适应。还有各种因素，比如产品有多复杂，产品负责人在产品中的专门化程度，以及PO有多少带宽来为多个产品执行PO职责。请在尝试之前将所有这些都考虑在内。

Is it good to have a Product Owner for the Enterprise System and "sub" Product Owners for the components of that system? i.e. In a Retailer would you have a PO for the enterprise system that drives "sub" PO's for say Retail, Supply Chain and Manufacturing?

再一次，你将不得不在你的组织中尝试它，以了解它是否“好”。在指定POs或sub时，只需遵循正确的Scrum指导原则。我在我的组织中尝试了它，它产生了奇迹！我们有一个首席采购官，以及其他几个你可以称之为次采购的人，但我更喜欢让每个人保持在同一级别，以避免指挥和控制行为，当滥用时，可能会毁了一个项目。首席POs的工作是确保POs在他们所做的事情上是成功的，并在需要的时候帮助POs。另外，采购主任的任命也可以由首席采购官与首席销售经理或销售经理一起完成。如果我可以稍微离题一点，SMs也遵循了同样的结构。首席SMs的工作将是帮助SMs成功地完成他们的工作，例如，如果SM不能解决障碍，他或她可以让首席SM来帮助解决它。

Be interested in how others deal with Scrum teams in an enterprise environment with many stakeholders in functional silos.

就像我在上面提到的。在我们的企业环境中，我们有一个首席PO和其他几个PO。还有一个由利益相关者组成的指导委员会。每个采购订单都有自己的产品积压要管理。我们有两周的冲刺。我们每个月召开两次名为“指导委员会会议”的会议，所有利益相关者和首席PO和POs开会，引导企业产品朝着正确的方向发展，每个PO都以Scrum术语(潜在的可发货用户故事)为他们的每个产品翻译工作，首席PO在教育和保护POs方面发挥着至关重要的作用，使他们免受对Scrum框架知之甚少的利益相关者和成员的影响。他们保护邮局不被劫持。每个PO都有自己的Scrum团队，由SM和团队成员组成。我建议让首席PO成为一名敏捷教练，在组织中拥有良好的地位。同时配置位置，它特别有助于解决团队间的依赖关系和问题。

注意:有一件事我们做不到，那就是一个团队的两个POs和一个产品积压，在POs之间有太多的冲突！

希望这能有所帮助。

Answer 2

产品负责人可以在多个产品中担任此角色，具体取决于产品的大小。另一方面，大型企业应用程序的子组件可以有多个产品所有者。然后你就有了一个“首席产品负责人”。

这是完全有效的，也是明智的。

所有这些概念都在Roman Pichler撰写的Agile Product Management With Scrum: Creating Products That Customers Love一书中有详细介绍。

我看过他的演讲，并在Scrum聚会上与他交谈过很多次。他的专长是产品所有者。

Answer 3

在类似的情况下，我也是一名ScrumMaster。您可以为您的开发工作的子系统拥有“子”产品所有者或“联合”产品所有者；在企业中，这是很常见的。他们本质上成为了一个“产品负责人团队”，其中也可能包括业务分析师。

然而，您应该为这个产品负责人团队指定一个“领导”；这个人可以解决分歧，并为积压工作建立总体优先级，这个人应该确保满足所有其他产品负责人的需求。在实践中，这通常是项目经理。

另一种方法是将子项目分离为单独的scrum团队，然后进行“scrum的scrum”；但我不认为这对单个开发项目有效，因为这将在团队之间创建更困难的信息流。除非每个子项目可以相互独立地运行，否则我建议使用第一种方法。