简介《华为IPD流程管理(完整版)》PPT面向产品研发管理从业者、IPD流程学习者及需要理解华为研发体系的项目与需求管理人员围绕IPD5.1 DRY RUN培训框架系统梳理以客户需求管理为核心的流程知识与组织协作要点。包内为1个pptx文件大小6.18MB便于作为培训课件或流程知识地图查阅。内容覆盖OR流程目的与定位、端到端需求管理中的收集、分析、实现、验证、分发以及需求承诺电子流、CCM角色、PMT/RMT/RAT组织体系等关键机制同时延伸到市场管理、任务书开发、概念与计划阶段、开发验证发布、生命周期、IPD客户化流程和度量指标帮助读者建立从需求入口到版本交付的整体认知。已有4843人学习适合用来对照实际项目梳理需求责任边界、承诺口径和流程节点也可作为IPD体系入门与团队内训的参考材料。1. IPD知识地图一条主线串起需求、路标与交付把 IPD 当成一堆流程图去背基本等于白学。它真正的主线只有一条需求从哪里来、由谁拍板、怎么变成路标和任务书、又怎么在开发验证发布的链条里不被稀释。围绕这条主线IPD 把客户需求管理OR、市场管理MM、任务书开发、概念与计划、开发验证发布、生命周期管理串成端到端的一条链中间用 PMT、RMT、CCM、RQA 这些角色当闸门。系统学这套东西的人最容易把它记成部门分工表复习时更该盯的是每个环节的输入、输出和签字权。这份笔记按「主流程—组织与承诺—市场管理—易错点—自测清单」重排了一遍适合正在系统学 IPD、或者需要快速找回地图的人。2. 需求管理主流程OR 从收集到分发的六步闭环需求这条线是整套 IPD 里最容易学成「名词解释」的部分。很多人能背出收集、分析、实现、验证、分发五个词却说不清每一步的输入从哪来、输出交给谁、卡住时该找哪个角色。真正把这条线走通一遍你会发现它本质上是一个带逆向回路的漏斗入口很宽出口很窄中间靠过滤和分析把噪音挤掉。2.1 OR 流程存在的理由与它在链条上的位置先看没有这套流程时会翻车的典型画面销售人员为了签单当面对客户承诺「下个版本一定支持广播功能」用服人员把现场问题直接甩给研发研发手里同时压着十几个渠道来的需求谁也说不清哪个优先级更高。结果是需求实现延迟、理解偏差客户在三个月后追问「你们说三月提供怎么六月还没出来」。这些不是执行不力而是缺少统一入口带来的结构性混乱。OR 是 Offering Requirement 的缩写指的是产品包需求。它要解决的正是上面这团乱麻目标可以浓缩成三句话统一需求管理让所有需求走同一个入口主动收集需求准确把握市场机会点降低紧急需求比重提升版本交付质量。注意第三条最容易被忽略——OR 不是要把需求变多而是要把「插队需求」变少让版本节奏稳定下来。从位置上看OR 夹在两条流程中间。上游是市场管理MM流程产出业务计划和产品线路标形成任务书Charter下游是集成产品开发IPD流程把产品包需求翻译成开发动作。业务计划、产品包需求、紧急产品需求这三样东西分别对应常规节奏、规划内需求和计划外冲击。把 OR 放在这个位置意味着它既不能脱离市场规划自说自话也不能绕过开发能力空许诺。提示复习时先画这条上下游关系再往里填角色。顺序反了后面所有职责都会记混。2.2 六步拆解收集、过滤、分析、实现、验证、分发端到端框架的起点是需求来源的确定。外部来源包括客户、行业分析、友商、展览、杂志内部来源包括 PDT、总体组、用服、预研、市场、研发。这一步的关键不是列清单而是明确「谁负责把哪一类来源的需求提上来」否则来源清单就是一张废纸。步骤核心动作输入输出主责角色收集确定内外来源收集价值需求来源清单、客户反馈原始需求条目市场、用服、PDT过滤解释、过滤、检视原始需求去重后的有效需求RAT分析分类、排序、证实有效需求需求包与优先级RAT、PMT实现新方案、新产品/新版本、加入在研产品需求包开发需求PDT、TDT验证TR 评审、早期确认、例行确认、常规确认开发需求验证结论RAT、RQA分发路标规划、版本规划、PCR验证结论路标、任务书、变更单PMT、IPMT过滤环节的三个动作值得单独说。解释是把客户口语化的描述翻译成产品语言过滤是判断这条需求属于共性还是个案、属于本产品还是别的产品检视是回到提出方确认「我理解得对不对」。这三步做完需求才配进入分析。分析环节的分类、排序、证实对应的是把需求归到功能域、排出优先级、用数据或客户访谈证实其真实性。很多团队跳过「证实」结果把某个客户的个人偏好当成了市场机会。实现环节有三条路径新方案、新产品或新版本、加入正在开发的产品。第三条最考验判断力因为它直接冲击在研版本的范围。分发则把结论送到三个地方市场管理的产品线路标规划、PDT 的版本规划、PDT 的 PCR产品变更请求。换句话说一条需求最终要么进入长期路标要么进入某个版本要么变成一次正式变更没有第四种归宿。需求纳入的位置也要记牢业务计划与路标、PDT 任务书、PCR。这三个落点分别对应战略层、项目层、变更层。复习时如果只记得「分发」两个字答题时很难展开把这三个落点补上答案立刻有骨架。2.3 需求承诺电子流的状态流转电子流是这条流程的「黑匣子」所有承诺必须留痕。它的特殊之处在于流程方向是自上而下的但信息回流是自下而上的逆向流程。理解这一点才能明白为什么状态机里必须有回退边。# 需求承诺电子流的核心状态与流转伪代码用于记忆状态机 states [草稿, 已提交, 预审, RMT分析, 已答复, 开发中, 验证中, 关闭] transitions { 草稿: [已提交], # 提交人CCM 或需求接口人 已提交: [预审, 草稿], # 要素不全退回补充 预审: [RMT分析], # 预审只查完整性不做取舍 RMT分析: [已答复, 开发中], # 答复口径由 RMT 统一给出 已答复: [开发中, 关闭], # 明确不做的需求关闭并留痕 开发中: [验证中, RMT分析], # 需求变更回到分析环节重评 验证中: [关闭, 开发中], # 验证不通过打回开发 关闭: [], } def can_transition(src, dst): return dst in transitions.get(src, [])这段状态机的记忆价值在于三条边。已提交 → 草稿说明预审不是走过场要素缺失必须退回开发中 → RMT分析说明变更控制不是开发自己说了算范围一动就要重新走分析验证中 → 开发中说明验证不是盖章不通过要真打回。参数上states是全部合法状态transitions是允许的迁移集合can_transition只做白名单判断实际系统还要叠加角色权限和时限。复习时能把这三条逆向边说清楚基本就不会把电子流记成一条直线。2.4 需求验证从市场需求到测试需求的逐级翻译验证环节的本质是「翻译链」。市场需求描述客户所想所需往下依次是产品包需求、设计需求、产品规格书、开发需求、测试需求。每一级都是一次收敛客户说要「信号好」产品包需求要落成覆盖指标设计需求要落成射频方案规格书要落成具体参数测试需求要落成可执行的用例。链上任何一级含糊最后都会变成开发阶段的扯皮。验证活动有四类RAT 参与 TR 评审、需求早期确认、例行需求确认、需求常规确认。TR 评审是把需求放进技术评审节点上过一遍早期确认是在开发前期就跟客户对齐理解例行确认按节奏滚动进行常规确认是交付前的收口。终点是 GA即一般可获得性意味着产品可以面向市场批量供货。把 GA 当作验证的结束标志而不是当作发布会的日期这个区别在答题时很关键。3. 需求组织与承诺机制RMT、PMT、CCM 的责任边界流程图画得再漂亮落到「谁签字」这一步还是会乱。这一章解决的就是签字权问题哪些团队做分析哪些团队做决策哪些角色做监督对外承诺又该由谁开口。组织记不清前面所有流程都会变成空转。3.1 需求管理组织体系谁分析、谁决策、谁监督需求管理组织体系里同时存在多个团队名字缩写接近非常容易混。C-PMT 与 PL-PMT 是组合管理团队前者是 IRB 的参谋机构后者是 IPMT 的参谋机构分别向对应的投资决策机构汇报。C-PMT 的支撑部门是战略与规划部PL-PMT 的支撑部门是 PL-Marketing。这层关系的记法是PMT 不拍板只做参谋拍板的是它上面的投资决策机构。团队全称含义核心职责汇报/支撑关系C-PMT组合管理团队公司级组合策略、路标输入向 IRB 汇报战略与规划部支撑PL-PMT组合管理团队产品线级产品线组合与业务计划向 IPMT 汇报PL-Marketing 支撑C-RMT / PL-RMT需求管理团队需求受理、分析结论、答复口径对接 PMT 与 PDTR-RMT地区部需求管理团队区域需求归集与前置处理对接地区部市场体系PL-RAT需求分析团队解释、过滤、检视、分类排序向 RMT 输出分析结论RQA需求质量监督需求质量抽查与流程合规独立监督PMT 的组成值得单独背一遍因为它是跨部门团队的代表样本主任、业务规划、市场分析、需求管理、S-PMT 代表或解决方案管理、大客户 Marketing 代表、区域 Marketing 代表、国内/国外销售部代表、预测、定价、技术规划、预算/损益、技术服务、订单履行/制造/采购、HR、OPS、执行秘书。这么多角色塞进一个团队目的只有一个让业务计划的每个要素都有主人。C-PMT 和 PL-PMT 的组成大体相同差异在于 C-PMT 设 S-PMT 代表和产品线 PMT 代表PL-PMT 设解决方案管理角色和产品族代表。PMT Leader 是 PMT 成员之一这个细节常被漏掉。它的特殊职责是解决与市场管理MM流程的衔接也就是说PMT 不只是需求侧的评审者还是 MM 与 OR 之间的接口。复习时把这句话记住很多跨流程的题就能接上。3.2 销售项目需求管理的五条硬原则这一节是整份材料里最像「军规」的部分也是最容易在案例题里丢分的地方。原则一共五条逐条拆开看。第一条需求承诺的接纳处理责任主体是各 RMT。今后各 PDT 无权接受来自全球产品行销体系、国际国内销售体系、全球技术服务体系的直接反馈需求。这句话的分量在于「无权」两个字它不是建议是权限收回。第二条所有需求承诺必须录入客户需求/承诺电子流以规范方式传递给 RMT邮件、电话、传真只能作为必要的沟通手段。换句话说沟通手段不等于受理凭证。第三条所有对外答复必须以面向市场发布的产品功能清单为基础包括市场技术指导书、业务签单附件等。功能清单未包括的需求必须经过 RMT 给出答复口径才能对外答复和承诺。第四条凡未经 RMT 批准的答复和承诺各产品线不承担提供的责任。这一条是责任切割线也是前面三条能落地的真正原因。第五条发生任何客户投诉时由代表处、办事处自行负责。这条最容易被误读成「甩锅」其实它对应的是「谁越权承诺谁承担后果」的机制设计。# 一条需求该不该由 PDT 直接接判断顺序不能颠倒 def route_requirement(req, published_feature_list): if req.channel ! 需求承诺电子流: return 退回邮件/电话/传真只作沟通手段必须补录电子流 if req.source in (产品行销处, 代表处, 办事处, 技术服务部): # 来自销售与服务体系的受理主体只能是 RMT if not req.rmt_id: return 转 RMTPDT 无权直接受理 if req.feature not in published_feature_list: return 待 RMT 给答复口径功能清单外的需求不得对外承诺 return 进入 RMT 分析这段判断的参数分别是channel是需求进入渠道source是提出方所属体系rmt_id是绑定的需求管理团队feature是需求对应的功能项published_feature_list是已发布的功能清单。顺序不能颠倒——先卡渠道再卡受理主体最后卡答复依据。把顺序记成「渠道→主体→依据」比死记五条原文更稳。3.3 CCM 角色投标到交付的唯一接口人CCM 是 Customer Commitment Manager客户需求承诺经理设在 PL-MKTG 和地区部 MKTG作为面向销售项目的需求管理接口人。它的职责可以按项目阶段切开看。投标阶段CCM 受理投标项目组提交的标书不满足项和需求负责监控、推动 RMT 提供答复、承诺、解决方案及相关技术资料。评标与澄清阶段CCM 组织需求评审与答复输出答复口径、解决方案、配置和技术资料答标书澄清结束后把新需求整理进电子流。合同谈判阶段组织需求确认输出需求确认文档作为合同附件对 CCL 进行评审并在合同评审表上签字召集 RMT 处理需求变更。交付阶段监控需求承诺的开发状态存在交付风险时组织 RMT、PDT、产品经理解决出现收费扩容情况时由行销产品经理负责向客户提供答复。对新进入某国家或某运营商的项目CCM 还有一项特殊职责推动地区部 PL-MKTG 把接口规范、网管规范、与网上设备互联互通的所有需求调查、分析清楚作为该项目的需求录入电子流。这一条常被当作边角料其实它是海外项目最容易踩坑的地方——接口和网管规范没提前摸清交付期一定出问题。注意CCM 是接口人不是决策人。它可以推动、监控、组织但答复口径仍然由 RMT 给出。4. 市场管理流程MM 如何为 IPD 供弹药如果说 OR 是漏斗MM 就是漏斗上游的水源。市场管理没做扎实需求管理就只能被动接单路标也会变成拍脑袋。这一章的重点不在背定义而在搞清楚 MM 的输出到底长什么样、由谁来做、做完怎么启动 IPD。4.1 MM 的定位与输出市场管理是一套系统的方法用于对广泛的机会进行选择收缩制定出一套以市场为中心的、能够带来最佳业务成果的战略与计划。它运用严格规范的方法分析市场走势与客户要求创建合理的市场细分规则对要投资和取得领先地位的细分市场进行选择和优先级排序从而制定可执行的业务活动。它最主要的输出是业务计划。这份业务计划的作用是驱动新产品包的开发并启动 IPD 流程。换个说法MM 决定「打哪个市场、投什么产品」IPD 负责「把产品做出来」。两者的衔接点就是任务书。市场管理流程是 IPD 流程的上游流程包括组合策略和路标制定制定任务书启动 IPD 流程。流程图上的顺序是理解市场、进行市场细分、组合分析、制定业务战略和计划、管理业务计划并评估绩效下游接 IPD 的概念、计划、开发、验证、发布、生命周期。输入侧则来自客户反馈、竞争对手信息、技术趋势、目前产品组合。把这条上下游关系记住就不会把 MM 和 OR 混为一谈MM 管「做什么」OR 管「要什么」。4.2 业务计划框架五段结构与三个追问业务计划框架分为五个部分。第一部分是了解/洞察市场环境包含价值扇区、竞争对手、客户三块。第二部分是组合分析和整体策略包含愿景目标目的、目标的选择、整体的策略及基本原理。第三部分是业务计划的组成要素分核心要素与操作性要素核心要素是产品包、定价与条款、分销、集成营销沟通操作性要素是支持与有熟练技能的资源、订单履行。第四部分是执行情况评估第五部分是风险评估与成功的关键因素。这套框架背后是三个追问。「我们现在在哪里」对应市场环境洞察我们处在什么样的市场中、这个市场发生着什么变化、客户是谁、需求是什么、竞争对手能提供什么、我们的核心能力限制因素是什么。「我们如何到达目的地」对应战略选项市场渗透、市场拓展、产品包考法、多样化哪种方案最好。「我们向哪里进发」对应愿景使命与目标以及计划缺口有多大。「我们是否做得对」对应监控时间表、预算、反馈信息。战术层面按客户 $APPEALS 的元素划分。这个工具的作用是把「客户为什么买」拆成可比较的维度让业务计划的每个要素都能对应到客户价值而不是停留在内部视角。business_plan: market_insight: # I 了解/洞察市场环境 value_sector: true # 价值扇区 competitors: true # 竞争对手 customers: true # 客户 portfolio_strategy: # II 组合分析与整体策略 vision_goal: true # 愿景、目标、目的 target_segments: true # 目标细分选择 strategy_rationale: true # 整体策略及基本原理 plan_elements: # III 业务计划组成要素 core: [产品包, 定价与条款, 分销, 集成营销沟通] operational: [支持与技能资源, 订单履行] execution_review: true # IV 执行情况评估 risk_assessment: true # V 风险评估与成功关键因素这份配置的用法是自检哪一项是false业务计划就在哪一段有缺口。参数上前三段属于「想清楚」第四段属于「看着办」第五段属于「留后手」。评审时按顺序过比通读一遍文档更容易发现漏项。实际使用中strategy_rationale最常被写成口号评审时要追问「为什么是这个细分市场而不是那个」答不上来就是没做实。4.3 五个步骤与 PMT 的参谋位置MM 的五个步骤是一条递进链。理解市场是铺信息面进行市场细分是按客户特征和需求把大盘子切开组合分析是评估每个细分市场的吸引力和自身竞争力制定业务战略和计划是选目标、定定位、配资源管理业务计划并评估绩效是滚动监控。五步里最容易走过场的是第二步因为细分规则一旦定得粗后面的组合分析和路标规划都会失真。角色上MM 的主要角色是 IRB/IPMT 与 PMT。C-PMT 是 IRB 的参谋机构向 IRB 汇报支撑部门是战略与规划部PL-PMT 是 IPMT 的参谋机构向 IPMT 汇报支撑部门是 PL-Marketing。组织结构上C-PMT 在上PL-PMT 居中PDT 在下形成「参谋—决策—执行」的三层。PDT 在 IPMT 和 PL-PMT 之下按产品线分布多个 PDT 并行。把 PMT 的位置记成「参谋机构」而不是「决策机构」是这一节最值钱的一句话。它解释了为什么 PMT 要凑那么多角色参谋机构的价值在于信息完整和视角平衡不在于权力大小。也解释了为什么 PMT Leader 要负责与 MM 流程衔接——参谋机构之间的接口比参谋与执行之间的接口更容易断。5. 易漏易错点五个最容易在案例题和实操中踩坑的地方前面几章是正向梳理这一章反过来专挑那些「看的时候觉得懂、用的时候必错」的点。每条按「易漏点—为什么漏—怎么补」展开复习时可以直接当错题本用。5.1 易漏点一把 PDT 当成需求受理窗口易漏点认为 PDT 离开发最近销售把需求直接给 PDT 更高效于是默认 PDT 可以接需求、可以答复。为什么漏从效率直觉看绕过 RMT 确实更快尤其在项目紧迫时。但这条捷径破坏的是责任链——PDT 接了需求却无权对外承诺最后要么超范围开发要么交付不了投诉还是回到代表处。更隐蔽的是PDT 接的需求不进电子流路标规划时就统计不到形成数据黑洞。怎么补把「受理主体」和「执行主体」分开记。受理主体是各 RMT执行主体才是 PDT。遇到案例题先问「这条需求是谁收的」再问「谁答复的」两个答案不一致就是流程违规。判断口诀PDT 可以提需求不可以收需求。5.2 易漏点二口头承诺不入电子流易漏点把邮件、电话、会议纪要当成需求受理凭证觉得「反正留了记录」。为什么漏日常沟通里邮件确实有痕迹容易让人误以为等同电子流。但电子流承载的不只是记录还有分派、时限、答复口径和闭环状态。邮件躺在个人邮箱里RMT 看不到度量指标统计不到变更时也追不到源头。怎么补记住一句原文表述——邮件、电话、传真只可以作为必要的沟通手段所有需求承诺必须录入客户需求/承诺电子流。复习时把「沟通手段」和「受理凭证」当成两个筐任何一条需求先问它落在哪个筐里。实操中可以在项目启动会上明确口头承诺一律视为无效补录电子流后才进入排期。5.3 易漏点三需求分发当成一次性动作易漏点认为分发就是把需求塞进某个版本分完就结束忽略变更控制和回退。为什么漏流程图上分发是个节点视觉上像终点。实际上分发有三个落点——路标规划、版本规划、PCR每一个落点后续都会变化。版本范围调整、客户优先级变化、技术方案不可行都会让已分发的需求回到分析环节。怎么补把状态机里的逆向边当作复习重点尤其是「开发中→RMT分析」这条。理解它的含义需求一旦变更不是开发内部改改就行要回到 RMT 重新评估、重新给口径。案例题里只要出现「范围变更」第一反应就该是走 PCR而不是让开发加班消化。5.4 易漏点四把 OR 等同于需求收集易漏点提到 OR 就只想到「收集需求」把过滤、分析、证实、验证全丢了。为什么漏收集环节最具体、最有画面感容易成为记忆锚点。加上很多团队的 OR 实践确实停留在建个需求池久而久之就把流程缩水成了工具。怎么补用目标反推。OR 的三个目标是统一管理、主动收集、降低紧急需求比重其中第三个目标只能靠过滤和分析实现光收集做不到。复习时把六步默写一遍每一步写一个输出物写不出来的那步就是薄弱点。特别要补「证实」这个动作它是把客户偏好和市场机会区分开的关键。5.5 易漏点五度量指标只看数量不看闭环易漏点统计需求条数、版本需求数、紧急需求占比却不看承诺兑现率和闭环周期。为什么漏数量类指标好取数、好汇报闭环类指标要跨系统关联取数麻烦。结果就是指标越做越漂亮交付风险一点没降。怎么补把度量拆成三层——入口层看来源结构和紧急需求比重过程层看分析周期和答复及时率结果层看承诺兑现率和验证通过率。三层里结果层权重最高因为它直接对应「提升版本交付质量」这个目标。复习时如果只能记一个指标记承诺兑现率它能把电子流、RMT 答复、开发验证三个环节串起来。6. 复习清单用一张自测表把 IPD 流程走通复习到这一步最怕的是「每章都眼熟合上书就串不起来」。我的做法是不再通读而是拿一张自测表逐项过凡是卡壳超过十秒的回到对应章节补。下面这张表按流程顺序排左列是自测问题右列是答不上来时该回看的位置。自测问题回看位置OR 的三个目标分别是什么哪个目标最容易被忽略2.1需求的外部来源和内部来源各举三个2.2过滤环节的解释、过滤、检视分别在做什么2.2需求分发的三个落点是什么2.2电子流里哪三条是逆向边各代表什么控制2.3从市场需求到测试需求要经过几级翻译2.4PMT 是参谋机构还是决策机构向谁汇报3.1、4.3RMT、RAT、RQA 三者的分工差别3.1销售项目需求管理的五条原则能复述几条3.2CCM 在投标、谈判、交付三阶段各做什么3.3MM 的最主要输出是什么它如何启动 IPD4.1业务计划五段结构里核心要素和操作性要素各包含什么4.2战略选项有哪四种4.2一条需求从提出到关闭至少要经过几个签字角色2.3、3.2过表的方法有讲究不要按顺序默读先随机抽三题答完再对。答对但说不清理由的算半对照样回看。比如「PMT 是参谋机构」这句能答出来但说不出「向 IRB 还是 IPMT 汇报」就说明组织关系没记牢要回到 3.1 把 C-PMT 和 PL-PMT 的汇报线重新画一遍。还有一个小技巧把六个流程节点写成六张卡片打乱后按「输入—输出」接力排序。收集的输出是原始需求过滤的输入是原始需求接不上就说明中间漏了动作。这个练习比背目录有效因为它逼你想清楚每一步到底交付了什么。当年我第一次做这个接力卡在「验证」和「分发」之间总觉得验证完就该结束后来才想明白分发是把验证结论送回规划侧方向是往上游走的。血泪经验是别在考前突击背角色缩写。C-PMT、PL-PMT、C-RMT、PL-RMT、R-RMT、PL-RAT、RQA 这一串硬背第二天就混。有效的办法是先画三层结构——投资决策层、参谋层、执行层再把缩写往里填填不进去的说明你只知道名字不知道位置。从那以后我每次复习这套流程都强制先画结构图再背名词宁可少背两个也不让缩写悬空。希望帮到你。本文还有配套的精品资源点击获取