IPD咨询实操：华为IPD流程计划阶段深度研究

引言：一个被严重低估的阶段

如果你问华为的研发人员，IPD流程六个阶段中哪一个最容易被忽视、却又最能决定项目成败，十有八九会指向同一个答案—计划阶段。

这不是危言耸听。在华为二十多年的IPD实践中，有太多项目因为计划阶段的草率而在开发阶段付出惨痛代价：需求反复变更导致代码推倒重来，系统架构设计缺陷在验证阶段才发现，关键器件选型失误造成采购周期失控，资源估算不足让团队连续加班三个月……这些问题的根源，往往都可以追溯到计划阶段那8到12周的工作是否真正做扎实了。

计划阶段在IPD流程中的定位非常清晰：它是概念阶段的”验证器”，也是开发阶段的”导航图”。如果说概念阶段回答的是”要不要做”和”做什么”，那么计划阶段回答的就是”怎么做”、“花多少钱做”、“多长时间做完”以及”能不能做成”。这个阶段的核心使命，用华为内部的话说，就是”把方案想清楚、把计划做扎实”。

本文将围绕华为IPD流程的计划阶段展开深度研究，从IPD体系的整体框架出发，回溯华为引入IPD的历史背景，详细拆解计划阶段的每一项核心工作，深入分析PDCP决策评审的运作机制，并探讨计划阶段与IPD其他部分的协同关系。文中会穿插安谋咨询及行业内的真实案例，力求为读者呈现一幅关于IPD计划阶段的完整图景。

---

一、IPD流程体系概览

1.1 什么是IPD

IPD，全称Integrated Product Development，中文译为”集成产品开发”。这个概念最早由美国PRTM咨询公司在20世纪80年代提出，其前身是PACE（Product And Cycle-time Excellence，产品及周期优化法）。1992年，IBM公司在面临严重经营危机时，引入并实践了这套方法论，经过两年多的变革，IBM在1994年总结提炼出了完整的IPD体系，随后这套体系被全球众多高科技企业所采纳。

IPD的本质，是一套将产品经营管理思想嵌入到新产品开发全过程的方法论。它不仅仅是研发管理流程，更是一套完整的产品经营管理体系。IPD的核心理念可以概括为几个关键词：

结构化流程：产品开发被明确划分为概念、计划、开发、验证、发布、生命周期六个阶段，每个阶段有清晰的目标、活动和交付物，阶段之间通过决策评审点（DCP）进行控制。

客户需求驱动：IPD强调从市场需求出发，而非从技术能力出发来定义产品。需求管理贯穿IPD全流程，确保开发的产品是市场真正需要的。

跨部门团队运作：打破部门墙，组建跨职能的产品开发团队（PDT），由PDT经理对产品的商业成功负责，各功能领域代表对各自领域的交付负责。

基于事实的决策：通过结构化的评审机制（包括DCP决策评审和TR技术评审），在每个关键节点基于数据和事实做出继续、调整或终止的决策，避免”拍脑袋”式的产品投资决策。

1.2 华为IPD的演进历程

华为引入IPD的故事，是中国企业管理变革史上的经典案例。

1998年，任正非在考察了IBM之后，做出了一个在当时看来极为大胆的决定：花20亿人民币（相当于华为当时一年的利润）请IBM顾问团队帮助华为进行IPD变革。这个数字在今天看来或许不算什么，但在那个年代，对于一家年营收不到百亿的民营企业来说，这无疑是一场豪赌。

任正非的判断基于一个残酷的现实：华为当时的研发管理存在严重问题。产品线各自为战，重复开发严重；项目成功率低，大量产品做出来卖不动；开发周期失控，承诺的上市时间一再推迟；跨部门协作困难，“铁路警察各管一段”……这些问题让任正非深刻意识到，华为必须从”游击队”式的研发模式转向”正规军”式的管理体系。

IPD变革在华为经历了三个阶段：

第一阶段（1999-2003年）：僵化学习。华为完全按照IBM顾问的方法论和模板来执行，即使觉得不合理也不做修改，先学会、再优化。这个阶段充满了阵痛，很多老员工不适应，甚至有人说”IBM那一套在华为水土不服”。但任正非的态度非常坚决：“先僵化、后优化、再固化。”

第二阶段（2003-2010年）：优化适配。在掌握了IPD的核心精髓后，华为开始结合自身业务特点进行优化。比如针对运营商业务的定制化需求，华为在IPD基础上发展了解决方案开发流程；针对消费者业务的快速迭代需求，华为引入了敏捷开发方法，与IPD形成了”双模”运作。

第三阶段（2010年至今）：持续进化。华为的IPD体系已经升级到IPD 3.0阶段，从最初的新产品开发（IPD 1.0），到新解决方案开发（IPD 2.0），再到新商业机会开发（IPD 3.0），IPD的内涵和外延都在不断扩展。同时，华为还将IPD与DSTE（从战略到执行）、LTC（从线索到回款）、ITR（从问题到解决）等流程深度集成，形成了端到端的企业运营管理体系。

1.3 IPD流程的六个阶段

华为的IPD产品开发流程（狭义的IPD流程）分为六个阶段，每个阶段都有明确的目标和边界：

这六个阶段构成了一个完整的”喇叭形”流程：前端（概念和计划阶段）投入资源较少，但决策影响最大；后端（开发和验证阶段）投入资源最多，但决策弹性最小。这种设计体现了IPD”分阶段投资、控制风险”的核心思想。

---

二、计划阶段的定位与核心目标

2.1 计划阶段在IPD流程中的战略位置

计划阶段是IPD流程的第二阶段，它承上启下，既是概念阶段的深化和验证，又是开发阶段的前提和约束。用建筑行业的比喻来说，概念阶段是在画草图、选地块，计划阶段则是在做施工图纸、编预算、排工期，开发阶段才是真正的破土动工。

计划阶段的战略重要性体现在以下几个方面：

第一，它是投资决策的关键节点。 在概念阶段，IPMT（集成组合管理团队）基于初步的商业论证做出”继续投资”的决策（CDCP）。但这个决策是相对粗略的，因为概念阶段的商业计划（O/SBP）包含大量假设。计划阶段的核心任务之一，就是把这些假设逐一验证，形成一份经得起推敲的详细商业计划。PDCP评审时，IPMT要基于这份计划做出是否”大额投资”的决策——一旦通过，就意味着要投入大量研发资源，后续变更成本极高。

