企业官网建设流程全解析

简介：围绕华为IPD流程管理的培训课件，面向产品经理、需求管理人员及研发流程建设者，系统梳理以客户需求为核心的端到端管理框架。内容从OR（Offering Requirement）流程切入，覆盖需求收集、分析、实现、验证与分发各环节，并延伸到需求承诺电子流、CCM角色职责、PMT、RMT、RAT组织体系、PDT与PCR协作、市场管理流程、任务书开发、生命周期阶段及IPD度量指标等知识点，配有培训材料索引与流程示意，便于按章节对照学习。整包仅含1个pptx文件，约6.18MB，结构集中、翻阅方便，适合作为内训讲义或流程梳理参考。目前已有4840人学习，可帮助读者快速建立IPD需求管理的整体认识，理解需求承诺、变更控制与跨部门协同的落地方式。

1. 一份 159 页的 IPD 流程管理手册，真正能被用的是哪几页

接手这份 IPD 5.1 完整版 PPTX 时，我第一反应是又一个拿来念稿的材料。翻到第 10 页那张四天 DRY RUN 日程表，看法变了：它把客户需求管理、市场管理流程、预测流程、任务书开发、概念到生命周期各阶段流程、IPD 客户化流程、度量指标全部编了页码区间，这是一份演练教材——让一条新组建的产品线在真跑项目之前，先把需求电子流、任务书、阶段评审在纸面上空跑一遍，把卡点暴露在没代价的时候。它解决的不是「IPD 是什么」，而是「我们这条线到底哪一步会卡」。适合产品经理、需求管理岗、流程与质量岗、研发项目经理，尤其适合正把需求从邮件和口头承诺里往外捞的团队。

2. 端到端需求管理：OR 五段闭环与需求承诺电子流怎么落

2.1 需求为什么会烂在邮件里：四个角色的错位现场

手册前几页画了一个特别真实的场面：销售已经在客户面前承诺下个版本支持广播功能，用服在现场发现缺陷往上抛，说这个问题不及时处理会很严重，研发这边焦头烂额，客户那边质问「你们说 3 月提供 XX 功能，怎么到 6 月还没出来」。四条线上每个人都在做自己认为对的事，合起来的结果是两件事：需求实现延迟、需求理解错误。

OR 就是冲着这个来的，Offering Requirement，产品包需求。它给自己定了三个目标：统一需求管理、主动收集需求、降低紧急需求比重、提升版本交付质量。注意第三条的措辞——「降低紧急需求比重」不是靠催研发催出来的，而是靠前端主动收集换来的。紧急需求占比高，本质上是需求管理缺位：平时没人系统性收集，需求就只能以事故的形式出现。

这套流程在位置上也很清楚：市场管理（MM）流程往下走是路标和任务书（Charter），任务书进 IPD；OR 横跨在中间，向上承接业务计划，向下把需求拆成产品包需求、紧急产品需求，分发给 PDT 和版本规划。搞不清这个位置，就很容易把 OR 做成一个「需求登记表」，登记完就没人管。

2.2 五段闭环：收集、分析、实现、验证、分发

手册把端到端需求管理拆成五段，每段都有明确的输入输出和责任人。照着这张表去对，绝大多数团队能立刻发现自己少的是哪一段。

两个细节值得单独拎出来。第一，「解释」排在「过滤」前面，顺序不能反。很多团队一上来就砍需求，砍完发现砍掉的是自己没读懂的那条。第二，验证不是发布前的那一次验收，手册里写了三种确认节奏——需求早期确认、例行需求确认、需求常规确认，而且是「一般可获得性（GA）」之前的持续动作。这一条如果只做最后一次，前面所有环节的错误都会在发布前一次性爆发，那时候已经没有后悔药了。

分发这一段最容易做成黑匣子。手册里明确列了四类去处：进业务计划/路标、进 PDT 的 Charter、走 PCR 变更、直接加入正在开发的产品。四条路的决策主体不一样，混着走的结果就是需求去哪儿了没人说得清。

