华为IPD流程15年演进：先僵化后优化，最值得借鉴的是节奏

简介：这份PDF以华为1999年启动IPD变革到2013年6.5版本发布为主线，梳理了15年间“先僵化、后优化”的完整演进路径，适合企业研发管理者、流程工程师及产品经理阅读。文档重点剖析了IPD与MM/OR对接、集成IPD-CMMI以及IPD+敏捷开发、解决方案IPD流程和小项目流程等关键优化点，并指出国内企业落地IPD时常见的流程僵化、与运营脱节、软件研发适配不足等问题。通过具体年份和版本线索，读者可以看清华为从引入IBM流程到形成自身特色解决方案的决策逻辑，特别是需求驱动、端到端衔接和分层分级评审体系的建设思路，对优化研发组织流程有直接借鉴意义。资源为1个PDF文件，约248KB，内容精炼但框架完整，可直接阅读或存档。目前已有126人学习浏览，适合希望学习华为产品开发管理体系并借鉴其落地经验的读者。

1. IPD 流程在华为 15 年：先僵化再优化，最值得抄的不是流程是节奏

一位硬件研发总监和我聊过：公司推 IPD 三年，流程文件写了几百页，评审会开了无数场，产品上市周期反而变长。他问我，华为当年到底怎么把这个流程“化”进去的？答案是四个字：先僵化，后优化。华为从 1999 年启动 IPD 变革到 2013 年 6.5 版本流程发布，15 年里前 5 年基本不碰流程，只做消化、理解、细化；2005 年之后才开始按自己的产品战略动手改。这份资料最值钱的地方，不是把华为的流程抄一遍，而是把“什么时候该忍、什么时候该改”的节奏讲清楚了。适合正在推 IPD 但看不清方向的研发管理者、想了解华为研发体系的产品经理，以及做研发流程咨询的从业者。

2. 1999–2004 先僵化阶段：IPD 导入的 5 年消化期，决策评审与文档体系怎么立住

2.1 IPD 到底改了什么：从职能式接力到跨部门重量级团队

IPD 全称是 Integrated Product Development，集成产品开发。它和国内很多企业熟悉的“串行研发”最大的区别在于：传统研发是按职能部门接力——市场提需求、研发做设计、中试验证、生产导入，每个环节做完就丢给下一个部门；IPD 把产品开发当成一条端到端的业务流，从概念到上市由一个跨部门团队全程负责，这个团队叫 PDT（Product Development Team，产品开发团队）。

PDT 不是虚拟的协调组，而是有明确责权利的重量级团队。核心成员来自研发、市场、制造、采购、服务、财务，在项目期间对结果共同负责。华为 1999 年刚开始推的时候，最难的不是画流程，而是让这些核心成员真正把时间投到项目里，而不是“人在 PDT，心在原部门”。所以“先僵化”阶段的第一件事，不是优化流程，而是把组织结构和管理制度先立起来。

另一个关键变化是决策方式的改变。以前产品立项是老板拍板，开发过程中基本没人管，直到快上市才暴露问题。IPD 引入了商业决策评审点（DCP, Decision Check Point）和技术评审点（TR, Technical Review），把产品开发分成概念、计划、开发、验证、发布、生命周期六个阶段，每个阶段结束都要过一个关口。

2.2 “先僵化”的具体操作：DCP 决策评审与 TR 技术评审两条线怎么搭

华为在前 5 年做的最主要工作，就是把 IBM 的这套流程原样搬回来，配上 IT 工具和考核机制，让所有人都按同一套规则走。当时流行的说法是“先僵化、后优化、再固化”，僵化期不允许随意提修改意见，先把流程走顺。

DCP 和 TR 是两条并行的评审线，它们的职责要分清楚：

两条线的关系很微妙：TR 是技术上的“体检”，DCP 是商业上的“拍板”。常见的问题是很多企业把这两个评审混在一起开，技术专家和业务领导坐在同一张桌子上，结果技术问题被商业决策带偏，或者业务问题被技术细节拖住。华为的操作是：TR 在 DCP 之前完成，TR 结论作为 DCP 的输入材料，两条线分开开、顺序不能乱。

这个阶段落地时，文档体系是最大的体力活。IPD 要求每个阶段都有明确的交付物清单，比如概念阶段的《产品需求文档》《业务计划书》，计划阶段的《开发方案》《测试策略》等。华为的做法是先不追求文档多漂亮，而是把“有没有、全不全、评审有没有过”作为阶段出口的硬条件。

提示：如果公司刚推 IPD，别急着开发 OA 流程审批系统。先用 Excel 管理阶段出口和评审计划，跑通两个试点项目后再上 IT 工具，否则工具会成为流程僵化的放大器。