第二，它是技术方案的定型期。 概念阶段确定了产品的”概念”，但这个概念是方向性的、粗线条的。计划阶段要把概念转化为可执行的系统方案，完成从需求到规格、从规格到架构、从架构到模块的层层分解。如果在计划阶段没有把架构设计清楚，开发阶段就会陷入”边设计边开发”的混乱状态，导致大量的返工和变更。

第三，它是项目计划的基准期。 计划阶段要制定端到端的详细项目计划，包括WBS分解、资源估算、进度安排、预算编制等。这份计划一旦通过PDCP评审，就成为后续执行的基准。华为内部有个说法：“计划阶段不扎实，开发阶段就是救火。”很多项目的延期和超支，根源都在于计划阶段的估算过于乐观或过于粗糙。

2.2 计划阶段的主要目标

根据华为IPD流程的定义，计划阶段的目标可以归纳为五个”清晰”：

清晰定义产品方案及其竞争优势。 计划阶段要基于选定的产品概念，完成系统架构设计和技术规格定义，明确产品的核心卖点和竞争策略。这个”清晰”不是概念层面的，而是要细化到每一个功能模块、每一项性能指标、每一个接口定义。

清晰完成需求规格化。 将概念阶段的市场需求、客户需求转化为详细的产品需求规格（PRD），并通过需求分解分配（RDM）将系统级需求逐层分解到子系统、模块和单板级别，确保需求无遗漏、无歧义、可验证。

清晰制定项目计划。 基于确定的系统方案和模块划分，从下到上制定端到端的WBS详细计划，包括开发计划、测试计划、采购计划、制造计划、营销计划等，并明确各阶段的里程碑和关键路径。

清晰评估和管理风险。 对技术风险、供应链风险、市场风险、资源风险等进行深入评估，制定详细的风险应对预案。特别要关注关键技术是否已突破、关键器件是否可获得、关键资源是否到位。

清晰完成商业论证深化。 基于确定的方案和计划，更新商业计划（O/SBP），完成更精确的投资回报测算、盈亏平衡分析、现金流预测等，为IPMT的投资决策提供可靠依据。

2.3 计划阶段的典型周期与投入

根据安谋咨询的经验数据估算，计划阶段的标准周期是8到12周。这个时间不是拍脑袋定的，而是基于大量项目实践总结出来的经验值—太短了做不扎实，太长了会丧失市场窗口。

计划阶段的资源投入相对于开发阶段来说是比较小的，但人员配置要求很高。PDT核心团队（包括PDT经理、开发代表、市场代表、制造代表、采购代表、财务代表、质量代表、服务代表等）需要全职或高比例投入，同时会根据需要引入系统工程师（SE）、架构师、关键模块负责人等扩展组成员。

计划阶段的投入产出比是非常高的。华为内部有个不成文的统计：计划阶段每多投入1周时间，开发阶段平均可以减少2到3周的返工时间。这个账算下来，计划阶段的”慢”实际上是为了开发阶段的”快”。

---

三、计划阶段核心工作详解：五大主线

计划阶段的工作看似繁杂，但归纳起来可以梳理为五条主线：需求规格化、系统设计、项目计划制定、风险评估、商业论证深化。这五条主线相互交织、相互依赖，共同构成计划阶段的完整工作内容。

3.1 主线一：需求规格化—从”要什么”到”怎么做”

1）需求规格化的本质

需求规格化是计划阶段的第一项核心工作，它的本质是将概念阶段相对模糊的市场需求转化为精确、可验证、可追踪的产品需求规格。

很多企业对”需求”的理解停留在”客户说要什么就做什么”的层面，这种理解是有问题的。在IPD体系中，需求是分层的：

• 市场需求（MR）：来自市场分析、客户访谈、竞争分析等，描述的是”市场需要什么”。

• 产品包需求（PPR）：将市场需求与内部需求（可制造性、可服务性、可测试性等）整合，描述的是”产品应该具备什么能力”。

• 设计需求（DR）：将产品包需求转化为设计层面的需求，描述的是”系统/子系统/模块应该如何实现”。

计划阶段的核心任务，就是完成从PPR到DR的转化，并通过需求分解分配（RDM）将系统级需求逐层分解到子系统、模块和单板。

2）需求分解分配（RDM）的方法

需求分解分配是IPD中一个非常关键的技术管理活动。它的核心思想是：将高层次的、抽象的需求逐层分解为低层次的、具体的需求，并将每一条需求分配到具体的责任模块。

RDM的典型做法是这样的：

第一步：建立需求追踪矩阵（RTM）。 这是一个从市场需求到设计需求、从设计需求到测试用例的完整追踪链条。RTM的核心价值在于：当某个市场需求发生变更时，可以快速定位到哪些设计需求和测试用例会受到影响。

一个简化的RTM模板如下：

第二步：进行功能分解。 系统工程师（SE）牵头，基于产品概念和系统架构，将产品包需求分解为子系统需求、模块需求。分解的原则是：每一条需求都必须有明确的归属模块，且模块之间的接口要清晰定义。

第三步：进行性能分配。 对于性能类需求（如吞吐量、时延、功耗、可靠性等），需要将系统级指标分解到各子系统和模块，并预留一定的设计余量。这个过程需要大量的仿真和估算。

第四步：进行需求验证。 分解完成后，需要组织评审，验证分解的完整性（是否有遗漏）、一致性（是否有矛盾）、可实现性（是否超出了当前技术能力）。

3）一个真实的教训：某通信设备的需求遗漏

这里讲一个华为内部的案例（已脱敏处理）。

某年，华为某产品线开发一款面向欧洲运营商的基站产品。在概念阶段，市场代表收集了大量客户需求，包括频段支持、容量、功耗、尺寸等。计划阶段进行需求分解时，团队重点关注了技术性能指标，却忽略了一个”隐性需求”—欧洲部分国家对基站设备的电磁辐射有严格的法规限制，要求设备必须通过特定的SAR（比吸收率）认证。

这个需求在概念阶段没有被明确提出（客户认为”这是基本要求，不需要特别说明”），在计划阶段的需求分解中也没有被识别出来。结果产品进入开发阶段后，在进行认证预测试时才发现这个问题。为了通过SAR认证，需要对射频前端的设计进行大幅修改，包括更换部分器件、调整天线布局、增加屏蔽措施等。

