实现一份产品待办列表的限制系列之二｜特性负责人和子领域产品负责人的经历

​前言

前一篇文章是以分析的方式写的，而在这篇文章中我将补充一段诺基亚网络时期的经历。因为已经过去十多年了，一些细节不会如我期望的那样准确，但是我希望仍然记录下了本质的部分。此外我将添加一些事后的推理，而实际情况是当引入这些变化时我们并没能将它们进行透彻的推理分析。今天，我会建议首先通过系统建模来推理将要引入的变化，然后在变化之后回到模型进行学习和适应。

专题目录

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

一个领域

这是一个在基于3G的网络产品中的领域，叫TT（Traffic & Transport，流量与传输）。在整个产品中有4-5个像这样的领域。在TT这个领域中，我们有12个团队，一份领域待办列表和一个APO（Area Product Owner，领域产品负责人）。

因为这段经历发生在有LeSS之前，我们其实并没有称它为RA（Requirement Area，需求领域），并且跟RA也确实有些差异。但是如果你就把它当作一个RA，甚至一个产品，并不影响理解这其中的变化。所有以下的变化都发生在TT领域范围之内。

主要的变化有两个，是一个接着另一个发生的。在引入变化之前已经形成了一些紧张状况，最明显的是APO的工作负荷。你可以想象，一个APO应对这样规模的领域是极具挑战的。

特性负责人

APO的工作超负荷了，他迫切需要人帮忙。我们为此引入CIO（Content Item Owner，内容项负责人）的角色来带领内容项的开发。内容项只是大特性的花哨名字而已，它的开发多数情况会跨多个团队和许多迭代。为了减轻理解负担，我将使用更通用的名词FO（Feature Owner，特性负责人）来描述这个角色，但是记得那些都是相当大的特性。

这个角色定义和涌现出两个方面。

• 产品领导力FO试着最大化特性的投资回报率。他维护特性开发的全貌，对特性范围内的条目进行优先级排序，与APO一起决定是否继续这个特性的开发还是转向其它特性。
  FO对特性做粗略澄清，并主导把特性拆分成较小的条目。然后他和团队在PBR（产品待办列表梳理）中协作来做细节澄清，并为那些条目定义验收测试。
  
• 技术领导力不像PO，FO也施加技术领导力。他会组织团队里的资深开发人员一起联合设计，并引导相关团队之间的协调。

最初，FO只是兼职角色，他仍然作为成员在团队中工作。FO在团队内还是团队外？我相信当时并没有清晰定义过，在引入这个角色后团队的边界变模糊了。FO是谁定的？APO和直线经理，而不是团队自己。这暗示它是一个团队外的独立角色。

产品领导力的部分与前一篇文章中提到的PO对应特性的模式类似。随着团队开发不同的特性，他们会跟不同的FO工作。

技术领导力的部分更多是偶然发生，而非设计如此。当特性跨多个团队时，团队就自然地去寻找某个人能跨团队带领大家，而非依赖多团队的自组织。

随着时间的推移，一些FO变成了全职。他们作为FO工作在一个接一个的特性上，并逐步减少在团队内的工作时间，直到完全没有。

我们究竟应该如何理解FO这个角色？

• 首先，FO并非真正的PO，因为他们的优先级排序只在特性内，使得他们对整体投资回报率的影响有限。事实上根本不应该有对应特性的PO。在那种情况下，已经失去了PO角色中最本质的部分 – 识别有价值的特性。
• 其次，FO的主要焦点在粗略澄清和拆分上，而细节澄清并定义验收测试则是在PBR中和团队一起做。在这点上它与BA（Business Analyst，业务分析师）类似，而BA应该是包含在团队里。此外它更像SE（System Engineer，系统工程师），因为他既工作在产品又工作在技术上。这并不奇怪，SE是现状的一部分，而把我们拉回现状的力量一直都潜伏着。

让我们看一下在领域里引入FO之后的影响。

• 在领域里有多少份产品待办列表？还是一份和一个优先级，由APO来决定。围绕领域待办列表的检查和适应仍然是每个迭代都在TT层面发生。
• 领域中有一组人（那些FO）积极发展产品知识和领导力。无论他们是往APO演进还是回到团队中，产品能力的提升都是确实的。
• 当APO开始更多跟FO而非直接跟团队工作时，团队里其他人发展产品知识的空间有所压缩，透明性也有所降低

子领域产品负责人

在后来的某个时间点，我们引入了sub-APO（子领域产品负责人）的角色。我们主要有两个子领域：TT-IP（基于IP的流量与传输）和TT-ATM（基于ATM的流量与传输）。在那个时候有人已经承担了几个特性的FO角色，并已经逐渐在子领域发展出不错的产品领导力。事实上，他们都已经是全职的FO。因此下一步感觉很自然，我们让他们成为了更永久的sub-APO。这看起来也像是自然的通往APO的职业路径。另外有两个因素影响了引入sub-APO的决策。一个是拆成子领域让优先级排序变得更容易，因为在每个子领域中的条目数量变少了。另一个是团队的汇报结构也在往基于子领域演进，比如6个专业化在TT-IP上的团队汇报给一个经理，而6个专业化在TT-ATM上的团队汇报给另一个经理。所有这一切看起来都很合拍。

然而，这反映出我们当时思考的随意性，缺乏对变化进行深入分析。比如，我们没有清晰地看到变化对产品待办列表份数的影响，以及进而对组织适应性的影响。

在TT-IP和TT-ATM各自引入sub-APO后有多少份产品待办列表？我们倾向于说还是一份，因为在TT领域仍然只有一个APO。但是如果更仔细看一下情况，我们会发现其实有了两份。无论是作为同一份TT待办列表里的不同视图维护还是单独维护两份待办列表，优先级排序主要还是在各自的待办列表中由sub-APO进行。此外，耦合的汇报结构也让团队附着于子领域，开始是心理上的，然后在能力上也是。随后，更多的待办列表降低了整体组织的适应性。

随着sub-APO的引入，对FO的需求也变少了，特别是在团队中的资深开发人员能够提供技术领导力的情况下。

小结

整个旅程看起来像这样：先是只有APO，接下来是APO加一组FO，再然后是APO和两个sub-APO。当我为这段经历添加推理时，感觉有些凌乱。我猜这是因为我们当时的思考就有些凌乱。在后来这些年思考逐渐清晰，我将在下一篇文章中提供一个新的视角。

作者介绍

作者：Yi Lv吕毅

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