研发业务互怼，似乎是大家都见怪不怪的一个问题。说到这其中核心争端之一的需求交付，各种方法论、各种框架，似乎都有一套看起来大同小异的解决方案。但这些方案，却经常会在实际落地时遇到推不下去，最终落为清谈的结果。
在过去多年，分析了几十家国内大中型企业需求交付现状后，我们对这一问题有了更深入的体悟，并总结出了一套帮助团队进行端到端需求管理的Adapt需求漏斗模型。这套模型理解起来非常简单，拿来即用，通过本文，对对该模型进行全面解读。
1
老板的困惑
研发团队天天很忙，产品经理也天天很忙，最后才勉强交付。业务产品在想研发团队到底在忙啥？人员投入这么多，一个10人天的需求为何迟迟排不上期，排上期又经常不能按期交付。是招的人太差，还是管理不行？
研发效能开始各种度量，有时看上去有作用，对研发交付有点感觉，有时看上去只是数据体现的更好了，业务产品怎么感觉不到变化。面对动态的需求、动态的团队，永远说不清道不明问题到底在哪里，如何有效进行改善。
问研发，通常得到的答复是产品经理给不出需求; 问业务，通常是说研发交付太慢、质量差，不能理解需求，多次澄清，一点小的调整就要走需求变更，PK永不停歇。
这可能是一个普遍现实
上述这种困惑的真实情况可能不难推测，既有研发的思维模式问题，也有业务伪需求积压的问题。这就是我们在做需求管理辅导时的普遍情况。
我们暂时搁置研发思维的话题，聚焦需求积压问题来聊一聊。
灵魂拷问一下产品经理，你的需求积压在哪里？你的产品在哪里？积压在 Excel 里，积压在邮件里，或曾经和你见面说过一次。
2
研发业务互怼的案例分析
需求漏斗是根据团队需求吞吐量、各状态需求个数等真实数据，生成的用于反映团队需求管理状况的漏斗工具。
Adapt需求漏斗模型，关注本公众号回复“漏斗”获取高清图
我们将Adapt需求漏斗模型图放出（上图），为便于大家理解，并先带入研发、产品不同视角下主观感受到的需求管理状况，再来看与该团队真实数据生成的漏斗有多大差别。最后，在本文的第3-4节，我们会全面解读该漏斗。
图 / 某金融组织某科技部落需求数据
上图是某金融组织某科技部落的需求数据，如果不看这些真实数据，研发和产品分别是如何看待团队需求管理状况的？
研发会说，我们都是在猜需求的，文档都没有就要开干，总是返工，产品经理的活我都干了。
产品经理会说，去年提的需求还没有实现，改个字就要起需求变更，一点都不快，不敏捷。
我们根据该部落需求数据生成需求漏斗，来看一下该部落需求管理的真实情况：
图 / 依据该部落需求数据，生成的需求漏斗图形
从该部落的漏斗来看，该部落首先存在需求规划不足（意向过少）、产品经理编写评审不及时（编写评审中少）、基本没有待排期的需求等问题。
这些问题带来的后果，就是常见的研发说需求质量差，变更多。在此种情况下，依然有需求提出方在正式会议上提出研发支撑不足。
同时，根据我的现场观察，研发团队产能尚有较大的提升空间。这是一个经过2个月跟踪的部落数据情况，产品经理已经用尽洪荒之力把能想到的需求都线上化后的结果。
这并不是孤例
从我们辅导的多家公司、不同团队来看，中间两层断层是十分普遍的现象。而意向提出，也会因为仅是规划而不能够有效线上化并存。最后到了研发临时紧急需求，而本质上这些需求在业务领导或用户早已提出。类似E小队的产品经理，一直在规划，等出个大招，却没有想过，研发又如何接得住需求。
3
Adapt需求漏斗可以解决哪些问题
从上一节该部落的案例可以看出，需求管理的真实情况，与研发、产品的主观想法，都有着巨大的差别。而这也是Adapt需求漏斗模型要首先解决的问题：
Adapt需求漏斗模型，首先要解决的，就是转变凭主观「我觉得」来评判需求做的好不好的情况，为团队提供一个真实的数据参考。
除此之外，Adapt需求漏斗模型，还能解决这5个问题：
问题1：需求状态多，看不清问题点
通过漏斗模型，需求体现在不同价值流归类中更高层级的视角，体现产品经理创新能力（需求意向数）、产品经理内部梳理需求详情（编写评审中需求数）、通过研发初步评估需求情况（待排期需求数）、研发团队需求吞吐量（本月研发测试需求数）、需求吞吐量波动情况（上月需求吞量）。通过状态归类，是否有阻塞、流动是否健康一收眼底。
问题2：研发前置难以推行
漏斗体现了需求加工的全过程，可以推进产品经理规划，让研发前置变得有效可行。
从产品经理内部梳理需求，然后与研发沟通澄清，再到研发上线。需求打磨是否充分、可研发需求量是否充足——研发前置规划离不开需求的前置规划，编写评审中的需求是一个显而易见的信号。
问题3：产能分配混乱
根据待排期及之前的需求规划，Adapt需求漏斗为产能分配提供了数据参考。
让团队从靠嗓子喊，谁声音大就支持谁的混乱状况，转向数据支撑的产能预分配。让研发资源真正用在刀刃上。
问题4：哪个事都很急，应急能力却很差
帮助团队聚焦目标，让团队告别「哪个事都很急、总是迫在眉睫」的窘况，真正提升研发应急能力。
让能规划的需求得到有效规划，需要紧急响应的事才可得到快速响应。保持研发的稳（质量好）与快（响应变化）。
问题5：产品经理又忙又乱
让前置需求规划得到充分澄清，研发过程中减少低效沟通，减少无效的需求变更，验收一次通过，研发质量与产能提升并存。释放出产品经理的产能，投入更多时间规划与编写需求。形成一个良性循环。
回顾上一节案例部落的需求漏斗，该部落应从何处改进？
下一步，该部落需要把强化透明，最好的方法是把它作为固化在工具中，作为共同关注的数据。从主观判断，转向需求断流风险的度量，从简单的需求排期逻辑转向研发和产品经理产能转向重点产品需求方式。
4
Adapt需求漏斗模型详解
看完了案例，我们来对Adapt需求漏斗模型进行初步介绍：
Adapt需求漏斗是将需求分为几个阶段，每个阶段对应不同的需求状态，并对其进行计数，结合团队需求月度吞吐量T值，最终观察团队需求管理情况的模型。
Adapt需求漏斗模型，关注本公众号回复“漏斗”获取高清图
Adapt漏斗模型有6个主要的参数：
T值
代表部落近半年每月上线需求数的平均值。可以根据实际情况调整取近一年或近3个月作为基准值。
意向需求数
部落所有主办需求中，需求状态是只有简单的需求描述的刚提出阶段。此处为需求漏斗的第一层，建议范围是1T-6T。
基于产品管理的角度来说，对产品的需求规划有1-6个月是相对合理的。假设某部落的T值为50个，则意向需求数应在50-300之间。若数量低于50则说明创新与规划不足，有可能造成漏斗第二层的断流。高于300则需对意向需求进行清理，因为为适应快速变化的市场，需求作为产品的最小交付单元，若规划过于久远的需求，不确定性更高，投入资源可能造成事倍功半的效果。
编写评审中需求数
部落所有主办需求中，需求状态属于优选/编写中/评审中的需求数。此阶段为需求漏斗的第二层，建议范围是0.8T-1.2T。
主要与科技交付节奏相吻合，若产品经理与部落是按月进行排期，则提前准备好部落一个月能交付的需求量便可。将资源聚焦在这些需求的细化上，既能防止研发需求断流，又能有效的提升排期需求质量，为后续部落的快速交付打下基础。
待排期需求数
部落所有主办需求中，需求状态在待排期状态的需求总数。当前阶段为需求漏斗第三层，达到待排期的需求状态一般要求需求成熟度为钻石需求。
部落按月度进行需求排期，待排期需求数为0.5T-1.5T。若需求成熟度已达标，确在此阶段常常超过1.5T，要考虑是否科技资源不足，按需补充资源。过低则可能造成研发断流或是排期需求质量差，交付时间长等。
本月研发测试需求数
部落所有主办需求中，已排期需求/研发中需求/测试与验收中需求总数。此阶段为需求漏斗第四层，指部落已排期的受理中需求数，建议在0.8T-1.5T之间。
若过低则可能资源利用不足，过高则会引起在制品过高。在制品过高容易造成协同排期困难，加大阻塞可能性，需求流动缓慢，资源浪费等。
上月需求吞吐量
部落所有主办需求中，上个月上线需求计数，反映部落上月需求产出，计算部落需求交付月度偏差率。
5
总结：需求漏斗带给需求管理哪些启示
1. 做好需求透明，对齐需求价值流是关键
图 / Adapt 框架推荐的需求价值流
从一句话需求开始，线上化管理，完整记录需求流转过程，做到透明，上下对齐，同一份清单。
2. 树立正确的观念，需求做不完才是正常的
为了改进上述现象中的问题，做好需求管理。我们总结四项要点：透明-规划-节奏-聚焦，设计出需求漏斗管理机制。
3. 漏斗看趋势，推动做好前置规划很重要
4. 度量调优，从主观判断需求多少转向度量需求断流风险
5. 从简单的需求排期逻辑转向研发和产品经理产能转向重点产品需求方式
6. 工具固化，支撑管理落地
最后，补充导入Adapt需求漏斗时的注意点：
如果是批量排期、迭代上线模式，在不同时间点统计的本月研发需求数可能差异较大。在这种情况下，可以使用最近30天完成的需求纳入本月研发需求数计算。
如果统计时点刚好月初，可能迭代才刚刚开始，当月需求可能存在差异是正常现象，需要稳定的产能模式，使用最近30天即可。
对Adapt需求漏斗模型有任何疑问，可在后台留言与我们沟通。扫关注本公众号并回复“漏斗”，即可获取Adapt需求漏斗高清模型图。????????
推荐阅读
874
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