这次遗漏的代价是：开发周期延长了4个月，直接成本增加了800多万人民币，更重要的是错过了客户的招标窗口，导致该产品在欧洲市场的首批订单损失了近3000万美元。

这个案例的教训是：需求规格化不能只看”显性需求”，还要挖掘”隐性需求”；不能只关注技术需求，还要关注法规需求、合规需求、可服务性需求等。华为后来在这个产品线的IPD流程中专门增加了一个环节：在计划阶段组织”法规合规评审”，由法务、认证、服务等部门共同审查需求清单，确保没有遗漏。

3.2 主线二：系统设计—从”概念”到”蓝图”

1）系统设计的层次

系统设计是计划阶段技术含量最高的工作，它决定了产品的技术架构、模块划分和接口定义。在华为IPD中，系统设计分为三个层次：

系统架构设计（TR1-TR2之间）： 在概念阶段完成初步架构评估后，计划阶段要对系统架构进行深化设计。这包括确定产品的总体技术路线、核心算法选择、硬件平台选型、软件架构设计等。对于新平台、新架构的产品，还需要组织专门的架构评审。

概要设计（TR2-TR3之间）： 在系统架构确定后，进行各子系统和模块的概要设计。概要设计要定义模块的功能、接口、性能指标、关键技术点等，但不涉及具体的电路设计或代码实现。

接口设计（贯穿全程）： 模块之间的接口设计是系统设计的核心难点之一。接口设计不当会导致模块耦合度过高、集成困难、测试复杂等问题。华为的做法是：在概要设计阶段就定义清晰的模块接口规范（包括物理接口、电气接口、软件接口、协议接口等），并通过接口控制文档（ICD）进行管理。

2）技术评审TR2和TR3

在计划阶段，有两个关键的技术评审点：

TR2（需求评审）： 评审产品包需求是否完整、准确、可验证，以及需求分解分配是否合理。TR2的通过标志着需求基线确立，后续的需求变更需要通过正式的变更控制流程。

TR3（概要设计评审）： 评审系统概要设计是否满足需求规格，架构设计是否合理，模块划分是否清晰，接口定义是否完整。TR3的通过标志着概要设计基线确立，可以进入详细设计阶段。

这两个评审不是走过场。在华为，TR评审有明确的通过标准，包括：评审问题清单全部关闭、遗留问题有明确的解决计划、风险已识别并有应对措施等。如果TR评审不通过，项目不能进入下一阶段。

3）架构设计的决策框架

在计划阶段，经常需要在多个技术方案之间做选择。华为使用一个结构化的决策框架来评估备选方案：

这个框架的关键在于：评估维度要根据产品特点来定制，权重要反映公司的战略优先级，评分要基于客观数据而非主观感觉。在华为，这类决策通常由系统工程师牵头，组织跨领域专家进行评分，最终由PDT经理决策。

4）案例：某服务器产品的架构选型

某年，华为服务器产品线计划开发一款面向云计算市场的高密度服务器。在计划阶段，团队面临一个关键的架构选择：是采用传统的”整机柜”架构，还是采用创新的”模块化”架构？

整机柜架构的优势是技术成熟、供应链稳定、成本可控；劣势是扩展性差、维护复杂、功耗优化空间有限。模块化架构的优势是灵活扩展、便于维护、可以针对不同场景定制配置；劣势是技术风险高、需要重新设计供应链、初期成本较高。

PDT组织了一次架构评审，邀请了研发、采购、制造、服务、市场等领域的专家。经过多轮讨论和评分，团队最终选择了模块化架构，但采取了”分步实施”的策略：第一期先实现基础模块化，验证技术可行性；第二期再实现高级模块化功能。

这个决策后来被证明是正确的。模块化架构使该产品在云计算市场获得了显著的竞争优势，客户可以根据业务需求灵活配置计算、存储、网络资源，维护效率提升了40%以上。虽然第一期开发比原计划多花了2个月时间，但产品上市后迅速成为该细分市场的爆款，第一年就实现了盈亏平衡。

3.3 主线三：项目计划制定—从”大概”到”精确”

1）端到端WBS计划

项目计划制定是计划阶段最耗时、最细致的工作。华为采用的是端到端WBS（Work Breakdown Structure，工作分解结构）计划方法，将产品开发的全流程工作逐层分解到可管理、可度量的工作包。

WBS的分解原则是：

• 100%原则：WBS要覆盖项目全部工作，不能有遗漏。

• MECE原则：各工作包之间要相互独立（Mutually Exclusive）、完全穷尽（Collectively Exhaustive）。

• 可管理原则：最底层工作包的工期一般不超过40小时（即一个人一周的工作量），便于跟踪和控制。

• 责任明确原则：每个工作包都有明确的责任人。

在华为，WBS通常分解为4到5级：

• L1级：阶段级（如计划阶段、开发阶段、验证阶段）

• L2级：领域级（如硬件开发、软件开发、测试验证、制造准备、营销准备）

• L3级：活动级（如硬件概要设计、硬件详细设计、PCB设计、单板调试）

• L4级：任务级（如完成原理图设计、完成PCB布局、完成信号完整性仿真）

• L5级：工作包级（如完成CPU模块原理图、完成电源模块PCB布局）

2）三级计划体系

华为的IPD项目计划采用”三级计划”体系：

公司级计划（L1-L2）： 由PDT经理负责，关注关键里程碑和端到端的进度安排。这个层级的计划通常只包含20到30个关键节点，用于向IPMT汇报。

领域级计划（L2-L3）： 由各功能领域代表负责，关注本领域的详细工作安排。例如，开发代表负责硬件和软件的开发计划，制造代表负责制造准备计划，市场代表负责营销计划。

个人级计划（L3-L5）： 由具体执行人员负责，关注日常工作的安排和跟踪。这个层级的计划通常细化到每周甚至每天的任务。

三级计划之间是”从上到下分解、从下到上汇总”的关系。PDT经理制定L1-L2计划后，各代表据此制定L2-L3计划，再分解到L3-L5计划。各层的计划汇总后，PDT经理进行整合和平衡，确保各领域计划之间的衔接和协调。

3）资源计划与预算编制

