IPD流程概念阶段是回答"做正确的事",计划阶段是回答"正确地做事",但开发阶段是把前面所有承诺兑现的过程。
我做了十来年研发管理咨询,见过不下五十家企业推 IPD,绝大多数卡壳的环节,都不是卡在概念阶段或发布阶段,而是卡在开发阶段—也就是别人讲的"按计划做产品"的那一段。
为什么?因为前面几篇文章里我们聊过,IPD 的概念阶段是回答"做正确的事",计划阶段是回答"正确地做事",但开发阶段是把前面所有承诺兑现的过程。一旦产品包需求冻结、PDT 签完 PDCP 合同,开发团队就要开始啃硬骨头:详细设计、编码、单元测试、SDV、SIT、TR4、TR4A、TR5,还有伴随全程的 EC 变更控制和需求变更审批。这些环节里任何一个掉链子,IPMT 都会收到一份"承诺达成率 78%、关键模块延迟 11 周"的告警邮件。
这篇文章就围绕华为 IPD 的开发阶段,讲清楚它到底在干什么、为什么这么干、和其他阶段怎么咬合等。
IPD 是 Integrated Product Development 的缩写,中文叫集成产品开发。它不是一套流程文档,也不是一个软件系统,本质是一种把产品开发当作"投资行为"来管理的思维模式。这套思想最早来自美国 PRTM 公司 1986 年出版的 PACE(Product And Cycle-time Excellence),IBM 在 1992 年把它落地为 IPD,华为 1998 年花了几十亿咨询费从 IBM 引入并本土化。
我经常在客户的高管会上说一句话:IPD 不是流程,是流程背后的决策机制和责任分配。你们看到的那张六个阶段、四个DCP、七个TR的图谱,只是这套机制的外在表现,真正值钱的是它在每个节点上回答的三个问题:
这三个问题对应的就是 DCP(决策评审)、TR(技术评审)和 PDT/IPMT 的角色责任。下面这张图我画过不下五十遍,各种版本都有,挑一个最干净的:
Charter → 概念(CDCP) → 计划(PDCP) → 开发 → 验证(ADCP) → 发布 → 生命周期(LDCP)
TR1 TR2/TR3 TR4/TR4A/TR5 TR6开发阶段是六个阶段里唯一一个"不设 DCP"的阶段—为什么?因为大决策在 PDCP已经拍板了,开发阶段要的是"把承诺兑现",所以用技术评审(TR)而不是投资决策来管控。这也回答了很多客户的疑问:"我们开发阶段没设 DCP,是不是漏了?"不是漏了,是设计如此。
华为 1997 年的状态,业界材料已经讲烂了,我换几个细节来讲。
当时华为的产品开发周期是业界最佳的两倍以上,某型号的研发投入产出比,行业平均是 3.3% 研发损失(就是花在已死项目上的钱占总研发投入的比例),华为当时在 12% 左右徘徊,远没到 IBM 当年 25% 那么夸张,但已经够疼。
更致命的不是数字,是任正非看到的一个画面。1997 年圣诞节他带队去 IBM,听了一整天 IPD 介绍后,看到的是 IBM 这种级别的公司,居然能把产品开发这件事用流程管得这么好。郭士纳是卖饼干的出身,不是技术大牛,但他用流程把 IBM 这头大象转过来了。任正非回国后说了一句话:"我们要买一双美国鞋,不合脚就削足适履。"
那华为引入 IPD 到底要解决什么?IBM 顾问的诊断报告里有一句狠话:"有时间一遍遍地低水平重复,却没有时间坐下来讨论如何把事情一次做好。" 这句话是后面很多动作的起点,包括开发阶段的"需求冻结"、"EC 变更控制"。
华为第一个 IPD 试点项目是无线业务部大容量移动交换机 VMSC6.0,2000年5月启动,跑了10个月。三条产品线试了一年,总周期缩短了50%。从 2001年开始,30%的产品线强制按IPD 2.0跑;2002年底,所有产品线必须跑IPD;2003年,销售额462亿,比1998年涨了五倍多。
2003年到2008年五年,研发项目平均周期持续缩短50%,产品故障率减少95%。这个数字我每次跟客户讲,对方都是先问"真的假的",然后沉默三秒。真的假的,数据摆在那里。
先把边界说清楚。开发阶段的起点是PDCP决策通过(计划阶段结束),IPMT在PDCP上签了项目"合同"给PDT,PDT 立下军令状;开发阶段的终点是ADCP决策通过(可获得性决策评审),产品包准备发布上市。
在开发阶段里,PDT要交付的核心结果有四样:
这四件事是串并交叉的,不是顺序做。SDV 还没跑完,硬件详细设计可能还在改;SIT 还在搭测试床,部分模块的 BBFV 已经过了好几个月。理解这一点,后面看EC变更控制为什么那么重要就懂了。
写到这里我特别想说一句—很多公司的开发阶段根本不是"实现",而是"补救"。为什么?因为前面两个阶段没把需求冻住,开发阶段还在救火。
华为IPD在开发阶段的核心目的,其实就两条:
第一条:在冻结的需求基线之上,按计划交付满足规格的实现。
第二条:在交付过程中,通过 TR 评审和 EC 控制,管理技术风险和需求变更。
第二条经常被忽略。客户经常问"开发阶段怎么管风险",我反问"你PDCP通过的时候,需求冻结了吗",对方一愣,后面的话就好聊了。
按时间先后和并行关系,开发阶段的活动可以拆成七块:
这七块里,1和7是时间点事件,2-5是持续性的工程活动,6是横向贯穿整个阶段的管控活动。
开发阶段PDT跟计划阶段PDT可能不是同一波人,至少核心代表要从"参与"变成"全职投入"。计划阶段的PDT核心组大约5-8 人,开发阶段要扩到12-25,各功能领域都要补人:
PDT 经理在开发阶段的核心动作,就是把这12-25 人的扩展团队"拢"到一起,让大家按统一节奏干活。这件事说起来简单,做起来极难,后面会专门讲角色和职责怎么落地。
2008 年前后,华为进军欧洲市场,参加巴塞罗那电信展(就是现在 MWC 的前身)。当时华为的策略是"me too but cheaper",用价格战打低端运营商。
但客户来了之后,一个专家直接站起来说:"我告诉你们如何做产品设计!" 华为的老员工在复盘里讲,这件事"伤害性不大,侮辱性极强"。
为什么讲这个?因为这件事反向暴露了开发阶段的两个痛点:
后来华为IPD 5.0、8.0的演进,核心就是补这两个洞—开发阶段不只是把"计划"做出来,还要把"差异化竞争力"做出来。折叠屏铰链量产良率从30% 提到85%,就是 PDT提前 6 个月介入屏幕供应商技术路线的结果—这件事发生在开发阶段的早期,而不是发布前救火。
1）详细设计到底在做什么
详细设计(Low Level Design, LLD)是把计划阶段的概要设计(High Level Design, HLD)进一步拆解到可以直接编码、可以出 PCB 图、可以出模具图的程度。它是开发阶段的"第一公里",没走好,后面所有事情都在补漏。
硬件详细设计的核心交付:
软件详细设计的核心交付:
结构/工艺详细设计的核心交付:
我经常在客户现场看到的问题是:详细设计还没做完,研发就开始编码了。这种"边设计边编码"的模式,代码返工率是 30% 以上,周期延迟 25% 以上。华为 IPD 在开发阶段第一件事就是 TR4 之前的"详细设计封版",没封版不准进入编码,这是死命令。
2）详细设计阶段的输出模板
这里我贴一个硬件详细设计评审检查清单(TR4 前置,各代表版),是我们安谋咨询给客户做过的一个版本,字段都是从IPD实践里拆出来的:
【硬件详细设计评审检查清单(TR4 准备版)】
被评审对象: <单板名称> <型号>
评审日期: YYYY-MM-DD
评审主席: <硬件 PDT 经理>
【财务代表】
□ 单板目标成本是否已分解到器件级?
□ 关键器件是否已在目标成本范围内?
□ 是否有 2 个以上供应商备选?
【质量代表】
□ 关键器件的认证计划是否完成?
□ 安规/EMC/防护标准是否已识别并写入设计约束?
□ DFMEA(设计失效分析)是否完成?
【采购代表】
□ 关键器件的供应商选择策略是否明确?
□ 新器件是否在器件路标库中已规划?
□ 长货期器件(>12 周)是否已下采购意向?
【硬件SE代表】
□ 设计规格与产品包需求的映射是否 100% 覆盖?
□ 双向需求跟踪(需求→规格→测试)是否完成?
□ 接口定义文档是否经过相关模块会签?
【硬件测试代表】
□ 硬件可测试性需求(DFT)分析是否完成?
□ 测试方案初稿(针对新器件、新电路)是否就绪?
□ 自测试覆盖度目标(95% 覆盖率)是否可行?
【结构代表】
□ 整机堆叠、ID 摆件是否完成自检?
□ 新工艺的可测试性是否满足?
□ 模具清单/工艺说明是否冻结?
【软件代表】
□ 驱动/操作系统适配是否完成评估?
□ 关键模块接口与硬件接口是否一致?
□ 软件功能分解是否 100% 完成?
【工业设计代表】
□ CMF 详细规范是否冻结?
□ 人机工程(按键、接口布局)是否经过 UCD 评估?这个清单的好处是:每个角色都有自己的"必答问题",开会时按字段对就行,避免出现"硬件说行,软件说不行,采购说没货"的扯皮。华为内部也有类似版本,只是字段更多(约 80-120 项),这里只展示关键30项。
3）详细设计的常见坑
坑一:把"概要设计"当"详细设计"。很多工程师不知道 LLD 和 HLD 的区别,HLD 写完就直接画 PCB,中间没有 LLD 这一层。解决方法:模板强制要求 LLD 必须包含"模块内部状态机"和"关键路径时序图"。
坑二:详细设计阶段就开始做 EC 变更。详细设计本身就在迭代,过早进入 EC 控制会拖慢节奏。华为的做法是:开发阶段开工会议时宣布"EC 控制开始",这之前的设计变更走"设计审查"流程,这之后的设计变更全部走 EC 流程。
坑三:跨模块接口在详细设计时才发现对不上。这个问题几乎所有企业都遇到过,解决办法是在 HLD 阶段做"接口冻结",LLD 阶段再做"接口实现"。
1）编码阶段的核心原则
编码阶段不是"埋头写代码",是"按 LLD 实现并自测"。这一阶段有几个原则是华为 IPD 反复强调的:
原则一:编码规范必须先于编码。华为内部有自己的编程规范(C/C++/Java/Python 各一份),违反规范的代码不能合入主干。这个规范包含命名、注释、函数长度、圈复杂度等具体指标。
原则二:每天都要合入主干(Git/CC)。这是华为在 2005 年前后推的硬要求,目的是把集成问题暴露在最早。早期有些团队一周合一次,结果到 SIT 阶段集成问题爆炸。
原则三:Code Review 必须做。华为的同行评审(PR)文化是从 IPD 推行的早期就建起来的,后面会专门讲。
2）编码阶段的输入输出
输入:
输出:
3）编码阶段的角色职责
| 角色 | 编码阶段核心职责 | 输出物 |
|---|---|---|
| 硬件工程师 | 按 LLD 完成原理图、PCB 设计,完成自测 | 原理图、PCB、自测报告 |
| 软件工程师 | 按 LLD 完成代码编写,完成自测与单元测试 | 代码、单元测试报告 |
| 结构工程师 | 按 LLD 完成 3D/2D 设计,完成可装配性自检 | 工程图、装配工艺初稿 |
| 工艺工程师 | 同步开发制造工艺文件 | 工艺文件初稿 |
| 测试工程师 | 准备 BBFV 测试用例和测试床 | BBFV 测试方案、用例 |
| QA | 过程审计,确认编码规范执行 | 审计报告 |
1）单元测试在 IPD 里到底指什么
IPD 里的"单元测试"和软件工程里的"单元测试"不完全一样。IPD 把"构建模块功能验证(BBFV)"和"构建模块集成测试(BBIT)"都归到开发阶段的单元测试范畴。构建模块可以是:
BBFV 通常以设计人员为主、测试人员参与(白盒),BBIT 通常以测试人员为主、设计人员参与(灰盒)。这两个测试必须在 TR4 之前完成,否则不让进入 SDV。
2）单元测试的质量门
单元测试质量门(给客户做过的版本):
【BBFV/BBIT 质量门】
□ 致命/严重缺陷清零
□ 单元测试覆盖率 ≥ 90%(关键模块 ≥ 95%)
□ 代码缺陷密度 ≤ 0.5 个/千行
□ BBFV 报告归档,问题闭环率 ≥ 95%
□ 接口验证:模块对外接口 100% 经过实际调用测试
□ 兼容性验证:模块与依赖模块的版本兼容性已确认这个门在开发阶段开工会议上就要公布,所有核心代表签字。达不到质量门,不让进入 SDV 阶段。
3）单元测试的常见坑
坑一:覆盖率虚高。为了凑 90% 覆盖率写一堆没意义的测试用例。解决方法:覆盖率按"业务路径"而非"代码行"计算。
坑二:单元测试和生产代码脱节。开发人员只管写代码,测试人员只管写测试,中间没有联动。解决方法:推行 TDD(测试驱动开发)或 BDD(行为驱动开发),至少做到测试用例先于代码评审。
坑三:硬件 BBFV 用软件模拟代替。硬件 BBFV 必须用真实器件或真实样机,不能用纯仿真。仿真可以做早期验证,但 BBFV 必须是实物。
1）SDV、SIT、SVT 三个层次的差异
IPD 开发阶段涉及的集成测试主要有 SDV 和 SIT,加上验证阶段的 SVT,合起来是开发-验证阶段的测试主轴。
SDV(System Design Verification,系统设计验证):子系统或模块级测试,以测试人员为主、设计人员参与,偏灰盒。关注内部实现,验证多个模块集成后是否满足设计需求。测试内容:基本功能、性能、容错/容限、EMC、热测试、环境可靠性等。
SIT(System Integration Test,系统集成测试):产品整机级测试,以测试人员为主,黑盒测试,验证设计需求是否全部满足。SIT 在 SDV 基础上增加可用性、可维护性、包装测试,模拟用户实际使用场景,覆盖度要求 98% 以上。
SVT(System Verification Test,系统验证测试):小批量试制阶段的验收测试,以测试人员为主、试制人员参与,关注产品质量一致性。SVT 必须在 SIT 完成后在验证阶段完成。
这三个测试是层层递进的,SDV 没过,不能进 SIT;SIT 没过,不能进 SVT。我看到有些客户把 SDV 和 SIT 混着做,结果某个子系统的故障拖到 SVT 才发现,这时候已经做了几百台样机,损失极大。
2）SIT 测试的输入输出
输入:
输出:
3）SIT 阶段的常见坑
坑一:把"集成测试"做成"系统测试"。集成测试关注模块间的接口与协作,系统测试关注整个产品的功能与性能。两者混着做,出问题不知道是接口的事还是功能的事。
坑二:SIT 测试用例覆盖率虚高。98% 覆盖率要求的是"业务场景",不是"代码路径"。很多客户把功能点覆盖了就算,但没覆盖异常路径。
坑三:跨部门协调不到位。SIT 涉及硬件、软件、结构、电源等多个领域,任何一方的样机延迟都会影响 SIT 启动。解决办法:在开发阶段开工会议上就锁定样机交付里程碑。
1）开发阶段为什么必须有 TR 评审
IPD 体系里有两个评审机制,一个是 DCP(决策评审,看商业),一个是 TR(技术评审,看技术)。开发阶段是 TR 评审最密集的阶段,因为这个阶段要把所有技术风险"过一遍筛子"。
我经常被问:"开发阶段设这么多 TR,会不会拖慢进度?"答案是不会,因为 TR 评审的代价远低于"带着技术风险进入发布阶段"的代价。一个隐藏的硬件兼容性问题,在 TR4 解决只要 1 周,在 SVT 阶段发现可能要 3 周,在客户现场发现可能要 3 个月。
2）TR 评审的 6 个核心原则
原则一:会前材料必须就绪。TR 评审不是讨论会,是决策会。所有材料必须提前 3-5 个工作日发出去,让评审专家有阅读时间。
原则二:评审专家必须有否决权。没有否决权的评审是走过场。华为的 TR 评审专家(包括外部顾问)有一票否决权,即使 PDT 经理不同意,专家说"不通过",就得改。
原则三:必须当场给出"通过/有条件通过/不通过"三种结论之一。"议而不决"是 TR 评审最大的浪费。
原则四:不通过的,必须明确责任人和整改时限。整改时限由 PDT 经理和评审主席共同商定,最长不超过下一个 TR 节点。
原则五:整改结果必须经过原评审专家复核。不能让 PDT 自己说"已经改了",要原评审专家签字。
原则六:TR 评审记录进入配置管理库,作为后续审计的依据。
3）TR 评审的 6 个核心角色
| 角色 | 职责 | 谁来担任 |
|---|---|---|
| 评审主席 | 主持评审,做最终结论 | 不在 PDT 内的技术专家 |
| PDT 经理 | 汇报项目状态,接受质询 | PDT 经理本人 |
| SE(系统工程)代表 | 讲解需求/规格/接口 | SE 经理或 SE 主管 |
| 研发代表 | 讲解技术方案和实现 | 硬件/软件/结构负责人 |
| 测试代表 | 讲解测试方案和结果 | 测试经理 |
| 质量代表 | 讲解质量数据 | 质量经理或 PQA |
| 财务/采购/制造代表 | 讲解配套情况 | 各功能领域经理 |
1）为什么开发阶段必须冻需求
这是开发阶段最核心、也最容易被忽视的一个环节。需求冻结(Requirement Freeze)是指 PDCP 通过后,产品包需求原则上不再变更;要变更,必须走变更流程。
为什么要冻?因为开发阶段的成本结构是"漏斗型"的。需求变一下,设计要改、代码要改、测试要改、样机要重做,已经做的库存要报废,客户承诺要重新谈。我在某客户那里看到过一组数据:开发阶段中后期的一个需求变更,平均成本是早期的 5-8 倍,周期延长 2-4 周。
华为在 IPD 1.0 阶段(2000-2002 年)踩过一个巨大的需求变更坑。当时华为是"客户要什么就给什么",任正非和销售出去见客户,回来就是一堆新需求,产品"像招手停巴士一样,随招随停"。结果:质量没保障,客户升级后老特性丢了,操作界面改来改去,客户怨声载道。
2）需求变更的三种类型
华为把开发阶段的需求变更分成 A、B、C 三类,对应不同的处理流程:
A 类变更:重大变更,影响产品包需求、影响关键架构、影响上市时间。这类变更必须升级到 IPMT 决策,可能引发 PDCP 重新评审。
B 类变更:中等变更,影响单个模块或子系统,不影响产品包需求和上市时间。这类变更由 PDT 经理决策,变更控制委员会(CCB)评审。
C 类变更:小变更,不影响架构,只影响实现细节(代码局部优化、文档修订、UI 微调)。这类变更由模块负责人决策,QA 备案即可。
3）需求变更申请单模板
这里我贴一个我们给客户用过的需求变更申请单（不便公开，感兴趣者可联系安谋咨询获取）。
4）变更控制委员会(CCB)的运作规则
CCB 不是个大会,是个小组,通常由以下角色组成:
CCB 的会议规则:
华为在变更控制上有一个特别狠的做法:任何 B 类以上变更,必须经过 SE 经理的"双向追溯"验证。也就是:这个变更在产品包需求→设计规格→设计实现→测试用例的链条上,每一个节点都要有明确的对应关系。如果 SE 经理说"找不到对应点",变更直接打回。
1）TR4:模块/系统评审
时机:详细设计完成后、SDV 启动前
核心问题:详细设计是否完整、可实现,模块/系统方案是否可行
输出:TR4 模块/系统设计评审报告
TR4 评审的典型问题清单(节选自某客户版本,共 80+ 项):
| 检查项 | 责任代表 | 通过标准 |
|---|---|---|
| 详细设计文档是否完整归档? | SE | 100% |
| 接口定义是否经过相关模块会签? | SE | 100% |
| 关键器件选型是否有 2 家以上供应商? | 采购 | 100% |
| 单元测试覆盖率是否达标? | 测试 | ≥90% |
| 致命/严重缺陷是否已闭环? | 测试 | 100% |
| DFMEA 是否完成并经过评审? | 质量 | 100% |
| 整机成本是否在目标范围内? | 财务 | ±5% |
| 安规/EMC/防护设计是否完成? | 质量 | 100% |
| ID/CMF 是否满足客户外观需求? | 结构 | 100% |
| 工艺可制造性是否经过评审? | 工艺 | 100% |
2）TR4A:系统设计验证(SDV)评审
时机:SDV 测试完成后、SIT 启动前
核心问题:SDV 测试结果是否满足子系统级要求,是否可以进入整机集成
输出:TR4A SDV 评审报告
TR4A 评审的特殊性在于:它要检查的不是"设计有没有",而是"实物有没有按设计做出来"。SDV 测试发现的致命/严重缺陷必须 100% 闭环,才能进入 SIT。
TR4A 评审的典型问题清单:
| 检查项 | 责任代表 | 通过标准 |
|---|---|---|
| SDV 测试用例执行覆盖率? | 测试 | ≥98% |
| 致命/严重缺陷清零? | 测试 | 100% |
| 关键性能指标(功耗、温度、时序)是否达标? | SE/研发 | 100% |
| EMC/安规/可靠性测试是否完成? | 质量 | 100% |
| SDV 遗留问题是否有改进计划? | PDT 经理 | 100% |
| 试制首批样机质量是否稳定? | 工艺 | 良率≥80% |
| BBFV/BBIT 报告是否完整归档? | 测试 | 100% |
3）TR5:样机评审
时机:SIT 测试完成后、验证阶段(ADCP)前
核心问题:整机是否满足产品包需求,是否可以进入小批量试制和发布准备
输出:TR5 样机评审报告
TR5 是开发阶段的"毕业考试",通过后 PDT就要准备 ADCP 决策材料。
TR5 评审的典型问题清单:
| 检查项 | 责任代表 | 通过标准 |
|---|---|---|
| SIT 测试用例执行覆盖率? | 测试 | ≥98% |
| SIT 致命/严重缺陷清零? | 测试 | 100% |
| 产品包需求实现率? | SE | 100% |
| 整机成本是否达成目标? | 财务 | 100% |
| 制造工艺文件是否就绪? | 工艺 | 100% |
| Beta 测试客户是否就绪? | 市场 | 已签约 |
| 客户服务支持计划是否完成? | 服务 | 已评审 |
| 培训材料是否准备就绪? | 服务 | 已发布 |
| 市场推广样机是否到位? | 市场 | 已交付 |
| 量产物料采购是否落实? | 采购 | 100% |
1) ADCP 在开发阶段的位置
ADCP(Availability Decision Check Point,可获得性决策评审)是开发阶段结束的标志,也是产品上市的"准生证"。ADCP 通过后,产品才能进入发布阶段,开始批量发货。
ADCP 的决策主体是 IPMT,由 IPMT 主席(通常是产品线总裁)主持。PDT 经理要做 30-60 分钟的汇报,IPMT 现场决策"通过/有条件通过/不通过"。
2）ADCP 评审材料清单
【ADCP 决策材料清单】
1. 项目状态报告
- 关键里程碑达成情况
- 实际成本 vs 预算
- 实际进度 vs 计划
- 风险与问题清单
2. 技术状态报告
- TR4/TR4A/TR5 评审结论
- 关键性能指标达成情况
- 遗留问题清单与改进计划
3. 商业状态报告
- 市场规模与份额预估
- 竞争分析更新
- 定价与盈利模型
4. 制造准备评估报告
- 生产线就绪情况
- 工艺验证结果
- 量产良率预估
- 物料齐套情况
5. 市场准备评估报告
- 推广计划就绪情况
- 销售渠道就绪情况
- Beta 测试客户反馈
- NPS(净推荐值)数据
6. 服务准备评估报告
- 客户支持体系就绪情况
- 培训材料发布情况
- 备件储备情况
7. 财务分析报告
- 项目总投入
- 预期销售收入与利润
- ROI/NPV 计算
- 投资回收期
8. 风险与建议
- 残余风险清单
- IPMT 决策建议(通过/有条件通过/不通过)3）ADCP 决策的三种结果
通过:产品可以上市,启动量产和市场发布。
有条件通过:产品在某些方面不达标,IPMT 给出具体整改要求,PDT 整改后报 IPMT 主席签字,可上市。
不通过:产品存在重大缺陷或市场条件不成熟,暂停上市,PDT 整改后重新发起 ADCP。
我见过的客户案例里,ADCP不通过的情况占 15-20%,其中一半是因为成本超支,一半是因为遗留问题太多。ADCP不通过是IPD体系最重要的"刹车",没有这个刹车,问题会一路拖到客户现场。
开发阶段里,IPMT 不直接管项目细节,只在 ADCP 节点上做决策。其他时间,IPMT 的角色是:
PDT 在开发阶段是"主心骨",PDT 经理要把所有日常决策都扛下来,包括:
开发阶段的所有输入都来自计划阶段。PDCP 决策通过时,PDT 拿到的是一份"项目合同",这份合同包含:
开发阶段对上游的接口管理,核心是"基线管理"。PDCP 通过后,所有输入文档立即冻结为"基线版本",任何修改必须走 EC 变更控制。
我看到太多公司在开发阶段,经常回去翻计划阶段的需求文档,发现需求写得不清楚,问 SE 经理,SE 经理说"我当时也没想清楚"。这种情况,华为的解法是:计划阶段的 SE 经理必须在开发阶段前期驻场,直到所有需求/规格细节都澄清完毕。这是死规矩。
开发阶段的输出是验证阶段的输入。开发阶段结束(TR5 通过)时,PDT 移交给验证阶段的内容包括:
开发阶段对下游的接口管理,核心是"可移交性检查"。PDT 经理在 ADCP 准备阶段,必须和验证阶段经理(可能是同一个 PDT 经理,可能是新接手的 LMT 经理)做"可移交性评审",确保所有交付物都齐全。
开发阶段不是孤岛,它和 IPD 其他主流程有大量交互。
和需求管理的接口:开发阶段的需求变更,必须经过需求管理流程的变更评估,变更后的需求必须重新进入"需求-规格-设计-测试"的可追溯链。
和技术的接口:开发阶段使用的技术平台、技术组件,来自技术开发流程。开发阶段如果发现技术问题,需要反向触发技术开发流程的优化。
和市场的接口:开发阶段的市场代表要持续收集客户反馈,为 Beta 测试做准备,同时为发布阶段的市场推广奠定基础。
和财务的接口:开发阶段的成本管控由财务代表负责,定期输出实际成本与预算的对比分析。
1）PDT 的角色与职责(开发阶段加强版)
| 角色 | 核心职责 | 关键输出 |
|---|---|---|
| PDT 经理 | 对产品商业成功负总责,管理 PDT 日常运作,主持 TR 评审 | 状态报告、决策建议 |
| SE 经理 | 管理需求/规格/配置变更,组织 TR 评审 | 需求追溯矩阵、变更影响分析 |
| 研发代表(硬件/软件/结构) | 按计划交付详细设计、实现、单元测试 | 设计文档、代码、样机 |
| 测试代表 | 组织 BBFV/SDV/SIT 测试,组织 TR 评审 | 测试方案、测试报告 |
| 财务代表 | 跟踪成本,做成本分析 | 成本月报 |
| 采购代表 | 关键器件采购,供应商管理 | 物料齐套清单 |
| 制造/工艺代表 | 制造工艺开发,试制支持 | 工艺文件、试制报告 |
| 市场代表 | 收集客户反馈,准备推广材料 | 市场需求文档、Beta 计划 |
| 服务代表 | 客户服务支持计划,培训材料 | 服务支持计划、培训材料 |
| QA 代表 | 过程审计,质量数据收集 | 审计报告、质量月报 |
| 配置经理(SCM) | 配置管理,基线管理 | 基线发布记录 |
2）IPMT 在开发阶段的角色
IPMT 在开发阶段是"不插手但有否决权"的存在。具体来说:
很多公司把 IPMT 做成"太上皇",什么都要管,结果 PDT 失去了自主权,所有决策都要升级到 IPMT,效率极其低下。华为的解法是:IPMT 主席在 ADCP 之外的例会出席率要严格控制,只关注战略和资源,不关注执行。
3）LMT 和 CCB 的边界
LMT(Lifecycle Management Team,生命周期管理团队)在开发阶段已经开始介入,主要做"为上市做准备"的工作,包括:
CCB(Change Control Board,变更控制委员会)是开发阶段最活跃的"非正式组织",负责 B/C 类变更的日常评审。CCB 不是个"会",是个"流程",可以一周开多次,也可以通过邮件决策,关键是 24 小时内响应。
说说开发阶段在 IPD 体系中的特殊地位。
前面四个阶段(概念、计划)都是"纸面工作",发布和生命周期阶段是"营销和运营工作",只有开发阶段是"真刀真枪的工程工作"。一家公司 IPD 推得好不好,看开发阶段的执行就够了。开发阶段做好了,产品按时按质交付;开发阶段没做好,IPD 就是挂在墙上的流程图。
我这些年见过至少五家公司,IPD 推了三年,概念和计划阶段都很漂亮,一到开发阶段就崩。崩的方式基本是这几种:
崩法一:PDT 扩编扩不起来,核心组还是原来几个人,扩展组没人干活。解法:PDT 经理必须有"虚拟决策权",能跨部门抽人。
崩法二:TR 评审走过场,所有评审都是"通过"。解法:TR 评审必须有外部专家参与,内部专家必须有否决权记录。
崩法三:需求变更失控,一周改三次需求。解法:CCB 必须 24 小时响应,所有变更必须有量化影响评估。
崩法四:开发阶段延期,PDT 经理报喜不报忧。解法:PDT 经理月度向 IPMT 报告,IPMT 主席要亲自盯关键里程碑。
崩法五:开发阶段"救火"文化盛行,工程师天天加班但没产出。解法:严格控制工作范围,不允许英雄主义,让英雄"无聊"才能批量产出。
这五种崩法,每一个我都见过真实案例,说出来都是泪。
如果你的企业正在推 IPD,或者准备推,基于我在开发阶段陪客户踩过的坑,给你五点实操建议:
建议一:不要在开发阶段"全功能上 IPD",先做 TR 评审和变更控制。开发阶段最大的两个价值点是 TR 评审和变更控制,这两件事投入不大、收益明显,可以先做。
建议二:PDT 经理培养比流程建设更重要。流程可以照搬,PDT 经理的能力培养不了。我见过一家公司流程做得跟华为一模一样,但 PDT 经理天天被部门经理拽走开会,根本管不了项目。
建议三:TR 评审材料模板要细化到字段级别。我前面贴的 TR4/TR4A/TR5 检查清单,每一个字段都要变成"必填项",不能是"参考项"。
建议四:变更控制要"轻流程重决策"。变更控制不是走流程,是为了做决策。CCB 的存在是为了让 PDT 经理快速做决策,不是为了拖慢决策。
建议五:开发阶段要有"可量化的退出标准"。什么叫开发阶段结束?不是日历上写的时间到了,是 TR5 通过 + ADCP 通过。两者缺一,产品不能进入发布阶段。
任正非说,IPD是把研发从艺术变成科学。我想接着任总的话后再加一句:开发阶段,是 IPD体系里最不性感、但最值钱的一段。
【 -END- 】
如需要开展华为IPD流程体系等培训和咨询项目的，请联系我们的学习顾问：directorniu (个人微信)
更多精选相关好文：
安谋咨询2026年度精选文章合集
华为IPD技术与平台规划TPP详解：框架、流程、内容、方法工具与运作
深度拆解华为IPD客户需求管理OR体系
华为IPD产品立项任务书（Charter开发）CDP流程详解
华为集成产品开发小IPD结构化流程详解：框架、内容、工具方法、组织、运作
深度拆解华为IPD决策评审DCP和技术评审TR：框架、内容、流程、运作、实战
华为IPD流程概念阶段深度拆解：从"做不做"到"怎么做"的产品投资决策逻辑
IPD咨询实操：华为IPD流程计划阶段深度研究
华为IPD体系下的MPP（营销计划流程）：打通从理解市场到产品上市
华为IPD体系下产品生命周期管理详解：从上市到退市的端到端经营逻辑
别再拍脑袋定价了！深度拆解华为IPD体系下的成本测算与定价机制
华为集成产品开发IPD质量管理体系详解：框架、内容、流程、方法工具、运作
华为IPD产品研发项目管理详解：框架、流程、内容、方法工具和运作
基于华为IPD体系的CBB（共用基础模块）复用技术库详解
华为IPD体系DFx详解：框架、流程、内容、方法工具、组织运作
华为IPD BOM与配置管理：复杂产品开发中的数据治理核心
深度拆解IPD流程中基线管理：框架、流程、内容、工具、组织运作
华为IPD中PDC组合决策与研发资源管道管理：解决项目选择与资源配置难题
【关于安谋咨询】
北京安谋管理咨询有限公司（简称“安谋咨询”）是专业传播华为管理理念和方法论的高端管理咨询和培训品牌，创立于2015年，核心合伙人10+来自于华为、中兴、腾讯、联想等世界500强知名企业，并担任过企业高管岗位。他们大都经历过华为管理变革期，掌握先进的咨询知识和实战经验，如IPD/LTC/ITR/MTL/ISC等。
安谋咨询是一家综合性的管理咨询和培训公司，业务涵盖战略、营销、研发、供应链、组织、人力资源、流程等专业领域，能够为客户提供从初创期到转型期的持续、全面陪跑服务。我们成立11年来服务过150多家企业，涵盖通信、半导体、电子、信息系统集成、家电、汽车、智能制造、高端装备、新能源、物流、快消品……等行业，对这些行业有丰富的洞察和理解。
我们奉行以客户为中心，本着为客户创造价值、与客户共同成长的价值理念，致力于成为客户成功路上的价值合作伙伴，对咨询方案在客户的落地效果进行操作级指导，长期战略合作客户超过30%。