2.3 需求承诺电子流：把邮件、电话、传真挡在门外

手册里对需求入口的约束写得非常硬，几乎是整份材料里执行性最强的几条：

• 需求承诺的接纳处理责任主体是各 RMT，PDT 无权直接接受来自销售体系（各产品行销处、各地区部产品行销部）、销售体系（各代表处、办事处）、技术服务体系直接反馈的需求；
• 所有需求承诺必须录入客户需求/承诺电子流，邮件、电话、传真只能作为必要的沟通手段，不能作为需求载体；
• 所有对外答复必须以面向市场发布的产品功能清单为基础，功能清单没覆盖的需求，必须由 RMT 给出答复口径才能对外说；
• 未经 RMT 批准的答复和承诺，产品线不承担提供的责任；发生客户投诉时由代表处、办事处自行负责。

这套规则的价值不在于「多了一道审批」，而在于把承诺权收回到一个有跨部门视野的位置上。为了避免这个位置变成瓶颈，手册设了 CCM 这个角色——客户需求承诺经理，在 PL-MKTG 和地区部 MKTG 设置，作为面向销售项目的需求管理接口人。它的职责清单可以直接抄：负责投标到交付阶段的客户需求承诺管理；受理投标项目组提交的标书不满足项和需求；监控并推动 RMT 给出答复、承诺、解决方案和技术资料；把需求录入电子流并做闭环管理；合同签订后监控开发状态，有交付风险时组织 RMT、PDT、产品经理解决；新进入某国家或某运营商的项目，推动地区部把接口规范、网管规范、互联互通相关需求调查清楚再录入。

电子流单子本身建议固定字段，别让每个项目自己发明：

电子流本身是「自上而下发起、自下而上逆向流转」的：收集、分析、实现、验证、分配五个环节往前走，但遇到 PDT 无法完成任务的情况要提请变更，往回走。所以流程设计上必须留回退路径，不能只画单向箭头。

2.4 分发决策：一次会议把需求分到四个去处

分发不是一个动作，是一次带结论的评审。手册给出的决策主体分布是：市场管理与产品线路标规划走 PMT/RAT，各功能部门走 PMT/RAT/SEG，Charter 与 PCR 走 IPMT/PMT，开发实现走 PDT/TDT/平台/其他，验证走 PDT/TDT。

实操上我一般会把它压成一次固定节奏的需求分发会，会前 48 小时把待分发清单发出去，会上只做四选一：进路标、开 Charter、走 PCR、并入在研版本。每个选项对应一句结论和一个责任人，散会前必须落进电子流。四选一之外的状态只有两个——退回补充信息、拒绝并记录理由，不允许出现「再看看」。

拒绝也必须留痕，这是血泪经验。需求被拒之后没有记录，三个月后同一个需求从另一个渠道再进来一次，重新分析一遍，浪费的是两拨人的时间。

3. 市场管理流程：五个动作把「机会」变成可执行的任务书

3.1 上游卡不住，下游全是返工：MM 与 IPD 的接口

手册对市场管理的定义是：一套系统的方法，用于对广泛的机会进行选择收缩，制定出以市场为中心、能带来最佳业务成果的战略与计划。它做的事是三件——分析市场走势与客户需求、创建合理的市场细分规则、对要投资和取得领先地位的细分市场做选择和优先级排序，最后输出可执行的业务活动。

它和 IPD 的关系是上下游：市场管理流程是 IPD 的上游，负责组合策略和路标制定、制定任务书、启动 IPD 流程。反方向上，IPD 各阶段把客户反馈、竞争对手信息、技术趋势、目前产品组合回灌给 MM。这条回灌线如果断了，路标就会变成一年一版的拍脑袋规划，第二年发现全部对不上。

