你以为的需求管理，其实是一场权力的重新分配
原文链接：https://mp.weixin.qq.com/s/K4bHsZmL0ohyU-VEGLLixg
先说一个可能让你不太舒服的判断：
大多数公司的需求管理失败，从来不是能力问题，而是权责问题。
他们缺的不是一个更好的模板，一个更聪明的分析师，而是一个敢不敢把"谁说了算"这件事写下来的勇气。
一家公司上线了需求管理系统，流程图画得漂漂亮亮，五个阶段清晰规范。然后呢？销售的需求照样插队，研发照样返工，项目经理照样在群里被三方同时骂。系统很热闹，但什么也没解决。
原因很简单——流程图只能规范动作，规范不了利益。
真正有效的需求管理，是华为花了三十年、用真金白银换来的那套东西。它的核心不是方法论，而是一场把"需求的话语权"从研发手里抢回来、还给市场的权力手术。
这篇文章不讲虚的，我们把华为的做法拆开来看，你会发现它每一步都在解决一个非常具体、非常痛的问题。
一、先看清一个残酷的事实：大部分需求是假的
华为内部有一句流传很广的话：“客户需求有80%是假的。”
听着刺耳，但它是一句技术性描述——这里的"假"，不是指客户在骗人，而是指客户说的那个需求，未必是他真正的需求。
PPT里那个案例我印象很深，因为它把这件事讲透了。
客户说：“话机听筒的电缆应该有10米长。”
研发接单，认认真真去做了一根10米长的线缆。做完发现，客户真正要的是"可以拿着电话在房间的任何地方通话"——他想要的不是10米，是自由。
如果研发接到的不是"10米"这个方案化、指标化的伪需求，而是"任何地方都能通话"这个客户问题，那么解法可能是无线耳机、可能是免提、可能是云通话，甚至可能什么都不用做——因为客户家里没信号墙。
一字之差，天差地别。
这就是需求管理的第一道闸门：把所有需求还原成"客户问题"，而不是"客户方案"。
华为的做法很具体——用"$APPEALS模型"（价格Performance之外的八维评估体系）和KANO模型去拆解需求。一条原始需求进来，先问八个问题：这是什么场景下的痛点？是必须有的、期望有的，还是惊喜型的？
它甚至规定了决策的十字路口：重要且紧急 vs 重要不紧急。
前者是救火，后者才是真正创造价值的地方。一家公司如果所有的资源都扑在"重要且紧急"上，它就永远在原地打转——因为重要不紧急的事，才是你拉开差距的地方。
二、绝大多数人搞反了顺序：先分析需求，再开发产品
华为IPD框架里有个被反复强调的区分：做正确的事，正确地做事。
前半句是需求管理，后半句是产品开发。很多人一辈子在练后半句的功夫，却从没认真练过前半句。
而华为的整套流程，是把"做正确的事"牢牢卡在了"正确地做事"的前面。
它把需求分成了五层，一层层往下穿透：
原始需求（RR）——客户嘴里那句大白话。“手机充电太慢。”
初始需求（IR）——经过专业翻译的标准化表达。“30分钟充至80%。”
系统特性（SF）——产品的核心卖点，端到端的解决方案。
系统需求（SR）——可测试、可验证的技术规格。
分配需求（AR）——拆解到硬件、软件、结构各个模块的具体执行需求。
注意这个收缩过程。华为的做法是逐层收敛，每往下走一层，就把"想象"替换成"事实"。
最狠的一条规矩写在PPT里：不可测试、不可验证的需求，直接砍掉。
这句话翻译过来就是：你不许用"体验更好"“更智能"“更高级"这种词来糊弄研发。凡是不能被验证的，它就不配进产品。
这是华为研发体系里最反人性、也最值钱的一条。
因为需求失控的根源，本质是"模糊”。而消灭模糊的唯一方法，就是逼着所有人把话说得能被验证。
三、华为的解法：把需求变成一条"端到端可追溯"的链
华为内部有一句描述需求管理IT系统的话，我认为是整份资料里最值钱的一句：
“在客户界面上，需求要完整的端到端的管理。需求从客户进来后，一定要给客户一个承诺或答复，不允许出现客户的需求被淹没掉的现象。”
被淹没。这三个字，才是绝大多数公司真正的死穴。
你可能有过这种经历：某个客户提了个需求，你转给研发，研发说"没排期”，你转头忘了，客户也没再来问，于是这个需求就消失在了某个Excel的某个角落。
不是被拒绝了，是被遗忘了。
华为的做法是把需求做成了五层穿透的链：每一条需求都有编号、有来源、有责任人、有承诺时间、有交付状态。销售想知道自己的需求进展，查系统，而不是去堵研发的门。
这一句话背后是两个世界观的切换：
在"口头需求直达研发"的世界里，需求是一种人情。谁声音大谁有理，谁和研发关系好谁先上。规则是隐形的，公平是稀缺的，效率靠个人关系维系。
在"需求管理电子流"的世界里，需求是一种资产。它有编号、有状态、有承诺人。规则是显形的，公平是可查的，效率靠系统维系。
华为1999年从IBM引进IPD，最难啃的骨头从来不是流程图画得多漂亮，而是**把需求从"人情"变成"资产"**这件事，要动多少既得利益。
组织架构图上，需求管理团队（RMT）、需求分析团队（RAT）横跨市场、研发、服务、制造、财务——这些人平时在各自的部门里，是借调到一个虚拟团队里做决策的。PPT里写得明明白白：产品管理部"既不属于研发体系，也不属于销售体系，他不看两边领导的脸色，独立、客观地对产品竞争力负责"。
一个不看两边脸色的人，才能做出让两边都难受的决策。
四、需求分发的本质：不是分派任务，是分配时间
大部分人把需求分发理解成"把活派给谁"。这只是表面。
华为的分类逻辑，本质上是在分配产品的时间轴：
中长期需求（3-5年） → 进入市场管理流程，做战略规划和技术预研
中期需求（1-3年） → 进入业务计划和产品路标
短期需求（1年内） → 进入项目任务书，走产品开发流程
紧急需求 → 走变更流程（PCR），插进正在开发的项目
四条不同的路，对应四个完全不同的决策层级。跨产品线的需求上IRB，产品线内的上IPMT，单产品线的上PL-RMT，产品经理就能定的小需求由产品经理和产品线总监拍板。
PPT里有一句话特别值得抄下来：“长期议而不决的需求，走快速通道。”
这是华为自己承认的妥协，但它恰恰暴露了制度设计的真谛——任何一套流程都会有堵点，成熟的体系不是没有堵点，而是给堵点开了逃生舱。
僵化的流程会把企业憋死，混乱的流程会把企业拖死。
还有一个数字，所有做产品的人都该记住：
紧急需求占比越高，说明企业的需求规划能力越差。
因为如果你规划得好、储备得足，就不需要靠"插队"来救火。一家公司的紧急需求占比，是它管理成熟度最诚实的体检报告。
五、变更管理：把"改需求"的代价，变成看得见的数字
这是我觉得华为整套体系里最高明的一环。
先看它对变更的分类，一共有五种：
PCR 项目变更请求：周期、资源、成本、范围变更
DCR 设计变更请求：设计方案变更、设计优化
RCR 需求变更请求：客户需求变更、设计需求变更
ECR 工程变更请求：对生产等下游环节的变更
PCN 产品变更通知
为什么要分这么细？因为不同性质的变更，影响的人和审批的层级完全不同。所有变更都走同一个流程，等于所有变更都不需要分类。
然后是变更处理的五步：申请 → 评估 → 审批 → 实施 → 验证。
看起来平淡无奇，但它厉害在一个地方：评估环节必须算清楚对周期、成本、质量的影响。
华为有一句话，我认为是需求管理领域最值钱的一句：
“变更不是不允许，而是要让变更的代价显性化——当’插队一个需求要推迟三周’被写在变更单上时，多数冲动的需求会自己消失。”
这句话厉害在哪？
它不靠道德，不靠觉悟，不靠领导拍桌子骂人。它靠把代价算清楚。
人在不知道代价的时候，是冲动的。销售不知道插队会推迟三周，所以他理直气壮。研发知道要重测三轮，所以他敢怒不敢言。
当三周被白纸黑字写在变更单上，会发生什么？大部分需求自己就消失了。
不是被砍掉的，是提出者自己算完账，默默撤回了。
这才是好的机制设计——不是让人不能犯错，而是让人在知道代价之后自己选择不犯错。
PPT里那句"必须确保他们有关于该产品需求的完整清单"“必须持续地依据需求管理电子流更新此清单”，听起来像废话。但它对应的是需求管理最现实的问题：三个月前的需求，现在还在吗？还能对上号吗？
需求一旦和版本、和工作单失去关联，就等于不存在。你连它被实现了没有都不知道，还谈什么管理。
六、如果你的公司没有RMT和RAT，先做这三件事
华为的体系看起来很重，但拆开来看，真正不能省的核心动作只有三个。
第一，把需求还原成问题，而不是方案。
在需求采集卡上强制加一个字段：“客户想解决什么问题？” 只写方案的需求，一律打回。这一条不花一分钱，但能挡掉一半的无效开发。
第二，给每一条需求一个编号、一个状态、一个责任人。
不需要买系统，一张表都行。关键是需求进来之后不能消失。这是需求管理的及格线，也是大多数公司不及格的地方。
第三，把变更代价写进变更单。
任何需求要插队，必须填三个数字：推迟多久、增加多少成本、影响多少范围。 就这一条，能挡掉公司里一半的临时插队。
这三个动作不需要IPD，不需要RAT，不需要跨部门团队。但它们背后指向的，是华为那套体系最核心的价值观——需求管理不是流程，是把决策权还给离客户最近的人。
最后
回到开头那个判断。
需求管理失败的公司，问题从来不在于"需求管理做得不够好"，而在于"组织不愿意承认谁有权说需求是错的"。
一个不敢说"这个需求不该做"的组织，就不可能有真正的需求管理。它只有需求接收。
华为用三十年证明了一件事：产品的竞争力，来自对客户需求的深刻理解；而对客户需求的深刻理解，来自于一个愿意承认自己会犯错、愿意为错误付出代价、愿意把代价写下来的组织。
所以，下次再有人跑过来插需求的时候，别急着答应，也别急着拒绝。
先拿出那张表，问他三个数字。
推迟多久？增加多少成本？影响多少范围？
这才是需求管理的开始。
欢迎关注！转发分享后，私信留言可以获得： 华为IPD如何做需求管理 PPT资料