企业官网建设流程全解析

简介：这是一份系统讲解华为IPD集成产品开发流程的PPT课件，聚焦客户需求管理（OR）这一核心主线，面向产品经理、研发主管、项目总监及流程变革人员，帮助解决需求来源分散、紧急需求占比高、版本交付质量不稳定等问题。课件共1个pptx文件，大小6.18MB，内容按四天培训结构组织，覆盖客户需求管理、市场管理流程、预测流程、IPD管理体系、任务书开发、概念计划阶段、系统设计、业务计划开发、开发验证发布阶段、产品开发营销计划、生命周期阶段及IPD客户化流程。在此基础上，还系统梳理了产品包需求、需求分析与跟踪、需求变更控制、需求度量指标、MARKET管理流程、PDT/PCR、C-PM/RMT、需求承诺电子流、需求分析团队与需求质量监督等20个关键知识点；预览中更包含端到端需求管理框架、PMT/RAT/RMT组织协同和CCM客户需求承诺经理职责等实战细节，可直接用于华为IPD流程导入、内部培训和需求管理体系搭建。目前已有4830人学习下载，适合需要深入理解IPD运作逻辑或落地需求管理机制的学习者。

1. IPD的知识地图：从需求黑洞到产品上市的一条主线

华为IPD流程管理这套体系，最容易看反的地方在于：它最核心的模块不是产品开发流程，而是客户需求管理。翻开这份完整版PPT的索引，第一块内容就是OR（产品包需求）流程，开篇引用了公司创始人的一段话——"满足客户需求是我们生存的唯一理由""我们的商业模式是以客户需求为导向"。这不是口号，而是整套流程设计的出发点。把十三个模块摊开看，其实只有一条主线：OR把四面八方涌进来的需求收拢成有优先级的输入，MM从市场机会里选出值得做的方向，IPD再把选择变成产品，生命周期负责让产品在上市后持续创造价值。这份完整版本身就是一次DRY RUN培训的索引，从客户需求管理一路排到度量指标。适合正在系统学IPD的人，也适合备考前想快速搭框架的人。下面是按这条主线拆出来的复习笔记。

2. OR需求管理：为什么"满足客户需求"要先有一套流程

IPD的开篇模块既不是概念决策评审，也不是项目计划，而是OR。OR是Offering Requirement（产品包需求）的缩写，这个项目是在外部咨询顾问指导下开展的FE项目之一，目的非常明确：统一需求管理；主动收集需求，准确把握市场机会点；降低紧急需求比重，提升版本交付质量。这三点是整章复习的锚点——所有关于OR的考点，最后都能归到这三条目的上。

2.1 为什么是OR：一场多方混战倒逼出的统一需求管理

先看需求没有被管理时会乱成什么样。PPT里画了一个多角色冲突场景：市场销售人员和用服人员催促"这个缺陷不及时处理，问题会很严重"；领导层已经向客户承诺"下个版本一定支持广播功能"；研发人员被夹在中间，需求实现延迟、理解错误，焦头烂额；客户则在质问"你们说3月提供XX功能，怎么到了6月还没出来"。这是很典型的"需求黑洞"：渠道太多、口径不一、承诺随意，最后谁都说不清需求到底算不算数、什么时候交付、谁对结果负责。

OR流程就是为治这个乱象而生的。它要解决的不只是"把需求记下来"，而是把需求管理变成一条有组织、有角色、有电子流、有验证关卡的端到端流程。梳理下来会发现，OR在整套IPD体系中的位置很特别：市场管理（MM）流程负责定路标和任务书（Charter），IPD流程负责把任务书变成产品，而OR流程相当于两者之间的"需求中转站"——业务计划、产品包需求、紧急产品需求都要从OR这里流出去。换句话说，没有OR，MM和IPD拿到的需求就是一堆未经整理的口头承诺。

复习时需要记住一个关键判断：OR不仅仅是"收集需求"，它的价值在于"统一"和"主动"两个词。统一意味着所有渠道的需求都进同一个管理框架；主动意味着不等客户投诉才补需求，而是提前通过行业分析、展览、杂志等外部渠道捕捉机会点。这两点直接对应OR三条目的中的前两条。

2.2 端到端流程框架：把来源、动作和出口一次看懂

OR的端到端框架可以拆成六个环节：确定来源 → 收集 → 分析 → 实现 → 验证 → 分发。先看来源，这是最容易被忽略但考试最爱考的输入侧。来源分外部和内部两类，PPT明确列出：

这一组来源要和"价值需求"这个概念连着记：收集环节强调"收集价值需求、外部需求、内部需求"，也就是说不是所有需求都值得收，先判断有没有价值。分析环节是整条流程里动作最多的一段，分两层：需求过滤（解释、过滤、检视）和需求分析（分类、排序、证实）。最容易漏的是"证实"——需求进了分析阶段，不代表它就是真的、可实现的，还需要跟客户或内部对齐证实，否则后面开发阶段很容易返工。

