华为IPD流程370个活动详解：从概念阶段到计划阶段的活动级拆解

简介：《华为IPD流程各阶段370个活动详解》是一份面向产品研发管理、项目经理及流程改进人员的专业参考文档，系统梳理了华为集成产品开发（IPD）流程从概念阶段到生产阶段所涉及的370个核心活动。文档以活动编号为主线逐项解析，覆盖概念启动、PDT核心组组建、任务书下达、项目计划制定、财务与研发活动监控等关键节点，并明确每项活动的负责人角色（如LPDT、PDT核心组、PAC等）与主要工作要求。尤其对概念阶段的流程进行了细致展开，包含LPDT与PAC的沟通、团队培训、质量目标设定等内容，可帮助读者快速理解IPD落地时的职责分工与操作顺序。资源共1个PDF文件，压缩包约815KB，内容组织清晰、便于按需检索。该资料已有4000余人学习下载，适合正在推行或学习华为IPD流程的团队与个人作为案头参考资料。

1. IPD流程不缺理念，缺的是把370个活动落到人：一份活动级详解能回答什么

先说一个我常听到的场景：公司引入华为IPD流程，流程文件堆了一书架，讲理念的PPT能讲三天，可新项目启动时，从概念阶段到计划阶段的接口怎么交接、LPDT要发哪些指令、每个代表在什么时间点产出什么，没人说得清。原因很简单，理念讲的是方向和节奏，落不了地的原因恰恰在活动级。这份PDF把华为IPD流程拆成了370个活动，每个活动一条，带编号、带角色、带输入输出，本质是一张“流程到岗”的活动地图。它的用法不是通读，而是按阶段查表、按角色对号。适合正在跑IPD的项目经理、PDT核心组成员，以及负责流程裁剪的PMO。接下来我按阶段拆一遍，重点说清楚编号规则、角色动作和评审门禁。

2. 概念阶段怎么运转：从PAC-05到LPDT-42的活动流拆解

2.1 概念阶段的入口：任务书、开工会与项目环境

概念阶段的入口是PAC-05概念启动。这一步不是走形式，PAC会对产品概念启动的可行性做评审，从提交材料到给出评审结论有明确时限——原文写的是“一般不超过6个工作日”。这意味着整个评审节奏是可控的。通过后，PAC-10开始组建PDT核心组，确定LPDT、SE、POP以及必要的外围组成员；紧接着是LPDT-03与PAC沟通，接受概念阶段任务书和立项通知书，并把任务书发布给PDT成员。

环境准备是概念阶段最容易敷衍、但后来翻车最多的环节。POP-10负责在财务系统中建立项目会计账目代码、建立WBS 1级模板和项目数据库、为PDT成员分配系统权限、维护PDM配置数据。注意，这一步要在开工会之前完成，否则后续财务费用归集和产品数据管理会变成一笔糊涂账。我见过不少项目跳过POP-10直接开工，结果研发投入发生几个月后财务对不上项目号，后面补账的代价远比当时花半天建账大。

LPDT-04做团队培训、LPDT-08创建沟通计划，然后LPDT-13开工会正式启动项目。开工会议程里有一条容易被忽视：签订资源承诺书（可选）。多数团队把它当可选项跳过，但资源承诺书能帮你在后续资源被其他项目抢走时拿回谈判筹码，我一般建议保留。

2.2 概念阶段的计划主线：WBS分级与四十小时工作包

概念阶段计划制定集中在LPDT-20一组活动上，原文里从LPDT-20到MKTPDT-20一长串编号。这里的看点是WBS的层级：概念阶段计划要拆到WBS 1/2/3/4级，而工作包必须控制在40小时以内。40小时约束是华为IPD计划体系的一个硬指标——不是建议，是约束。它的含义是任何一项被指派的任务，责任人要在不超过一周的工作量内能交付，否则就要继续拆分。

各角色在计划制定中的分工也值得细读：

注意，这里各个代表不是等LPDT分配任务，而是每个代表都要基于WBS模板产出自己的分领域计划，再由LPDT汇总。IPD的“集成”二字体现在这里：计划不是自上而下分解出来的，而是各领域代表并行编制后再集成的。如果你所在团队习惯由项目经理一个人写好计划再分发，这本身就是和IPD的偏差。

