简介这份《华为IPD流程管理完整版》PPT面向产品经理、研发管理者及流程建设人员围绕华为IPD体系中的客户需求管理主线梳理从需求收集、分析、实现、验证到分发的端到端流程帮助读者理解OR流程、产品包需求、需求变更控制、CCM角色职责与跨部门协同机制。压缩包内含1个pptx文件约6.18MB以完整培训课件形式组织内容涉及市场管理、任务书开发、概念与计划、开发验证发布、生命周期及IPD客户化流程并覆盖PDT、PCR、C-PMT、RMT、需求承诺电子流、需求分析团队与需求质量监督等关键概念和工具。已有4843人学习适合用于搭建IPD知识框架、对照实际项目梳理需求管理职责也可作为内训或流程复盘参考便于快速定位需求度量指标、各阶段流程要点并理解各流程之间的接口关系。1. 一份 159 页的 IPD 5.1 培训课件它补的是流程落地里最缺的那块拼图第一次翻这份 IPD 5.1 的 DRY RUN 培训课件我以为是又一份讲理念的宣讲材料直到看见索引页把 4 天课程切成 14 段、每段都挂着具体页码——第 2 到 13 页讲客户需求管理14 到 29 页讲市场管理流程一路排到 159 页收尾。IPD 流程管理难落地的地方从来不是概念而是这种颗粒度需求从哪个口子进来、谁来接、接不住怎么退回、退回后怎么留痕。这份 pptx 把 OR 流程、需求承诺电子流、MM 流程、任务书开发、TR 评审点、度量指标串成了一条闭环适合正在做研发流程改造的产品经理、流程工程师、质量角色照着抄骨架也适合刚接手需求管理岗的人补体系课。2. 需求入口怎么收口OR 流程与需求承诺电子流的五段拆解2.1 三种需求失序形态与一份可检索的页码索引课件开篇没有直接讲流程而是先摆了三张“事故现场”。第一种是单向承诺市场侧已经对客户承诺“下个版本支持广播功能”研发侧毫不知情缺陷拖到版本末期才爆。第二种是渠道发散市场需求、用服反馈、领导指示、客户投诉四条线同时往研发灌没人做统一登记同一个需求被描述成四种样子。第三种是紧急插队承诺“3 月提供”的功能拖到 6 月还没影子紧急需求比重一路走高版本交付质量随之塌方。这三种形态指向同一个结论需求管理的第一个动作不是分析而是收口。OROffering Requirement流程在课件里被定位成需求管理的总入口目标写得很直白——统一需求管理、主动收集需求、降低紧急需求比重、提升版本交付质量。注意“主动收集”这四个字它意味着需求不能只等着销售往回带还要从行业分析、友商动作、展会、杂志这些外部来源以及 PDT、总体组、用服、预研、市场、研发这些内部来源主动去捞。课件本身是按 4 天课程组织的索引页把 159 页切成 14 段段落边界就是模块边界。把它先整理成下面这张表后面查任何概念都能直接定位比从头翻页快得多序号模块页码区间典型内容1客户需求管理2-13OR 定义、电子流、CCM 职责、销售项目需求原则2市场管理流程14-29MM 五步、业务计划框架、PMT 角色3预测流程30-36需求预测与备货输入4IPD 管理体系37-41整体框架与阶段划分5任务书开发流程42-57Charter 的输入输出6概念、计划阶段流程58-63阶段目标与交付件7系统设计概要64-74架构与需求映射8业务计划开发75-88商业论证与定价9开发、验证、发布阶段流程89-97TR 评审点、GA 判定10产品开发营销计划流程98-113上市与推广节奏11生命周期阶段流程114-125退市与版本维护12IPD 客户化流程126-133客户定制需求的裁剪13IPD 度量指标134-146流程健康度与需求指标14综合演练与收尾147-159DRY RUN 串讲如果不想每次靠肉眼翻用一段脚本把整份课件拆成按页的文本后续做关键词回溯会省很多事# 把 pptx 按页拆成 jsonl便于按关键词定位页码 from pptx import Presentation import json SRC ipd_5_1_dryrun.pptx # 课件文件名按实际改 OUT ipd_pages.jsonl prs Presentation(SRC) rows [] for idx, slide in enumerate(prs.slides, start1): chunks [] for shape in slide.shapes: # 只有带文本框的 shape 才有 text_frame图形和表格需另行处理 if not shape.has_text_frame: continue for para in shape.text_frame.paragraphs: text .join(run.text for run in para.runs).strip() if text: chunks.append(text) rows.append({page: idx, text: \n.join(chunks)}) with open(OUT, w, encodingutf-8) as f: for r in rows: f.write(json.dumps(r, ensure_asciiFalse) \n) print(pages:, len(rows), blank:, sum(1 for r in rows if len(r[text]) 10))这段代码的逻辑很朴素遍历每一页的每一个 shape只处理has_text_frame为真的对象再把段落里的 run 文本拼起来。参数上唯一需要改的是SRC。输出用 jsonl 而不是 csv是因为课件里的长段落含换行和逗号csv 容易错列。跑完看blank的数值那些页基本是纯流程图页文字被拆在图形节点里脚本捞不到需要人工回看——课件里流程类页面占比不低这一点心理预期要先有。2.2 需求承诺电子流的五段收集、分析、实现、验证、分发课件把需求承诺电子流画成一个带回路的状态机主干是收集 → 分析 → 实现 → 验证 → 分配其中“分配”环节有个分支PDT 评估后认为做不了就提请变更回到分析环节重走。这个回路是整个流程最值钱的部分因为它给了研发一个合规的“退回”出口——没有这个出口压力会全部转化成私下承诺。阶段主责角色关键动作输出物卡点判据收集各 RMT、CCM录入需求、标注来源与客户需求单是否录入电子流邮件电话不算数分析RAT、RMT解释、过滤、检视、分类、排序、证实分析结论是否完成客户早期确认实现PDT / TDT纳入版本规划或 Charter版本需求清单是否进入已批准的项目范围验证RQA、测试需求确认与验证验证记录需求与规格书是否可双向追溯分发PMT / RMT答复口径、技术资料下发答复包是否基于已发布的功能清单表格里最容易被忽略的是最后一列的判据。举个最常见的错把“需求已录入”当成“需求已受理”。电子流里录了单子只代表收集环节完成分析环节如果没做客户早期确认后面实现出来的东西大概率不是客户要的。课件里专门区分了三种确认——需求早期确认、例行需求确认、常规确认对应的时点分别是分析阶段、开发过程、GA 之前。这三种确认不能合并合并了就丢掉了纠偏窗口。另一个细节是电子流的闭环。课件给了一条硬规定所有需求承诺必须录入电子流邮件、电话、传真只能作为沟通手段不能作为承诺载体。这条规定听起来官僚实际是给后面所有争议留证据链。需求变更时变更记录挂在同一条单子上追溯时不用满世界找邮件。2.3 角色边界PMT、RMT、RAT、RQA、CCM 谁管哪一段课件在组织体系那页列了一长串缩写C-PMT、C-RMT、PL-RMT、PL-RAT、R-RMT、RQA。第一次看容易懵其实按“层级 职能”两个维度拆就清楚了。层级别上分中央C、产品线PL、地区部R职能上分管理团队PMT/RMT和分析团队RATRQA 是横切的监督角色。PMT组合管理团队负责与 MM 流程衔接决定做什么、不做什么是投资决策的参谋机构RMT需求管理团队是需求的唯一受理主体各层级 RMT 对应各自范围RAT需求分析团队承接 RMT 分下来的分析任务同时参与 TR 评审RQA需求质量监督独立于业务线查的是流程执行质量而不是需求内容CCM客户需求承诺经理设在产品线市场部和地区部市场部是销售项目对接需求管理的唯一接口CCM 这个角色值得单独说。课件把它的职责拆成四条负责投标到交付全过程的客户需求承诺管理受理投标项目组提交的标书不满足项和需求推动 RMT 给出答复、承诺、解决方案和技术资料把需求录入电子流并做闭环管理。合同签订后的交付阶段如果承诺的开发状态有风险CCM 要组织 RMT、PDT 和产品经理一起解决。换句话说CCM 不是传声筒是带推动权的项目经理角色。课件里还有一条容易被跳过的原则杀伤力很大未经 RMT 批准的答复和承诺产品线不承担提供责任发生客户投诉时由代表处、办事处自行负责。这条规则在推行初期一定会挨骂但它是把“随口承诺”这个口子堵上的唯一办法。我见过推行失败的案例问题几乎都出在这一条上——规矩立了但第一个违反的人没被追责后面就全散了。3. 从 MM 到 Charter市场管理流程把机会翻译成任务书的四步3.1 MM 五步与业务计划框架的实际用法市场管理流程在课件里的定义是“对广泛的机会进行选择收缩制定以市场为中心、能带来最佳业务成果的战略与计划”。这句话拆开就是两件事先做减法再做排序。流程本身分五步——理解市场、进行市场细分、组合分析、制定业务战略和计划、管理业务计划并评估绩效。输入侧接了客户反馈、竞争对手信息、技术趋势、目前产品组合输出侧是产品线业务计划、产品项目组合、产品线路标以及最终启动 IPD 的任务书。业务计划的框架在课件里占了不小篇幅分成五段了解洞察市场环境、组合分析和整体策略、业务计划的组成要素、执行情况评估、风险评估与成功关键因素。这个框架最有价值的地方是它对应了四个追问追问对应框架段要回答的内容我们现在在哪里I 市场环境处在什么市场、市场在怎么变、客户是谁、对手能提供什么、自身能力边界在哪我们向哪里进发II 组合分析愿景使命、目标、计划缺口有多大我们如何到达II 整体策略市场渗透、市场拓展、产品包扩充、多样化选哪个以及为什么我们是否做得对IV 执行评估时间表、预算、反馈信息第三段的组成要素又分核心和操作性两层。核心要素是产品包、定价与条款、分销、集成营销沟通操作性要素是支持资源、订单履行。这里的分层不是学术洁癖它对应两个不同的评审视角核心要素回答“这个生意成不成立”操作性要素回答“这个生意交付得出来吗”。很多业务计划栽在后者——商业论证做得漂亮订单履行和资源支撑那栏是空的。3.2 细分市场到路标的推演步骤课件里没给完整模板只给了流程框图和 $APPEALS 这个工具名。按这个场景下常见的做法从细分到路标可以落成五步第一步切分维度先定死。按客户类型、按应用场景、按采购模式三条里选一条主维度另外两条做交叉验证。维度换来换去是新手最容易犯的错切出来的细分市场没法做组合分析。第二步每个细分市场填一张吸引力表。规模、增速、毛利水平、竞争强度、进入门槛五列打分。打分不需要精确需要的是同一套标尺让不同人打出来的表能放在一起比。第三步用自身能力做一次反向过滤。技术积累、渠道覆盖、服务能力三项逐项判断“够得着 / 跳一跳够得着 / 够不着”。第三档直接砍掉别留念想。第四步组合分析做取舍。把留下来的细分市场放到“吸引力 × 自身能力”的二维格子里优先级排序。排完要回答一个问题资源只够做前两个的时候后三个是砍掉还是延后延后到什么时点。第五步落到路标和任务书。每个进入前两档的细分市场对应一个路标条目条目要写明目标客户群、目标版本、目标时间窗。路标定了之后任务书才有依据。这套推演里最容易被跳过的是第四步的“砍”。我见过太多路标是加法做出来的每个细分市场都留了一小块结果资源摊薄哪一个都没打透。课件把 MM 流程定义成“选择收缩”重点在后两个字。3.3 任务书Charter的七段骨架任务书是 MM 流程交给 IPD 流程的接力棒课件里单独用一段页码42-57 页讲任务书开发流程。常见做法是把 Charter 拆成七段每段都有明确的评审人段落核心问题评审关注点机会描述这个市场机会是什么、有多大数据来源是否可靠目标客户与细分卖给谁、不卖给谁与 MM 的细分结论是否一致产品包定义提供什么、边界在哪用 $APPEALS 逐项对齐客户关注点竞争分析对手是谁、差异化在哪是否只写了友商参数对比商业目标收入、毛利、份额、时间窗与路标是否冲突里程碑与资源关键节点、人力与预算需求资源是否已获承诺风险与假设什么情况下这个项目不成立是否有对应的退出条件第三段用 $APPEALS 对齐这件事要展开说。$APPEALS 拆的是八个客户关注维度落到任务书里就是八行清单逐行写“客户期望水平”和“本产品包达成水平”。写不出来或者写出来和竞品没差异的维度就是后续开发的坑。第七段的退出条件尤其容易被写成摆设实际做法是每条假设后面跟一句“如果这条不成立我们在哪个阶段门做终止决策”没有这句话的风险条目不算写完。任务书评审不通过退回 MM 重做这个回路在课件里画得很清楚。现实里更常见的是任务书带着一堆“待定”进 IPD然后概念阶段花三个月补作业。与其这样不如在任务书阶段就把待定项列成清单明确谁在什么时点前关闭。4. 阶段门怎么判概念到生命周期的六个节点与 TR 评审口径4.1 概念与计划阶段把不确定性砍到可决策IPD 主流程的阶段划分在课件里是概念、计划、开发、验证、发布、生命周期六段前两段加起来页数不多58-63 页但决策密度最高。概念阶段要回答的是“做不做”计划阶段要回答的是“怎么做、花多少、什么时候交”。概念阶段的核心输出是产品包需求和初始的商业论证。这个阶段允许粗糙但不允许含糊。判断标准可以落到三条目标客户群是否收敛到一个可描述的集合产品包边界是否划到了“不做什么”这一层关键假设是否已经列出并有验证计划。三条里缺一条进入计划阶段就会反复。计划阶段是把概念阶段的不确定性逐条关闭。系统设计概要在这一阶段成形需求要从产品包需求往下分解到设计需求、产品规格书、开发需求、测试需求。课件里有一条链路写得明确市场需求 → 客户所想所需 → 产品包需求 → 设计需求 → 产品规格书 → 开发需求 → 测试需求。这条链断在哪一环后面的验证就没法做双向追溯。这里有个实操经验计划阶段的评审别只看交付件齐不齐要看需求分解链路能不能走通。随便挑三条产品包需求往下追到测试需求追不通就说明分解没做完。这个动作十分钟能做完比翻几十页文档有效。4.2 开发验证发布TR 评审点与 GA 判定口径开发、验证、发布三个阶段在课件里对应 89-97 页核心是技术评审点TR和一般可获得性GA的判定。RAT 在这个阶段不是旁观者要参与 TR 评审确认需求在设计和实现中没有被悄悄改掉。TR 评审容易流于形式原因通常是评审材料只写“做了什么”不写“和需求对得上吗”。有效的做法是每个 TR 点固定回答三个问题本阶段承诺的需求清单完成了几条、未完成的原因是什么、有没有新增需求以及新增需求走了什么变更流程。第三个问题最能暴露问题——新增需求如果没走 PCR说明变更控制已经失效。GA 判定在课件里对应“验证确认”环节需求侧要做的是常规确认确认交付的功能与当初承诺的功能清单一致。判定口径建议按下面这张表逐项过判定项通过标准常见失败原因需求覆盖承诺需求全部实现或已正式变更口头变更未落单验证闭环每条需求有对应验证记录测试用例未与需求关联答复口径对外功能清单已更新并发布用旧清单答复新客户遗留问题遗留缺陷有分级和处理计划遗留项没 Owner交付准备服务、制造、订单履行已就绪只关注研发侧完成度第四项和第五项是最容易漏的。研发视角的“做完了”和市场视角的“能卖了”之间隔着服务准备和订单履行课件在业务计划的操作性要素里提过这两块落到 GA 判定上就是硬门槛。4.3 营销计划与生命周期发布不是终点产品开发营销计划流程单独占了 98-113 页篇幅比开发验证发布还长这个配比本身就在传递信息上市节奏、定价条款、分销渠道、集成营销沟通是产品成功的一部分不是研发做完之后市场部接手的事。营销计划的输入是业务计划里的核心要素输出要能回答“首发打哪个客户群、用什么价格锚点、渠道怎么铺、推广节奏怎么排”。生命周期阶段流程114-125 页处理的是发布之后的事版本维护策略、退市节奏、存量客户的升级路径。这部分在课件里和 IPD 客户化流程126-133 页相邻逻辑上说得通——客户化需求大量产生在生命周期阶段老客户的定制诉求、新进入市场的接口规范、网管要求、互联互通要求都会在这个阶段涌进来。如果没有客户化流程做裁剪这些需求会绕过 OR 直接进研发。课件里有个具体动作值得抄对于新进入某个市场或某个客户的项目CCM 要推动地区部市场把接口规范、网管规范、与现网设备互联互通的所有需求调查、分析清楚作为项目需求录入电子流。这一步做在前面后面就少一堆“上线前两周发现接口对不上”的事故。5. 避坑与常见问题五个真实翻车场景和处置办法坑一电子流成了登记簿分析环节形同虚设现象是电子流里的单子数量很好看但版本规划会上没人拿它做输入需求该插队还是插队。原因是收集环节被当成 KPI录入数量成了考核项分析环节没有对应的质量要求。解决办法是把考核点从“录入多少条”换成“分析结论被采纳多少条”同时给分析环节设时限——录入后 N 个工作日内必须出分析结论超时自动升级到 RMT。没有时限的分析环节一定会烂在队列里。坑二把“已录入”当成“已承诺”对外口径失守现象是销售拿着电子流截图告诉客户“这个需求已经在流程里了”客户理解成“你们答应了”。原因是团队没有区分受理和承诺两个状态对外的答复口径没有统一出口。解决办法是把对外答复的口径收敛到 CCM 一个出口并且明确只有基于已发布功能清单的答复才算数功能清单外的需求必须 RMT 给出答复口径才能对外说。这条规矩最好写进投标模板从源头卡住。坑三任务书带着一堆待定进概念阶段现象是概念阶段评审时产品包边界、目标客户群、商业目标三项里总有一两项写着“待明确”。原因是 MM 流程和 IPD 流程的交接没有硬门槛任务书评审变成了走过场。解决办法是给任务书设“待定项清单”每项写明责任人和关闭时点超过约定时点未关闭的概念阶段不予通过。允许待定但不允许无限期待定。坑四TR 评审只对进度不对需求现象是 TR 评审会上讨论的全是进度风险和资源缺口需求实现情况一页带过。原因是评审材料模板里没有需求对照章节评审人也就顺着材料问。解决办法是把“承诺需求完成率、未完成原因、新增需求变更记录”三项固化成 TR 材料的必填页缺页直接退回。模板不改习惯不会变。坑五度量指标只统计不消费现象是每月出一份指标报表需求及时率、紧急需求占比、变更次数都有数但没人根据数做决策。原因是指标设计时只考虑了“能不能算出来”没考虑“算出来谁用、用来改什么”。解决办法是每条指标后面强制挂一个“触发动作”紧急需求占比超过阈值时触发 RMT 做一次来源分析并调整收集策略变更次数超标时触发一次需求分析质量回溯。指标没有触发动作就只是装饰。6. 度量指标不沦为填表四类指标的设计口径与一次回放验证课件最后一段134-146 页讲 IPD 度量指标内容不多但方向是对的指标要能反映流程健康度而不是反映填表勤奋度。按这个场景的常见做法指标可以分四类每类的设计口径不一样类别示例指标设计口径触发动作入口质量需求描述完整率、来源标注率只统计电子流字段不搞人工打分完整率低于阈值时回退给提交人补全流转效率分析周期、答复及时率按工作日计剔除等待客户确认的时间超时单子每周拉一次清单点名变更控制变更单占比、变更原因分布区分需求变更和实现变更需求变更占比高说明前端分析不足交付质量承诺需求兑现率、GA 后需求返工数以版本为单位统计不按人统计兑现率低于目标时复盘任务书阶段设计口径里最要紧的是“不按人统计”。一旦指标挂到个人数据立刻失真所有人都学会在填字段上做文章。按版本、按团队统计才有讨论空间。指标定完之后要做一次回放验证方法很土但有效挑一个刚结束的版本从电子流里拉出这个版本的全部需求单按时间轴走一遍——什么时候录入、什么时候出分析结论、什么时候进版本规划、什么时候验证、对外答复用的哪版功能清单。走完一遍前面四类指标里哪些是真实可得的、哪些根本拉不出数据一目了然。拉不出数据的指标直接砍掉别留着下个季度再试。回放里最常见的发现是需求单和版本规划之间没有关联字段。这意味着“承诺兑现率”这个指标根本算不准因为无法确定某条需求到底承诺在哪个版本。补这个字段的成本很低但要在下一个版本之前补拖过一个版本历史数据就永久缺失了。从那以后我每次看到“度量指标”四个字都会先问三句这条数据谁填、填完谁看、看了改什么。三问答不上来的指标一律不进表。希望帮到你。本文还有配套的精品资源点击获取