企业官网建设流程全解析

简介：一份聚焦IPD集成产品开发流程中开发阶段活动说明的实用文档，面向产品经理、项目经理、研发管理骨干及流程改进人员。内容围绕项目开发、验证与发布阶段的关键动作展开，系统梳理了确定外围组成员、更新项目文件与智力资本数据库、召集开工会、执行对外合作计划等核心环节，并延伸至项目监控、资源协调与变更管理。文档采用中英文对照方式呈现，每个活动均附有简要描述与建议议程，例如开工会列出了项目目标介绍、版本开发合同书发布或签字仪式、PDT任命宣读、签订承诺书等安排，便于团队直接对照执行。资源仅含1个PDF文件，大小约236KB，轻量易读，适合在项目启动会或流程培训中参考。目前已有312人学习下载，可作为IPD落地实施中的速查手册，也能为优化团队协同、明确角色职责提供依据。

1. 拿到《IPD-产品开发流程-开发阶段活动说明》先别急着写代码：这个阶段到底管什么

我第一次拿到《IPD-产品开发流程-开发阶段活动说明》这份文档，第一反应是：计划阶段刚过，团队还挤得出时间读流程说明吗？后来发现，越早读完越划算。在 IPD 流程里，“开发阶段”不是“把设计做完”，而是从计划决策评审（PDCP）通过之后，到可获得性决策评审（ADCP）之前的一条高压走廊：需求基线冻结、技术风险清零、供应链和制造能力同步收敛，最后交出一套“可量产、可销售、可交付”的产品资产，而不只是一台样机。这套活动说明最值钱的地方，是告诉每个角色在哪个时点交什么、用什么标准判断能不能往下走。对产品经理、项目经理、研发骨干和流程负责人来说，它就是开发阶段的路线图。这篇笔记按这类说明文档最常见的结构，把活动骨架、各领域分工、评审机制和踩过的坑一次讲清楚。

2. 把开发阶段的骨架先立住：从 PDCP 到 ADCP，活动怎么排、里程碑怎么设

很多团队把开发阶段等同于“写代码、打样、测功能”，这是对 IPD 最大的误解。开发阶段承接的是计划阶段的“合同”：产品包需求已经转成产品规格，目标成本、项目计划、风险清单都经过评审并基线化。开发阶段的使命，是把这份纸面合同变成真实的产品，同时把制造、采购、市场、服务、财务的准备度一并拉起来。常见做法是把它拆成三条主线同时推进：产品开发主线、制造与供应链准备线、市场与服务体系准备线。三者不再是串行接力，而是并行收敛，最终的聚合点就是 ADCP 之前的最后一轮评审。

在华为 IPD 流程的实践里，IPD 通常被切成概念、计划、开发、验证、发布、生命周期六个阶段，也有公司把开发和验证合并成一个“开发与验证阶段”。不管怎么切，开发阶段的入口都定在 PDCP 通过、计划合同发布之后；出口则定在可获得性决策评审（ADCP）或者首发（GA）之前。判断一份《活动说明》写得规不规范，先看它有没有把这几个边界事件写全：PDCP 结论、计划合同发布、TR4A 之后的样机冻结、TR6 的试产验证通过、ADCP 的上市建议。边界事件缺一个，阶段活动就容易“悬空”。

2.1 阶段出口的五个收尾产物

开发阶段结束时，要交付的不是一样东西，而是一组互相咬合的资产。缺了任何一块，ADCP 都会被打回。我一般用下面这张清单来验收一个开发阶段是否“真正做完”：

这五项不是“能做出一样就另一样”，而是必须同时满足，才能进入发布决策。最容易翻车的是第五项：研发认为产品好了，财务却算不过账，导致 ADCP 被顶住。所以财务活动一定要进开发阶段的周计划，不能等到快评审了才补数。

2.2 活动按“主流程 + 支撑活动”分层组织

拿到活动说明，第一件事是看它有没有把活动分层。常见结构分两层：主流程活动和支撑领域活动。主流程活动是阶段的主干，按技术成熟度推进；支撑活动则围绕主流程同步展开，把采购、制造、市场、服务、质量、成本这些维度往里汇。