2.3 需求侧的动作：市场验证、可制造性、可服务性如何汇入产品包需求

概念阶段的另一条主线是需求开发。MKTPDT-30验证市场需求，直接对应《产品线规划书》和客户访谈；SE-06验证可用性需求，IDE-10参与易用性需求定义；CSS-10定义可服务性需求；AME-15定义可制造性与可测试性需求；TE-10定义软件和硬件可测试性需求。这些动作的产出最终汇入SE-10的“定义产品包需求和产品概念”。

这里有个容易被新手忽略的点：产品包需求不是只包含功能需求。原文里SE-10明确写了要覆盖“销售、获得、计划、安装、培训、支持、维护、升级、退出”，并且要集成地理需求（NLS）、RAS需求、知识产权建议。换句话说，产品包需求是端到端生命周期需求，研发只是其中一个子集。概念阶段如果只把精力放在功能和性能上，到了计划阶段做需求分解时就会发现可服务性、可制造性需求没经过验证，倒回去补的代价是巨大的。

SE-03定义RAS需求也在这个阶段完成。可靠性、可用性、可维护性三类需求不是上线以后才考虑的，而是在概念阶段就基于上一版本缺陷、设计经验沉淀下来，并且要考虑公司内部产品共享、平台借用带来的需求约束。做平台化产品的团队，SE-03这一条尤其要重视。

2.4 概念收口：TR1评审、CDCP决策与经验教训

概念阶段的收口是两级评审。先是SE-20（PQA-20同样执行）做TR1技术评审，重点看产品包需求的完备性、技术可行性、产品概念是否满足需求，评审通过后需求基线化（SE-30）并置于变更控制之下。再是LPDT-40与PAC充分沟通业务计划，最后PAC-20做概念决策评审（CDCP），给出继续或终止的结论。

TR1里有一个细节值得琢磨：评审通过后“需求应被置于更改控制之下”。这意味着需求不是定完就冻结，而是后续所有变更必须走受控流程。SE-40专门写的是监控和管理需求更改，连“如果基线化后的需求发生较重大或频繁的变更，SE需要在经验教训总结中进行分析”都写出来了。这说明华为IPD对需求变更的态度很明确：允许改，但必须有结构化流程，并且要复盘变更原因。

概念阶段最后一个动作是LPDT-42项目经验教训总结。注意它发生在概念决策评审之后，而不是项目全部结束之后——这是阶段性的经验教训沉淀，不是秋后算账。内容按统一模板录入IT系统，供后续项目查询复用。

3. 计划阶段做厚还是做薄：扩展组、需求分解与Build划分

3.1 计划阶段的组织动作：扩组、计划开工会、WBS 3/4级计划

计划阶段入场先做组织准备。PAC-30增扩PDT，把计划阶段所需的扩展组成员补齐；LPDT-46做团队培训，重点转向计划阶段流程和系统工程；POP-20更新项目文档，把外围组成员加入数据库；最后LPDT-50开计划阶段开工会。这里参考议程多了“概念阶段回顾和交付件介绍”，言外之意是计划阶段不能脱离概念阶段的结论另起炉灶。

计划阶段的项目计划制定不再是WBS 1/2级，而是下沉到WBS 3/4级（LPDT-55及各领域代表对应活动号）。工作包必须控制在40小时以内的约束依然生效。此时各代表的任务和概念阶段相比发生了质变：CSPDT-45要基于概要BOM结构树和系统设计概念框图制定详细的可行性服务需求，MNFPDT-45要确认PP、AME组成的制造项目小组并评估工作量，PROPDT-45要分析关键部品（比如某些长周期器件）对开发主计划的制约，并制定关键部品的进度计划。

PROPDT-45这条是计划阶段采购工作的核心逻辑：不是等设计定稿再采购，而是在计划阶段就要识别长周期器件、关键芯片的采购风险，倒排进度。如果概念阶段PROPDT-20已经明确了主芯片、LCD、Camera、Memory这些关键器件，计划阶段就要把供应商谈判和样品获取的周期卡进项目计划。见过不少项目在这时候才发现某颗料采购周期要26周而不在计划里，整个开发计划被迫重排。

