实现一份产品待办列表的限制系列之一｜PO对应团队还是特性？

​前言:

最近我碰巧翻到一篇十年前写的旧文，叫“PO对应团队还是特性？”；我发现它可以被连接到实现一份产品待办列表的限制这一话题。那时的思考触碰到了一些因素，但依然模糊。过去这些年我对该话题的思考有所改善，因此决定写一个关于它的系列文章。同时我也决定把这篇旧文作为这个系列的第一篇。

专题目录:

01	PO对应团队还是特性？
02	特性负责人和子领域产品负责人的经历
03	来自PO在澄清上的限制
04	来自PO在优先级排序上的限制
05	来自团队在领域开发上的限制

PO对应团队还是特性？

PO对产品成功负责；PO也是团队工作的唯一入口。在一个单团队的环境里，PO一直跟那个团队工作，所有事情都很清晰。

然而，在一个多团队的环境里，事情变得更复杂了。当团队数量太多时，一个PO跟这个产品里所有团队工作变得困难。这导致有多个PO跟不同团队工作。在产品层面仍然有一个PO，他创建了一个包含多个PO的PO团队。一个PO通常跟超过一个团队工作，但不会是所有团队。因为一个大特性可能被多个团队一起开发，就有两种关联PO和团队的模式出现。

• PO对应团队
• 固定PO和团队之间的对应关系。对每个PO来说，他一直跟那几个团队工作。自然他也会管理产品待办列表中与他团队的工作相关的部分。

• PO对应特性
• 并不固定PO和团队之间的对应关系，而是根据团队工作的特性来改变。在这种模式里，PO是对产品中的特性负责。哪些团队工作在那些特性上，PO就跟哪些团队工作。

我一直建议PO对应团队，并感到PO对应特性有些不对劲。这篇文章试图澄清为什么，不仅为你，也为我自己。

PO对应特性的好处和问题

让我们先来理解一下PO对应特性试图获得的好处。主要有两个：

1. PO可以在产品的某个部分和一些特性上专业化。任何团队能工作于任何部分的产品虽然理想，刚开始却并不一定可行。这一点同样适用于PO。PO对应特性使得他们可以在产品的某个部分上专业化；
   
2. 整个特性都由一个PO管理，从而减少相关团队的协调开销。

PO对应特性的最明显问题是，如果一个团队同时需要工作于多个特性该怎么办？如果你允许多个PO对接同一个团队的话，就又把诸如冲突的优先级、部分分配之类的传统问题给带回来了。

但是PO对应特性也不一定就意味着多个PO对应一个团队，还是可以做到在任何时候谁是团队的PO都是清晰的。如果团队工作于两个特性，负责更重要特性（基于价值、大小等因素）的那个PO可以在相应迭代中作为团队的PO。其他PO则需要跟团队PO工作以让他们的内容排进那些迭代中。那样一来，当团队工作于不同特性时会有PO的切换。虽然对团队来说在任何时候只有一个PO，在交接阶段两个PO还是可以一起工作。

以上安排是否就没问题了？我不认为如此。PO对应特性有两个更深层的问题。

1. PO对应特性加强了对当前特性的焦点，而对流动和长期持续性有所损害。如果我们想要让团队在迭代中达到高效，我们需要在特性进入迭代前将它准备好。这要求逐步梳理待办列表和未来的特性。如果我们想要让版本更可预测，我们需要主动应对风险和不确定性。这要求提早投入来预研。如果我们想要持续交付高质量的产品版本，我们需要降低改动成本。这要求逐渐偿还在遗留系统中的技术负债。然而，PO对应特性会更偏向于短期的项目思维。
   
2. PO对应特性打破了反馈回路，而反馈对学习和持续改进至关重要。当PO对应特性时，PO不太可能和之前做特性的团队一起从诸如不切实际的承诺、牺牲完成的定义、围绕需求的无效协作等错误中学习。

简而言之，PO对应特性经常导致失去短期与长期的平衡，而对于PO这一角色而言，只是最大化一个迭代或者一个特性的投资回报并不够，而是需要持续地在产品的生命周期里都做到。

PO既对应团队又对应特性

我们如何能把PO对应特性的那些好处实现到PO对应团队的模式中呢？形成产品领域是关键。

一方面，领域需要足够大以容纳大多数特性。即使那些特性的工作会散布到多个团队，整个特性还是能够在一个领域内管理，从而让协调变得容易。另一方面，足够大的领域依然小于整体产品，因此PO还是可能在领域内专业化。

关于一个PO能够工作的团队数量，有人说不超过2个，也有人说可以到10个，我认为的有效点是5个左右。一个PO对应5个团队既能有一定的专业化又能让特性协调简便。

写于2011.4

作者：Yi Lv吕毅

国内首位CST、LeSS（大规模框架）认证师、敏捷教练及顾问。他的工作焦点一直在大规模产品开发上，尤其是帮助组织从LeSS中获益或是直接导入LeSS。其中的一段经历被作为LeSS案例记录了下来：华为 – 没有Scrum的LeSS（https://yihuode.io/articles/324）。他相信LeSS打开了通往产品开发领域中学习型组织的阶梯。