手册里那句定位讲得很准：市场管理的使命是确定公司为获取市场成功应开发什么产品，并启动 IPD 流程。注意是「应开发什么」，不是「能开发什么」。这两者的差别，就是路标规划会和研发排期会的差别。

3.2 五个动作跑完一轮 MM

这套东西看起来是战略语言，落地时会卡在第三、四个动作之间：组合分析做完了，谁来决定砍掉哪个细分市场？手册的答案是 PMT 提方案、IPMT/IRB 决策，PMT 是参谋机构、IPMT 是决策机构。这条线如果不清晰，组合分析就会做成一份没人敢签字的 PPT。

3.3 业务计划的五段骨架与 $APPEALS

手册把业务计划拆成五段，并配了三个追问，我把它整理成下面这样更好用：

战略选项在手册里列了四条：市场渗透、市场拓展、产品包考虑、多样化。选哪条不是重点，重点是选完之后要能说清「为什么不是另外三条」。

「我们如何到达目的地」这一段里，手册要求按客户 $APPEALS 的元素划分战术。常见的八个维度是价格、可获得性、包装、性能、易用性、保证、生命周期成本、社会接受程度。我一般会让团队在业务计划里对每个维度写一句「客户当前期望」和一句「我们现状」，两句话对不上的地方就是产品包需求的来源。这比直接从竞品功能表抄一份需求清单靠谱得多，因为抄来的是别人的答案，$APPEALS 问的是自己的问题。

3.4 细分市场打分：把「感觉这个市场不错」变成可排序的表

组合分析最容易变成玄学的地方是「吸引力」。给一张固定维度、固定权重、固定打分的表，配合季度复盘，至少能保证每次判断的口径一致：

打分只用 1～5 分，不给中间小数，逼着打分人做判断。分数出来之后不要急着排序，先看一眼有没有哪个细分市场在「技术就绪度」上拿了 1 分却排在前三——那就是典型的靠想象力做规划。

4. 组织与角色：PMT、RMT、PDT 的接口怎么切

4.1 PMT 的席位表：一个跨部门团队该坐哪些人

手册给的 PMT 组成是这份材料里最可抄作业的部分之一，直接列了席位：主任、业务规划、市场分析、需求管理、S-PMT 代表或解决方案管理、大客户 Marketing 代表、区域 Marketing 代表、国内/国外销售部代表、预测、定价、技术规划、预算/损益、技术服务、订单履行/制造/采购、HR、OPS、执行秘书。

C-PMT 和 PL-PMT 的组成基本相同，但有细微差异：C-PMT 中有 S-PMT 代表和产品线 PMT 代表，PL-PMT 中有解决方案管理角色和产品族代表。支撑部门也不一样，C-PMT 的支撑部门是战略与规划部，PL-PMT 的支撑部门是 PL-Marketing。组织结构上，C-PMT 是 IRB 的参谋机构，向 IRB 汇报；PL-PMT 是 IPMT 的参谋机构，向 IPMT 汇报。

席位表的实际用处是查漏。我见过最常见的问题是「预测」和「订单履行/制造/采购」两个席位长期空缺，结果业务计划里的销量预测是市场拍的，交付能力是研发猜的，两边在评审会上第一次对账。另外，执行秘书这个席位看着不起眼，但它是会议决议能不能落地的关键——没有固定的人做记录和跟踪，PMT 会开成月度座谈会。

4.2 RMT、RAT、RQA 与 CCM：四层需求管理组织怎么切

手册列的需求管理组织体系是：C-PMT、C-RMT、PL-RMT、R-RMT（地区部需求管理团队）、RAT（需求分析团队）、RQA（需求质量监督）。这几个缩写的区别如果不在文档里写清楚，新人第一周就会晕。

这张表里最关键的一行是 PDT 那行。手册原文写得很明确：今后各 PDT 无权接受来自全球产品行销体系、国际国内销售体系、全球技术服务体系直接反馈的需求。这条规则在纸面上很清楚，执行起来会被「客户很急，先答应了再说」冲垮。所以配套的必须是 CCM 这条通道要足够快——如果走正规电子流要两周才有答复，一线一定绕开它。

