需求管理是产品工作中非常重要的一个环节。但很多人不知道怎么管理，或者就是凭借一些零散的方法论进行处理。这篇文章，作者以华为的IPD需求管理为例，通过Why、What、How三个角度和数个案例，教大家如何进行需求管理，希望有所帮助。

一、WHY：为何要引用IPD来搭建需求管理体系

笔者在多年产品工作生涯中，对需求管理有一定的理解和沉淀。也引入了很多任务协同软件，可最终总难以达成预期的管理目标。直到深入研究IPD体系，才豁然开朗。需求管理软件若脱离了卓越的产品管理思维，就如同临摹画作一般，形易而神难。

需求管理体系！简言之、就是需求的全生命周期管理，从需求的洞察、规划、设计、开发、测试、运营。

而为何我说现在的需求管理软件脱离了卓越的产品管理思维呢？

我观察主要突出有如下几个问题：

1、问题1：只有工具思维、没有管理思维

不少引入任务协同软件的团队，会粗暴的认为只要引入了软件，就完成了需求管理。殊不知软件只是一个没有生命的工具，就比如一把刀、若落入正义之人手，则是守土安民的利器；若落入奸邪之人手，则是祸国殃民的帮凶。管理思维才可以给予工具以生命，需求管理体系需要自己去总结、比如产品成功管理、质量标准管理、需求方案管理、流程时效管理、人天投入管理、关键KCP管理、组织能力管理等等。

这些管理思维更需要团队想清楚弄明白，并为了将团队从“一次成功走向一直成功”，再将这些管理思维固化在流程上，而流程的承载载体就是软件工具。

2、问题2：只有当下的流程交付思维、没有长期的组织能力思维

还有不少团队会将软件协同工具在组织内走通流程之后，就万事大吉了。然后流程可能几年都不会有重新审视和价值评估。其实这个方法也不对的、当下的流程交付只是代表那一刻的管理思维已达到最优、可长期来看，业务和市场在变化、对组织的能力要求也在变化、组织能力需要新增更多的关键KCP、组织能力需要新增更多的质量标准。

所以、组织能力不仅仅是当下的管理行为、更应该是长期的管理策略。

王之涣《登鹳雀楼》：“白日依山尽，黄河入海流。欲穷千里目，更上一层楼”。

我们要做好需求管理、若思维停留在“任务协同、工具软件”的楼层、必然打不成管理预期，我们应该要在更上一层楼，思维要拔高到“流程标准、组织能力”层面。

那么就需要引入IPD管理思想，将行业最佳实践的集成产品开发管理模型嵌入到需求管理场景中，最终打造出真正具备价值的“需求管理平台”。

二、WHAT：什么是IPD

2.1 IPD集成产品开发概念

IPD（Integrated Product Development，集成产品开发）体系是业界最佳的产品创新与研发管理体系，它将产品开发视为一项投资行为，通过业务战略的制订，洞察市场机会，确定产品和项目的价值最大化风险最小化的投资组合；通过基于应用场景的客户需求挖掘，定义产品的价值主张和功能卖点；通过高质量的Charter开发（新产品立项分析），确保产品开发团队是在做正确的事；通过产品和技术异步并行开发，跨部门的重量级业务团队，以及结构化的研发流程，确保产品开发团队正确地做事；通过技术货架和产品平台的共享，构建核心技术竞争力并让产品开发过程像搭积木一样快捷；通过增量绩效管理及“以奋斗者为本”的研发人力资源管理，夯实产品持续成功的研发基础

2.2 IPD流程框架

2.3 IPD管理体系价值

1、提升产品市场成功率：

加强市场研究和需求分析，做好业务策略及决策、产品规划和定义，加快开发进度，保障开发质量，控制开发成本，强化产品上市，从而大大提升新产品开发的成功率和商业化成效，大大降低产品研发的浪费

2、提升产品质量竞争力：

通过能力复用降低开发成本、通过关键KCP加强产品质量保证和构建质量控制体系，过程质量保障结果质量、在过程中增加质量保证活动、来确保每一个交付件达成质量要求从而提升产品质量竞争力。

3、提升技术和平台开发力：

强调技术开发与产品开发有效分离，在平台/技术规划的牵引下，加大技术开发和积累的力度，不断提升技术实力，同时建立强大的产品平台，发挥平台的杠杆作用，实现公用技术模块（CBB）重用率的不断提升

4、提升产品的成功必然性：

通过明确的阶段划分和决策评审点，有相应的流程、工具和方法，把能力建在组织上，构建从营销到产品开发的整个管理流程体系，确保把一个产品的成功能复制到其它产品

三、HOW：提升产品市场成功率和成功必然性（从一次成功走向一直成功）

需求管理也分为几个阶段，分别为“要不要做、怎么来做、做得如何”。这也对应价值管理的三个维度“价值创造、价值实现、价值经营”。需求管理首先要解决的就是“要不要做”。我们来看一下，当下的需求管理普遍存在的痛点情况。

首先、需求价值评估的标准不定，以领导的意志为转移、以产品的感性喜好为依规、以独立节点的局部最优为考量、以需求的先进先出为排序规则。整个需求评估都是感性的、没有方法论的、根本无法量化市场成功概率。

其次、市场讯息万变、组织尔虞我诈。需求代表的其实就是“野心”，产品人作为需求的解析者、评估者和经营者，需要对这些“野心”进行剖析、排序、经营，可产品人的个体力量是薄弱的、凭一己之力去抗衡整个漂浮多变的需求暴风骤雨。犹如一叶扁舟驶入魔鬼三角洲。