主流程活动通常包括：阶段启动与项目开工会、系统设计冻结、概要设计、详细设计、样机开发与单元测试、集成与系统测试、样机评审（TR5）、小批试产验证（TR6）、BETA 测试与问题收敛。每个活动都有自己的输入输出和完成标准。支撑活动则不按“技术迭代”走，而是按“准备度”推进，比如供应商送样认证、模具验证、SOP 编写、销售预测更新、备件清单确认、认证预测试、预算执行分析等。活动说明里如果只写了研发活动，没有采购和制造，那它就只是一份设计计划，不是开发阶段计划。

区分主流程和支撑活动还有一个实际用途：排计划和管资源。主流程活动决定关键路径，支撑活动决定阶段出口能否被“拖住”——比如产品做完了但模具没验证完，照样出不了货。所以我做开发计划时，会让主流程活动对应 WBS 的第一、二层，支撑活动挂靠在相关里程碑下，和预算分摊一一对应。

2.3 用 WBS 把计划基线固定下来

活动说明落不到 WBS 上，就只是一堆名词。常见做法是三层 WBS：第一层按阶段里程碑分（PDCP 后启动、TR5、TR6、ADCP）；第二层按领域分（研发、采购、制造、市场、服务、质量、财务）；第三层落到具体活动。每个活动带四个属性：责任角色、输入条件、输出交付物、完成标准。

计划阶段评审通过的 WBS 是“计划合同”的一部分。到了开发阶段，如果有人要往里面加活动，不是说加就加，而是走变更：评估对里程碑、成本、资源的冲击，再决定是否接受。很多项目开发阶段失控，不是计划没做，而是 WBS 变成了“活的”，今天加个需求，明天加个认证，基线形同虚设。把 WBS 当合同管，是开发阶段活动说明真正生效的前提。

提示：一份可执行的《开发阶段活动说明》，至少包含四个要素：活动清单、输入输出、责任角色、完成标准。缺了“完成标准”，评审就只能靠感觉。

3. 各领域在开发阶段的分工与交付物：研发、采购、制造、市场、服务分别交什么

开发阶段的骨架立住后，接下来要回答的是“谁在什么时候做什么”。我观察过不少团队，研发很忙，但采购、制造、市场的人闲到快忘记自己在这个项目里。等到样机出来了，才开始补供应商认证、补工艺流程、补产品资料，整个阶段被拉长一两个月。这一章把常见活动说明里各领域的“份内事”梳理一遍，每个领域只抓核心活动和交付物。

3.1 研发活动：从概要设计到样机冻结的三级推进

研发活动是开发阶段的主线，但它的推进方式不是“写完代码就完”。常见做法是把研发活动拆成三级：概要设计、详细设计、样机与测试。概要设计对应 TR3，解决系统架构、模块划分、关键技术选型和风险消解方案；详细设计对应 TR4，落到单元模块、接口定义、原理图、代码结构、测试方案。样机冻结对应 TR5，硬件的原理图和 BOM 锁定、软件代码冻结基线，之后进入系统级测试和试产验证。

研发活动最容易忽略的交付物不是代码和图纸，而是测试报告和“设计说明记录”。很多团队的 TR 评审现场，PPT 讲得漂亮，但单元测试覆盖率、缺陷收敛曲线、静态检查结果拿不出来。评审委员会无从判断“设计是否完成”。所以在活动说明里，我会给每个研发活动加上最低交付标准：单元测试用例通过率不低于 90%、严重和致命缺陷清零、模块接口文档与代码一致。有了这些硬数字，TR 评审才能从“听汇报”变成“查证据”。

研发活动还需要和“样机物料”挂钩。样机不是想打就能打的，PCB 制板、结构件开模、长周期芯片采购都有周期。所以研发活动里要包含“样机物料清单冻结”和“采购申请释放”两个动作，通常提前两到四周把 BOM 释放给采购，否则样机节点必然顺延。

3.2 采购活动：长周期物料、供应商认证与模具验证

采购在开发阶段做的事，远不止“买东西”。对硬件产品来说，供应商定点、送样认证、模具验证、产能评估这四件事，决定了产品能不能按期试产。常见活动包括：发布 RFQ 并完成供应商比选、对关键物料做 EVT/DVT/PVT 三阶段送样认证、跟踪模具 T1/T2 试模、确认长周期物料下单节点、评估供应商产能并签供货承诺。

关键参数集中在两个时间点。第一，长周期物料的采购申请必须在 PDCP 之前就启动，开发阶段只是持续跟踪，典型提前量在 12 到 16 周；第二，PVT（量产验证）送样必须在 TR6 之前完成，不能一边开 TR6 一边等物料认证。如果活动说明里没有“物料就绪度”这个检查项，开发阶段的进度承诺就是空中楼阁。