2.3 这个阶段的常见误读：僵化不等于机械执行

“先僵化”经常被误解为“不许任何人提意见”。实际上华为的僵化有两个前提：一是僵化的是流程框架，不是业务细节；二是僵化期有明确的时间边界——5 年。2004 年之前，华为对流程文件的修改控制得很严，但对每个项目怎么裁剪、评审怎么组织，仍然允许 PDT 按项目特点灵活安排。

判断僵化期是否结束，有个很朴素的标志：流程里的角色不再问“我为什么要做这件事”，而是问“这件事怎样做得更快更好”。当团队开始主动讨论效率、讨论裁剪、讨论流程之间的衔接时，说明流程已经内化了。华为 2005 年跨入“后优化”阶段，正是基于这个判断，而不是简单地按日历走。

3. 2005 年的两个关键转折：MM/OR 端到端对接，客户需求直通开发

3.1 IBM-IPD 的断点在哪里：规划与开发之间缺了一根需求管道

IBM 给华为的 IPD 流程，解决的是“如何把产品开发出来”的问题，但有一个明显的短板：从市场机会识别（MM, Marketing Management）到产品开发之间，需求传递是断的。做规划的人不知道开发团队实际能交付什么，开发团队拿到的需求文档往往只是规划文本的摘录，没有原始客户声音。

华为 2005 年干的第一件大事，就是把 IPD 与 MM、OR（Order-to-Cash，从订单到回款）对接。通俗地说，MM 负责回答“做什么、为什么做”，IPD 负责“怎么做出来”，OR 负责“怎么卖出去、怎么回款”。以前这三段流程各自为政，市场部门抱怨产品不对路，研发部门抱怨需求变来变去，销售部门抱怨交付太慢。对接之后，客户需求可以从市场端直接通到开发人员手中。

这个改进的实质，是把“需求驱动产品开发”从口号变成了一条可运行的管道。需求不再是售前顾问回来之后写一篇 PPT 丢给研发，而是分层次、分优先级、带原始访谈记录地进入开发流程。

3.2 需求驱动的落点：需求分层与端到端传递机制

需求管道要跑通，光有理念不够，还得有具体的分层方式和传递载体。华为的做法是给需求分了三个层次：

分层之后，需求进入的路径也变了。售前或产品经理收集到需求，先做初步分析，判断属于哪一类、应该进哪条管道。进 IPD 开发的需求，必须带标准的需求描述模板，包含背景、场景、业务价值、验收标准，避免“客户说要，我们就要”的模糊传递。

提示：很多企业 IPD 推不动，核心原因是需求入口是乱的。市场人员有需求直接找研发负责人，研发负责人按个人判断决定做不做，流程被绕过，IPD 自然成了摆设。需求端到端管道建立的前提，是把所有需求强制收口到统一的需求管理平台。

3.3 从卖产品到卖解决方案：IPD 解决方案流程的提出

除了需求驱动，2005 年华为还有一个更激进的创举：提出《IPD 解决方案流程》。传统 IPD 的颗粒度是“一个产品”，而电信市场的客户要的是“解决一个业务问题”——比如建一张覆盖全省的 4G 网络，里面涉及基站、核心网、传输、网管、集成服务、培训多个产品线和交付环节。

IBM-IPD 只解决“如何开发一个赢利的产品”，华为需要解决“如何为关键细分市场提供端到端的解决方案”。所以华为在 IPD 之外新增了一套解决方案开发模型，把多产品线、多合作方的开发过程纳入统一控制。这个转变的意义远超流程层面：它把华为从一家卖设备的公司，推向了卖解决方案与服务的公司。

对国内企业来说，方案流程的门槛比较高，因为它的输入是“客户业务痛点”，而不是“产品需求”。但它的核心思想可以借鉴：当你的产品必须组合销售时，就要在 IPD 之上增加一个整合层，专门负责方案级的需求分析、架构设计和集成验证。

4. 软件开发适配：从 IPD-CMMI 到 IPD+敏捷，重型流程怎么变轻

4.1 为什么软件不能照搬硬件 IPD

华为的主业是电信设备，早期 IPD 的流程设计天然偏向嵌入式系统开发——硬件为主、软件为辅、发布周期长。但到了 2005 年前后，软件研发的工作量已经占到绝大多数，而且软件有完全不同的节奏：变更频率高、版本迭代快、bug 修复和市场反馈的耦合度高。如果软件项目也按硬件 IPD 的节奏走，每个版本都要走完六个阶段、过完所有评审，一个功能从立项到上线至少要半年，市场早就跑了。

