IPD流程解析：客户需求管理、OR与MM流程及角色分工

简介面向华为IPD流程体系的学习者与产品研发管理者这份课件系统梳理IPD 5.1 DRY RUN培训中的客户需求管理主线适合需要理解需求从收集、分析、实现、验证到分发全链路以及OR流程、市场管理流程、任务书开发、生命周期阶段和客户化流程的读者。压缩包内为1个pptx文件约6.18MB以培训课件形式组织按课程索引串联章节便于快速定位关键概念与流程图。内容围绕产品包需求、需求分析团队、需求变更控制、需求承诺电子流、CCM角色、PDT/PCR等展开并配有端到端需求管理流程框架、需求管理组织体系示意和销售项目需求管理原则可帮助读者建立从需求收集到承诺闭环的整体认知对照实际项目理解RMT、PMT等角色的职责边界。已有4843人学习下载适合作为IPD入门梳理、团队内训和需求管理流程对照参考。1. 到底什么叫 IPD为什么一堆团队都在学这套流程很多团队都经历过这种场面销售在客户那边拍着胸脯承诺“下个版本一定支持”研发这边翻着排期表一脸茫然最后客户在季度末发现功能没上线愤怒地打来电话。问题不在谁不努力而在于“需求”这个东西从客户嘴里出来之后没有一条被管住的路。IPD全称 Integrated Product Development集成产品开发。一句话说清它是一套把市场需求、产品规划、开发、验证、发布、生命周期管理串成一条链的研发管理框架核心要回答四个问题——做什么、为什么做、谁来做、做到什么程度算完成。这份资料是一套完整的 IPD 流程管理培训材料主线讲客户需求管理OR 流程与市场管理MM 流程配套角色分工、需求承诺、变更控制与度量指标。搞懂它你判断一家公司的研发体系是在真跑还是只在会议纪要里跑会清楚很多。2. 需求为什么总在扯皮客户需求管理与 OR 流程的真实作用几乎所有走过弯路的产品团队都有同一个感受最累的不是写代码而是搞清楚到底该写什么。市场说客户要 A销售说客户其实要 A 加 B用服说线上已经有人投诉 C 了研发说这三样排期根本塞不下。需求如果从多个口子各自进来、各自承诺最后一定会翻车——这不是能力问题是结构问题。这一章就拆开 IPD 里最核心的那一段客户需求到底是怎么被接住、分析、分下去、再验证回来的。2.1 客户需求管理为什么它是整个流程的核心先把结论摆出来在 IPD 体系里客户需求管理不是“研发前的一个准备动作”而是整个流程的发动机。原料里有句话讲得直白——“满足客户需求是我们生存的唯一理由”商业模式是以客户需求为导向的。这句话听着像口号落到流程上其实是个很硬的约束如果需求没被管住后面所有环节都是在为错误的目标加班。想象一家餐厅前厅的服务员、外卖平台、老板的朋友、后厨自己出去买菜谁都能直接冲进厨房喊一句“加个菜”。短期看响应很快长期看后厨必然乱套备好的料浪费、出餐顺序全乱、客人等到发火。需求管理做的就是给这家餐厅设一个统一的下单台所有点单先落在纸上再按优先级排进灶台。原料里描述的那个典型场景很写实市场销售人员、用服人员、研发人员、领导、客户五方各说各话。销售已经向客户承诺下个版本支持广播功能领导一句指示压下来研发焦头烂额客户在电话里质问“你们说 3 月提供怎么 6 月还没出来”。这里面每一个环节单看都没错错在缺一个统一入口和一套统一的判断标准。需求实现延迟、理解偏差、紧急需求挤占正常排期本质上都是“没有唯一真相源”造成的。所以客户需求管理要解决的是四件事需求从哪些渠道进来、进来之后按什么规则解释和过滤、哪些进当前版本哪些进路标、承诺出去之后怎么跟踪闭环。它管的是“需求的整个生命周期”而不是某一次需求评审会。提示判断一家公司的需求管理是否真的在运转看一个细节就够了——同一个需求销售、研发、用服三边拿到的描述和优先级是不是一致的。不一致说明还没有统一入口。2.2 OR 流程把四面八方的需求收进同一个入口OR 是 Offering Requirement 的缩写可以理解为“产品包需求”。原料里给它的定位很清楚这是在外部咨询机构指导下开展的一项流程改进工作目的有四条——统一需求管理、主动收集需求、准确把握市场机会点、降低紧急需求比重、提升版本交付质量。后面两条特别值得琢磨为什么“降低紧急需求比重”会成为一个正式目标因为紧急需求本质上是一种透支。每来一个“这个必须马上做”就等于从已经排好的计划里抽走一块资源抽得多了原定版本的质量和交付节奏必然受损。OR 流程的思路不是拒绝紧急需求而是把需求收集前置、常态化让大部分需求在规划阶段就被看见而不是等到火烧眉毛才补。OR 流程在整条链上的位置可以这样理解市场管理MM流程负责判断“打哪个市场、做什么产品”输出路标和任务书OR 流程负责把需求系统地收上来、分析清楚喂给任务书和产品开发IPD 流程再往下做具体的开发和交付。三者是上下游咬合的关系OR 卡在中间既承接市场判断又给开发定输入。需求来源被明确分成外部和内部两栏。外部包括客户、行业分析、竞争对手、展览、杂志内部包括产品开发团队、总体组、用服、预研、市场、研发。这个划分的价值在于它逼着团队承认“需求不只来自客户”内部一线的痛点、预研的技术可能性、市场的趋势判断都是合法输入。很多团队只盯着客户工单结果产品越做越被动。举个具体的例子。某图像处理 Demo 的团队原本只有一条需求通道客户提工单。后来他们把用服记录的“客户反复问但没提工单”的问题、预研组验证过的新算法、展会上看到的同类产品交互方式全部按 OR 的框架录进同一个池子再统一做解释和过滤。结果是下一个版本的功能清单里有三项来自内部渠道的需求被提前识别避免了上线后再补的返工。2.3 端到端需求管理收集、分析、实现、验证、分发五步OR 流程真正落地靠的是一条端到端的链条。原料里把它拆成几个连续动作确定来源、收集、分析解释、过滤、检视、分类、排序、证实、实现纳入业务计划或路标、形成任务书、走变更请求、验证、分发。听上去步骤不少其实可以用一句话概括每一条需求都要能回答“它从哪来、凭什么排这个位置、最后落到哪个版本、怎么确认做到了”。第一段是收集。关键不是“多收”而是“收价值需求”。原料里特别强调外部需求和内部需求都要收但收集动作本身要规范不能让邮件、电话、当面聊成为正式渠道。正式渠道只有一个需求承诺电子流。其他方式只能算沟通手段不能算数。第二段是分析也是最容易被做浅的一段。解释是把客户的原话翻译成产品语言过滤是判断这条需求是否在范围内、是否是伪需求检视是拉相关方一起看有没有理解偏差分类是按功能、性能、质量等维度归堆排序是按价值和紧急度排队证实是回头跟提出方确认“我们理解得对不对”。这六步少一步后面就可能出现“做完了但客户说不是这个意思”的经典翻车。第三段是实现也就是需求真正被“纳入”。原料里给了三条纳入路径进业务计划或路标、进产品开发团队的任务书、走产品变更请求。三条路径对应三种时间尺度——路标管长远任务书管当前版本变更请求管已经启动的开发过程中的调整。分不清这三条就会出现“什么都想塞进当前版本”的拥堵。第四段是验证第五段是分发。验证包括早期客户确认、例行需求确认、常规确认以及在技术评审节点上的参与分发则是把确认过的需求派到对应的承接方——市场管理、产品线路标规划、版本规划、变更请求等。整条链还有一个逆向的闭环需求承诺电子流既是自上而下的分配流程也是自下而上的反馈流程完成情况要回填未完成的要提请变更。阶段核心动作常见失败点收集统一入口外部内部都收邮件电话口头承诺绕开电子流分析解释、过滤、检视、分类、排序、证实只分类不证实理解偏差留到开发阶段实现纳入路标、任务书或变更请求三条路径混用版本无限膨胀验证早期确认加节点评审只在最后验收问题发现太晚分发派到对应承接方并跟踪派出去就没人管闭环断掉3. 上游的战场选择市场管理MM流程在决定什么需求收上来之后紧接着的问题是这些需求该投向哪个市场很多团队在这一步是拍脑袋的——看到别人做什么就跟着做看到哪个客户嗓门大就先做哪个。市场管理流程存在的意义就是把“拍脑袋”换成“有依据的选择”。3.1 市场管理为什么存在先选战场再投兵力原料对市场管理的定义是一套系统的方法用于对广泛的机会进行选择收缩制定出一套以市场为中心的、能够带来最佳业务成果的战略与计划。注意“选择收缩”这四个字——它的前提是机会太多而不是太少流程的作用是砍掉大部分聚焦少数。具体动作包括分析市场走势和客户要求、建立合理的市场细分规则、对要投资和取得领先地位的细分市场做选择和优先级排序、制定可执行的业务活动。翻译成大白话先看清楚这块地适合种什么再决定今年种哪几垄最后才谈怎么施肥。打个比方这就像开饭馆之前先挑商圈。你可以选写字楼区做工作日午市也可以选住宅区做晚市和周末但很难同时把两边都做到最好。市场管理做的就是逼你明确回答我们服务谁、不服务谁、凭什么赢。它和 IPD 的关系是上下游。市场管理流程是 IPD 的上游负责组合策略和路标制定、制定任务书、启动 IPD 流程。换句话说IPD 负责“把选中的事做出来”市场管理负责“选对要做的事”。上游选错下游执行得再漂亮也是白费。3.2 业务计划的五个部分MM 流程最主要的那张表市场管理流程最主要的输出是业务计划。原料给的框架可以拆成五块每一块对应一个必须回答的问题。第一块是了解与洞察市场环境涉及价值扇区、竞争对手、客户。它回答的是“我们现在在哪里”处在什么市场、这个市场在怎么变化、客户是谁、需求是什么、竞争对手能提供什么、我们自己的核心能力限制在哪里。这一块做不实后面全是空中楼阁。第二块是组合分析和整体策略涉及愿景、目标、目的、目标的选择、整体策略及基本原理。它回答的是“我们要往哪里去”和“怎么去”有哪些可选战略方案市场渗透、市场拓展、产品包扩展、多样化哪一种最适合我们。第三块是业务计划的组成要素分核心要素和操作性要素。核心要素包括产品包、定价与条款、分销、集成营销沟通操作性要素包括支持与有熟练技能的资源、订单履行。这一块是把战略翻译成可执行的经营动作缺一块计划就落不了地。第四块是执行情况评估靠监控、时间表、预算、反馈信息来判断“我们是否做得对”。第五块是风险评估包括整体风险评估和成功关键因素识别。这五块合起来其实在反复问三个问题我们现在在哪里、我们向哪里进发、我们如何到达目的地。原料里还提到按客户 $APPEALS 的元素划分来设计战术这个工具的作用是把“客户为什么买”拆成若干可比较的维度让战术设计有抓手而不是凭感觉。对不熟的读者可以这样理解业务计划的分量它不是一份写给领导看的汇报材料而是一份“未来一段时间资源往哪投”的承诺书。承诺书里没有量化目标和取舍逻辑执行层就只能靠猜。3.3 任务书CharterMM 和 IPD 之间的交接棒市场管理流程跑完输出的是产品线业务计划、产品项目组合、产品线路标。这些东西要变成研发能接手的输入中间需要一个转换动作这个动作就是任务书也就是常说的 Charter。任务书的分量在于它是一个“开关”。原料里的流程图明确画了一个判断市场管理流程产出机会和路标之后要不要立任务书立才启动 IPD 流程不立就回到市场管理继续观察。这个 Y/N 判断看着简单实际是最容易被跳过的一步——很多团队是先立项再补理由而不是先想清楚再立项。任务书里应该承载什么至少包括目标市场、目标客户、产品包的核心价值主张、大致的时间窗口和商业目标。它不需要细到功能清单但必须细到“能判断该不该做、值不值得投人”。注意任务书不是需求清单。把一堆功能条目塞进任务书等于跳过了市场管理这一步直接把研发推到执行位。真要做需求清单那是 OR 流程和后续版本规划该干的事。4. 谁在拍板谁在执行IPD 里的角色分工流程画得再漂亮落到人头上如果职责不清一样会卡住。IPD 体系里角色不少初学者最容易晕的就是这一块。这一章按“决策层—执行层—需求层—接口层”的顺序把主要角色捋一遍。4.1 PMT 组合管理团队站在产品线之上看组合PMT 是 Portfolio Management Team 的缩写组合管理团队。原料给的定义是与产品开发团队类似是一个跨部门团队。它的组成相当宽主任、业务规划、市场分析、需求管理、解决方案管理代表、大客户市场代表、区域市场代表、销售部代表、预测、定价、技术规划、预算与损益、技术服务、订单履行/制造/采购、人力资源、运营、执行秘书。看这个名单就能明白它的定位它不是某一个部门的代表而是把一条产品线涉及的所有职能拉到一张桌子上共同对“投什么、不投什么、先做哪个”负责。组织位置上组合管理团队向投资评审机构汇报是它的参谋机构支撑部门是战略与规划部门产品线层的组合管理团队向产品线投资管理团队汇报支撑部门是产品线市场部门。这个“参谋机构”的定位很关键——它不直接指挥开发而是提供判断依据和排序建议。为什么要设这么一层因为开发团队天然有“把手上的事做完”的惯性很难客观地判断“这件事还值不值得做”。组合管理团队站在更高一层看整个盘子才能做出取舍。这也是它和产品开发团队最本质的区别一个管“做不做”一个管“怎么做”。4.2 PDT 与 PCR执行单元和它的变更入口PDT 是 Product Development Team产品开发团队负责把一个具体的产品包从概念做到发布。它是跨部门执行团队成员来自研发、市场、用服、制造、采购等围绕一个产品目标协同工作。PCR 是 Product Change Request产品变更请求。它是需求“纳入”的三条路径之一专门处理已经在开发过程中的变更。为什么单独设一个入口因为开发一旦启动任何变更都会牵动排期、资源、验证计划必须有正式的评估和批准动作不能靠群里吼一声就改。这两者的关系可以这样理解产品开发团队是施工队变更请求是施工过程中的设计变更单。没有变更单就改图纸最后验收一定对不上。在需求分发决策上原料列了几类承接方组合管理团队或需求分析团队、各功能部门、投资管理团队或组合管理团队、产品开发团队或技术开发团队及平台。不同层级的需求派到不同层级的承接方这个分层避免了“所有需求都往一个团队身上压”。4.3 需求管理团队与需求分析团队需求的分层接待体系需求这条线上角色是分层的。原料里出现了几类中央层需求管理团队、产品线层需求管理团队、地区部需求管理团队以及需求分析团队和需求质量监督角色。分层的逻辑是按“离客户的距离”和“决策权限”来的。地区部层贴近一线负责把当地客户和项目上的需求接住、初步筛选产品线层负责把本产品线相关的需求汇总、分析、排序中央层负责跨产品线的统筹和规则制定。需求分析团队则是在具体分析环节提供专业支撑的跨职能小组。需求质量监督这个角色的存在说明这套体系对“需求本身的质量”是有要求的。需求写得含糊、无法验证、前后矛盾都属于质量问题。设一个专门盯这件事的角色比事后返工便宜得多。这套分层体系解决的是一个很现实的问题一线不能什么都往上报总部也不能什么都自己接。分层的本质是“在正确的层级做正确的判断”。4.4 CCM把销售承诺接住的那个人CCM 是 Customer Commitment Manager客户需求承诺经理。原料里写明这个角色设在产品线市场部门和地区部市场部门作为面向销售项目的需求管理接口人。它的职责范围覆盖从投标到交付的整段负责销售项目投标阶段至交付阶段的客户需求承诺管理受理投标项目组提交的标书不满足项和需求监控并推动相关团队给出答复、承诺、解决方案和技术资料把需求录入需求承诺电子流并做闭环管理合同签订后监控开发状态存在交付风险时组织相关方解决对于新进入某市场或某客户的项目推动把接口规范、网管规范、互联互通需求调查清楚再录入。为什么需要这么一个人因为销售项目的时间压力和研发的排期压力天然冲突。销售希望“先答应下来再说”研发希望“别答应做不到的事”。中间如果没有一个既懂客户又懂内部能力边界的角色两边就会互相甩锅。原料里还定了两条硬规则值得单独拎出来所有对外答复必须以面向市场发布的产品功能清单为基础功能清单没覆盖的需求必须经过需求管理团队给出答复口径才能对外承诺凡未经批准的口径产品线不承担提供的责任。说白了承诺要有出处否则就是个人行为。5. 常见误区与易混概念这五个词初学者最容易搞混5.1 误区一把 IPD 当成研发部门内部的流程易混点在于IPD 全称里有“开发”两个字很多人第一反应就是“这是研发的事”。但看它的组成就知道市场管理在上游做选择需求管理在最前面接输入用服和制造在中间参与销售和客户承诺在末端闭环——研发只是其中一段。之所以容易混是因为大部分团队最早接触 IPD 都是从研发流程改造开始的看到的材料也多是开发阶段的活动图久而久之就形成了“IPD 等于研发流程”的印象。再加上研发是执行主体出问题时第一个被问的也是研发这个误解就被强化了。怎么区分看一个动作在不在 IPD 范围内问一句“它是不是在回答做什么、为什么做、谁来做、做到什么程度算完成”中的任何一个。市场选择回答“做什么”需求管理回答“为什么做”角色分工回答“谁来做”验证和度量回答“做到什么程度算完成”。四个问题跨了多个部门所以 IPD 天然是跨部门的不是某一个部门的内务。顺带说一个容易踩坑的点把 IPD 当成一套要一次性建成的制度。它更像一套持续校准的协作习惯先跑通一条链再扩到多条链比一次性铺开要稳。5.2 误区二把 OR 流程当成一张需求收集表易混点在于OR 流程里确实有“收集”这个动作而且收集表是它最显眼的产物所以很容易被简化成“填表交上来”。之所以容易混是因为收集是整条链里最容易看见、最容易考核的一步。领导问“需求管理做得怎么样”最方便的回答就是“这个月收了多少条”。于是收集被当成了目的分析和证实被跳过。怎么区分OR 流程的价值大头在收集之后。解释、过滤、检视、分类、排序、证实这六个动作才是把“一堆抱怨”变成“一份可执行清单”的关键。只收不析收得越多噪音越大。原料里把“降低紧急需求比重”列为目的之一也说明它追求的是结构改善而不是数量增长。5.3 误区三把需求变更控制当成“不让改”易混点在于“控制”这个词听起来就像“限制”很多人一看到变更要走流程第一反应是流程在挡路。之所以容易混是因为变更流程确实会带来等待要评估、要审批、要重排计划。对急着交付的人来说这段等待很煎熬于是流程就成了背锅的对象。怎么区分变更控制的目的不是拒绝变更而是让变更的代价被看见。一条需求改不改关键不是“能不能改”而是“改了之后影响哪些版本、哪些验证、哪些承诺”。把影响摊开再决定改还是不改、什么时候改这才是控制的含义。真正该防的是绕开流程的口头变更——那种变更没人评估影响最后往往在验收阶段集中爆发。5.4 误区四把 PMT 和 PDT 当成同一类团队易混点在于两者都是跨部门团队成员构成看起来有重叠名字也都带“团队”两个字。之所以容易混是因为在组织图上它们经常画在一起且都向上一层管理机构汇报不仔细看职责说明很难分清。怎么区分记一句话就够——PMT 管“做不做”PDT 管“怎么做”。PMT 站在产品线之上看组合负责市场选择、优先级排序、资源投放建议PDT 围绕一个具体产品目标负责把它从概念做到发布。一个是选局一个是打局。选局的人不该被具体项目的排期牵着走打局的人也不该替整个产品线做取舍。5.5 误区五把需求承诺电子流当成走形式易混点在于电子流在很多人眼里就是“多填一个系统”尤其是当邮件和电话已经把事情说清楚了再录一遍显得多余。之所以容易混是因为电子流的即时收益不明显——填的时候麻烦不填的时候也未必马上出事。它的价值要到几个月后才体现查历史承诺、追交付状态、做版本对比。怎么区分看它是不是唯一的正式入口。原料里写得很清楚邮件、电话、传真只能作为必要的沟通手段正式承诺必须录入电子流。一旦允许“重要的事走邮件、小事才录系统”电子流就退化成台账闭环也就断了。判断标准很简单三个月后要复盘一条承诺的来龙去脉能不能只靠电子流查清楚。能就是真在用不能就是形式。6. 什么时候该用 IPD什么时候别硬套聊到这里最实际的问题来了这套东西是不是所有团队都该上先说什么情况下值得用。产品线长、需求来源多、跨部门协作频繁、承诺一旦出错代价高的团队最需要这套框架。典型特征是同一个需求在不同部门有不同版本、版本排期经常被紧急需求打乱、客户投诉集中在“承诺了没做到”。这几种症状出现两种以上说明缺的不是努力是结构。场景建议原因多产品线、多区域销售值得完整引入需求入口分散不统一就会互相挤占资源单产品、客户集中先引入需求管理与变更控制市场管理那套组合分析投入产出比暂时不高十人以下小团队只借用需求分层和承诺留痕角色分工细化到 PMT、PDT 层级会拖慢决策项目制交付、一次性为主谨慎使用路标和组合管理的价值依赖长期产品规划再说什么时候别硬套。团队规模很小、产品方向单一、决策链条本来就短的时候把角色拆成组合管理团队、开发团队、需求管理团队、需求分析团队四层只会让一个本来三句话能定的事走三天流程。这时候更该借的是它的思想——需求要有唯一入口、承诺要有出处、变更要评估影响——而不是它的组织形态。还有一种情况要特别注意把流程当成考核工具。一旦收集数量、电子流录入率变成 KPI很快就会出现为了填而填的需求分析环节被彻底架空。流程是用来降低协作成本的不是用来制造新工作的。我自己踩过的一个坑值得说一下。早年在某模拟项目里团队一开始热情很高把所有角色、所有电子流、所有评审节点一次性铺开结果第一个版本就卡住了需求分析会开成了批斗会变更请求积压了一堆没人评最后大家默契地回到了邮件沟通。后来复盘才想明白问题不在流程本身在于我们跳过了“先跑通一条链”这一步直接上了全套。从那以后我每次引入任何流程都强制先只跑一条最窄的路径——一个产品、一类需求、一个承诺入口——跑顺了再往外扩。希望这个教训能帮到你。这份资料把 IPD 的完整框架、角色职责、需求管理五个阶段、市场管理与业务计划的结构都整理在了一起适合拿来做团队内部的对照材料逐条核对自己现在缺的是哪一环。先把最窄的那条链跑通比一次性照搬整套要靠谱得多。本文还有配套的精品资源点击获取