4.3 Charter 任务书：立项前必须钉死的几件事

任务书是从路标进入 IPD 的闸门。手册把 Charter 放在 MM 与 IPD 的交界处，意思是它由市场侧发起、由开发侧承接。一份能用的任务书，我通常要求至少钉死这几项：

最后一项经常被省略，然后项目结项会上所有人对「算不算成功」各说各话。

4.4 阶段流程与评审点：从概念到生命周期

手册的课程结构里，阶段流程占了很大篇幅：概念、计划阶段流程，系统设计与概要设计，业务计划开发，开发、验证、发布阶段流程，产品开发营销计划流程，生命周期阶段流程。这些阶段与决策评审点、技术评审点是配套的，常见做法如下：

阶段评审的价值不在于「签字」，而在于它是一个强制停下来的时点。没有这个时点，需求变更会一直往后拖，直到拖进验证阶段，然后所有人都很难受。

5. 避坑与排查：DRY RUN 演练里最容易翻车的五处

5.1 电子流建了单，闭环率却低得离谱

现象：电子流上线三个月，单据数量不少，但状态停在「待分析」的占了一大半，销售那边反馈「录了也没人管」。

原因：不是流程设计问题，是分发环节没有回执机制。需求录进去之后，谁接手、什么时候给结论、结论是什么，全靠人盯。手册里那套 RMT 受理、CCM 推动的分工，如果没有落到单据状态上，就只是一句话。

解决：把电子流状态机固定成六态——待分析、已分发、开发中、已验证、已关闭、已拒绝，每个状态变更必须带责任人和时间戳；每周出一次超期清单，超期 7 天自动升级到 RMT；拒绝也必须填理由并通知提交人，否则提交人会换渠道再提一遍。

5.2 紧急需求占比不降反升

现象：OR 流程跑了两个季度，紧急需求占比从 40% 涨到 55%，版本交付质量没改善。

原因：只做了「接收」，没做「主动收集」。手册里 OR 的目标之一就是主动收集需求、准确把握市场机会点，如果团队只是把原来邮件里的需求搬进电子流，紧急需求一条没少，只是换了个地方排队。另外，优先级排序如果按「谁嗓门大」来，紧急需求永远赢。

解决：把收集环节的来源清单真正跑起来，行业分析、友商、展览、杂志、预研这些内部外部来源定期出需求，别只等客户提；同时给紧急需求设配额，比如每个版本不超过总量的一定比例，超出的必须由 RMT 集体决策并记录理由。配额是硬约束，比讲道理管用。

5.3 DRY RUN 开成了 PPT 朗读会

现象：三天的演练，前两天半在念材料，最后半天大家说「收获很大」，回到项目上该怎么做还怎么做。

原因：演练没有输入物。手册的日程表是按材料内容排的（客户需求管理、市场管理流程、预测流程、任务书开发流程、各阶段流程、客户化流程、度量指标），如果照本宣科念，就是听课。演练的本质是拿一条真实或半真实的产品线，把流程走一遍。

解决：演练前先备好三样东西——一条真实产品线的路标草案、一份待评审的任务书草稿、一个待分发的需求清单。三天里至少留一天半做分组实操：第一组做需求分发四选一，第二组写任务书，第三组按阶段评审点做一次模拟评审。每组出结论，全员点评。演练的输出不是心得体会，是三个可以直接用的文档。

5.4 答复口径不一致，同一个需求对外说了三种说法

现象：客户从销售、用服、技术支持三个渠道问同一个需求，拿到三个不同的时间点，最后投诉到高层。

原因：对外答复没有锚定在功能清单上。手册的规则很清楚：所有对外答复必须以面向市场发布的产品功能清单为基础，功能清单未包括的需求，必须经过 RMT 给出答复口径才能对外答复和承诺。实际执行时，功能清单更新滞后，一线拿不到最新版本，只能凭印象说。

