实现一份产品待办列表的限制之五｜来自团队在领域开发上的限制

前言

在前两篇文章中，我们分别探讨了来自PO（Product Owner，产品负责人）的在澄清和优先级排序上的限制。在这篇文章中，我们将要看来自团队的限制。

专题目录

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

团队的开发能力

与来自PO的限制类似，我们也会受限于团队的开发能力，如下图所示。

在团队能做的和需要做的之间有差距，团队由此产生焦虑。对此的响应是创建更多的产品待办列表，以使团队需要做更少就行。大致逻辑如此，但让我们深入下去。

团队的焦虑是如何增加产品待办列表份数的？事实上有两种场景，在下图中呈现为两条不同的链路。

团队的焦虑是如何增加产品待办列表份数的？事实上有两种场景，在下图中呈现为两条不同的链路。

团队自行决定只挑选他们更有能力开发的特定条目。这样做创建了隐性的待办列表；

团队向PO提出他们缺乏开发一些条目的能力，PO同意他们可以只挑选其另一些条目。这样做创建了显性的待办列表。

用什么可以表示团队的开发能力？“一个团队能开发的条目数量”是一个选项。于是“一份产品待办列表中的条目数量”其实就是“一个团队需要开发的条目数量”。请注意这里的条目数量其实不是指速度，而是指类别。

在“待办列表份数和多面学习”的系列中，我们描述了三种专业化，基于各类开发能力 – 职能、技术和客户领域。直接限制一份产品待办列表的是在客户领域上的开发能力，尽管开发在各个客户领域经常会要求不同的技术和熟悉不同的技术模块。因此，我们可以把变量定义为更聚焦的“一个团队能开发的领域数量”。更新后如下图。

受限于团队在客户领域上的开发能力，我们创建RA（Requirement Area，需求领域） – 其实就是客户领域 – 来应对。因此一个团队只会属于一个RA，并且同一个RA中的所有团队都共享一份待办列表和一个优先级。然而，团队属于哪个RA将会随着业务和市场的变化而变化。

充分但不必要

在LeSS的产品和LeSS巨型的RA内，团队应该有宽泛的知识，从而具备适应能力，能够从一份共享的待办列表中拿任何条目来做。这听起来像每个团队能开发任何条目，但它是保持一份待办列表和一个优先级的充分不必要条件。

有一个LeSS指南叫“优先在客户领域上专业化”，我们在华为的LeSS导入中加以了应用。下图（稍作修改以强调领域这个维度）和文字是从该案例中摘录的片段。

“该平台有4个相对明显的领域（比如操作系统扩展、补丁），重组后会有6个团队。我们试着兼顾广度和效率，通过两条约束条件：1）每个团队至少能做两个领域的工作；2）每个领域的工作至少有三个团队能做。这样一来，每个团队还能有一定程度的专业化，它对效率有利；同时也能做到整个组织仍以来自产品负责人输入的优先级顺序工作，而不用因为受限于能力不得不去调整优先级。”

在这个案例中，我们有一个产品，包含了4个领域。团队需要在几个领域里开发？简单的回答会是4个，因为有可能在某个时候所有高优先级条目都来自这4个领域中的某一个。然而，我们设置的约束却是至少2个领域。怎么解释？因为实际上在任何时候来自任何领域的高优先级条目至多占到50%，由此我们只需要每个领域至少有3个团队（6个团队的一半）能够开发。这意味着每个团队要能在2个领域（4个领域 x 3个团队 ÷ 6个团队）里开发。

如果看之前我们12个团队共享一份待办列表的经历，我们的团队也不是完全同质的。他们在RA内的更小领域上专业化，但是当专业化变得过于限制时，我们会让其他团队学习需要的领域来打破它。

推迟需求领域而保持一份产品待办列表

基于以上洞察，我们发现有比RA更好的应对团队开发能力限制的选项，就尽可能保持一份产品待办列表而言。让我们用一个例子来解释。

假设一个产品包含4个领域（A/B/C/D），有12个团队工作在这个产品上。我们的限制是每个团队只能在2个领域里开发。

• 两个RA、两份待办列表
  通常的方式是创建两个RA，每个包含2个领域。比如说，RA1有领域A/B和团队1-6；RA2有领域C/D和团队7-12。如下表所示。表格中的“x”表示团队【1-12】能在领域【A/B/C/D】里开发。

• 没有RA、一份待办列表
  基于每个团队只能在2个领域里开发的限制，我们还能保持一份产品待办列表吗？看情况。如果一份待办列表意味着每个团队需要在4个领域的任一个里开发，那样就不能。然而，一份待办列表可以只要求8个团队能在领域A开发（也就是在某个时候至多8/12的高优先级条目来自领域A），6个团队在领域B上，6个团队在领域C上，4个团队在领域D上，那样就能。一个可能的配置如下表所示。
  

我们如何把它付诸实践呢？我们首先问PO来试着理解需要：你估计在某个时候来自每个领域高优先级条目的最大占比是多少？或者，你可能在某个时候投入到每个领域最多的团队数量是多少？我们本质上是在了解需要的适应性程度，根据在每个领域里需要多少个团队能够开发。

然后，我们将它转化成约束，根据每个团队要能在几个领域里开发。这就成了自设计团队工作坊的输入。约束可能通过合适组建团队或后续学习或两者兼有来满足。无论哪种情况，我们都把团队标注为“能（在这个领域）开发”。我们可以进一步区分为“能开发/有技能”和“能开发/学习中”。有新领域涌现时，没有一个团队能，或者说，每个团队都能！团队决定哪些团队先进入那个领域发展能力。所有那些团队都将在“能开发/学习中”的状态。尽管如此，不要把它过度复杂化，因为这只是一个快照，会一直演变。

结论

到目前为止，我们已经通过以下话题探讨了实现一份产品待办列表的限制。

1. PO对应团队还是特性？
2. 特性负责人和子领域产品负责人的经历
3. 来自PO在澄清上的限制
4. 来自PO在优先级排序上的限制
5. 来自团队在领域开发上的限制

最后我想给你一项挑战 – 参考这个系列中的想法来实验以让10-15个团队共享一份产品待办列表。我期待你分享从中获得的经验和学习！

作者：吕毅

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

近期公开课