3.2 需求分解和分配：从产品包需求到子系统技术规格

计划阶段的中间动作是需求分解和分配，核心是SE-50一组活动。原文里SE-50的描述讲得很透：与硬件工程师、软件工程师、结构工程师一起分析产品包需求，把需求分解到硬件、软件、结构子系统，再进一步分配到下一层子系统、部件或模块；各领域之间怎么分工、互相接口怎么定义，都要在这里确定。

EE-20负责硬件需求分解，SWE-20负责软件需求分解，ME-20负责结构需求分解。注意ME-20里有一句“确定可能采用的新工艺、新技术”，这说明结构域的需求分解不只是把现有工艺对应上去，还要识别工艺风险。分解完不是直接进设计，而是SE-60生成系统方案和规格设计，输出产品技术规格以及系统设计概念框图。

到这一步，概念阶段的产品包需求才真正变成长得可指导开发的技术规格。我见过一些团队SRG（系统需求规格）写得像产品宣传册，到处是“用户体验良好”“性能大幅提升”这类不可验证的表述，到了TR2评审才发现规格根本没法指导详细设计。正确的做法是每个需求条目都要能对应到验证方法和验收标准——这在TR2评审标准里属于基本要求。

3.3 Build划分与TR2：计划阶段的收口动作

计划阶段一个容易被低估的动作是SE-65的Build划分。原文给了关键步骤：根据设计需求和设计规格建立功能-模块矩阵；分析功能跟踪矩阵，建立unique-combination关联；划分Build；画Build拓扑图并整理模块进度计划。这个Build策略直接决定后续开发阶段的集成测试节奏。

这里解释一下Build是什么。它不是按交付批次划分，而是按集成粒度划分——每一轮集成把哪些模块合在一起做成一个可测的增量。Build规划得好，开发和测试能并行起来，集成风险能提前暴露；Build规划得粗，到开发后期模块一次性拼装，出问题定位成本成倍上涨。华为IPD把Build策略放在计划阶段而不是开发阶段做，本身就是把集成风险前置的思路。

计划阶段收口是SE-70技术评审2。TR2关注产品需求的分解和分配、产品规格和系统总体方案，评审通过后将产品规格置于变更控制之下。到这一步，计划阶段的交付物（业务计划、系统规格、各领域详细计划）具备进入决策评审的条件。

3.4 概念阶段和计划阶段的对比：从粗到细的两级计划

拿概念阶段和计划阶段对比看，能看到华为IPD计划体系的两级结构设计：

两级计划的差异本质上反映了不确定性递减的规律。概念阶段信息少，计划只能做到1/2级；到计划阶段，需求分解完成、系统方案确定，计划才可以拆到可执行的3/4级。有些团队为了“看起来规范”，在概念阶段就逼着做详细到天的计划，结果全是拍脑袋的假设，反而把关键风险掩盖了。

4. 活动编号、角色代码与评审门禁：先读懂370个活动的编码规则

4.1 活动号的读法：PAC-05、LPDT-20A、SE-20里的三层信息

一份活动清单难不难用，取决于你能不能从活动号反推活动属性。这份370个活动的编号规则是“角色前缀-序号”，同一角色的活动按阶段顺序递增。拆解一下：

从这张表能看出规律：同一角色在不同阶段的编号有连续性，序号大小约等于流程推进顺序。因此当你拿到一条活动号时，可以先判断角色归属和阶段归属，再判断这活动是决策、计划、执行还是评审。这份PDF里同一活动号会出现多行，比如SE-20和PQA-20都是TR1评审，这说明该活动有多个角色共同执行或共同背书。

4.2 角色代码表：PDT体系里的十六个常见角色

活动清单里最劝退新人的是各种角色缩写，这里按原文把常见代码整理成一张查表：

