企业官网建设流程全解析

简介：这是一份系统讲解华为集成产品开发（IPD）流程管理的完整版PPT，适合企业研发管理人员、产品经理、项目经理及流程改进人员学习。内容围绕客户需求管理这一IPD核心展开，逐项介绍了OR流程、产品包需求、需求分析、需求跟踪、需求变更控制、需求度量指标，以及IPD管理体系、任务书开发流程、生命周期阶段流程、IPD客户化流程，并梳理了PDT、PCR、C-PM、RMT等关键组织与概念；同时结合IPD 5.1 DRY RUN培训材料，覆盖客户需求管理、市场管理流程、预测流程、任务书开发流程、概念/计划/开发/验证/发布等端到端阶段，特别对需求承诺电子流和客户需求承诺经理（CCM）的职责做了展开说明。整份资源为1个pptx演示文稿，压缩包约6.18MB，便于直接演示和对照学习。目前已有4830人学习下载，是一份结构完整、偏实操讲解的IPD流程学习资料。

1. IPD到底是什么：先看懂这套产品开发的总流程

“说好3月提供XX功能，怎么到了6月还没出来？”在IPD流程里待过的人，对这句话都不会陌生。它背后是一连串熟悉的场景：销售为了拿单，拍胸脯答应客户“下个版本一定支持”；客服被客户追问，只能两头传话；研发被临时需求反复打断排期，越赶越乱；到最后谁都没错，但功能就是没交付。问题的根源不在某个人的态度，而在于缺少一套流程去回答“需求怎么进来、谁拍板、按什么节奏交付”。

IPD，全称Integrated Product Development，集成产品开发，就是为了解决这类问题而生的管理体系。它把产品从想法到退市的完整链条装进一个统一框架：需求统一管、市场先想清、开发分阶段、决策有评审。无论你是产品、研发还是项目管理岗位，看懂IPD，就相当于拿到了产品开发的一张总地图——之后再看任何关于需求、版本、立项的争论，你都能立刻知道它们发生在哪一环、为什么存在。

2. OR需求管理：为什么所有承诺都要走统一入口

如果只抓一个细节来理解IPD，我建议先看需求管理。原因很简单：产品开发所有的乱，几乎都先乱在需求上。

2.1 一个需求四个来源：市场、销售、服务、预研都在“喊话”

在没有统一需求管理的团队里，需求是这样进来的：市场人员参加完展会，带回来一个“行业趋势”；销售在客户现场被问到一个功能，当场答复“下个版本肯定有”；服务工程师处理故障时，发现用户真正想要的其实是一个更易用的界面配置；预研团队则认为下一款产品应该提前支持某种新协议。每条信息都真实，也都很急。可当它们同时砸向研发时，冲突就来了：每个需求都有人背书，却没人排序，谁嗓门大谁先做；版本计划被频繁插入的需求撕碎；最要命的是，一旦需求理解出现偏差，返工成本会被直接放大好几倍。

于是有了OR——offering requirement，直译是“产品包需求”。大多数人以为它是一个文档，其实它是一套流程。OR项目最初的推动目标就四个：统一需求管理；主动收集需求去抓市场机会；降低紧急需求的比重；提升版本交付质量。通俗地说，OR就是给整个公司装一个统一的“物业报修台”：所有跟产品相关的要求都从同一个口子进来，由调度中心安排优先级、派单给最合适的师傅，再由后台回访确认问题真的解决了。

如果没有这个报修台，小区里每个业主都直接找电工、找水管工、找保安队长，最后活干了没有、谁负责、怎么验收，一概没人说得清。OR就是那个接管一切的总调度。它不会让需求变少，但能让每个需求都有记录、有归属、有结果。

2.2 六个环节怎么跑：从收集到验证的闭环

OR流程有六个环节：收集、分析、实现、验证、分发，覆盖需求从进来到被满足的全过程，外围还有贯穿始终的跟踪与变更控制。

收集环节不只被动等客户提，还包括行业分析、友商产品、展览会资料、杂志报道，以及内部PDT、用服、预研、市场、研发的各种看法。分析环节做的是“过滤”：先把垃圾需求和重复需求拍掉，再对剩下的需求解释清楚、做完整性检视，接着分类、排序、证实，确认用户确实需要它。打个比方，这就是一个土豆分拣台——先把带泥的、烂掉的甩出去，再按大小品相分筐，而不是把地里的东西直接倒进厨房。

实现环节决定需求怎么落地：是放进业务计划和产品路标，还是通过项目任务书直接立项，或者以PCR（产品变更请求）的形式加入正在开发的产品，甚至单独开辟一个新方案、新版本的通道。验证环节负责对照最初的需求描述做确认：需求有没有真的被实现、被实现得对不对。分发则由PMT/RAT做决策，把排好序的需求分配给对应的PDT、平台或项目组去执行。