实现环节的出口有三条：纳入业务计划/路标、纳入PDT Charter（任务书）、提出PCR（产品变更请求）。这三条出口把OR和下游流程串了起来——需求要么进入路标规划，要么变成任务书启动开发，要么作为变更插入正在开发的产品。验证环节则对应测试需求的验证和确认，做到一般可获得性（GA），其中RAT要参与TR评审，同时做需求早期确认、例行需求确认和需求常规确认三类活动。

分发环节是很多人看漏的地方：需求分析完不是自动进入开发，而是要分发决策到PMT/RAT、各功能部门、SEG、IPMT/PMT、PDT/TDT/平台等不同角色，PDT/TDT在项目范围内承接。复习时建议把这六个环节连成一句话默写：来源要分内外，收集要有价值，分析先过滤后排序，实现走业务计划、Charter、PCR三个出口，验证靠TR评审和三类确认，分发要按组织层级找对人。

2.3 需求承诺电子流与CCM：闭环的关键在"逆向回路"

需求承诺电子流是OR流程落地最重要的载体，复习时先看懂它的总体结构：处理需求时，流程是自上而下的（收集→分析→实现→验证→分发），但它同时又是一条自下而上的逆向流程——PDT接到任务单后如果无法完成任务，要提请变更，再往回走验证确认。这层"逆向回路"就是需求管理最容易翻车的地方：很多人只记得需求从前端往后端推，忘了后端完不成时还有一条变更回路。

电子流的主要活动依次是：录入 → 预审 → PMT/RAT分析并给出结论 → 客户早期确认 → 下发PDT任务单 → 分发 → 检查任务是否完成 → 验证。其中"客户早期确认"放在PDT动手之前，这是需求承诺能不能闭环的第一道闸门。配套的验证确认子流程把需求逐层细化：客户所想所需 → 产品包需求 → 设计需求 → 产品规格书 → 开发需求 → 测试需求，越往后越接近可实现的规格。

与电子流强相关的还有销售项目的需求管理原则，这里有三条硬规矩值得单独划重点：

1. 需求承诺的接纳和处理责任主体是各RMT，今后各PDT无权接受来自全球产品行销体系、国际国内销售体系、全球技术服务体系直接反馈的需求。
2. 所有需求承诺必须录入客户需求/承诺电子流，邮件、电话、传真等方式只作为必要的沟通手段。
3. 所有对外答复必须以面向市场发布的产品功能清单为基础（也包括市场技术指导书、业务签单附件等）；功能清单未包含的需求，必须经过RMT给出答复口径，才能对外答复和承诺。未经RMT批准的答复和承诺，各产品线不承担提供责任；发生投诉时由代表处、办事处自行负责。

这三条原则合在一起，本质是把"对外承诺权"收拢到RMT。哪怕研发觉得某个需求技术上完全可行，也不能绕过RMT直接答复客户，这是OR和普通需求池管理最大的区别。

CCM（客户需求承诺经理）这个角色是为销售项目设的接口人，设在PL-MKTG和地区部MKTG。它的职责五条，可以按时间轴串起来记：投标阶段受理标书不满足项，推动RMT答复和给解决方案；投标过程中把需求录入电子流并负责闭环管理；合同签订后监控需求承诺开发状态，有交付风险时组织RMT、PDT、产品经理解决；进入新国家或新运营商项目时，推动把接口规范、网管规范、与网上设备互联互通的需求调查清楚并录入电子流。从投标到交付，CCM始终是"需求承诺"这条链上唯一对口的协调人。

提示：销售项目需求管理的三条原则里，最后一条的后果最容易被忽略——未经RMT批准的承诺，各产品线不承担提供责任。这意味着口头答应客户"可以做"，最后可能没人认账。

3. MM市场管理：IPD上游的机会选择与业务计划引擎

如果说OR解决的是"需求怎么收"，那MM解决的就是"机会怎么选"。MM（市场管理）是IPD的上游流程，它用一套严格的方法对广泛的市场机会进行选择收缩，最终输出可执行的业务计划。这一章的复习重心不在流程细节，而在业务计划框架和MM与IPD的交接关系上。

3.1 MM是什么：对广泛机会做"选择收缩"

MM的定义可以拆成三个层次。第一，它是一套系统方法，目的是对广泛的机会进行选择收缩，制定以市场为中心的、能带来最佳业务成果的战略与计划。第二，它是核心流程之一，要求用严格规范的方法分析市场走势及客户要求，创建合理的市场细分规则，对要投资和取得领先地位的细分市场进行选择和优先级排序，制定可执行的业务活动。第三，它是业务计划的源头，通过定义市场营销取得成功需要执行的活动，制定可盈利、可执行的业务计划，驱动新产品包的开发。