另外，采购活动的输出不只是物料，还包括一份“供应风险评估表”：单一供应商物料名单、替代方案、最小起订量、交货周期、价格走势。这份表要喂给 ADCP，决策者才知道“产品发布后供应链会不会掉链子”。

3.3 制造与工艺准备：从试产到直通率的验证闭环

制造活动在开发阶段的目标，是证明“产品在产线上能够稳定地被造出来”。活动包括：工艺路线设计与评审、SOP 编写与培训、工装夹具设计验证、试产线体搭建、小批试产、直通率与关键工序能力分析。很多团队把制造活动压缩成“TR6 之前试一把产”，结果试产一次通过率只有 50%，问题清单十几页，阶段被迫延长。

我一般会给制造活动设三个硬指标：试产直通率不低于某个基线（视产品复杂度而定，简单产品 95% 以上，复杂产品 85% 以上）、关键工序的过程能力指数 Cpk 不小于 1.33、返工流程和不良品处理机制有书面记录。三个指标没有同时达标，不建议向 ADCP 提报“可上市”。这些参数不要写在 PPT 里，写进活动说明，评审才有据可查。

制造活动还有一个容易被忽视的输入：可制造性检查（DFM）。研发的图纸出来，制造代表要提前做 DFM 评审，把焊盘间距、贴片方向、结构装配公差这些问题在开模和试产前解决掉。等产线拉起来再改设计，一把改动可能就是两周起步。

3.4 市场、服务、质量与财务的同步活动

这些领域看似离研发远，但 ADCP 能不能过，往往由它们决定。市场侧的活动是：更新销售预测和产品定价、编写产品资料与销售工具包、完成销售培训、确认渠道和首批铺货计划。服务侧的活动是：确定备件策略与备件清单、编写安装与维修手册、培训服务工程师、设计现场部署方案。

质量和法规侧更关键：开发阶段要并行推进认证预测试（EMC、安规、无线入网等)、可靠性测试（温循、振动、寿命）、环境与有害物质检测。这些测试周期长，不能等到 TR6 之后再做。常见做法是在详细设计完成时就启动预测试，TR5 样机出来后用正式样机跑认证，在 ADCP 之前拿到正式报告或者至少拿到“无重大风险”的预测试结论。

财务活动的产出不是“一张报销表”，而是三份材料：目标成本预测（当前 BOM 成本与目标成本差距）、项目预算执行率（实际花费和剩余预算）、盈亏分析与定价建议。这些材料直接进 ADCP 决策包。如果财务只在评审前三天收到通知，大概率只能给出一个不痛不痒的“预算花完了”的结论，无法支持决策。

4. 驱动阶段转动的暗线：PDT 例会怎么开、TR3-TR6 技术评审怎么过、BETA 测试怎么设计

活动清单是静态的，真正推动阶段往前走的是三条暗线：PDT 例会的节奏、技术评审（TR）的结论、BETA 测试的数据流。许多团队活动说明写得好，但例会开成汇报、评审开成宣讲、BETA 开成“请客户吃饭”，最后阶段失控。这一章把三条暗线分别说透。

4.1 PDT 例会从“汇报进度”改成“决策和处置”

开发阶段一般每周开一次 PDT 例会，由 PDT 经理主持，各领域代表（研发、采购、制造、市场、服务、财务）必须到场。例会不是让每个人念一遍“上周干了什么”，而是聚焦四类议题：关键路径是否受阻、技术风险是否有新问题、需求变更是否影响基线、资源和预算是否需要调整。每一类议题都要在会后留下决策记录。

我会让会议组织者准备一张“议题单”：每个议题标注类型（决策/信息/讨论）、责任人、期望结论和时限。会上只讨论需要决策的事项，信息类内容提前发邮件。没有决策的 PDT 例会开得再长，也不会让开发进度前进半步。另一个实用规则是“红黄绿”状态：绿灯事项不进会议室，黄灯事项明确升级时间和责任人，红灯事项当场形成处置方案。这样每个例会基本能控制在 45 分钟以内，而不是两小时空转。

4.2 TR3-TR6 技术评审：每个评审点看什么、怎么投