计划阶段不仅要排进度，还要算清楚需要多少资源、花多少钱。

资源计划包括： - 人力资源：需要多少人、什么技能等级、什么时间到位、投入多少比例。 - 设备资源：需要哪些开发设备、测试设备、仿真工具等。 - 物料资源：需要哪些关键器件、模块、原材料，采购周期多长。 - 场地资源：需要多少实验室空间、办公空间等。

预算编制包括： - 研发费用：人员工资、设备折旧、材料费、外包费等。 - 制造费用：工装夹具、产线改造、试产费用等。 - 营销费用：市场调研、品牌推广、渠道建设等。 - 管理费用：项目管理、质量保障、知识产权等。

在华为，预算编制采用”自下而上”的方法：各模块负责人估算本模块的开发成本，汇总到领域代表，再汇总到PDT经理，最后形成项目的总体预算。这个预算要与商业计划中的投资回报测算相匹配，如果预算超出了商业计划中的预期投入，就需要重新审视方案或商业假设。

4）关键路径分析

在WBS计划制定完成后，PDT需要进行关键路径分析（Critical Path Method, CPM），找出决定项目总工期的关键任务链。

关键路径分析的价值在于： - 识别项目的”瓶颈”，将管理重点放在关键路径上的任务。 - 评估进度风险，如果关键路径上的任务延期，整个项目就会延期。 - 优化资源配置，通过增加资源或调整逻辑关系来缩短关键路径。

在华为，关键路径分析是PDT经理的”必修课”。一个典型的做法是：在计划阶段，PDT经理每周组织一次关键路径审视会，跟踪关键任务的进展，及时识别和解决可能导致延期的风险。

5）计划阶段计划模板示例

以下是一个简化的计划阶段项目计划模板框架：

【项目计划书】

一、项目概述
   1.1 项目背景与目标
   1.2 产品范围与边界
   1.3 关键里程碑

二、WBS分解
   2.1 L1-L2级工作分解
   2.2 关键路径识别
   2.3 里程碑定义（含准入/准出标准）

三、进度计划
   3.1 总体进度安排（甘特图）
   3.2 各领域详细进度计划
   3.3 关键路径任务清单

四、资源计划
   4.1 人力资源计划（含技能矩阵）
   4.2 设备与工具计划
   4.3 物料与采购计划（含长货期物料清单）

五、预算计划
   5.1 研发费用预算
   5.2 制造费用预算
   5.3 营销费用预算
   5.4 预算汇总与现金流预测

六、风险管理计划
   6.1 风险识别清单
   6.2 风险评估矩阵
   6.3 风险应对措施与责任人

七、沟通计划
   7.1 会议机制（周会、月度评审、里程碑评审）
   7.2 报告机制（日报、周报、月报）
   7.3 问题升级机制

八、质量管理计划
   8.1 质量目标与度量指标
   8.2 技术评审计划（TR2、TR3等）
   8.3 测试策略与测试计划

九、依赖关系与接口管理
   9.1 内部依赖关系（跨模块、跨领域）
   9.2 外部依赖关系（供应商、合作方、第三方）
   9.3 接口控制计划

十、变更管理计划
   10.1 变更控制流程
   10.2 变更影响分析模板
   10.3 变更审批权限

3.4 主线四：风险评估—从”可能出问题”到”出了怎么办”

1）IPD中的风险管理理念

IPD强调”风险前置”，即在项目早期识别和评估风险，而不是等到问题发生了再去救火。计划阶段是风险管理的黄金窗口期，因为此时方案尚未定型、资源尚未大量投入，调整的成本相对较低。

华为的风险管理遵循”识别-评估-应对-监控”的闭环：

风险识别： 通过头脑风暴、历史项目复盘、专家访谈、检查清单等方法，全面识别项目可能面临的风险。

风险评估： 对识别出的风险进行定性和定量评估，确定风险的概率和影响程度，排序后聚焦高优先级风险。

风险应对： 针对每个高优先级风险，制定具体的应对措施，包括规避、转移、减轻、接受四种策略。

风险监控： 在项目执行过程中持续跟踪风险状态，及时更新风险清单，对新出现的风险进行识别和评估。

2）风险评估矩阵

华为常用的风险评估矩阵如下：

风险等级划分： - 红色（15-25分）：高风险，必须制定详细应对计划，并上报IPMT关注。 - 黄色（8-14分）：中风险，需要制定应对措施，由PDT经理跟踪。 - 绿色（1-7分）：低风险，保持关注即可。

3）计划阶段重点关注的五类风险

在计划阶段，PDT需要重点关注以下五类风险：

技术风险： 关键技术的成熟度如何？是否已有原型验证？技术方案的可行性是否有把握？如果技术方案失败，有没有备选方案？

供应链风险： 关键器件的供应商是否可靠？是否有第二供应商？采购周期是否满足项目进度？器件价格是否有大幅波动的风险？

资源风险： 核心人员是否能到位？关键技能是否具备？如果核心人员离职或调离，有没有备份？

市场风险： 市场需求是否会发生变化？竞争对手是否会有重大动作？政策法规是否会有调整？

进度风险： 关键路径上的任务是否有延期风险？外部依赖（如供应商交付、客户确认等）是否可控？

4）案例：某芯片项目的风险应对

某年，华为海思计划开发一款高端网络处理器芯片。在计划阶段的风险评估中，团队识别出一个高风险项：该芯片采用的最先进制程工艺（7nm）在当时全球只有台积电一家能够量产，且产能非常紧张，排期存在很大不确定性。

这个风险的评估结果是：发生概率”高”（4分），影响程度”灾难性”（5分），风险等级20分（红色）。

PDT制定了以下应对措施：

1. 规避策略：与台积电提前签订产能预留协议，锁定部分产能。

2. 减轻策略：同时与三星接触，评估其7nm工艺的兼容性，作为备选方案。

3. 转移策略：将部分非核心功能模块采用成熟制程（14nm）实现，降低对最先进制程的依赖。

4. 应急计划：如果台积电产能无法保障，启动”分片流片”方案，即先流片核心模块验证，再流片全片，虽然会增加一次流片成本，但可以缩短整体周期。

这些措施在后来被证明是非常有价值的。在芯片开发过程中，确实遇到了台积电产能紧张的问题，但由于提前做了准备，项目只延期了1个月（而不是可能的6个月以上），最终产品成功上市并获得了市场认可。