这组角色基本覆盖了IPD跨职能团队的全景。你可以对照自己团队的组织架构看缺口——许多公司推行IPD只搭了研发、市场、制造三个角色，财务代表和订单履行角色是缺失的，后面的成本失控和发货混乱往往就发生在这里。

4.3 评审机制：TR1/TR2与DCP的组合

评审维度上，这张活动表存在两种评审：技术评审（TR）和决策评审（DCP）。它们的区别在于评审对象和决策权。举个例子，概念阶段有TR1（产品包需求和概念评审）和CDCP（概念决策评审），计划阶段有TR2（需求和系统方案评审）和而后面的PDCP。TR由技术线负责（SE主责、PQA配合），DCP由PAC决策，前者关注“做不做得好”，后者关注“值不值得做”。

一个常见误解是把TR当作DCP的预审会，开完TR就算过门槛。实际上，TR不过，DCP材料根本不具备上报条件；DCP不过，项目最多止步于当前阶段。两组评审串行把关，才是IPD门禁的完整逻辑。整理成表格更直观：

5. 避坑指南：把370个活动表落地时最常见的五个“想当然”

5.1 看到TR1通过就直接进CDCP，没给PAC留沟通时间

现象：概念阶段TR1评审通过后，团队直接整理材料上CDCP决策会，结果PAC委员对业务计划提问，很多答不上来。 原因：原文LPDT-40明确要求“在决策评审材料提交给PAC成员后的3到4天内，与委员们进行沟通”，并且每次沟通要有纪要、沟通后修改业务计划、汇总问题在评审会上汇报。这个环节是给PAC消化材料和提前暴露问题的缓冲带，跳过它等于把问题原封不动搬到决策会上。 解决：把“与PAC充分沟通”当成正式活动排进计划，预留至少3到4天，并输出沟通纪要和修改记录，随决策材料一起提交。

5.2 概念阶段财务估算只算研发预算，忽略V版本全周期

现象：概念阶段业务计划里的财务部分是研发项目的预算，结果后续特性版本开发费用超支，项目整体ROI算不过来。 原因：原文PAC-20里写得很清楚：概念阶段的财务估算按V版本进行，要把V版本第一个特性版本的计划决策评审点之后、到最后一个特性版本GA点为止的所有WBS 1/2级计划所需投资都估算进去。这是产品级而非项目级的财务视角。 解决：财务评估不要只覆盖当下这个版本，要以V版本为单位做全周期投资测算，把后续特性版本的研发、验证、生产准备费用全部纳入初始业务计划。

5.3 工作包拆不到40小时以内，计划形同虚设

现象：项目计划里出现“完成整机验证”“完成驱动开发”这种颗粒度的工作包，任务跨两周以上，进度一拖再拖。 原因：原文在LPDT-20和LPDT-55反复强调“工作包必须在40小时以内”。这个约束没有被当成硬指标，计划拆到部门级就停了。 解决：审视计划时把超过40小时的工作包一律打回重拆。判断标准很简单：责任人是否能在一周内交付该工作包，如果不能，就继续向下分解。

5.4 技术评审和决策评审混为一谈，用汇报代替评审

现象：TR1评审会开成PPT汇报会，SE讲完需求、市场讲完分析，评审组提几个问题，然后签字通过。后续开发阶段发现需求本身存在矛盾。 原因：TR1的评审对象是产品包需求的完备性、技术可行性和产品概念的有效性。评审组要逐项核对需求条目是否可验证、概念是否满足需求，而不是听汇报。PQA-20和SE-20同时出现在TR1活动中，本身就说明这是技术把关。 解决：TR评审要有checklist，按需求条目逐条确认完整性、可测试性和技术方案可行性，输出明确结论“通过/有条件通过/不通过”。有条件通过要列出整改项和验证责任人。

5.5 需求通过TR1基线化后放任变更，导致范围失控

现象：需求基线化后，客户和市场又提了不少新需求，团队来者不拒，产品包越滚越大，计划阶段WBS 3/4级计划反复调整。 原因：SE-40明确写了需求定义后仍可能随时间变化，但这些更改必须通过结构化流程进行。基线化后的重大或频繁变更，SE还要在经验教训中分析原因。原文里“将导致不良影响”这句话说得已经够直白。 解决：基线化之后的需求变更一律走变更控制流程。SE要评估变更对计划、成本、进度的冲击，重大变更要重新评估是否影响DCP决策前提。如果变更频繁，先停下来分析是不是概念阶段市场验证没做透。

