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

见贤思齐

点击关注“有赞coder”获取更多技术干货哦～作者：老雷团队：效能改进导语当一个组织处在几人或是几十人的规模时，会共同维护一份产品待办列表，许多冲突和矛盾都会暴露得快而明显。而当组织扩张到上百人时，就会随着业务单元规模形成N份产品待办列表，我们便会意识到，有些问题因为过于普遍而被忽略，或是由于被更小的组织单元消化，或是在全局视角看起来不具备共性和短期影响力。但我们时常会在这些暂时被隐藏的问题或风险上栽大跟头。本文作者将为你介绍的是，如何形成并统筹管理大规模产品待办列表，从而降低协作沟通成本，提升资源利用率。那个令人头秃的夜到了月底，所有产品技术都在如火如荼地进行着做月度规划，安排下个月计划做什么需求。唯独产品经理小王迟迟动不了手，因为每个业务都有需求依赖他所代表的业务技术的支持，面对所有需求方都说自己的需求紧急重要，他不知如何是好。这样的情况，每个月都会遇到，通常他会去依照他的想法排优先级，排不上的再做一轮又一轮沟通。而这一次，他叫上我（作者）、某产品线TL (Team Leader）以及所有需求方产品经理，决定现场直接 battle ，现场各自阐述价值，一一排序，一决生死，整个过程紧张且刺激。那天晚上我们有了结论，但是整个过程总共花了整整4个小时，看着四下散去的产品经理和小王满意的笑容，我拭去脑门淌了一晚上的汗。症结在哪从那天起，我们就从未停止地思考如何降低同类场景的沟通成本，最后挖掘出问题可能的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需求究竟高优在哪里，是否有明确的价值标签可分类，有指标可度量他们的价值，未来我们不光光是拿优先级说话，更是拿价值说话？我望着小王期待的眼神，摸了摸自己的发际线，又是一个头秃的夜……拓展阅读透过 OKR 进行项目过程管理为什么选择使用 OKR 进行项目过程管理效能改进之项目例会导入实践组织级敏捷转型的四个阶段如何在项目管理中进行「系统思考」之一如何提升「会议效率」效能改进的「六项修炼」有赞的效能改进实践（序）大规模产品技术团队需求管理实践客户反馈需求管理实践6个方法打造项目管理氛围效能改进中的度量实践端到端需求全生命周期管理3招把战略项目落到实处—Scrum三支柱在战略项目管理中的应用Vol.260如果读者对效能改进也有兴趣，欢迎加入有赞效能改进团队，请将简历投递至：leilishan@youzan.com，我们共同探讨和实践。