IBM 当年的 IPD 里并不是没有软件开发流程，而是太重。华为的选择是分两步走：先集成 IPD-CMMI，把 CMMI 的软件工程实践纳入 IPD 框架；2007 年到 2010 年各产品线试点敏捷开发之后，再形成 IPD+敏捷的混合流程。这个过程很有参考价值，因为它没有否定 IPD，而是给 IPD 加了一个“软件模式”。

4.2 集成 IPD-CMMI：两层体系怎么绑在一起

CMMI（Capability Maturity Model Integration，能力成熟度模型集成）是软件行业的过程改进框架，包含需求开发、技术解决方案、验证、确认、配置管理等实践域。华为集成 IPD 和 CMMI 的做法，不是两套体系并存，而是做“映射”和“裁剪”。

具体操作上，以 IPD 的阶段划分为主线、以 CMMI 实践域为内容填充。比如 IPD 的“验证阶段”，对应 CMMI 的验证（Verification）和确认（Validation）两个过程域，评审标准直接复用 CMMI 的实践描述。这样做的效果是：IPD 负责大节奏（什么时候立项、什么时候发布），CMMI 负责小节奏（设计怎么评审、测试怎么执行、配置怎么管理）。

值得注意的一点：集成不是把两套流程简单叠在一起，而是把重复的评审合并掉。CMMI 有同行评审，IPD 有 TR，如果各开各的会，项目组一周至少有三天在开会。华为的做法是：TR 评审中嵌入 CMMI 的同行评审要求，一份评审材料同时满足两套体系的检查项。

4.3 IPD+敏捷：从重型过程管理转向轻量过程管理

CMMI 解决了软件过程规范问题，但并没有解决响应速度问题。2007 年起华为在各产品线试点敏捷开发，到 2010 年左右形成 IPD+敏捷的混合流程，核心变化有三点。

第一，把需求拆成“版本需求”和“迭代需求”两层。版本需求进入 IPD 的计划阶段，对应产品版本的总体范围；迭代需求由开发团队在版本范围内自主编排，采用敏捷的迭代节奏交付。第二，把 IPD 的验证阶段打散到各个冲刺（Sprint）中，不再等到开发全部完成再集中测试。第三，把重量级的文档要求裁剪为“必要才写”，比如详细设计文档不再强求，代码评审记录和自动化测试脚本替代了一部分文档的作用。

这个阶段的关键是边界划分：哪些决策权限留在 IPD 层面，哪些下放到敏捷团队。华为的经验是——立项决策、发布决策、重大需求变更必须走 IPD 评审，迭代内部的计划调整、技术方案选择、任务拆分全部下放给敏捷团队。

提示：如果你的公司同时推 IPD 和敏捷，最怕的是“两层皮”。敏捷团队说我们跑迭代，IPD 说我们要过 TR，两边各讲各话。解决方法是把迭代作为 IPD 阶段的子结构：IPD 的概念阶段产出迭代计划，开发阶段按迭代执行，TR 评审时直接引用迭代的测试结果。

4.4 2008 年之后的减重：小项目流程、DFx 与分层分级评审

2008 年后华为做了一个“反向优化”：降低 IPD 的厚重性要求。不是因为 IPD 太重了（重是它的基因），而是不是所有项目都值得同等流程强度。

华为推出 IPD 小项目流程，针对两类场景：一类是客户定制开发，需求明确、技术风险小、周期短；另一类是小型产品开发，比如一个单板、一个软件工具。小项目流程的裁剪原则是：保留立项决策和发布决策两个 DCP，砍掉中间的计划 DCP；TR 评审从全景评审简化为针对性评审，只审关键技术点。交付物的数量也从二十多份减到七八份。

同期华为还引入了 DFx 要求和 QMS 质量管理体系，并建立了分层分级的 IPD 流程评审体系。所谓分层分级，是指不同规模的项目走不同深度的流程：

这套分层分级的设计，解决的是 IPD 在国内企业最常见的痛点——流程不分大小项目“一视同仁”，导致小项目跑流程的时间比干活还长。华为 15 年的演进轨迹本质上是一个持续做减法的过程：先做加法把流程完整地建起来，再按业务现实做减法把流程变轻。

5. IPD 落地避坑与常见问题：需求驱动失效与流程僵化的典型迹象

5.1 需求驱动没建立：IPD 变成研发搪塞市场的工具

现象：市场部门提了需求，研发说“这个需求没进基线”“需求变更要走流程”，以此拒绝响应。流程成了研发挡市场的挡箭牌。

原因：企业只学了 IPD 的研发阶段，没有建 MM 和 OR 的对接。需求进来的入口不统一，研发手上的需求清单和市场实际需求脱节，流程就变成了保护研发的手段。