这里最容易被忽略的是“闭环”。很多团队的需求管理是直线型的——收到了、排期了、发布了，就结束了。而OR要求在发布前做“需求早期确认”和“例行需求确认”，并在研发过程中让RAT参与TR评审，一层层对照当初的承诺进行验证。换句话说，IPD把“客户说想要”和“客户真的收到”这段距离焊成了闭环，任何一个需求要是没经过验证环节，它就不算结束。

2.3 承诺电子流：口头答应不算数

OR中还有一个很容易被忽略但极其重要的机制：需求承诺电子流。它解决的是需求管理中最隐蔽的问题——承诺失控。客户需求可以从客户、销售、服务等多个渠道冒出来，为了拿下订单，市场人员和销售习惯于先答应再讨论。如果这些口头承诺不进入统一流程，研发根本不知道自己在哪些场合被“卖”了出去。

这套机制立下三条规矩：第一，所有需求承诺必须录入客户需求/承诺电子流；第二，邮件、电话、传真只作沟通工具，不算承诺生效；第三，凡是功能清单之外的需求，必须由RMT（需求管理团队）给出答复口径，业务人员才能对外答复，未经RMT批准的任何答复，公司层面不承担兑现责任。

有了电子流，从标书制作阶段开始，标书不满足项就被CCM（客户需求承诺经理）录入电子流，推动RMT评审，在合同签订前明确答复口径；合同签订后，承诺进入交付阶段跟踪；一旦出现交付风险，由CCM组织RMT、PDT和产品经理共同解决。简单说，这就是给“承诺”上保险：谁答应的话，系统里都留痕，最后能否兑现，流程里有据可查。

需求统一只是IPD的入口。比需求更早的问题其实是：公司到底该做哪个市场、不做哪个市场。这就该轮到MM出场了。

3. MM市场管理：为什么立项之前先要决定“不做什么”

3.1 先有地图再动工：MM是IPD的上游流程

IPD看起来是从“立项”开始的，但立项之前还有一段更重要的路：市场管理，也就是MM（Market Management）。市场管理流程是IPD的上游，它用一套系统方法对广泛的市场机会做“选择收缩”，最后形成一份以市场为中心、能带来最佳业务成果的战略与计划。

把这段话翻译成大白话就是：市场上有很多种可能，客户也有很多种冲动，但你不可能全部满足。MM要做的，正是回答三个问题：我们现在在哪里；我们要到哪里去；怎么去。

类比一下：IPD像是盖一栋楼，MM则是开工前的拿地与定位。开发商不会随便买块地就动工，得先研究这个片区住什么人、周边楼盘什么价位、自己资金能撑多大体量、未来几年会不会有政策变化，然后才决定盖住宅还是写字楼。没有MM就启动IPD，等于不研究地段直接开工——房子很可能真的盖起来了，但盖完才发现没人买。

具体到流程上，MM包括理解市场、市场细分、组合分析、制定业务战略和计划、管理业务计划和评估绩效。理解市场要看宏观环境、价值扇区、竞争对手和客户；市场细分要创建合理的细分规则；组合分析则对多个细分市场做优先级排序，明确哪些市场值得投资、要在哪些市场取得领先地位，哪些市场干脆放弃。

3.2 业务计划：MM最主要的输出

MM流程有多个活动，但最重要的输出只有一个：业务计划。说白了，MM会议开完不能只留下几张汇报PPT，而要交出一份能够真正指导后续开发的业务计划。

业务计划的框架通常围绕五个问题展开，我整理成了一张表：

业务计划本身还分“核心要素”和“操作性要素”：核心要素包括产品包、定价与条款、分销、整合营销沟通；操作性要素包括有熟练技能的资源支持、订单履行等。

为什么要强调业务计划？因为没有业务计划的产品开发，经常是研发自己给自己定目标：技术很先进、功能很丰富，但市场根本不买单。而MM要求先算清楚这笔账再动手——产品还没立项，就得把“卖给谁、凭什么卖、赚多少”讲明白。

3.3 任务书：从“要不要做”到“开始做”

MM流程跑完后，业务计划回答了“要不要进入某个市场”。如果答案是“要”，接下来会产出两个与IPD直接衔接的成果：产品线路标，以及对每个项目的任务书（Charter）。