解决：把功能清单当成一个受控文档管理，版本号、发布日期、责任人固定，每次 RMT 结论出来 48 小时内更新；CCM 在投标阶段就把标书不满足项汇总成跟踪表，逐条推 RMT 给口径。答复模板统一成三句话：现在支持什么、什么时候支持、不确定的部分由谁跟进。

5.5 度量指标口径打架，数据谁都不认

现象：季度复盘会上，市场说需求平均响应时间是 5 天，研发说是 21 天，两个数字都有出处。

原因：统计口径不同。市场侧算的是「录入到首次答复」，研发侧算的是「录入到关闭」，中间差了分析、分发、实现三段。手册里 IPD 度量指标这一块之所以单独占一个章节，就是因为口径不统一时，指标会变成吵架工具。

解决：每个指标写清四件事——起点事件、终点事件、统计对象、数据来源系统。定完之后至少冻结两个季度再调，中途改口径等于把历史数据全部作废。

6. 把 159 页压成一张自检表：指标口径与一次演练的排法

手册最后那块度量指标，翻起来最枯燥，用起来最值钱。我的做法是先定指标，再定检查项，最后把检查项做成一份能勾的表。

先看指标口径怎么定，下面这张表是按常见实践整理的，具体阈值要按自己产品线的历史数据校准，别照抄数字：

指标定完之后，把流程要求翻译成检查项。我一般存成一个 yaml，跟着项目走，评审前逐条勾：

# IPD 流程运行自检表（按阶段勾选，未通过项必须写原因和责任人） demand_management: - id: OR-01 check: 需求是否全部通过电子流录入，无邮件/口头承诺 stage: 收集 - id: OR-02 check: 每条需求是否有来源标记和原始描述（未经二次加工） stage: 收集 - id: OR-03 check: 分析结论是否经过检视，过滤理由是否记录 stage: 分析 - id: OR-04 check: 分发是否四选一（路标/Charter/PCR/在研版本）且有责任人 stage: 分发 - id: OR-05 check: 对外答复是否引用功能清单条目或 RMT 口径 stage: 答复 market_management: - id: MM-01 check: 目标细分市场是否有打分表与权重说明 stage: 组合分析 - id: MM-02 check: 业务计划五段是否齐全，风险评估是否有结论 stage: 业务计划 charter: - id: CH-01 check: 任务书是否含市场机会、产品包定义、财务预测、里程碑 stage: 立项 - id: CH-02 check: 验收标准与度量口径是否在立项时确定 stage: 立项 review: - id: RV-01 check: 阶段评审是否有决策结论（继续/调整/终止），而非仅签字 stage: 各评审点

这份表的价值在于它把「流程执行得好不好」从主观判断变成了可勾选项。勾不上的地方就是下一轮要改的地方，不用开会讨论感受。

再看一次三到四天的 DRY RUN 怎么排。手册给的日程是按天分块的：第一天客户需求管理、市场管理流程、预测流程；第二天 IPD 管理体系、任务书开发流程、概念与计划阶段流程；第三天系统设计与概要设计、业务计划开发、开发验证发布阶段流程；第四天产品开发营销计划、生命周期阶段流程、IPD 客户化流程、度量指标。照着念四天，效果一定差。我的排法是压缩讲授、放大实操：每天上午两小时讲材料，下午分组做事，最后一天下午只做一件事——把三份产出（需求分发结论、任务书草稿、评审问题清单）过一遍，明确谁在什么时候补完。

从那以后我每次拿到这类流程手册，都强制走一遍同样的动作：先找到日程表和页码索引，确认它想让人练什么；再抽出五段闭环和角色表，对一遍自己团队缺哪一环；最后把缺的那一环做成一张能勾的表。不做这三步，手册就只是 PPT。希望帮到你。

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