3.5 主线五：商业论证深化—从”大概能赚”到”算清楚”

1）商业计划的更新与深化

概念阶段的商业计划（O/SBP，Offering/Solution Business Plan）是基于大量假设的初步测算。计划阶段的核心任务之一，就是基于确定的方案和计划，将这些假设逐一验证或修正，形成一份更加可靠的详细商业计划。

商业计划深化的内容包括：

市场预测更新： 基于最新的市场数据和竞争态势，更新销量预测、市场份额预测、价格预测等。

成本测算细化： 基于确定的BOM（物料清单）和设计方案，精确测算产品的制造成本、研发成本、营销成本等。

投资回报测算： 基于更新的销量和成本数据，重新计算NPV（净现值）、IRR（内部收益率）、投资回收期等指标。

盈亏平衡分析： 计算产品的盈亏平衡点销量，评估市场预测是否足以支撑盈利。

现金流预测： 预测项目全生命周期的现金流入和流出，评估公司的资金压力。

2）商业计划的关键财务指标

在华为，商业计划的核心财务指标包括：

这些指标不是孤立的，需要综合分析。例如，一个项目的NPV很高，但投资回收期很长，对于现金流紧张的公司来说可能就不是好项目；反之，一个项目的IRR很高，但绝对规模很小，对公司的整体贡献也有限。

3）案例：某企业网产品的商业论证

某年，华为企业BG计划开发一款面向中小企业的统一通信产品。在概念阶段，初步的商业计划显示：预计售价5000元/台，年销量10万台，毛利率35%，NPV为1.2亿元，看起来是个不错的项目。

进入计划阶段后，随着方案的细化和市场调研的深入，团队发现了几个关键问题：

1. 成本测算偏差：初步测算的BOM成本为2800元，但详细设计后发现，为了保证语音质量和稳定性，需要采用更高规格的音频编解码芯片和回声消除模块，BOM成本实际为3200元。

2. 价格压力：竞争对手在该细分市场已经推出了类似产品，定价在4500元左右，为了获得市场份额，华为产品的定价需要下调到4200元。

3. 销量预测调整：考虑到中小企业的采购周期较长、渠道建设需要时间，第一年的销量预测从10万台下调到6万台。

基于这些更新，团队重新进行了财务测算：

这个结果让PDT经理非常纠结。NPV仍然是正的，但毛利率远低于企业BG的基准线（30%），IRR也接近最低可接受标准。PDT内部产生了激烈争论：一部分人认为应该继续推进，因为该产品可以完善华为在企业通信领域的产品布局，具有战略价值；另一部分人认为应该终止项目，因为财务回报不达预期，且会稀释整体毛利率。

最终，PDT经理将这个问题提交给了IPMT。IPMT在PDCP评审中进行了详细讨论，综合考虑了战略价值和财务回报后，做出了”有条件继续”的决策：要求PDT在开发阶段将BOM成本降低10%（通过器件替代和设计方案优化），同时市场代表要制定详细的渠道拓展计划，确保第二年销量达到8万台。如果开发阶段中期评估显示这两个目标无法达成，项目将被终止。

这个案例体现了IPD”基于事实决策”的精髓：计划阶段的商业论证不是走过场，而是真正影响投资决策的关键依据。当假设被证伪时，要有勇气重新审视项目的可行性，而不是”为了立项而立项”。

---

四、PDCP决策评审：计划阶段的”期末考试”

4.1 PDCP的定位与意义

PDCP（Planning Decision Check Point，计划决策评审点）是计划阶段的终点，也是整个IPD流程中最重要的决策节点之一。如果说CDCP（概念决策评审点）决定的是”要不要继续投资”，那么PDCP决定的就是”要不要大额投资”。

PDCP的核心意义在于：

第一，它是资源投入的分水岭。 PDCP之前，项目投入的资源相对较少（主要是PDT核心团队的人力投入）；PDCP之后，项目将进入开发阶段，需要投入大量的研发资源（包括硬件开发、软件开发、测试验证、制造准备等），同时可能还需要投入采购资金（长货期物料的提前采购）。如果PDCP决策失误，后续的损失会非常大。

第二，它是方案定型的里程碑。 PDCP评审通过后，产品的系统方案、技术规格、项目计划、商业计划等都被”冻结”，成为后续执行的基准。后续如果发生重大变更，需要通过正式的变更控制流程（PCR，Plan Change Request）来申请。

第三，它是PDT与IPMT的”合同签订”点。 在华为，PDCP通过时，PDT经理要与IPMT签署一份”合同”，明确项目的目标、预算、进度、资源等，PDT对项目的商业成功负责。这个”合同”不是法律意义上的合同，而是一种绩效承诺机制。

4.2 PDCP的评审内容

PDCP评审的内容非常全面，涵盖了计划阶段的全部工作成果。评审材料通常包括：

1. 产品包需求与规格 - 产品包需求清单（PPR）及其分解分配结果 - 需求追踪矩阵（RTM） - 技术规格书（包括功能规格、性能规格、接口规格等）

2. 系统设计方案 - 系统架构设计文档 - 概要设计文档（硬件、软件、结构、工艺等） - 接口控制文档（ICD） - 关键技术验证报告

3. 项目计划 - 端到端WBS计划（L1-L3级） - 关键路径分析 - 资源计划与预算 - 采购计划（特别是长货期物料的早期采购计划）

4. 风险评估 - 风险识别清单 - 风险评估矩阵 - 风险应对措施

5. 商业计划 - 更新的O/SBP - 财务测算（NPV、IRR、投资回收期、盈亏平衡分析等） - 市场预测与竞争分析

6. 各领域计划 - 营销计划（Marketing Plan） - 制造计划（Manufacturing Plan） - 采购计划（Procurement Plan） - 服务计划（Service Plan） - 质量计划（Quality Plan）

4.3 PDCP的评审流程

PDCP评审不是一场简单的汇报会，而是一个结构化的决策过程。华为的PDCP评审流程如下：

第一步：材料准备（评审前2-3周）

PDT经理组织各功能领域代表按照模板要求准备评审材料。材料在提交IPMT之前，必须在PDT核心团队内部评审通过，确保内容的准确性和一致性。

