1. 先说清楚IPD开发阶段到底在做什么很多人在IPD流程图上看到开发阶段四个字第一反应就是这不就是写代码、做设计吗。如果你也这么想那大概率会在真正进入这个阶段时被烦到怀疑人生。华为IPD流程整个周期里的活动数量是370个而光开发阶段这一个节点就占了其中相当大一块背后涉及研发、测试、供应链、采购、制造、服务、财务、市场等几乎所有功能部门的协同。换句话说开发阶段不是一个技术实现问题它是一台精密运转的管理机器。这篇文章就围绕IPD流程中开发阶段的活动展开结合我这些年参与IPD项目落地和产品开发的实际经验把这些活动到底怎么组织、为什么这么设计、哪些地方最容易崩盘一项项讲明白。适合正在做IPD流程建设或变革的研发经理、项目管理办公室成员也适合那些准备导入IPD但还停留在听过名词阶段的中小企业研发负责人。看完你至少能回答三个问题开发阶段从哪进来、到哪出去、中间凭什么质量闸口把关。我见过不少团队把IPD理解成加了一堆评审会实际上评审会只是表象开发阶段真正的内核是活动分层、责任落地和交付物驱动。这套东西不搞明白上线只能学个形。2. 开发阶段的入口条件与370个活动的组织逻辑2.1 从哪个关口正式进入开发阶段IPD流程里产品开发从概念阶段、计划阶段一路走到开发阶段不是自己顺理成章流进来的。它有一张严格的门票——计划决策评审点也就是PDCP。在这个决策评审点之前项目团队要拿出完整的业务计划包括产品包需求、初步的总体方案、市场策略、财务分析、资源承诺等。管理层在PDCP投完票、批了钱和资源项目才算正式从纸面设计进入真刀真枪的开发阶段。这个入口条件经常被忽略但它特别关键。很多没有真正落地过IPD的团队以为开发阶段是从项目启动会开始的大家坐在一起喊喊口号、分分工就开工了。但在华为IPD的语境下哪怕内部代号已经定了只要PDCP没有签核开发活动就不能大规模展开。这个机制倒逼着概念和计划阶段把需求想透、方案想透避免边开发边改需求这种经典灾难。我以实际经验说一句入口卡得越严开发阶段越顺。反过来入口松一天后面可能多出来三十天的返工。这跟装修房子一个道理图纸没定好就砸墙最后一定到处返工。2.2 370个活动怎么从五个方面组织起来370个活动这个数字第一次看到的人容易懵。我也见过有项目经理把活动清单打印出来贴在墙上结果发现根本没有哪个人能完整看完一遍。其实这370个活动不是孤立堆在那里的它们是按专业领域和职责分工组织起来的。研发域包括总体方案设计、模块详细设计、代码编写、单元测试、集成测试、样机调试等是整个开发阶段最核心的发动机。市场域包括产品资料撰写、市场推广物料准备、样板点建设、销售工具包开发等这些活动的目的是保证产品出来之后有人会卖、卖得出去。供应链与制造域包括物料清单BOM发布、物料认证、供应商导入、生产工艺准备、试产、批量生产验证等解决的是能不能造出来、能不能稳定造出来的问题。服务域包括安装调试手册编写、运维工具开发、培训课件制作、服务交付工具准备等牵扯的是客户买回去之后能不能用起来。财务与项目管理域包括开发成本核算、目标成本跟踪、资源计划执行、风险监控等解决的是干完这个项目到底挣不挣钱。换句话说370个活动不是研发一个部门的事。IPD最核心的思想之一就是集成开发阶段做的不是把一个技术方案变成一台机器而是把一套可卖、可造、可交付、可服务的商业承诺变成现实。如果你所在团队现在还只有研发人员在为开发阶段排计划其他部门都在等通知这实际上就已经偏离了IPD的底层逻辑。2.3 开发阶段与前后阶段的活动衔接再补一个容易忽略的点——开发阶段和上游计划阶段、下游验证/发布阶段不是严格串行的。IPD里有很多活动是叠着做的比如市场资料撰写可以早于样机出来制造工艺准备可以和模块开发并行。这个并行不是无原则的它背后依赖一个叫集成计划的机制所有领域的活动统一排进项目主计划用依赖关系把先后次序标清楚。举个例子BOM的初步版本在开发阶段前中期就要首发了否则采购没法提前备料供应商没法提前备产等样机全部做完再发BOM交付周期至少慢一个月。有经验的项目经理都明白BOM发布不是研发关起门来完成的活动它牵动着采购、计划、制造、财务一整排流程节点。3. 核心活动拆解技术评审、设计与制造准备3.1 技术评审活动TR4、TR5、TR6怎么组织华为IPD的技术评审体系里开发阶段横跨了好几个关键的TR评审点。TR这个地方我用最直白的话解释它是研发内部的质量闸门每个TR都有自己的评审要素和退出标准不过关就得整改或就地验收不通过。放开发阶段的具体场景TR4对应的是模块/子系统验证完成可以开始系统集成的节点。TR5是系统集成验证完成满足进入Beta测试的条件。TR6是产品验证完成具备量产发布条件。每个TR评审点承载的关键材料完全不一样评审组的人员构成也不一样。TR4重点看什么模块级设计规格是否符合总体设计、单元测试覆盖率和通过率、关键算法的实现效果、模块接口定义是否稳定、各模块之间的依赖关系是否清晰。TR5重点看什么系统功能与产品包需求之间的追溯性、系统性能和可靠性指标实测结果、遗留问题的风险评估、系统集成测试报告。TR6重点看什么产品全要素验证结果包括功能、性能、可靠性、兼容性、安全、可服务性、可制造性等还要看Beta测试客户反馈、试产情况、物料供应准备情况。技术评审这个动作本身实操里最容易陷入两个极端。一个极端是评审会变成部门汇报会研发讲了一下午模块实现细节评审专家抓不住重点。另一个极端是评审会变成仪式会大家提前把材料备齐、走个过场实际风险根本没人拍板。这两种我都见过。好的技术评审会前必须有明确评审要素表责任专家提前审阅材料会上只讨论问题、结论和风险不做技术培训。3.2 研发域的详细设计与模块开发活动从TR4之前倒推开发阶段最开始的一批核心活动就是详细设计和模块开发。这个阶段大家通常叫技术实现期但在IPD的活动清单里它绝对不是写到哪算哪的自由模式。每一条代码、每一块逻辑或者硬件原理图、结构图都得能追溯到最初的产品包需求。IPD把这套动作叫做需求追溯性活动简单说就是往后能问一句这个功能是被哪个需求驱动的。具体到实操层面详细设计完成之后要输出一套完整的详细设计文档其中包括模块接口设计、数据库设计、关键算法设计、异常处理设计、可靠性设计等。这些文档会作为编码或开发活动的输入。大多数没落地过IPD的团队会问现在都敏捷了还需要这么重的详细设计文档吗我的观点是文档的粒度可以根据产品风险灵活调整但设计先行这个原则不能丢。硬件产品尤其不能省画板子之前不做原理图评审等着你的就是改版三回的痛苦。模块开发这个活动本身不同的技术领域做法完全不一样。硬件领域的模块开发是原理图绘制、PCB布局布线、FPGA逻辑开发软件领域是设计编码、单元测试、代码走查结构领域是三维建模、仿真分析、手板验证。虽然形态不同但背后的管理活动是统一的每个模块要有负责人、有交付计划、有质量基线。开发阶段之所以被称为370个活动最密集的阶段核心秘密就在于每一个模块都不是只做研发那一件事它同时要完成测试用例准备、物料准备、工艺准备等一堆配套动作。3.3 制造与供应链活动的关键路径接着上面那段说。如果你的产品只是纯软件供应链活动相对简单。如果是硬件、硬件加软件或者包含结构件那么制造与供应链活动一定是开发阶段的关键路径之一。制造域的代表性活动有这么几类可制造性设计DFM评审、试产准备、小批量试产、量产爬坡验证。DFM评审往往在详细设计阶段就要介入比如PCB布局是否考虑了SMT贴片工艺要求、结构件的公差设计是否考虑了模具工艺能力、线缆组件的装配顺序是否合理。这些一旦等到样机做出来再改模具费、贴片费、改版费分分钟烧掉预算。供应链域的代表性活动包括物料认证、供应商开发、样品验证、首批物料采购、长周期物料备料。物料认证这个环节特别容易踩坑尤其是芯片、连接器、电池这些关键物料。物料认证不只是拿个规格书回来它要跑电气性能验证、环境可靠性测试、批次一致性验证必要时还要做供应商现场审核。我在实际项目里见过一个电阻电容这种基础器件因为没做物料认证整批货到了产线发现物料引脚共面性不过关最后整批报废重新采购交期硬生生拖了三周。制造与供应链的启动时机是个老生常谈但永远有人忽视的问题。一群人力争等设计冻结了再启动供应链活动理由是频繁变更会浪费供应商精力。但从IPD的活动编排看供应链活动必须和详细设计并行启动因为供应商开发、模具开发、长周期物料采购的周期往往比研发设计周期还长。沃尔玛采购会提前一年锁定供应商产能IPD产品开发其实也是同样的逻辑。3.4 服务与市场领域提前介入的意义服务与市场领域在开发阶段的活动很多研发工程师看不懂总觉得产品还没做出来市场部在忙活啥。实际上这些活动恰恰是IPD和普通研发流程拉开差距的地方。市场域开发阶段的主要活动集中在产品上市准备。这包括客户化需求确认、竞争分析更新、产品定位和卖点提炼、产品命名与商标注册、产品资料撰写、市场宣传物料制作、销售激励方案制定。产品资料撰写尤其需要时间一个复杂的通信设备或者工业设备产品说明书、安装指导、配置手册、故障处理指南加起来可能上千页这些如果等到上市前一个月才开始写质量一定拉跨。服务域的活动集中在可服务性设计验证和服务交付工具准备。什么叫可服务性设计验证拿一台设备来举例现场安装时能不能一个人搬动、机柜里能不能方便理线、故障指示灯是否醒目易识别、远程诊断功能是否可靠这些决定了一款产品在客户现场的交付效率和运维成本。我以前见过一款机架式设备设计阶段没人认真做可服务性验证结果到了客户现场发现更换电源模块必须先把十几根线缆拆掉一个简单操作要停机半小时。后来改结构花了半年半年里所有交付项目都被客户投诉。服务资料和工具也得跟着开发走。安装手册、开局调测记录表、巡检脚本、远程升级工具、日志采集分析工具这些交付物如果没有在开发阶段同步开发、同步验证等项目进入验证阶段再补就变成了为了交付而交付质量堪忧。IPD把市场和服务的活动提前放进流程本质上是把未来能不能用、好不好卖的声音在开发过程中就持续放大给开发团队听而不是等产品做完再秋后算账。4. 实操层面的做法文档、BOM、样机与评审节奏4.1 一个典型开发阶段的项目日历长什么样活动清单很丰富但没有编排就没有意义。我基于自己的项目经验把IPD开发阶段的项目日历梳理成四个节奏段你可以作为一个参考切片来理解。第一段详细设计与模块开发启动。这个阶段大概占开发周期前30%的时间主要做系统总体设计细化、模块详细设计评审、关键物料选型验证、测试策略和测试计划评审。在这个阶段研发人员和测试人员就要一起评审测试计划不能等开发完了再叫测试过来测一下。供应链活动同步启动BOM初版发布给采购做备料准备。第二段模块实现与子系统集成。这个阶段是整个开发过程强度最高的阶段编码、硬件调试、结构手板验证并行推进子系统集成测试逐项开展。TR4评审通常安排在这个阶段的末尾评审过了才能进入全系统集成。产品经理、市场人员在这一段开始撰写产品资料初稿并与早期客户做需求确认。第三段系统集成与样机验证。系统联调、性能调优、可靠性测试、安全测试、Beta版本发布全套验证活动在这个阶段密集展开。TR5评审安排在这个阶段的出口通过之后意味着产品功能已经稳定可以进行外部测试。制造和供应链在这个阶段会安排小批量试产试制提前暴露量产问题。第四段量产验证与发布准备。完成试产问题闭环、批量物料认证、产品资料齐套、服务工具验证。TR6评审是这个阶段的收口闸门之后进入验证阶段的Beta测试和正式量产发布再往后就是GA发布。我带的项目里这一段的重点工作是试产问题闭环问题能不能清干净决定TR6能不能顺利过关。4.2 技术评审会怎么开才不走过场技术评审不是技术讨论会。很多团队犯的错误是把评审专家请过来大家一起坐下来研究这个问题还有什么别的解决方案。讨论很愉快但评审结论出不来问题责任说不清。真正的技术评审会应该聚焦三件事第一对照评审要素表逐项给出符合性判断第二识别风险项和遗留问题明确owner和关闭日期第三给出明确的评审结论——通过、有条件通过或打回。评审会之前最晚提前三到五天要把评审材料发给评审专家。材料里除了设计文档还必须包含一份评审要素自查表让专家知道重点看什么。评审会的产出物是一份评审报告里面记录每个评审要素的结论、风险项、遗留项、整改责任人和时间点。会后项目组需要一个跟踪闭环机制通常在周例会上回顾遗留项状态风险不关闭就不允许进入下一个阶段。所谓有条件通过一定要有明确的整改时限和验证方式。否则就是变相通过。我在流程里坚持一个原则有条件通过的整改项如果超过两周没有关闭必须升级到项目指导委员会重新评估风险。这个机制看着繁琐但能挡住大量看起来没事但其实是坑的漏网之鱼。后来不止一个团队跟我反馈差的就是这一条。4.3 BOM、样机、物料齐套管理刚才反复提到BOM这里展开讲。BOM是连接研发、供应链、制造和财务最核心的数据载体。开发阶段的BOM管理一般分三步走工程BOM、试产BOM、量产BOM。工程BOM在详细设计阶段就搭出来这时候可能还有很多替代料没有定试产BOM在进入小批量试产前冻结BOM上的每个物料都要有明确的状态比如可用限量用替代用禁用量产BOM则必须在量产开始前完全冻结所有物料状态转正。BOM的准确性直接影响物料齐套。物料齐套率是开发阶段供应链管理最关键的指标它衡量的是按计划需要备的料实际到了多少比例。我之前管过一个硬件项目BOM发布时没有仔细核对物料生命周期状态结果有一款物料已经进入EOL停产状态采购等了两周才发现根本下不了单。后来我们在BOM评审流程里加了一个物料生命周期检查强制每个物料在进入试产BOM前必须核对生命周期状态和供应商供货风险等级这个Bug再没出现过。样机管理也是一项常被忽视的活动。硬件开发阶段样机是什么版本、放在谁那里、每个版本的变更记录、各模块的版本匹配关系都要有账可查。很多项目翻车就翻在版本管理混乱测试那边拿着一版软件配合硬件样机测试软件和硬件的版本不匹配一晚上测出来的数据全部报废。IPD开发阶段对样机管理的要求是建立样机台账每次组装样机必须记录硬件版本、软件版本、结构版本、物料批次测试报告必须关联对应样机编号。这套机制看起来很重但能够大幅减少扯皮和无效测试。4.4 需求变更在开发阶段如何控制开发阶段最怕的是什么我接触过的项目经理十有八九会说需求变更。IPD对需求变更有一套完整的控制机制核心是变更控制委员会CCB和变更管理流程。在开发阶段不是所有变更都被禁止但任何变更都不能绕过评估直接进开发。哪怕只是改一个按钮的位置也要评估改动范围、工作量、进度影响、成本影响、其他模块的连带影响然后由变更控制委员会裁决。我讲一个真实的经验有个硬件项目在开发阶段中期客户提出要把某接口从A类连接器换成B类连接器理由是使用的更方便。乍一听是个很小的改动。但评估团队查了一轮后发现这牵扯到结构开孔改模、PCB布局调整、电源和信号完整性重新仿真、线缆组件重新设计、环境可靠性试验重做整体影响开发周期三周追加成本六十多万。最后变更控制委员会否决了这个变更把它引导到下一版本规划项目按时发布了。需求变更控制的关键不是一刀切不让改而是所有变更必须被看见、被评估、被决策。我在流程推行初期研发团队嫌流程烦走变更要填一堆表单但在吃过几次没走变更偷偷改最后基线崩溃的亏之后所有人比我还积极地提变更申请单。工具是死的规矩是活的重点在于让所有人对变更成本有清醒的认知。5. 我实际踩过的坑与给后来者的建议5.1 坑一活动清单堆出来了但没人认领刚推行IPD时最常见的现象是咨询顾问给了一套370个活动的模板流程部门照着模板把开发阶段的活动全排进计划然后召集各领域代表开会过了一遍大家点头说没问题。结果项目一启动很多活动根本没人执行。为什么因为模板里的活动到各领域时没有明确的角色映射大家不知道哪件事归自己。这个问题怎么解决我后来用的办法是活动认领会。项目启动后每个功能领域必须把自己负责的活动清单逐条确认确认时不光看活动名称还要确认活动的输入、输出、责任人、周期、依赖关系。确认完由领域负责人签字承诺。这套做法看着像是在走形式但它强制各领域去思考我的活动到底靠什么完成、我需要的上游输入是什么、我的下游靠我什么东西。没有这轮强制思考IPD落地一定会变成墙上流程。5.2 坑二评审材料太厚评审专家根本看不完我见过一份TR5评审材料打印出来四百多页评审专家每个人拿一摞回去看。实际上是个人都看不完最后评审会上大家只能听着做汇报评审结论跟着汇报的节奏走。评审质量彻底失控。后来我们规定评审材料必须配一份一页纸的评审摘要里面写清楚本次评审的范围、核心结论、风险项、关键数据、遗留问题。详细文档作为附件专家按需查阅。同时材料提交时间严格卡在评审会前至少五个工作日不够时间看材料的专家有权要求延期评审。这一条规定执行之后评审会上争吵的质量明显提升因为专家是带着问题来的不是带着困意来的。5.3 坑三试产发现的设计问题没有闭环量产全炸小批量试产的目的就是暴露问题。但很多项目的试产报告写得很漂亮问题清单列了二三十项项目经理看了一眼说都记下来了结果并没有完全闭环。尤其是那些属于设计层面的问题因为试产已经完成人被抽走去做别的事问题搁在那里没人管。等到量产启动旧问题原封不动出现在产线上造成的损失远大于当时多花两周解决的成本。我的习惯是每次试产结束必须举行一次问题清零会议把试产发现的所有问题逐项过堂明确三条怎么改、谁改、什么时候改完验证。验证必须是在下一轮试产或插单验证中实实在在跑一遍而不是改完了三个字就算数。这个机制我推得很严因为我知道量产的效率和质量其实是靠开发阶段一点点扛出来的。5.4 坑四测试资源永远在抢计划永远在飘测试资源的冲突是开发阶段管理最头疼的问题之一。研发说测完就交付测试说排队排到下周项目经理夹在中间两头挨骂。IPD对测试的管理方式是把测试计划纳入主计划统一编排在详细设计阶段就把测试方案、测试用例和测试资源规划确定下来。测试计划不是后台部门自己排的而是和开发计划绑定的。实际操作中还有一个很实用的做法是测试用例分级。把用例分成冒烟测试、核心功能测试、全量回归测试三档。开发阶段每天的集成验证只跑冒烟和核心功能全量回归放到关键节点跑。这样既不浪费测试资源又能保证最高的风险覆盖。以前我带的项目软件集成测试周期平均要十二个工作日做了用例分级和测试计划前移之后压缩到七个工作日左右而且缺陷逃逸率还下降了。写在最后的几点个人体会做了十几年项目带过几次IPD流程上线我个人对IPD开发阶段最大的体会是那370个活动不是用来吓唬人的它真正的价值在于让每个领域的每个人都清楚自己应该什么时候干什么事。IPD解决的问题从来不是我们缺一个聪明人而是我们缺少一种让所有聪明人有序协作的方法。如果你正在推动某个产品团队导入IPD我建议你别一上来就盯着370个活动清单发愁。先挑开发阶段里最容易翻车的三条线理清技术评审怎么开、BOM怎么管、物料和样机怎么齐套。这三条线捋顺了其他活动会自然地找到自己的位置。最后再分享一个实用技巧开发阶段的周报格式一定不能是罗列工作进展而是围绕关键交付物和风险项更新好的项目经理不看你在做什么只看该交付的东西有没有按期浮现出来。