出乎意料的是,我从未写过战略产品所有者/战术产品所有者模型的博客,这令人惊讶,因为它是我一次又一次发现并一次又一次提倡的模型。
我发现许多公司都已安装了该模型的版本,他们已经创建了该模型来处理自己的情况。 但是,这些公司中很少有人意识到这是重复发生的解决方案,而且是相当合法的。 (我应该把它写成一个模式,但是我已经有一段时间没有写任何模式了。)
更重要的是,我发现许多公司和个人都面临采用产品所有者的问题,因此可以从中受益。 具体来说,正如我已经提到的, 产品负责人有很多工作要做,一种方法是分担负载。
如果我将其编写为模式,则缩略图版本将显示以下内容:
产品负责人缺乏时间(有时甚至是技能)来完全填补角色,因此将角色一分为二。 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