任务书就是IPD的“发令枪”。它把产品包需求、目标细分市场、竞争定位、盈利目标打包成一份正式立项文件，交给PDT去执行。同时，在决策链上PMT（组合管理团队）也在座——PMT本来就是市场管理流程在组织层面的延伸，它负责组合层面的策略和路标制定，解决与MM流程的衔接问题。中央层面的C-PMT、产品线层面的PL-PMT，以及产品线需求管理团队PL-RMT、地区部需求管理团队R-RMT，共同构成了这张决策网。

至此，逻辑链就串起来了：MM决定做不做，OR统一管需求，IPD负责把决定变成产品。很多团队在IPD上踩坑，就是因为跳过了MM，从立项之后才切入，结果需求没谱、目标模糊，流程再全也救不回来。

4. 从概念到退市：IPD六阶段与评审关口

4.1 六个阶段各管什么：一条主线看全貌

IPD流程主线包含六个阶段：概念、计划、开发、验证、发布、生命周期。

概念阶段相当于产品的“脑洞期”，把模糊的想法收敛成几个可选方案，做出初步业务分析，判断值不值得继续投入。计划阶段则把选中的方案做细，形成系统设计概要、业务计划和市场营销计划——版本要做什么功能、什么时候发布、需要多少资源，都在这一阶段落定。

开发阶段就是实打实地做产品：软硬件设计、编码、测试准备，同时市场端要同步准备营销计划，而不是等开发完了才开始想怎么卖。验证阶段负责回答“做得对不对”：内部测试、用户试用、问题修复，验证合格的产品才能考虑发布。发布阶段意味着产品真正推向市场，也就是通常说的GA（一般可获得性）——客户可以正式签单采购了。

最后的生命周期阶段管产品上市之后的持续演进：小版本更新、功能增强、维护支持，以及最终退市，把资源让给下一代产品。如果你想找一份覆盖完整的资料来对照，这套完整版PPT正是按这条主线编排的：任务书开发流程、概念与计划阶段流程、系统设计概要、业务计划开发、开发验证发布阶段流程、产品开发营销计划流程、生命周期阶段流程，都是这条主线上的一段。

4.2 评审关口：流程里的“红绿灯”

六个阶段摆在那里只是骨架，真正让IPD“收紧”的是阶段之间的评审关口。评审分两类：一类看技术，叫TR评审，研发团队用事实和数据告诉所有人“我们做出来的东西技术上到底行不行”，需求分析团队RAT也会参与TR评审，对需求满足情况给出判断；另一类是业务层面的决策评审，管理层对照业务计划看“这个产品还值不值得继续投钱、能不能进入下一阶段”。

每个阶段想往下走，都要先过对应的关口，过不了就返工或者停掉。这就是为什么听过IPD的人都会提到“红绿灯”这个词——关口的意思就是不亮绿灯不准走。

再结合第2章讲过的需求验证环节：需求早期确认、例行需求确认，其实也是评审的一种形式，只不过评审对象从“技术方案”换成了“客户需求是否被满足”。可以说，评审点就是产品开发流程里最不能省的部分，它避免了研发闭门造车到最后一刻才发现方向错了的情况——那种情况下的返工成本，往往足够再做一个大版本。

4.3 角色地图：PMT、RMT、PDT各管哪一段

IPD流程里最让人头晕的就是角色缩写：PMT、RMT、PDT、IPMT、RAT、CCM……很多人刚接触时都把它当成“黑匣子”，但其实按职责拆开就清楚了，我整理成了一张角色表：

这张表的逻辑是：决策层负责拍板，PMT和RMT负责做决策前的分析，PDT负责执行，CCM在销售端口守住外部承诺。IPD之所以强大，不是因为流程多，而是角色和职责在流程开始前就分清了。很多项目推行IPD失败，原因不在流程文档写得不够厚，而在角色没有真正确认，出了事还是“研发背锅、销售免责”。

5. 常见误区：IPD不是软件，也不是瀑布开发

5.1 误区一：IPD等于上一套流程软件

觉得上了系统、需求进电子流、任务自动分派就是IPD的，基本都误判了。软件是工具，IPD是管理体系。流程软件顶多能让需求“在线化”，但IPD真正改的是决策方式——谁有权拍板、按什么标准拍、拍完怎么验证。

为什么混：市面上叫“IPD管理软件”的产品很多，容易让人产生“买了就等于落地”的错觉。怎么区分：判断有没有落地，就看三件事——有没有统一的需求入口，有没有业务评审关口，有没有角色对承诺负责。三条都齐了，哪怕用表格也能跑起IPD；三条都不沾，花再多钱上系统也就是用了张更贵的电子表。

5.2 误区二：需求管理就是写需求文档