第二步：预审（评审前1周）

PDT经理将评审材料提交给IPMT执行秘书，由执行秘书分发给各位IPMT委员。委员们在会前进行预审，给出书面评审意见。如果预审意见较多或有重大问题，可能需要延迟上会。

这里有一个重要的原则：“问题不上会”。即在预审阶段发现的问题，PDT要在会前与相关委员沟通解决，不能带到会上再讨论。这样可以大大提高评审效率。

第三步：正式评审会

PDCP评审会由IPMT主任主持，PDT经理进行汇报。汇报时间通常控制在30-45分钟，重点讲清楚：产品方案是什么、计划怎么做、风险在哪里、需要什么资源、预期回报是多少。

汇报结束后，IPMT委员进行提问和讨论。委员们关注的重点包括： - 市场代表：市场需求是否真实？竞争分析是否充分？营销策略是否可行？ - 财务代表：财务测算是否可靠？预算是否合理？投资回报是否达标？ - 研发代表：技术方案是否可行？关键技术是否已验证？开发周期是否现实？ - 采购代表：关键器件是否可获得？供应链风险是否可控？采购成本是否合理？ - 制造代表：制造工艺是否成熟？产能规划是否合理？制造成本是否可控？

第四步：决策

IPMT基于讨论结果，做出以下决策之一： - Go（继续）：批准进入开发阶段，授权投入相应资源。 - Go with condition（有条件继续）：批准进入开发阶段，但要求PDT在一定期限内完成某些整改事项。 - Redirect（重新定向）：要求PDT调整方向后重新评审。 - No Go（终止）：终止项目，释放资源。

第五步：决策归档与传达

IPMT秘书将决策结果和会议纪要正式归档，并分发给相关方。PDT根据决策结果，启动开发阶段的工作或执行整改要求。

4.4 PDCP评审的”红线”

在华为，PDCP评审有一些不成文的”红线”，如果触碰了这些红线，项目很难通过评审：

红线一：关键技术未验证。 如果产品的核心技术在计划阶段还没有经过原型验证，评审委员通常会要求推迟PDCP，直到技术可行性得到确认。因为一旦进入开发阶段才发现技术方案不可行，损失将非常大。

红线二：需求不清晰。 如果产品包需求还存在重大分歧或模糊地带，评审委员会认为项目还没有准备好进入开发阶段。需求是开发的输入，输入不清，输出必然有问题。

红线三：计划不可信。 如果项目计划过于乐观（比如关键路径上的任务排期没有留任何余量），或者资源估算明显不足，评审委员会质疑PDT的执行能力。

红线四：财务不达标。 如果更新后的商业计划显示项目的财务回报不达标（如NPV为负、IRR低于要求、毛利率低于基准线），除非有充分的战略价值论证，否则很难通过评审。

红线五：风险不可控。 如果项目存在高风险项，但没有制定有效的应对措施，或者应对措施明显不可行，评审委员会认为项目的成功概率太低。

4.5 案例：某终端产品的PDCP”闯关”

这里讲一个华为消费者BG的真实案例（已脱敏处理）。

某年，华为消费者BG计划开发一款面向高端市场的智能手表。在概念阶段，该产品凭借”超长续航+专业健康监测”的差异化定位获得了CDCP通过。进入计划阶段后，PDT团队信心满满，认为这款产品一定能成功。

然而，在准备PDCP材料的过程中，团队发现了几个棘手的问题：

问题一：续航目标可能无法实现。 概念阶段承诺的续航时间是14天（典型使用场景），但详细测算后发现，如果同时开启心率监测、血氧监测、GPS定位等功能，实际续航只有5天左右。要达到14天续航，需要将电池容量增加一倍，但这会导致手表厚度和重量超标，与”轻薄时尚”的定位冲突。

问题二：健康监测功能的准确性存疑。 该产品的核心卖点之一是”医疗级”健康监测，但计划阶段与医疗机构的联合测试显示，血氧监测的准确率只有85%左右，距离医疗级标准（95%以上）还有较大差距。

问题三：成本超预算。 初步测算的BOM成本比概念阶段预估的高出了30%，主要原因是采用了定制的低功耗芯片和医疗级传感器，这些器件的单价远高于预期。

面对这些问题，PDT内部产生了分歧。一部分人主张”先过PDCP再说”，认为这些问题可以在开发阶段解决；另一部分人主张”如实汇报，接受IPMT的决策”。

PDT经理最终选择了后者。在PDCP评审会上，他坦诚地汇报了这三个问题，并提出了两个备选方案：

方案A（激进方案）：坚持原有定位，但将上市时间推迟3个月，用于优化功耗算法和传感器校准，同时通过规模效应降低器件成本。风险是可能错过市场窗口。

方案B（务实方案）：调整产品定位，将”医疗级健康监测”改为”专业级健康监测”，降低准确性要求，同时通过简化部分功能来降低成本和功耗。风险是差异化优势减弱。

IPMT委员们进行了激烈的讨论。市场代表认为方案B会削弱产品的竞争力；财务代表认为方案A的成本风险太高；研发代表认为两个方案的技术风险都可控，但方案A的时间风险较大。

最终，IPMT主任做出了”Go with condition”的决策：选择方案A，但要求PDT在开发阶段的前两个月完成功耗优化和传感器校准的关键技术验证，如果验证不通过，自动转为方案B。同时，要求采购代表在两个月内与供应商谈判，将关键器件的采购价格降低15%以上。

这个案例说明，PDCP评审不是”找茬”，而是帮助项目团队发现问题、解决问题。坦诚面对问题，提出可行的备选方案，往往比”粉饰太平”更容易获得IPMT的支持。

---

五、计划阶段与IPD的协同与接口

5.1 与概念阶段的衔接

计划阶段与概念阶段的衔接非常紧密。概念阶段的输出是计划阶段的输入，主要包括：

项目任务书（Charter）： 这是IPMT授权项目启动的正式文件，明确了项目的商业目标、市场定位、投资预算、关键里程碑等。计划阶段的所有工作都要围绕Charter的目标展开。

初步产品包需求： 概念阶段收集和整理的市场需求、客户需求，需要在计划阶段进行细化和规格化。

选定的产品概念： 概念阶段通过评估选择的最优概念，是计划阶段系统设计的出发点。