技术评审是开发阶段的“质检站”。一套常见的 TR 划分是这样的：TR3 评审概要设计，解决“系统架构和关键技术方案是否成立”；TR4 评审详细设计，解决“模块级设计是否可开发、可测试”；TR5 评审样机，解决“产品是否达到了 Beta 测试的状态”；TR6 评审试产验证，解决“产品是否具备上市和量产条件”。TR 的编号在不同公司略有出入，但评审逻辑是通用的：每个评审点都有一个退出标准，标准不满足就不能进入下一个活动。

评审组织一般由系统工程师（SE）牵头，而不是项目经理。SE 负责汇总评审材料、确定评审专家人选、主持评审会议、跟踪问题关闭。评审结论分三种：通过、有条件通过、不通过。最忌讳的是“有条件通过”用得太顺手，条件列了一堆，后续没人跟踪关闭。我一般会在有条件通过的结论后附一张“条件跟踪表”，每条条件带责任人和预计关闭日期，下次评审先过这张表。

TR 评审还有一个容易被忽视的点：评审专家不能只请研发内部的人。至少要拉制造、采购、质量和服务的代表参加。TR5 如果只看功能，不看可制造性和可服务性，问题会在 TR6 集中爆发。跨领域评审能提前暴露很多“技术上行得通、现实中做不出来”的问题。

4.3 BETA 测试：客户现场的“最后一根救命稻草”

样机 TR5 通过后，产品进入 BETA 测试，这是开发阶段里唯一在客户真实环境里验证产品的机会。BETA 测试做不好，发布后的问题只能靠售后和客诉来买单。BETA 测试设计有三个关键参数：站点数量、站点类型、测试协议。

站点数量取决于目标市场的多样性。常见做法是选 3 到 8 个站点，软件产品可以多，硬件产品受样机数量限制，精选 3 到 5 个即可。站点类型要覆盖三类：标杆客户（有影响力、愿意给反馈）、典型客户（代表主流场景）、宽容客户（愿意陪你调试 bug）。只选“关系好的客户”是 BETA 测试最大的坑，因为宽容客户发现问题也未必较真，收集不到真实反馈。

BETA 测试协议要提前书面化：测试周期、数据采集方式（日志、问卷、远程诊断）、问题级别定义、响应时限、退出条件。退出条件通常包括：无致命问题、严重问题关闭率达到 80% 以上、关键性能指标达到产品规格、客户对重点场景确认可用。BETA 测试结束时，要输出一份“客户问题清单和发布建议”，它直接进入 ADCP 决策包，是评审委员衡量“产品能不能卖”的最硬证据。

5. 避坑实录：IPD 开发阶段最容易翻车的 5 个现场问题与处理办法

活动说明写得再完整，也挡不住现场的执行偏差。这一章是我在多个项目里反复踩过的坑，按出现频率和破坏力排序，每条都是“现象 → 原因 → 解决”的写法，可以直接对着排查。

5.1 TR 评审变成“PPT 宣讲会”，退出标准形同虚设

现象：TR 评审会开得热热闹闹，研发讲了两个小时，评审委员听完表态“辛苦了，通过”，或者象征性提几个问题。第二次 TR 才发现产品设计有硬伤，返工成本以周计算。

原因：退出标准写得太软，全是“基本完成”“无重大遗留”，没有量化门槛。评审委员没有前置阅读评审材料，现场只能听个大概，很难问出有质量的问题。解决：把每个 TR 的退出条件做成清单，每项都带可验证的证据名和具体阈值。比如 TR5 的“缺陷清零”不能写“严重 bug 基本关闭”，而是写“致命缺陷 0 个、严重缺陷 0 个、一般缺陷收敛且无新增超 3 天未响应”。评审材料提前 3 个工作日发给评审专家，会上只核对证据，不看宣讲。

5.2 需求变更悄悄进开发阶段，基线形同虚设

现象：设计做到一半，市场突然说“客户要求加一个接口”，研发觉得“改动不大，顺手做了”。一个月后，“顺手”的改动累积到三周工作量，计划延期的锅最后甩给了测试时间不足。

原因：计划阶段的 PRR（产品包需求）和产品规格没有建立严格的基线管理，变更没有走 CCB（变更控制委员会）流程。开发阶段任何需求变更，哪怕表面上很小，都要经确认：它会影响功能、工期、成本还是三者全占。解决：开发阶段开工第一周，正式冻结产品规格基线。后续所有需求变化统一走变更申请单，由 CCB 评估影响再决定接受、拒绝或推迟到下一个版本。活动说明里要给变更流程留出明确入口，不能让人找不到提交变更的地方。

