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

ScrumMaster中文CSM认证课程- 2021年9月-北京线下面授班-敏捷项目管理培训
2021年8月15日
实现一份产品待办列表的限制系列之二|特性负责人和子领域产品负责人的经历
2021年8月17日

​前言:

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

专题目录:

01PO对应团队还是特性?
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打开了通往产品开发领域中学习型组织的阶梯。

评论关闭了。

拨打免费咨询电话 021-63809913