三个层次对应三个关键词：选择收缩、市场细分、业务计划。MM不是"什么市场都做"，而是先分清楚哪些细分市场值得投、哪些该放弃，再把资源压到有领先机会的地方。这个过程在流程上体现为五步：理解市场 → 进行市场细分 → 组合分析 → 制定业务战略和计划 → 管理业务计划、评估绩效。这五步可以对应"现在在哪里、如何到达目的地、向哪里进发、是否做得对"四个问题来记。

MM最主要的输出就是业务计划，其他输出如产品项目组合、产品线路标、任务书，都是从业务计划派生出来的。复习时把"业务计划是MM的核心交付物"这句话记住，整章的重心就不会偏。

3.2 业务计划框架：五部分、四问、两组要素

业务计划框架是MM章最可能出大题的地方，它的结构是固定的五大部分：

注意III部分的两组要素：核心要素是产品包、定价/条款、分销、集成营销沟通，这些直接决定产品怎么定义、怎么定价、怎么卖；操作性要素是支持和订单履行，决定产品卖出去之后能不能真正交付。复习时容易漏的是把"集成营销沟通"归到操作性要素里，它是核心要素，不是后勤杂事。

四个问题里，"我们如何到达目的地"对应可选战略方案的分析：市场渗透、市场拓展、产品包开发、多样化，重点判断哪种方案最好；然后定目标（计算出业务目标）、定战略（选择目标市场细分、确定合适定位）、定方法（按客户$APPEALS的要素划分战术）。"计划缺口有多大"这个问题常被跳过——愿景和使命与现实之间的差距，正是业务计划要填的洞。

3.3 MM与IPD的关系：任务书是交接棒

MM和IPD的关系，一句话就能说清：市场管理的使命是确定公司为获取市场成功应开发什么产品，并启动IPD流程；MM是IPD的上游流程，包括组合策略和路标制定、制定任务书，然后启动IPD。在流程图上，MM做的是"理解市场→细分→组合分析→制定业务战略和计划→管理业务计划评估绩效"，最后输出一个判断：这个方向要不要立项？如果Y，就下发任务书；如果N，就停在规划层面。

任务书（Charter）就是MM交给IPD的"交接棒"。IPD流程拿到任务书后，才进入概念、计划、开发、验证、发布、生命周期六个阶段。反过来说，IPD不是自己决定做什么产品，而是承接MM的选择结果。很多人在复习时把OR、MM、IPD当成三段独立的知识点背，实际上它们是一条链：OR提供需求输入，MM做机会筛选和优先级排序，IPD做产品实现。这条链上任何一个环节断了，下游都会空转。

3.4 PMT组织：参谋机构，不是决策机构

承接MM流程的组织是PMT（组合管理团队）。PMT与PDT类似，是跨部门团队，但定位完全不同——PMT是IPMT的参谋机构，向IPMT汇报，支撑部门是PL-Marketing；C-PMT是IRB的参谋机构，向IRB汇报，支撑部门是战略与规划部。一句话：PMT是出方案的，不是拍板的。

PMT的组成非常典型，复习时可以按职能分组记忆：

• 规划侧：主任、业务规划、市场分析、需求管理
• 市场侧：S-PMT代表或解决方案管理、大客户Marketing代表、区域Marketing代表、国内/国外销售部代表
• 专业侧：预测、定价、技术规划、预算/损益、技术服务、订单履行/制造/采购、HR、OPS、执行秘书

这里有一组容易记混的差异：C-PMT和PL-PMT角色组成基本相同，但有细微差别——C-PMT中有S-PMT代表和产品线PMT代表，PL-PMT中有解决方案管理角色和产品族代表。换句话说，中央层面的PMT更强调"各产品线之间的协同"，产品线层面的PMT更强调"解决方案和产品族落地"。考试如果问两个PMT的区别，答出"S-PMT代表 vs 解决方案管理角色"这一条就能得分。

4. 易漏点复盘：流程衔接、角色职责与承诺电子流的三类翻车现场

这一章把前面两章最容易错、最容易漏的点集中在一起复盘。我按"易漏点 → 为什么漏 → 怎么补"的结构整理六条，覆盖流程衔接、角色职责和承诺管理三个面。

4.1 流程衔接的两个易漏点：OR与MM的边界、MM与IPD的交接