PPT做得再漂亮、PRD写得再长，如果需求没人分析、没人拍板、没人验证，它只是“愿望清单”。需求管理强调的是一个闭环：收集、分析、实现、验证、分发、变更控制。文档只是某个环节的产物，不是流程本身。

我见过一份几十页的需求文档里埋着一个致命假设——研发默认客户要的是批量导入，实际客户只想要手动导出，而团队没人做“证实”这一步，因为大家都忙着把文档写得更规整。等发布后被客户投诉，返工成本远超早一天确认的功夫。说到这里，可能有人会问：文档到底该写到多细？答案是写到“能被验证”为止，而不是写到“看起来很全”。

5.3 误区三：MM就是市场调研

市场调研收集信息，MM做取舍决策。调研只回答“客户想要什么”；MM要回答的是“我们选择服务谁、不服务谁、为什么这个细分市场值得投入、投入之后用什么业务计划承接”。

为什么混：一份扎实的调研报告往往好几百页，工作量大到让人天然觉得“做完调研就等于有结论”。怎么区分：看输出物。调研的输出是信息和洞察，MM的输出是业务计划、产品线路标和任务书。没有MM的调研，拿回来的往往是一堆“什么都要”的需求——而MM正是那把把“什么都要”砍成“这个要做、那个不做”的刀。

5.4 误区四：OR等于工单系统

工单系统只关心“谁在什么时候提了什么、处理到哪一步”，它是记录工具。OR关心的是一件事：这个需求到底值不值得做、做出来怎么承诺、做完怎么验证。OR流程里的分析过滤、分类排序、证实、承诺、验证这些动作，是工单系统完全没有的。

为什么混：两者界面都长得像“填单子、派任务”，电子流看上去也差不多。怎么区分：问一个问题——需求被驳回或推迟时，系统里有没有记录“为什么”以及“谁拍板”的？工单系统通常没有，OR必须有。如果只是把需求录进电子流然后等着派单，那只是把救火行为从打电话改成了在线提交。

5.5 误区五：IPD是瀑布开发

IPD看起来分前后六个阶段，很接近瀑布模型，但两者内核完全不同。瀑布模型强调步骤的先后顺序：做完需求分析才做设计，做完设计才编码，天然把市场、开发、测试分隔开。IPD强调的则是“决策节奏”：六个阶段是为了让管理层定期看到“这个产品现在值不值得继续投入”，而不是强迫所有人排队等待。

所以IPD开发过程中，市场需求可以继续进入，营销计划可以同步做，测试人员可以提前介入，只要需求变更走PCR评审就行。一句话：瀑布关心步骤顺序，IPD关心决策节奏。如果你所在团队吐槽“IPD太死板”，大概率是把IPD用成了瀑布——阶段成了硬墙，评审成了过场。

6. 什么时候用、什么时候别用：给IPD画一条合适的边界线

6.1 用在哪：需求多来源、承诺高风险

当你的项目具备这三个特征中的至少两个，IPD就值得认真用：第一，需求来源不止一条线，销售、市场、服务、领导都在提；第二，对外承诺的代价高，答应客户一个功能，违约直接影响合同或口碑；第三，开发周期长、失败成本高，做错了不是改一行代码，而是几个月的返工。在这类环境下，统一入口、评审决策、全程留痕三个机制能直接帮你防住最大的风险——需求失控。

6.2 别用在：探索期和小项目

但IPD也有明显的“不适用区间”：3到5个人的小团队做一次性工具、内部脚本、创意Demo；或者项目处于连客户都没想清楚要什么的高速探索期——这时候全流程的IPD反而是负担。完整版PPT里那套评审体系，对应的是多部门协同、投入上规模、需要按节奏对赌市场的场景；小团队硬要套完整流程，光是评审会就能把创新劲头耗光。

6.3 一个翻车例子

我在项目上踩过一次血泪坑：给一个只有二十来人的小项目强套了整套IPD，团队从“每天写代码”变成“每两周开会”，需求电子流里的状态比代码进展还多，最后项目延期，连客户都忍不住问“你们是不是在过流程而不是做产品”。那次翻车让我彻底明白，后悔药不是流程给的，是怎样在“失控”和“仪式感”之间做选择。

从那以后，我每次启动项目都会先问自己一个问题：我们真正要管理的是需求失控，还是流程仪式感？答案如果是前者，就把IPD最核心的三件套带上——统一入口、评审关口、承诺留痕；答案如果只是后者，那不如不开这个头。如果你正在为产品流程头疼，希望这篇文章帮你想清楚了一个问题：你的项目到底需要哪一档IPD。需要完整流程模型做参照时，这套覆盖了需求、市场、开发、生命周期全链条的资料，足够当一张随时翻的地图。

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