初始商业计划（O/SBP）： 概念阶段的初步商业论证，需要在计划阶段进行深化和验证。

初步项目计划： 概念阶段的WBS概要计划，需要在计划阶段细化为端到端的详细计划。

在实际运作中，概念阶段和计划阶段之间并不是”泾渭分明”的。有些工作（如需求分析、架构评估）在概念阶段就开始了，在计划阶段继续深化；有些工作（如关键技术验证）可能跨越两个阶段。华为的做法是：以CDCP为分界点，CDCP之前的工作属于概念阶段，CDCP之后的工作属于计划阶段，但允许有合理的重叠。

5.2 与开发阶段的衔接

计划阶段与开发阶段的衔接是IPD流程中最关键的接口之一。计划阶段的输出直接决定了开发阶段的输入质量。

需求基线： 计划阶段通过TR2评审后，产品包需求被”冻结”，成为开发阶段的需求基线。后续的需求变更需要通过正式的变更控制流程（PCR）来申请，且需要评估变更对进度、成本、质量的影响。

设计基线： 计划阶段通过TR3评审后，系统概要设计被”冻结”，成为开发阶段详细设计的依据。概要设计中的模块划分、接口定义、性能指标等，都是详细设计的约束条件。

项目计划基线： 计划阶段通过PDCP评审后，端到端项目计划被”冻结”，成为开发阶段进度跟踪的基准。后续的计划变更需要通过PCR来申请。

预算基线： 计划阶段通过PDCP评审后，项目预算被”冻结”，成为开发阶段费用控制的基准。

合同承诺： PDCP通过后，PDT经理与IPMT签署”合同”，PDT对项目的商业成功负责。这个”合同”是开发阶段绩效考核的依据。

5.3 与需求管理流程的协同

IPD体系中有一个独立的需求管理流程（OR流程，Offering Requirement），它负责收集、分析、分发和验证市场需求。计划阶段与需求管理流程的协同体现在：

需求输入： 计划阶段的产品包需求来源于需求管理流程的输出。需求管理流程通过$APPEALS模型（价格、可获得性、包装、性能、易用性、生命周期成本、社会接受度）对需求进行分类和优先级排序，为计划阶段的需求分解提供依据。

需求变更： 如果在开发阶段发生需求变更，需求管理流程负责评估变更的合理性和优先级，IPD流程负责评估变更对项目的影响。两者协同，确保需求变更受控。

需求验证： 计划阶段的需求规格化工作，需要与需求管理流程中的需求验证活动相衔接，确保最终开发的产品满足市场需求。

5.4 与技术开发流程的协同

IPD体系中还有一个独立的技术开发流程（TDT流程，Technology Development Team），负责核心技术和平台的预研和开发。计划阶段与技术开发流程的协同体现在：

技术成熟度评估： 计划阶段需要评估产品开发所需的关键技术是否已成熟。如果技术尚未成熟，需要判断是等待技术开发流程完成后再启动产品开发，还是在产品开发中同步进行技术攻关。

平台复用： 计划阶段的系统设计要考虑是否可以复用技术开发流程中已开发的平台或模块。复用成熟平台可以大大降低开发风险和周期。

技术路标对齐： 计划阶段的产品技术方案要与公司的技术路标对齐，确保产品的技术方向与公司的长期技术战略一致。

5.5 与供应链管理流程的协同

计划阶段与供应链管理流程（ISC流程，Integrated Supply Chain）的协同主要体现在：

器件选型： 计划阶段的系统设计需要确定关键器件的选型。这个选型不仅要考虑技术性能，还要考虑供应链的可获得性、成本、交付周期等。采购代表在计划阶段就要介入，评估器件的供应链风险。

早期采购： 对于长货期物料（lead time超过3个月的器件），计划阶段需要制定早期采购计划，提前下单，避免开发阶段因物料不到位而延误。

供应商管理： 计划阶段需要评估关键供应商的能力和风险，必要时启动新供应商的认证流程。

5.6 与营销管理流程的协同

计划阶段与营销管理流程（MPP流程，Marketing Plan Process）的协同主要体现在：

营销计划制定： 计划阶段需要制定详细的营销计划，包括目标市场、目标客户、定价策略、渠道策略、推广策略等。这个计划是商业计划的重要组成部分。

市场评审（MR）： 在PDCP之前，需要进行市场评审（MR1），评估营销计划的成熟度。MR1的通过是启动PDCP的必要条件。

上市准备： 计划阶段就要开始规划产品的上市活动，包括发布日（AD）的确定、GA（一般可获得性）时间的规划、渠道备货计划等。

---

六、计划阶段的管理组织与职责

6.1 PDT（产品开发团队）的构成

PDT是IPD流程的核心执行组织，是一个跨职能的虚拟团队。在计划阶段，PDT的构成如下：

PDT经理（LPDT）： 团队负责人，对产品的商业成功负总责。在计划阶段，PDT经理的核心职责包括：组织计划阶段的工作、整合各领域计划、准备PDCP评审材料、与IPMT沟通等。

开发代表（RDPDT）： 负责研发领域的工作，包括系统设计、概要设计、详细设计、测试验证等。在计划阶段，开发代表要组织完成系统架构设计和概要设计，制定开发领域的详细计划。

市场代表（MKTPDT）： 负责市场领域的工作，包括市场需求分析、竞争分析、营销策略制定等。在计划阶段，市场代表要更新市场预测，制定营销计划，组织市场评审（MR1）。

制造代表（MNFPDT）： 负责制造领域的工作，包括制造工艺设计、产能规划、制造成本控制等。在计划阶段，制造代表要评估制造可行性，制定制造准备计划。

采购代表（PROPDT）： 负责采购领域的工作，包括器件选型、供应商管理、采购成本控制等。在计划阶段，采购代表要完成关键器件的选型评估，制定早期采购计划。

财务代表（FPDT）： 负责财务领域的工作，包括预算编制、成本控制、财务分析等。在计划阶段，财务代表要更新商业计划的财务测算，评估项目的投资回报。

质量代表（PQAPDT）： 负责质量领域的工作，包括质量计划制定、质量目标设定、质量评审组织等。在计划阶段，质量代表要制定质量计划，组织TR2和TR3评审。

服务代表（SEPDT）： 负责服务领域的工作，包括可服务性设计、服务策略制定、服务准备等。在计划阶段，服务代表要评估产品的可服务性，制定服务计划。

