我原先以为这个选择本质上和一份还是多份产品待办列表是相同的。当我细想后，发现还是值得把它写成单独的话题。作为两个最流行的大规模敏捷框架 - SAFe和LeSS - 在这上面就做了不同的选择。SAFe中的ART（敏捷发布火车）和LeSS中的LeSS（到8个团队）规模上是近似的。在ART中，定义了产品经理和若干团队PO（产品负责人）；而在LeSS中，却只定义了一个PO跟所有团队工作。在本文中，我们会探索围绕一个还是多个PO这个选择的系统动态。
在SAFe里对ART的描述中，它提到了定义团队PO的原因。
“规模大了，一个人就没法既处理产品和市场策略又专注于敏捷团队。因此，产品经理和团队PO们会一起驾驶火车。”
让我们来探索为什么这么选择以及它产生的后果。
优先级排序 胜于 需求澄清
以下因果回路图呈现了引入多个PO来分担需求澄清工作量所产生的相关动态。
引入多个PO作为减轻一个PO所需承担需求澄清工作量的解决方案反映为B1回路，它可以这样读：
- 一个PO澄清需求的工作量变高
- 引入更多PO
- 一个PO澄清需求的工作量变低
在这个解决方案背后有一个常见的误解，以为PO唯一负责澄清需求。在单团队Scrum里，这更像是一种选择，Scrum指南里这样描述：
“PO可以做以上工作，也可以让开发团队做。”
以上工作包括需求澄清。
而在多团队Scrum里，如果我们希望让一个PO能够和多个团队工作，团队分担需求澄清工作就变得很必要了。LeSS里这样阐述：
“一个LeSS里的PO专注于努力思考优先级，但和团队协作澄清需求。并且他会鼓励和帮助团队直接和真正的用户／客户对话。他作为一个连接者，而非中间人。”
这个替代的解决方案反映为B2回路，它可以这样读：
- 一个PO澄清需求的工作量变高
- 团队参与需求澄清越多
- 团队和客户工作的能力越强／团队具有更丰富的业务领域知识
- 一个PO澄清需求的工作量变低
R回路解释了为什么多个PO的做法如此常见，它可以这样读：
- 一个PO澄清需求的工作量变高
- 引入更多PO
- 对PO澄清需求的依赖越大
- 团队参与需求澄清越少
- 团队和客户工作的能力越弱／团队具有更贫乏的业务领域知识
- 一个PO澄清需求的工作量变高
- 引入更多PO
如果读了这个系列之前的文章，你一定已经认出了这里的“舍本逐末”系统基模。
合同游戏的现状
以下因果回路图呈现了从研发引入多个PO来应对业务方的改变阻力所产生的相关动态。
业务和研发之间传统的工作方式是基于合同游戏的。业务和研发协商一个发布的合同，然后业务就交由研发交付合同。在导入敏捷之前双方是没有基于迭代的协作的。当你想有更多PO时，对业务方就意味着更多的改变。阻力应运而生，最终导致在研发这边创建了更多PO。这样做消除了阻力同时又满足了对PO角色的需要。现状得以保留。
B1回路是个速效方案，它可以这样读：
- 业务方需要的改变越大（需要更多PO）
- 产生的改变阻力越大
- 在研发这边引入更多PO
- 业务方需要的改变越小
B2回路是个根本方案，它可以这样读：
- 业务方需要的改变越大（需要更多PO）
- 产生的改变阻力越大
- 对业务方的辅导越多
- 团队和业务之间的协作越多（或者作为PO，或者作为干系人，关键是基于迭代来协作）
- 带来越多价值和越大灵活性
- 业务方需要的改变越小
R回路解释了为什么这么容易就回复到现状，它可以这样读：
- 业务方需要的改变越大（需要更多PO）
- 产生的改变阻力越大
- 在研发这边引入更多PO
- 团队和业务之间的协作越少（因为团队和PO之间的协作变成了研发内部的协作）
- 带来越少价值和越小灵活性
- 业务方需要的改变越大
是的，你又一次看到了“舍本逐末”系统基模。
结论
我看到过两种常见的一个产品多个PO的情况。
在许多互联网公司，这些团队PO就是低级别的产品经理。他们更多工作在战术层面，而非战略层面。当他们喂给团队详细的规范和用户界面草图时，团队在产品探索上的参与度就会很低。这不仅丧失了让团队贡献于产品探索的机会，也为达成产品交付所需的共同理解制造了障碍。
在更传统的行业，从研发这边引入团队PO的做法很常见。当他们关注于需求澄清时，他们本质上退化为传统的业务分析师。有很多理由反对业务分析师的角色，我最喜欢的是Martin Fowler和Dan North在2007伦敦QCon上做的主题演讲中阐述的，简而言之就是，“桥比渡轮更好”。
当你选择有多个PO时注意后果！
英文版：https://blog.odd-e.com/yilv/2017/03/seeing-the-system-dynamic-1-vs-n-product-owners.html