实现一份产品待办列表的限制之三｜来自PO在澄清上的限制

实现一份产品待办列表有哪些限制呢？有两个方面，分别来自PO（Product Owner，产品负责人）和团队。我们将首先关注来自PO的限制。当有人说一个PO不可能管理一份由很多个团队共享的产品待办列表时，背后其实有两个不同的限制。一个是澄清，基于的假设是PO需要澄清产品待办列表中的条目；另一个是排优先级，基于的假设是PO需要为产品待办列表中的条目排优先级。我们将在这篇文章中关注第一个限制，并在下一篇文章中关注第二个限制。

专题目录：

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

在澄清上的伪限制

一份产品待办列表带来优化的组织适应性，然而能否实现受限于一些因素，其中一个就是PO的澄清能力。这可以由以下平衡回路表示。

PO的澄清能力可以度量为“PO能澄清的条目数量”。在能力（比如PO能澄清50个条目）和需要（比如在一份产品待办列表中有200个条目）之间的差距就造成了PO的焦虑。最常见的响应是增加产品待办列表的份数，并相应地增加PO的数量，以使每个PO只需要澄清更少的条目，因为在每份产品待办列表中包含了更少的条目。如果我们接受这个逻辑，恐怕最多也就做到2-3团队共享一份产品待办列表。

但是，这是一个伪限制，因为我们并不需要让PO给团队澄清所有的条目。团队可以自己澄清条目，而PO更多专注在排优先级上。这正是LeSS指南“排优先级胜过澄清”所描述的，并可以由以下平衡回路表示。

团队的澄清能力是一个能否实现的关键因素。团队开始时缺乏产品知识和技能来把澄清做好的情况很常见。这是否意味着澄清至少暂时来说是实现一份产品待办列表的一个真实限制？并不是，因为即使在那种情况下我们还是可以保持一份产品待办列表。

保持一份产品待办列表

当团队还没准备好立刻把澄清承担起来时，我们还是可以保持一份产品待办列表，但是会有一些人在澄清上帮助PO。因为那些人只是帮助澄清，他们并不维护单独的产品待办列表。因此他们并不是PO，而更像是之前文章中描述的FO（Feature Owner，特性负责人）。以下是与澄清相关的部分。

“FO对特性做粗略澄清，并主导把特性拆分成小的条目。然后他在PBR（Product Backlog Refinement，产品待办列表梳理）中和团队协作来做细节澄清，并为那些条目定义验收测试。”

这个方式可以由以下平衡回路表示。

与引入多份产品待办列表不同，我们保持一份产品待办列表，但是会有一些FO来帮助PO澄清。不过请记得团队至少在PBR中会参与细节的分析。

那些FO从哪儿来？让我们来看两种场景，一种是过去有“团队PO”维护自己团队的一份单独列表，而另一种则没有。

• 在第一种场景中，“团队PO”可能不愿意立即加入到团队，无论有没有正当理由。在这种情况下，我们可以把“团队PO”转为FO，并去除各自独立的产品待办列表。同时，他们仍然通过他们的产品知识和技能来带领大家澄清。这样一来马上就创建了一份产品待办列表，并往PO排优先级而团队澄清的愿景迈出了下一步。
  
• 在第二种场景中，一些成员可能带头来积极发展有效澄清所需的产品知识和技能。当之前并没有“团队PO”时，有必要作为一个新的角色引入FO吗？可能不需要。一般来说，这跟FO和团队在澄清中的相互作用有关。

转变中的特性负责人

FO这一角色是在团队内还是团队外？在之前的经历中，我们并没有定义清晰，只是有一些暗示将其作为团队外的角色。这对团队的其他成员有着负面影响。

引入FO角色的危险之处反映在以上“负担转移”的动态中。B1回路表示的FO澄清是短期治标的方案，而B2回路表示的团队澄清是长期治本的方案。此外还有一个上瘾的R回路在加强我们对FO方案的依赖。B2回路代表了愿景，如果缺乏共同愿景，我们将永远陷在B1回路中。

一旦我们认同了共同愿景，我们可以通过减少B1同时增加B2来加以影响。在战术层面有一些可能的下一步：

• 明确FO是团队内的角色，由团队决定谁承担哪个特性的FO（减少B1）
• 在PBR中由FO带领团队来学习和成长产品能力（增加B2）
• 让不同的团队成员承担不同特性的FO（减少B1）
• 在某一个特性上尝试没有显式的FO，而是让团队自组织来澄清（增加B2）

最终我们应该去除FO角色吗？事实上，如果团队决定保留FO作为一个团队内的动态角色，我并不介意。只要是团队成员通过自组织在不同的时间承担不同特性的FO，这个角色就已经不再是限制了。

作者：吕毅

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