5.3 计划、成本两张皮，财务给不出“值不值得发”的判断

现象：ADCP 前财务要项目盈亏分析，财务人员说“我没数据”，项目经理说“预算早超了但财务没告诉我”，最终决策全靠拍脑袋。

原因：WBS 与预算没有对齐，活动没有挂接资源和成本。项目经理管进度，财务管报销，两个体系不通。解决：从计划阶段就把预算分摊到 WBS 的每个活动，开发阶段按活动周期导出“实际成本 vs 预算”的报告。常见做法是每周 PDT 例会把财务数据作为一项固定输入，不需要财务每次重新统计，而是直接从工时系统、采购订单、费用报销三处抽取，自动汇总。活动说明里要写明财务活动在整个阶段的采样时点，而不是只在 ADCP 前来一次。

5.4 试产一次通过率低，工艺准备永远“晚一步”

现象：样机做出来，兴冲冲安排试产，结果直通率不到六成。一分析，SOP 没写、工装没验证、操作员第一次上手。问题清单里一半是制程问题，不是产品问题。

原因：制造代表没有在 TR3 早期介入，工艺路线设计、DFM 检查和工装策划都被推迟到样机出来才启动。解决：制造活动在开发阶段启动会上就同步展开，TR3 之后完成工艺路线初版，TR4 之后完成 DFM 检查，TR5 前完成 SOP 初稿和工装验证。试产前做一次“制造准备度检查”，把直通率目标、设备状态、人员培训、物料齐套四件事全部确认完再启动线体。

5.5 BETA 测试变成“走场子”，问题清单没人跟踪

现象：BETA 测试结束，报告写了“客户反馈正面，产品建议发布”。结果上市后客户现场问题集中爆发，好几个是 BETA 期间已经出现但被归为“轻微”的缺陷。

原因：BETA 测试协议没有定义问题级别和响应机制，站点选择偏向友好客户，反馈质量低。解决：BETA 测试必须有书面的问题定级标准（致命/严重/一般/轻微）和响应时限，基本原则是：致命问题一票否决、严重问题要有临时规避方案才能继续发布评估。每个问题挂责任人，每周更新状态，BETA 结束时的“问题清单”不只是附件，它是 ADCP 的决策依据之一。如果 BETA 测试报告没有带问题清单，评审委员会有权直接打回。

6. 把阶段做实的一个技巧：用退出条件清单倒排活动，周一例会只看五个数

如果只能带走一个方法，我建议你用“退出条件清单倒排活动”来管理开发阶段。做法很简单：从 ADCP 往前倒推，先写出每个评审点的退出条件，再根据退出条件反推每个领域必须在何时交付什么。

以 TR6 为例，我先列退出条件：试产直通率达标、关键工序 Cpk 达标、认证报告无不利结论、物料供应无高风险项、BETA 问题严重项关闭率达到 80%、目标成本偏差在允许范围内。然后倒排：直通率达标需要试产前做工艺验证，工艺验证需要 SOP 和工装提前到位，工装设计和 DFM 检查就要在 TR4 同步启动。这一串倒排下来，每个活动都有了“必须完成的日期”，而不是“尽量完成”。退出条件清单里每项都要带“证据出处”：报告名称、责任人、更新频率。

我还会把周一 PDT 例会压缩成“只看五个数”：关键路径偏差天数、致命/严重缺陷数量、试产直通率（如果已试产）、BETA 问题关闭率、预算执行率。五个数不达标的项就是当周处置议题，其余一律看趋势、不占用会议时间。这套做法管过几个产品线后，开发阶段最大的变化是：例会短了、评审有据了、ADCP 不再靠“感觉可以发”来决策。

回头想，我最早栽的一个跟头就是“活动说明拿来存档，不进计划”。后来把退出条件倒排成表，贴在白板上，每个活动负责人自己认领交付日期，不再事事等项目经理催。一份活动说明的价值，不在文档本身，而在它能不能让每个角色在节点前知道自己手里的活是“卡别人脖子”还是“被别人卡脖子”。希望这份拆解帮你在开发阶段少走我走过的弯路，让 IPD 真正从页面上的流程图变成项目现场的行动指南。

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