大规模产品待办列表处理策略—需求分级

导语

当一个组织处在几人或是几十人的规模时，会共同维护一份产品待办列表，许多冲突和矛盾都会暴露得快而明显。而当组织扩张到上百人时，就会随着业务单元规模形成 N 份产品待办列表，我们便会意识到，有些问题因为过于普遍而被忽略，或是由于被更小的组织单元消化，或是在全局视角看起来不具备共性和短期影响力。但我们时常会在这些暂时被隐藏的问题或风险上栽大跟头。本文作者将为你介绍的是，如何形成并统筹管理大规模产品待办列表，从而降低协作沟通成本，提升资源利用率。

那个令人头秃的夜

到了月底，所有产品技术都在如火如荼地进行着做月度规划，安排下个月计划做什么需求。唯独产品经理小王迟迟动不了手，因为每个业务都有需求依赖他所代表的业务技术的支持，面对所有需求方都说自己的需求紧急重要，他不知如何是好。这样的情况，每个月都会遇到，通常他会去依照他的想法排优先级，排不上的再做一轮又一轮沟通。而这一次，他叫上我（作者）、某产品线 TL (Team Leader）以及所有需求方产品经理，决定现场直接 battle ，现场各自阐述价值，一一排序，一决生死，整个过程紧张且刺激。那天晚上我们有了结论，但是整个过程总共花了整整 4 个小时，看着四下散去的产品经理和小王满意的笑容，我拭去脑门淌了一晚上的汗。

症结在哪

从那天起，我们就从未停止地思考如何降低同类场景的沟通成本，最后挖掘出问题可能的 3 大症结点：

1. 排期方式：排期过程中如何才能让大家站在同一频道说话，所谓重要紧急的程度和维度如何体现？

2. 资源分配：当被多方需求依赖时，资源限定的情况下，到底投入哪些“真正重要紧急的事情”性价比更高？

3. 优先级决策：小王作为单个业务的需求承接方，无法决策优先级，那么谁可以？

解决策略

基于以上问题点，我们引入了需求分级管理策略，下面通过策略和做法的介绍，来对问题点一一做解答：

问题 1：排期过程中如何才能让大家站在同一频道说话，所谓重要紧急的程度和维度如何体现？

策略 1：我们统一将需求的属性分为 P0-P4 这 5 大层级，由二级业务线负责人决定 P3 需求列表，再由一级业务线负责人从 P3 需求中筛选出业务线最重要的需求为 P2，最后由公司业务规划委员会从各业务线 P2 需求中筛选出公司层级最重要的需求为 P1。自此，一份跨团队的公司整体的大型待办列表页就产生了，沟通方式从“A 和 B 的需求分别重要紧急在哪里”切换成“先排 P0-P1 需求、其次 P2 到 P4”，排期方式从一个一个排，变成一块一块排，大部分需求无需纠结细节。

问题 2:资源限定的情况下，到底投入哪些“真正重要紧急的事情”性价比更高？

策略 2：根据二八原则，我们 80%的价值往往由上线需求里那 20% 产生，而我们现在却花了不少精力在另外 80%的需求上，最终整体的效果事倍功半。P0-P1 的圈定，便是从筹备阶段便识别出那 20%的可能性，并且设立了“P0-P1”默认优先支持、不可被抽调资源等原则，确保 P0、P1 从过程推进和结果得以高质量的保障，经由所属产品经理验证后，定期与业务规划委员会 review P0/P1 清单的实际价值，从而验证这 20%是否正如期望。

值得一提的是，关于 P0/P1 的圈定，是通过业务线负责人提报汇总后经由业务规划委员会筛选而成，过程中，P0/P1 需求会经历评定、打回、确认价值，这样的信息交换，使得公司层面和业务线对“重要紧急”的认知得到对齐，趋使业务线在源头上做业务规划和资源规划更为精准，避免关于规划对齐的过多沟通成本或是研发资源浪费。

问题 3:小王作为单个业务的需求承接方，无法决策优先级，那么谁可以？

策略 3：我们将公司产品待办列表优先级评定和业务线产品待办列表评定的权利赋予了公司业务规划委员会和业务线负责人。由这群人综合产品所处阶段、战略诉求、业务阶段 OKR 等因素，确认不同层级的需求清单。不同业务线的清单里每个需求的价值各异，但背后隐含的价值“程度”是一致。

需求分级远非如此

• 拒绝吃大锅饭，做到有的放矢。我们在推动研发效能改进的过程中，往往眉毛胡子一把抓，所有需求的周期、延期、吞吐严格要求。殊不知其中有重点需求滥竽充数，也有特殊需求做了老鼠屎，影响整体指标。技术负责人看到效能指标起起伏伏只得摇头叹气，无从下手。但我们其实也可以做到“因材施教”，针对不同梯队的需求，提出程度不一的要求，例如要求 P0 不延期，P1 延期率不超过 10%，P2 延期率不超过 30%，那在过程控制中，技术同学便有了发挥空间，才有可能“两全其美”。抑或是对 P0～P2 的需求要求做到严格的上线效果回顾和运营动作评分，以确保重要的事情都得到了应有的反馈。

• 以小见大，快速识别问题和风险。P0/P1 虽然是少数的集合体，但它们起到了放大镜的作用。为了清除实现最重要的事情上的阻碍，我们会更专注地审视这些高优需求身上出现的问题和风险，例如某一中台业务极为短缺，背后可能是资源问题，也有可能是中台化的进程还太慢；例如 P1 需求上线后的效果数据惨不忍睹，不是需求本身有问题，而是严重缺乏运营动作。这些问题反应在 P1 身上，但往往是共性问题，清除这些阻碍，对全局效能提升起到的也是事半功倍的效果。

因此，我们会发现，需求分级看起来是解决排期问题、解决沟通成本问题，实际上它解决的是大规模团队的规划问题、决策与执行之间的信息鸿沟问题，甚至是能有效提升组织的自主优化能力、风险识别能力、自主驱动价值能力。

小王的烦恼彻底不见了？

需求分级让小王负责的业务线排期变更快了，没排上需求的产品也很少来 battle 了，但是他发现公司里 P1 的数量似乎越来越多，他找来我一起讨论，这些 P1 需求究竟高优在哪里，是否有明确的价值标签可分类，有指标可度量他们的价值，未来我们不光光是拿优先级说话，更是拿价值说话？我望着小王期待的眼神，摸了摸自己的发际线，又是一个头秃的夜……