6. 把370个活动表转成团队RACI表：用脚本做角色负载与关键路径检查

6.1 用脚本把PDF里的活动表转成CSV

拿到这份PDF，第一件事不是人肉读，而是转成结构化数据。常见做法是用Python加pdfplumber把表格抽出来，清洗后落成CSV，方便后续透视和分析。我一般会这样做：

import pdfplumber import pandas as pd # 打开PDF并抽取表格 rows = [] with pdfplumber.open("华为IPD流程各阶段370个活动详解.pdf") as pdf: for page in pdf.pages: tables = page.extract_tables() for table in tables: for row in table: # 过滤空行和表头行 if row and row[0] and "编号" not in str(row[0]): rows.append(row) # 组装成DataFrame，按原表列结构命名 df = pd.DataFrame(rows, columns=["编号", "阶段", "活动", "活动号", "活动描述", "角色"]) # 去重：同一活动号多角色并行执行的情况保留 df = df.drop_duplicates().reset_index(drop=True) # 导出CSV，便于后续透视 df.to_csv("ipd_activities_370.csv", index=False, encoding="utf-8-sig") print(f"共导出 {len(df)} 条活动记录")

逻辑说明：pdfplumber按页抽取表格，每页的表格行追加到rows列表；过滤条件是跳过表头行（“编号”关键字）和完全空行；列名按原表结构定义——编号、阶段、活动、活动号、活动描述、角色。去重时保留同一活动号多角色并行执行的情况，因为一个活动多角色参与是IPD的正常形态，不能按活动号直接去重。

参数说明：encoding="utf-8-sig"是为了让CSV在Excel里打开不乱码，如果你用WPS或LibreOffice可以改成utf-8。如果PDF里有跨页断行的情况，导出的活动描述字段可能不完整，需要人工核对编号连续性和描述结尾。

6.2 用透视表看角色负载和阶段活动分布

转成CSV后，第一个值得做的透视是按阶段和角色统计活动数量。这能直观看出“哪个阶段哪个角色最忙”，从而判断资源分配是否合理。

import pandas as pd df = pd.read_csv("ipd_activities_370.csv") # 按阶段+角色统计活动数 pivot = pd.pivot_table( df, index="阶段", columns="角色", values="活动号", aggfunc="count", fill_value=0 ) # 输出概念阶段各角色活动数，按降序排列 concept = pivot.loc["概念阶段"].sort_values(ascending=False) print(concept.head(15)) # 检查是否有同一活动号分配给了多个角色（并行执行） dup_activity = df.groupby("活动号")["角色"].nunique() parallel = dup_activity[dup_activity > 1] print(f"存在并行角色的活动数：{len(parallel)}")

逻辑说明：按阶段和角色做数据透视，统计每个角色在每阶段承担的活动数量；然后单独看概念阶段各角色的负载排序；最后用groupby统计每个活动号对应的角色数，找出并行执行的活动，这些往往是需要跨职能协作的关键节点。

参数说明：aggfunc="count"统计的是行数，即活动条目数。如果一个活动号下同一角色出现多次条目，建议先按“活动号+角色”去重再统计，否则负载数字会偏大。sort_values(ascending=False)得到的是“活动条目最多的角色”排在最前。

做完这步，你就有了三个可落地的产出：按阶段的活动清单、按角色的负载表、以及一份关键并行活动清单。把这些交给PDT各代表核对，绝大多数“流程到岗”的盲区会立刻暴露出来——比如某个角色在概念阶段挂着30个活动却只配了一个人，或者某个关键并行活动两边的负责人都以为对方在主导。这份370个活动的文档，最终价值不在“看过”，而在这一张能指导排兵布阵的透视表上。从那以后我每次接手IPD类项目，第一件事就是把活动清单数据化，强制走一遍角色负载核对，再开始谈计划。希望帮到你。

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