简介这份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 把产品开发当成一条端到端的业务流从概念到上市由一个跨部门团队全程负责这个团队叫 PDTProduct Development Team产品开发团队。PDT 不是虚拟的协调组而是有明确责权利的重量级团队。核心成员来自研发、市场、制造、采购、服务、财务在项目期间对结果共同负责。华为 1999 年刚开始推的时候最难的不是画流程而是让这些核心成员真正把时间投到项目里而不是“人在 PDT心在原部门”。所以“先僵化”阶段的第一件事不是优化流程而是把组织结构和管理制度先立起来。另一个关键变化是决策方式的改变。以前产品立项是老板拍板开发过程中基本没人管直到快上市才暴露问题。IPD 引入了商业决策评审点DCP, Decision Check Point和技术评审点TR, Technical Review把产品开发分成概念、计划、开发、验证、发布、生命周期六个阶段每个阶段结束都要过一个关口。2.2 “先僵化”的具体操作DCP 决策评审与 TR 技术评审两条线怎么搭华为在前 5 年做的最主要工作就是把 IBM 的这套流程原样搬回来配上 IT 工具和考核机制让所有人都按同一套规则走。当时流行的说法是“先僵化、后优化、再固化”僵化期不允许随意提修改意见先把流程走顺。DCP 和 TR 是两条并行的评审线它们的职责要分清楚评审线评审什么谁参加决策输出DCP 业务决策要不要做、值不值得投、资源够不够IPMT投资管理委员会继续/停止/重新定向TR 技术评审技术方案是否成熟、风险是否受控PDT 内部技术专家技术就绪度评估两条线的关系很微妙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、OROrder-to-Cash从订单到回款对接。通俗地说MM 负责回答“做什么、为什么做”IPD 负责“怎么做出来”OR 负责“怎么卖出去、怎么回款”。以前这三段流程各自为政市场部门抱怨产品不对路研发部门抱怨需求变来变去销售部门抱怨交付太慢。对接之后客户需求可以从市场端直接通到开发人员手中。这个改进的实质是把“需求驱动产品开发”从口号变成了一条可运行的管道。需求不再是售前顾问回来之后写一篇 PPT 丢给研发而是分层次、分优先级、带原始访谈记录地进入开发流程。3.2 需求驱动的落点需求分层与端到端传递机制需求管道要跑通光有理念不够还得有具体的分层方式和传递载体。华为的做法是给需求分了三个层次需求层次定义典型例子对应流程客户需求单个客户的具体诉求某运营商要求网管系统支持批量配置需求管理流程市场共性需求一类客户的共同诉求多个客户都反映设备升级时业务中断时间长MM/产品规划内部需求研发、制造、服务自身改进诉求可制造性要求、可维护性要求DFx/技术平台分层之后需求进入的路径也变了。售前或产品经理收集到需求先做初步分析判断属于哪一类、应该进哪条管道。进 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两层体系怎么绑在一起CMMICapability 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砍掉中间的计划 DCPTR 评审从全景评审简化为针对性评审只审关键技术点。交付物的数量也从二十多份减到七八份。同期华为还引入了 DFx 要求和 QMS 质量管理体系并建立了分层分级的 IPD 流程评审体系。所谓分层分级是指不同规模的项目走不同深度的流程项目类型决策评审点技术评审交付物数量适用场景大型解决方案全流程 4 个 DCP全 TR 序列完整交付物新产品平台、解决方案中型产品项目3 个 DCP关键 TR裁剪交付物产品改型、新版本小项目2 个 DCP针对性 TR精简交付物客户定制、小工具这套分层分级的设计解决的是 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 工具都建好了结果业务部门用了一个季度就悄悄绕回老路。后来我才明白流程推行者最容易犯的错是把“建流程”当成“做系统”以为文档发布之日就是变革成功之时。从那以后我每到一个企业看研发流程都强制自己按上面三个口径拉数据而不是听管理层讲故事、翻流程文件。数据不会骗人流程有没有长在公司里三个月的数据就能看出来。希望帮到你。本文还有配套的精品资源点击获取