出乎意料的是，我从未写过战略产品所有者/战术产品所有者模型的博客，这令人惊讶，因为它是我一次又一次发现并一次又一次提倡的模型。

我发现许多公司都已安装了该模型的版本，他们已经创建了该模型来处理自己的情况。 但是，这些公司中很少有人意识到这是重复发生的解决方案，而且是相当合法的。 （我应该把它写成一个模式，但是我已经有一段时间没有写任何模式了。）

更重要的是，我发现许多公司和个人都面临采用产品所有者的问题，因此可以从中受益。 具体来说，正如我已经提到的， 产品负责人有很多工作要做，一种方法是分担负载。

如果我将其编写为模式，则缩略图版本将显示以下内容：

产品负责人缺乏时间（有时甚至是技能）来完全填补角色，因此将角色一分为二。 SPO（战略产品负责人）一个人看起来很长远，他们专注于客户和战略。 另一个是TPO（战术产品所有者），着眼于近期（本次冲刺，下一个冲刺，下一季度）。 TPO将大部分时间用于交付团队，而SPO则将大部分时间用于客户和高级利益相关者。

有时产品负责人缺乏时间，仅仅是因为-正如我之前说过的-产品负责人应该做很多工作而根本没有时间。

有时他们会因为团队庞大而缺乏时间，或者团队缺乏领域知识（因此需要向PO提出很多问题）。 有时，采购订单需要花很多时间才能满足客户需求，即使是最有才华的采购订单也不能一次位于两个地方。

他们可能还没有时间，因为他们还有其他工作要做。 虽然我认为产品负责人的角色是一份全职工作，但有时是合适的人担任该角色（通常是因为他们指挥权）需要将该工作与另一个角色结合起来。

例如，在交易柜台上，产品负责人可能应该是一位高级交易员，他既了解域名又有权对功能说是和否。 但是根据定义，这样的人没有时间。 通常，我希望有一个专门的产品负责人，但是有时拥有必要权限的唯一方法是再做一份工作。

有时，应该是产品负责人的人-再想想我们的交易员-缺乏担任该职位的技能和经验。 因此，他们再次需要帮助。

SPO / TPO模型的关键在于，担任该角色的两个人需要用一种声音说话。 如果不这样做，则模型将失败。 理想情况下，当TPO不可用时，SPO将加入其中，反之亦然。

在另一个场合，SPO / TPO模型可能有用：大型团队。

理想情况下，只有一个产品负责人，一个团队和一个工作流。 但是有时会有几种产品，团队和流。 在这里，您可能会有一个SPO负责长期工作，还有几个TPO，每个TPO都与一个团队一起工作。

现在，像所有好的模式一样，这个也不乏缺点……

我听过Scrum倡导者反对这种模式：他们说一个真正的产品负责人 。 他们的观点是……将更多的人放在交付团队和客户之间确实会影响沟通。

软件开发面临的问题之一是，当多个人认为他们有权说出下一步要构建的内容时。 当客户远离开发团队并且由多个人来协调需求时，会发生另一个问题。

理想情况下，开发人员可以直接与客户交谈，但这通常是不可能或不可取的-我现在不讨论原因。 因此，一个真正的产品所有者就是一个很好的解决方案。

但是随后，一个真正的产品负责人成为了瓶颈，因此我们将角色划分为SPO / TPO。 但是，每次我们在编码人员和客户之间引入另一个链接-另一个人-引入问题的可能性就越大。 因此，这成为一种平衡行为。

介于两者之间的人是理想的。

一个人可以做得更好。

两个人可以比一个人进步。

三…我需要说服力，这是对两的改进。

四...我很难相信有四个人来调解客户的声音是一种进步……除非您以前当然有五个！

翻译自: https://www.javacodegeeks.com/2018/05/the-product-owner-refactored-the-spo-tpo-model.html