PO或者类似角色，绝对是所有敏捷角色中最为苦逼的角色。如果不信，来看看这张图。

处于风暴中心的PO

刨除那条与高管有关的线之后，以及结合Scrum Guide，你会发现PO 最关键的职责就是处理“需求优先级”。毕竟PO 作为团队的带路党（好像哪里怪怪的），PO 能否做好需求排序就成了其工作最核心的任务之一。

需求类型引出的问题

既然要排序，那么对于需求的类型就需要直面。

如果我们简单粗暴一点，将需求区分为功能性与非功能性需求的话，我们会发现，针对功能性需求，PO的排序是比较简单的，因为这是PO 的工作职责与范围。但是在非功能性需求方面，绝大多数都是“技术问题”，或者叫做“组件”。这种需求无法直接给用户提供价值，但是部分甚至绝大多数用户价值需要构建在这些非功能需求之上，比如短信发送能力、比如高负载、比如高可用。

而对于PO而言，如何对非功能性需求排序，就成为了一个重要工作。但这恰恰击中了某些PO的“知识盲区”。

绝大多数的PO不具有很强的技术能力，那么在对技术问题或者组件的理解上就不会充分，在这种情况下，很多PO 会陷入迷惘，不知道该怎么做。如果让其再对这些功能性需求进行排序，对某些PO 来说，他们更倾向于“当前去世”。

有些团队为了解决这个问题，做了一个看似明智的做法，那就是“引入一个技术PO”，从而有专人来负责类似的事件发生。

但，真的可以解决么？

不足之处

上述的做法看似完美解决，但是隐含了以下几个问题：

1. 双PO的形式，会对团队产生“两个手表”的困境。

如果这两个PO 产生冲突或者意见不一致，团队会比较疑惑到底该听说的。

这一定程度上增加了团队内部的沟通成本；

2. 两个PO的工作如何分配是个问题。

虽然我们可以给某个PO 加上一个“技术PO”的头衔，但是在实际业务中，单纯脱离业务而存在的技术，本质上是不存在的。

任何的技术都要为某个业务来服务。

在这种情况下，两个PO工作产生交叠就不可避免；

抛开上述１中的不一致问题，其实也还会产生工作重复等情况；

3. 工作量分配不确定导致的人员浪费。

每次我们规划的工作比例是不可确定的，这就导致了PO与技术PO的工作比例无法确定，甚至在迭代过程中也会有变更的可能性。

在这种情况下，我们连粗略的掌握两位PO的工作量都做不到，这明显会产生精益中所说的“负载不均衡”导致的浪费；

4. 在形式上，我们排除了团队参与需求的可能性。技术需求也是需求，这点与业务需求并没有明显的区别。针对技术需求而言，其需求方就是研发人员本身。在这种设定之下，PO要做的以及能做的，就要回归到如何与“需求方”沟通，确定该需求的优先级。唯一不同的是，这里的需求方是绝对的内部干系人——团队，而不是传统意义上的外部相关方罢了。

需求优先级的解决方案

这个标题有点夸大，毕竟不同团队有不同的做法。我只能就过去的一些做法，给出我们当时的解决方案。

PS：这里我们假设需求是包含了功能性需求和非功能性需求。

在我们的过去经验中，我们有两种做法来应对，下面分别来说一下。

01|方案一

这点是很多敏捷前辈、大牛推荐的。简而言之就是——将技术性需求放入需求的验收标准中去。

这种做法本质是将需求合并，将非功能性需求整合到功能性需求中去，从而解决了为非功能性需求排序的想法。一言蔽之——我不去解决问题，我直接将有问题的部分干掉。

这种做法优势和劣势：

优势：

足够简单且易于操作，对PO来说是最直接的处理方法。这种做法将PO的行业优势发挥到极致，同时又将纯技术的工作完全抛给了研发团队解决。从根本上做到了专人专事。

劣势：

这种做法劣势和优势一样明显。如果验收测试非常复杂，复杂到无法在一个迭代中处理完成且功能需求与非功能性需求强依赖（比如DSL或者研发框架这种级别），你就会发现这些功能性需求是无法在当前迭代有任何“功能可见”的进步，且这种状态可能存在较长时间，直到非功能性需求解决。

02|方案二

这种做法在一些前辈的书中也偶有提及，即将非功能性需求直接当作与用户故事同样类的事物存在，比如技术故事，或者简单的使用“组件”这种方式。

该方式的本质在于正面回答了“系统是否只有用户故事”，承认了用户故事不能100%适用于所有的项目需求（此处不准确，用户故事本质不是需求而是工具，以后有机会说），从而将组件也好、技术故事也好，直接罗列出来。然后由研发人员（即技术需求的相关方）与PO沟通，最终由PO来决定优先级。

这种做法更加容易理解，因为其将需求统一化了，不再区分具体的需求类型。但是该做法区分了需求的相关方，通过与不同的相关方沟通，由PO 统一做决定。

这种做法优势和劣势：

优势：

不在刻意区分需求类型，也不再强迫全部使用用户故事，降低了用户故事编写难度，也在一定程度上反向推进了研发与PO的沟通，否则优先级完全无法排出来，导致工作无法开展。

劣势１：

对研发和PO的要求都大幅提升，要求研发可以用通俗的语言给PO讲清楚其重要性，帮助PO能建立正确的价值判断；

同时也对PO 的技术能力提出了一些要求，毕竟不是每个需求都可以不用技术语言就能说明白。

劣势2：

如果过分包容技术故事或者组件的存在，且不能很好的控制其大小，会在这个层级上的需求之间产生极强的依赖，最终让整体研发过程更像瀑布（至少是组件研发期间）。

这里请注意：

瀑布没有问题，这条劣势中的关键词是“极强的依赖”。

这些依赖会使得团队在开发这些需求时有过多的限制，这将会极大影响任务推进，包括但不限于进度、代码开发、继承、发布等工作。

Tips：PO 可以通过一些问题与研发沟通，从而获得技术故事、组件的优先级：

1. 为什么需要这个功能？

2. 如果推迟一段时间，是否会影响功能的开发？如果有影响，影响是什么？3. 我们需要付出怎样的成本？

4. 如果不做会怎么样？

5. 有没有其他替代方案？比如采购现成方案或者开源组件？

6. 其他任何你觉得有用的问题

03|多说一句

没有绝对的证据证明两种方法的优劣，根据需要使用是最好的，因地制宜需要每一位敏捷从业者牢记心中，是否需要混合，是否需要偏重某种方法，是否有其他解法？我都无法直接给出回答，这些回答都需要你在自己的敏捷实践中去摸索，找到最适合的方法。

最后说一句

我一直认为敏捷的成功，一定是需求管理的成功，而需求管理的第一步必然是确定优先级，否则这就与敏捷所说的“价值交付”南辕北辙了，花费大量的时间、精力，最终交付出来的却不是用户最需要的。

所以，No 优先级 No 敏捷~