解决：先把需求入口收口。建立统一的需求管理平台，制定需求描述模板，每个月开一次需求评审会，由产品管理团队对需求做优先级排序。需求不进评审会就不允许进入研发通道，从制度上堵住“口头需求”。

5.2 流程厚重、僵化在 1.0 版本：与公司运营流程脱节

现象：IPD 流程文件第一版发布后三年没更新过，业务模式已经变了，流程还在用旧逻辑。项目组按流程做了一堆文档，但实际决策还是靠领导拍板，流程只是“事后补材料”。

原因：对 IPD 的敬畏变成了不敢改。认为流程是“西方最佳实践”，改动有风险。加上缺少流程 owner，没有专人负责流程的持续优化。

解决：给每个流程指定 owner，每年做一次流程审视。审视的标准很简单：哪些环节在拖慢项目、哪些文档没人看、哪些评审没有改变任何决策。删掉这些环节，不要犹豫。

5.3 软件业务照搬硬件流程：效率与质量两头都不讨好

现象：软件开发项目按硬件 IPD 的节奏走，设计阶段写了几百页文档，开发阶段压缩到几周，测试只剩最后一个月。结果是文档写得很厚，软件质量一塌糊涂。

原因：没有识别软件和硬件开发的本质差异。软件的需求变更成本低、迭代速度快、测试可以自动化，用硬件的一次性开发逻辑约束软件，必然导致过程冗余和结果失控。

解决：软件项目至少要做 IPD-CMMI 集成，迭代节奏用敏捷。如果短期内推不动敏捷，先做一步：把软件开发阶段的评审从“文档评审”改为“代码评审+测试结果评审”，把文档要求降到最低必要。

5.4 只学了文档没学决策：评审会走过场

现象：IPD 的各个阶段都有评审记录，交付物齐全，但产品质量还是问题频出。翻评审记录发现，所有评审结论都是“通过”，没有任何有分量的反对意见。

原因：评审会变成了“通知会”。会前材料不提前发放，参会人现场翻文件，业务领导不提问，技术专家不较真，评审成了走流程。本质上是没有建立“评审不通过是常态”的文化。

解决：评审会前三天发放材料，会前收集书面意见；评审结论必须是明确的“通过/不通过/有条件通过”，有条件通过必须列整改项和验证责任人。如果连续多次评审全票通过，先怀疑评审标准的有效性。

5.5 没走完僵化期就急着“优化”

现象：流程推行不到一年，各业务部门已经提交了几十条优化建议，流程版本迭代了三次，执行的人跟不上版本变化，又回到按习惯办事。

原因：对“先僵化”的理解不到位。企业花了钱请顾问、写了流程，急着要看到“优化”成效，把优化当成了 KPI。实际上流程结构还没稳定，角色还不清楚，优化只会让体系更乱。

解决：设定明确的僵化期。至少跑 6 到 12 个月，期间只收集问题不修改流程，用“问题清单”记录，到期后集中做一次版本修订。这个节奏是从华为实践里可以直接抄的经验。

6. 验证你的 IPD 是否长在公司里：三个可量化的自检习惯

流程是否内化，不能靠感觉判断。我每次去企业诊断 IPD，只看三个数：需求直通率、评审决策有效率、小项目平均周期。

需求直通率，统计的是从市场端提出需求到研发团队拿到结构化需求描述的平均天数。健康的 IPD 场景下，这个数字应该在 7 到 15 天之间。超过一个月说明需求管道不畅，研发把时间耗在反复澄清上。评审决策有效率，指评审会上被否决或要求返工的比例。如果连续一年所有评审全部通过，不是项目质量好，而是评审没有起作用。小项目平均周期，检验的是流程裁剪是否有效。如果小项目的周期和大项目一样长，说明分层分级没有真正落地。

我一般会建议企业把这三个指标做成月度报表，贴在研发管理看板上。注意，这三个指标看的不是“执行率”，而是决策质量和响应速度。流程文件大家都会写，但能否让需求变快、让评审变准、让资源变省，才是流程真正的价值。

作为曾经也迷信过“流程至上”的工程师，我在这上面吃过亏。当年我负责推进一套重型研发流程，花了大半年把流程文档和 IT 工具都建好了，结果业务部门用了一个季度就悄悄绕回老路。后来我才明白，流程推行者最容易犯的错，是把“建流程”当成“做系统”，以为文档发布之日就是变革成功之时。从那以后，我每到一个企业看研发流程，都强制自己按上面三个口径拉数据，而不是听管理层讲故事、翻流程文件。数据不会骗人，流程有没有长在公司里，三个月的数据就能看出来。希望帮到你。

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