所以，需求管理要保障市场成功率、同时要保障成功必然性。就需要给单个产品人员配备一柄利剑、斩断这剪不断理还乱的思絮。

3.1 实践案例一：KCP评分卡

如下笔者负责的需求管理体系，在整个需求评审环节，搭建了需求价值评估KCP的评分卡片、通过该评分卡体系化的管理产品市场成功率、定义了需求价值评估标准、需求的可行性和优先级不再以个体的意志为转移。同时该体系以组织发文的形式下达到需求管理流程、从而保障了管理体系的公信力。

并且、该评分卡也辅助提供了很多实践案例、这些实践案例可快速的帮助产品人员提升能力，各个需求均必须填充该KCP评分卡，且在“8个KCP”中进行评审，若评审不通过的则会驳回重写。

3.2 实践案例二：8大KCP

以笔者经手的一款财经系统，该产品逻辑复杂，横跨费用、应收、应付、资金、总账、影像、数据等多个产品模块；同时作为财经系统而言，专业性又特别强。往往一个需求牵一发而动全身。更为关键的是该产品覆盖集团95%以上的产业，而集团又是一家多元化经营的企业，各产业需求的差异性极强，有时候需求还会出现相互矛盾之处。

为了将KCP可持续的在组织中运作，笔者团队还搭建了一套需求质量管理系统。将KCP嵌入到流程之中。

下图为8大KCP的管控要点：

下图为8大KCP的流程图：

3.3 实践案例三：KCP嵌入到系统流程中

四、HOW：搭建技术开发平台、提升产品质量竞争力（能力落在组织上）

产品质量竞争力的指标是“效率、稳定、成本”。通俗而言、即用最少的钱造出更多的好产品（多快好省！！效率=多/快、稳定=好、成本=多/省），这必然立于商业不败之地。可实际情况是团队开发耗时不透明、耗时合理性无法评估；产品质量输出不稳定、质量标准无法有效执行；企业重复造轮子的事情时有发生、技术中台稳定性不足。

产品质量竞争力的工作主题就是三个“质量标准落实在流程上（KCP）、公用技术模块（CBB）、最小化经营单位（阿米巴）”（如下图所示）。通过这三个主题承载产品竞争力指标，最终实现多快好省的可持续的提升产品质量竞争力。

4.1 质量标准落实在流程上（KCP）

所有的管理动作若需要通过会议、邮件、培训来监督，则该管理目标一定难以持续。管理要有效、一定要摆脱人的因素干扰。人有惰性、人有私心、人有失误。通过“人来管人”或“人来自管”都是不可持续的。

所以、管理动作要做成漏斗模式、流程要经过必须经过这个漏斗筛查一遍，一些大颗粒的不良问题通过漏斗这个质量标准做了排查。换言之、质量标准要落实在流程上，并嵌入到关键评审点上（KCP），通过KCP起到漏斗的过滤效果。

4.2 公用技术模块（CBB）

军事理论：存地失人、人地皆失；存人失地、人地皆存。

军事中何为组织竞争力？是一座城池、还是一支军队。上面的理论再明白不过~~城池诚然可以获得补给、可并不能根本性的奠定军事格局的战略主动权。只有“消灭更多的敌方有生力量、扩大更多的自我军队力量”才是真正的战略主动权，而且占据更多的城池，则意味着要分兵把守，无形中也削弱了军队的灵活机动性。

同理，开发团队的组织竞争力，也不是不知疲倦的攻克一个个项目、更是拥有更多的“自我开发力量”。除了一些高精尖的产品强依赖某一位科学家式的英雄，其实大部分的IT产品都依赖团队的快速交付。而其中若团队拥有更多的组件框架、拥有更多的公共技术模块，则可大幅度的提升开发团队组织竞争力，从而真正的实现能力落在组织上。

公用技术模块封装了很多技术框架，一个初出茅庐的开发工程师调用这些框架即可快速交付产品。同时这些公用技术模块还可以让系统耦合性更低、让系统稳定性更强、同时也可提升团队的凝聚力。

4.3 最小化经营单位（阿米巴）

《稻盛和夫 | 阿米巴经营》：阿米巴经营就是通过小集体的独立核算，实现全体参与经营，凝聚全体员工力量的经营管理系统。首先就是要有能使全体员工毫无疑义地全力埋头工作的经营理念和经营哲学

曾记起《韩非子·内储说上》中有一个“滥竽充数”的寓言故事。齐宣王的吹竽团队就如同一条需求的各个参与者、有用研、产品、设计、交互、开发、测试、运营。南郭处士可能就隐藏其中。若需求不量化各个节点的耗时，那就如同300人同时吹竽，分不清优劣、看不清谁在裸泳。

组织效率肯定不是一锅粥和稀泥，得分清楚子丑寅卯、需理得出鱼目混珠。所以就需要在组织中做“最小化经营单位（阿米巴）”。将需求的各个参与者单独拎出来量化人天。这和阿米巴经营一样、小集体的独立核算，从而实现全员参与经营的目标

4.4 实践案例一：需求管理流程的阿米巴

下表是整个需求质量管理流，在整个管理流中共细分为12个节点、每个节点对应着不同的团队角色。当然很多节点在一些企业内并不是必须，笔者分这么细目标在于量化人天，也是根据本身的产品特点而定。

五、总结

无论是购买还是自建IT软件，首先要解决的不是软件工具选型问题，而是管理思维再造问题。换言之、软件供应商销售的也并非冷冰冰的软件工具，而是顾问式的管理最佳实践。