系统工程师（SE）： 技术负责人，负责系统架构设计、需求分解分配、技术方案评审等。在计划阶段，SE是技术工作的核心推动者。

6.2 IPMT（集成组合管理团队）的角色

IPMT是IPD流程的决策组织，负责产品投资的决策。在计划阶段，IPMT的角色包括：

投资决策： 在PDCP评审中，基于PDT提交的商业计划和项目计划，做出是否继续投资的决策。

资源分配： 批准PDT所需的资源（人力、预算、设备等），并监控资源的使用效率。

风险把控： 评估项目的整体风险，对高风险项目进行重点关注或干预。

绩效评估： 基于PDT的”合同”承诺，对PDT的绩效进行评估和考核。

IPMT通常由公司或产品线的高级管理人员组成，包括产品线总裁、研发总裁、市场总裁、供应链总裁、财务总监等。IPMT主任通常由产品线总裁担任。

6.3 各角色的协作机制

在计划阶段，PDT各角色之间的协作机制包括：

周例会： PDT经理每周组织一次PDT核心团队例会，跟踪计划阶段各项工作的进展，协调跨领域的问题。

专题研讨会： 针对关键技术问题、架构选择问题、风险应对问题等，组织专题研讨会，邀请相关专家参与讨论。

评审机制： 通过TR2、TR3等技术评审，以及MR1市场评审，确保各领域的工作质量。

问题升级机制： 当PDT内部无法解决的问题（如跨领域冲突、资源争夺等），通过问题升级机制提交给IPMT或相关高层决策。

---

七、计划阶段常见陷阱与应对

7.1 陷阱一：重方案设计，轻资源评估

现象： 计划阶段花了大量时间做系统设计和方案论证，但对资源需求和预算的评估却非常粗糙。常见表现包括：人员投入按”理想状态”估算（假设所有人100%投入、没有请假、没有会议干扰），预算只算了直接成本（没算管理费用、质量成本、风险储备金等）。

后果： 开发阶段资源不到位，关键岗位人员被其他项目抽调；预算超支，不得不申请追加投资，影响IPMT对PDT的信任。

应对： 资源评估要”留余量”。华为的做法是：人员投入按80%的有效工作时间来估算（留出20%用于会议、培训、突发事件等）；预算要包含10%-15%的风险储备金；关键资源要有备份方案。

7.2 陷阱二：方案设计”分步走”，导致反复修改

现象： 总体方案设计完成后，各模块再分别做方案设计，结果发现模块之间的接口不匹配、性能指标冲突，导致总体方案需要反复修改。

后果： 计划阶段的时间被大量消耗在方案修改上，TR3评审一再推迟；开发阶段的详细设计建立在不断变化的概要设计上，导致大量的返工。

应对： 采用”同步工程”的方法。在概要设计阶段，各模块负责人要同步参与设计讨论，接口定义要尽早确定并冻结。华为的做法是：在TR3之前，组织多次”接口对齐会”，确保各模块的接口定义一致。

7.3 陷阱三：风险评估”走过场”

现象： 风险评估只是列了几条”放之四海而皆准”的风险（如”技术风险”、“市场风险”），没有深入分析风险的具体表现、发生概率、影响程度，更没有制定具体的应对措施。

后果： 开发阶段风险爆发时，团队措手不及，没有预案，只能临时”救火”。

应对： 风险评估要”具体化”。每一条风险都要明确：风险描述（具体是什么问题）、触发条件（什么情况下会发生）、影响分析（如果发生，对进度/成本/质量的影响有多大）、应对措施（如果发生，具体怎么做）、责任人（谁负责监控和应对）。

7.4 陷阱四：计划与绩效脱节

现象： 项目计划制定得很详细，但团队成员的绩效考核与计划任务没有挂钩。计划是计划，考核是考核，“两张皮”。

后果： 团队成员对计划的执行缺乏动力，计划沦为”摆设”；进度延误时，无法追溯责任。

应对： 将计划任务分解到个人绩效。华为的做法是：PDCP通过后，PDT经理与各核心成员签署绩效承诺书（PBC，Personal Business Commitment），将项目的关键里程碑和交付物纳入个人绩效考核。

7.5 陷阱五：商业论证”自我说服”

现象： 商业计划的编制过程变成了”证明项目可行”的过程，而不是”客观评估项目”的过程。团队倾向于选择乐观假设，对不利因素选择性忽视。

后果： IPMT基于不真实的商业计划做出投资决策，项目上市后实际表现远低于预期，造成投资损失。

应对： 引入”红队机制”。在商业计划评审时，指定一个”红队”（由与项目无直接利益关系的人员组成），专门负责挑战商业计划中的假设，提出反面意见。华为在一些重大项目的PDCP评审中，会邀请财务部门或战略部门的独立人员进行”压力测试”。

---

八、计划阶段的工具与方法

安谋咨询实战工具模板（部分），请联系客服人员获取（联系方式见文末）。

---

九、结语：慢即是快

“慢即是快”这句话看似简单，却蕴含着IPD最深层的管理智慧。在快节奏的商业环境中，很多企业倾向于”边想边做”、“快速试错”，认为这样可以抢占市场先机。但华为二十多年的IPD实践告诉我们：对于复杂的高科技产品开发，“慢即是快”—在计划阶段多花一些时间把方案想清楚、把计划做扎实，可以在开发阶段节省数倍的时间，避免大量的返工和变更。

计划阶段的价值，不仅仅在于输出一份漂亮的项目计划书，更在于通过系统化的思考过程，让团队对产品的技术方案、市场定位、资源需求、风险挑战形成统一的认知。这种认知的统一，是后续高效执行的基础。

当然，计划阶段也不是越长越好。我们的经验是：8到12周是一个相对合理的时间窗口。太短了做不扎实，太长了会丧失市场窗口。关键在于”质量”而非”时长”—在有限的时间内，把该做的工作做到位。请牢记：

“计划阶段的草率，是开发阶段灾难的开始；计划阶段的扎实，是项目成功的一半。”

---

【 -END- 】

如需要开展华为IPD流程体系等培训和咨询项目的，请联系我们的学习顾问：directorniu (个人微信)​

更多精选好文：安谋咨询2026年度精选文章合集