易漏点一：把OR当成IPD里的一个环节，忽略了它是独立流程。为什么漏：OR的验证、分发活动和IPD的概念、计划阶段在时间上有重叠，看起来像同一件事。怎么补：用输入输出关系区分——OR输出的是"产品包需求、业务计划/路标更新、PDT Charter、PCR"，这些是供给下游的输入；IPD输出的是产品本身。OR是把需求变成可执行的输入，IPD是把输入变成产品。

易漏点二：把MM的市场细分和OR的需求分析混为一谈。为什么漏：两边都在做客户分析，术语还长得像。怎么补：记一句话——MM决定"做哪些市场"，OR决定"做哪些需求"。MM做的是细分市场选择和优先级排序，OR做的是产品包需求的分类、排序和证实。两件事在同一根链条上，但对象完全不同。

4.2 角色职责的两个易漏点：PMT是参谋、RMT是需求的归口

易漏点三：把PMT当成决策机构。为什么漏：PMT听起来像"管理团队"，名字里带Management，容易被误认为有拍板权。怎么补：背组织关系——C-PMT是IRB的参谋机构，PL-PMT是IPMT的参谋机构，都向各自的决策层汇报，真正拍板的是IRB和IPMT。PMT LEADER虽然属于PMT成员之一，但他解决的是与MM流程的衔接，而不是决策。

易漏点四：搞不清RMT、RAT、RQA、CCM各自干什么。为什么漏：缩写太多，全是R开头的团队，背了就忘。怎么补：按职责层次记——RMT是需求管理团队，是承接需求承诺的责任主体；RAT是需求分析团队，做分析和结论；RQA是需求质量监督，盯质量；CCM是客户需求承诺经理，是销售项目的接口人。四条线各管一段：RMT管归口、RAT管分析、RQA管质量、CCM管接口。PL-RMT和PL-RAT是产品线层面的对应团队，R-RMT是地区部的需求管理团队。

4.3 承诺管理的两个易漏点：口头答复、电子流不闭环

易漏点五：PDT直接答复销售或客户提出的需求承诺。为什么漏：研发最懂技术，销售最容易直接找研发"帮忙看一眼能不能做"，一开口就变成变相承诺。怎么补：背三条铁律——所有需求承诺必须录入电子流；对外答复以产品功能清单为基础；未经RMT批准的答复和承诺，各产品线不承担提供责任。PDT可以评估可行性，但不能对外承诺。

易漏点六：需求承诺电子流走到"分发"就以为闭环了。为什么漏：电子流的正向流程（收集→分析→实现→验证→分发）看起来在分发处就结束了，但实际的逆向回路没有画在显眼位置。怎么补：记住电子流同时是自上而下和自下而上的——PDT无法完成任务时要提请变更，验证环节还要回到客户早期确认。检查一张电子流是否闭环，要看三点：任务单是否下发、完成状态是否验证、变更是否走PCR。

注意：以上六条里，后果最重的是第五条——未经RMT批准的承诺，各产品线不承担提供责任。这意味着任何绕过电子流的口头承诺，一旦出问题，承诺人自己扛。

5. 复习清单：用一条主线、四套组织、五段流程自测查漏

复习到最后，建议把笔记合上，按下面三步做一次"空手默写"。

第一步，画一条主线：OR（需求管理）→ MM（市场管理）→ IPD（产品开发）→ 生命周期。边上标注三个衔接点：OR的出口是业务计划/路标、PDT Charter、PCR；MM的出口是业务计划、产品线路标、任务书；IPD的起点是任务书。画不出衔接点，说明流程之间是断开的，回看第2.2节和第3.3节。

第二步，默写四套组织：决策层（IRB、IPMT）、参谋层（C-PMT、PL-PMT，注意它们的支撑部门和成员差异）、需求管理层（C-RMT、PL-RMT、R-RMT、PL-RAT、RQA）、执行层（PDT、TDT）。重点检查两条关系：PL-PMT是IPMT的参谋机构；PMT LEADER属于PMT成员之一，负责和MM衔接。默写时把CCM放在"销售项目接口人"的位置上单独标出来。

第三步，用八问自测清单逐项过，答不出来的就是漏洞：

查漏补缺时优先回看三处：一是电子流的逆向回路（PDT完不成任务怎么办），二是RAT参与TR评审的时机（验证环节，不是开发环节），三是未经RMT批准的承诺后果（各产品线不承担提供责任）。这三处是提问频率最高、也是平时最容易一带而过的地方。

我第一次复习这套内容时，流程图背得滚瓜烂熟，结果被问"PDT能不能直接答复客户需求"，一下就卡住了——因为我把全部精力都放在了正向流程上，完全没注意到承诺权和角色边界才是IPD真正管得最严的地方。从那以后，我每次复习都强制自己先默写角色和职责表，再走一遍流程主线，最后才看细节。希望帮到你。

本文还有配套的精品资源，点击获取