实现一份产品待办列表的限制之四｜来自PO在优先级排序上的限制

在前一篇文章中，我们探讨了来自PO的其中一个限制 – 在澄清上的伪限制。在这篇文章中，我们将探讨来自PO的另一个限制 – 在优先级排序上的真限制。

专题目录:

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

PO对应团队还是特性？

在优先级排序上的真限制

除了在澄清上的限制外，另一个限制是PO的优先级排序能力。不像团队可以做澄清，因此PO的澄清能力是个伪限制；一般认为PO是必须要能排优先级的，因此PO的优先级排序能力是个真限制。这可以由以下平衡回路表示。

在优先级排序上的动态与在澄清上的动态类似。PO的优先级排序能力可以度量为“PO能排序的条目数量”。在能力（比如PO能排序100个条目）和需要（比如在一份产品待办列表中有200个条目）之间的差距就造成了PO的焦虑。最常见的响应还是增加产品待办列表的份数，并相应地增加PO的数量，以使每个PO只需要排序更少的条目，因为在每份产品待办列表中包含了更少的条目。

当我们把两个限制如上图放在一起时，我们发现主要的差别在于哪个限制先起作用。换句话说，哪个数值 – “PO能澄清的条目数量”还是“PO能排序的条目数量” – 更少？正如我们所知，我们需要澄清条目以能排序。然而澄清的程度会根据目的是排序还是交付而不同。当以交付为目的时，我们需要澄清得更细。因此，“PO能澄清的条目数量”要比“PO能排序的条目数量”更少。比如说，一个PO能澄清50个条目，但能排序100个条目。

事实上，这是LeSS和LeSS巨型框架中定义的“8”这个神奇数字背后的主要假设。我们假设实现一份产品待办列表的限制是来自于PO的优先级排序能力，也就是一个PO能排序100个细粒度的条目。其它假设还有：1）多细粒度的条目？一个迭代一个团队4个条目；2）往前看多远，也就是需要保持多少个迭代的细粒度条目？2-3个迭代。基于这些，大致我们需要为一个团队排序12个细粒度条目。然后，100除以12差不多就是“8”，这就是整个逻辑。

一起排优先级

但是在之前的经历中，我们有12个团队共享一份产品待办列表，很显然是打破了这个限制。我们是如何做到的？关键在于FO（Feature Owner，特性负责人）。

“FO试着最大化特性的投资回报率。他维护特性开发的全貌，对特性范围内的条目进行优先级排序，与APO一起决定是否继续这个特性的开发还是转向其它特性。”

事实上，随着FO参加到优先级排序中，我们增加了优先级排序能力。PO和一组FO一起能排序更多的条目。

在我们的实践中，PO在更粗粒度上主导优先级排序，而FO则在更细粒度上。但是他们是在一份产品待办列表上一起排优先级，并还是基于迭代来检查并适应，以全局优化客户价值。在PO和FO的定期会议上，PO设置整体的粗粒度优先级，就像一份优先级指南；而FO则分享各自特性内的细粒度优先级，并建议自己负责特性的哪部分需要现在就做，哪部分相比其它特性可以晚些时候再做。

还有其它的方式来一起排优先级。比如PO提供愿景并引导FO来进行优先级排序。这样做，他们其实是共创一个优先级，而愿景则作为排优先级的指南。

在上面的左图中，展示了当一起排优先级时PO和FO决策比重随时间发生的变化。最初，PO完全自己来决定优先级。然后，PO后退来给FO参与决策创造空间。最后，很可能PO主要是引导，而优先级决策主要由FO来做。PO仍负责产品愿景，但随着FO做更多决策，优先级排序能力得到了提升。

在上面的右图中，FO被团队所替代。在之前的文章中，我们探讨了FO如何从一个团队外的由PO或者管理者指定的角色转变成一个团队内的通过团队自组织涌现的角色。当转变发生时，就成了团队或者他们中的部分人在和PO一起排优先级。

根据LeSS指南“排优先级胜过澄清”，PO应该主要专注于排优先级，而把细节的澄清交给团队。但这并不必然意味着只有PO能排优先级。当PO和团队一起排优先级时，优先级排序能力变得不那么限制了。

后续思考

到目前为止，我们已经探讨了来自PO的限制，包括在澄清上的伪限制和在优先级排序上的真限制。即使是在优先级排序上的限制，我们也可以通过一起排优先级让它变弱。

然而，愿景还是由PO提供。在展望愿景上的能力会是来自PO的终极限制吗？我们其实已经探索过这个话题 – 产品的共同愿景。共创愿景是可能的，虽然很难！愿景给一起排优先级提供了指南，而一起排优先级又促进了共同愿景。因此，看起来并没有来自PO的对实现一份产品待办列表的绝对限制。

作者：吕毅

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