简介这份资料面向产品研发管理者、IPD流程推进人员及项目经理聚焦产品开发流程中“开发阶段”的关键活动梳理了外围组成员任命、项目环境更新、开工会召集、对外合作计划执行以及项目监控等内容为理解从计划阶段转入开发阶段后的具体操作节点提供清晰参考。资源共1个文件为PDF格式压缩包约236KB适合在移动端或电脑端快速查阅、按活动条目对照实践。目前已有312人学习下载属于小而精的流程说明类素材。内容预览中保留了中英对照的活动描述并给出了开工会的具体议程建议读者可据此了解每一步骤的输入、输出及责任人便于在自身项目中落实IPD开发阶段的管理动作。1. 计划评审刚过就乱成一锅粥开发阶段活动说明到底在管什么在一家正在导入 IPD 产品开发流程的硬件公司计划决策评审通过那天还带着仪式感大家签完字承诺就写进了合同。接下来两个月办公室里最常响起的是“这事怎么没人早点说”样品做完了才发现外壳要开模测试用例写完了才发现环境没搭财务还在用立项时的估算到开发结束才爆出超支三成。《IPD-产品开发流程-开发阶段活动说明.pdf》要解决的就是这个问题它是 IPD 流程在开发阶段的“操作手册”把从开工到样机、再到可制造准备的每项关键活动的触发条件、输入输出和评审门禁讲清楚。适合正要导入 IPD 的产品经理、刚接任开发任务的 PDT 核心成员以及所有被“研发很忙、交付却总差一口气”折磨的管理者。2. 开发阶段在整个 IPD 流程里的位置DCP 与 TR 两套评审如何给它划线2.1 六个阶段、四个决策点开发阶段的前门与后门IPD 产品开发流程把一款产品从概念到退市的完整过程切成了六个阶段概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段。概念阶段回答“做什么”计划阶段回答“怎么做”开发阶段回答“做出来”验证与发布阶段回答“做对了没有、能不能卖”生命周期阶段则处理退市与收尾。不同公司的阶段名略有差异但这个主干几乎一致。阶段与决策评审点的对应关系我习惯用一张表记阶段关键决策评审本阶段的典型活动范围概念阶段CDCP 概念决策评审市场机会分析、产品包概念、技术可行性判断计划阶段PDCP 计划决策评审需求冻结、总体方案、项目计划、商业承诺签订开发阶段出口对接 ADCP详细设计、样机开发、测试、可制造性准备验证阶段ADCP 可获得性决策评审系统级验证、小批量试产、发布准备发布阶段GA 一般可获得性发布批量上市、早期客户支持生命周期阶段EOL 生命周期终止评审产品退市、存货与资料处理开发阶段的前门是 PDCP。也就是说开发阶段活动说明的入口条件通常写着计划决策评审已通过、需求基线已冻结、项目团队正式任命、PDCP 承诺合同已签署。后门是 ADCP走到这一步意味着产品已经达到“可发布”状态。开发阶段活动说明里所有活动本质上是为你在这个区间里不跑偏、不遗漏、不欠账而设计的。这里有一个常见误解。很多团队把开发阶段当成“研发使劲干”的阶段觉得前门一开大家闷头写代码、画板子就行。实际上IPD 流程里的开发阶段是一条并行跑道研发活动在跑采购、制造、财务、服务同样在跑。活动说明要管住的不只是研发而是所有在开发阶段有动作的角色。2.2 一份活动说明文档到底在写什么第一次打开这种 PDF 的人容易失望它没有项目管理书籍式的叙事就是一张张活动表。每一行描述一个活动字段通常是这七样活动编码、活动名称、触发条件、输入、活动步骤、输出物、责任角色。做得细一点的公司还会加上周期参考值和模板引用。这些字段落在实际项目里各有各的用途。字段在文档里回答什么落地时的用途活动编码这个活动属于哪个活动组建 WBS 时作为任务编号前缀触发条件什么情况下活动可以启动判断任务依赖关系避免抢跑或空等输入开始前需要哪些文档或数据作为前置任务的完成标准活动步骤这个活动具体做哪几件事拆子任务、分配人力输出物活动结束必须交出的东西建评审检查表、做文档归档责任角色谁牵头、谁参与分配资源避免“没人负责”参考周期正常需要多长时间排计划的起点但只能当参考你看这些字段实际上是把项目管理里最常用的“输入-活动-输出”结构落到了纸面上。IPD 流程比一般项目管理啰嗦的地方在于它把活动之间的依赖关系、评审关系和商业决策关系也一并写进去了。所以读这份文档时不要把它当制度汇编背而是要把它当一张任务地图每个活动在哪个阶段触发、交什么出来、谁来接、由哪个评审来把关。我一般会建议项目经理拿到 PDF 后第一件事不是通读而是把“输出物”这一列全部抽出来做成一份 Excel 清单。后面排计划、设检查表、做审计全靠这份清单。2.3 为什么要两套评审交替划线开发阶段活动说明里会出现两类评审一类是 DCP 决策评审一类是 TR 技术评审。DCP 站在业务视角决定这个项目“继续投还是停”TR 站在技术视角判断“方案行不行、产品做出来没有”。两者性质完全不同活动说明里它们通常分开出现。很多研发团队把开发阶段当成黑匣子进去几个月出来一个样机。DCP 和 TR 的设计就是为了戳破这个黑匣子DCP 在入口和出口设卡TR 在过程中分段把关。常见做法下开发阶段会安排三个关键技术评审点TR4 偏模块与系统设计TR5 偏样机完成度TR6 偏发布准备度。至于具体怎么分布不同公司差异很大下一章我会展开讲。理解这套结构对你读活动说明很有帮助。看到“输出物”时你要能立刻反应出它对应哪个 TR 的评审要素看到“里程碑”时你要能指出它离哪个 DCP 最近。两份评审体系在你脑子里咬合成一张网开发阶段才不会被过成“研发闷头干、评审补个签字”的走形式。3. 拆解开发阶段的关键活动从启动会到问题单闭环的落地步骤3.1 第一步不是写代码而是项目开工会活动说明里开发阶段的第一个活动通常是项目开工会也就是 Kickoff。这个活动看起来像动员会实际输出却非常硬技术任务书和项目计划初版。没有这两个输出后续的设计活动缺少基准资源调度也没有依据。技术任务书要覆盖产品定义、目标市场与客户、功能性能指标、关键里程碑、成本目标、资源约束、以及项目组织与接口关系。开工会结束前项目经理要把这些内容逐字确认不能“先开起来后面补”。我的习惯是开工会后半小时内把任务书签发的动作和项目计划初版同步完成否则会议信息三天后就失效了。开工会还有一个隐形目标让所有跨功能代表在会上正式认领自己的开发阶段任务。采购不是“被通知来参会”而是要当场明确长周期物料清单什么时候给到制造代表要确认可制造性分析排进哪一周财务要确认开发成本跟踪表的更新频率。活动说明里每个活动都有责任角色开工会就是把“角色”变成“人名”的那个场合。3.2 设计活动链三层设计要分开评审开发阶段的研发主线是设计活动链。常见做法是拆成三层总体方案设计、详细设计、模块级设计。三层的输出物和评审侧重点完全不同不能一次评审会带过。总体方案设计解决系统架构问题。输出物是总体方案设计书要回答系统由哪几个子系统组成、关键技术路径是什么、有哪些风险、软硬件怎么分解、接口怎么定义。这一层的评审如果草率后面所有详细设计都在错误的地基上盖楼。详细设计解决功能模块怎么实现。输出物是详细设计说明书重点看功能逻辑、模块接口、可测试性设计。模块级设计则落到代码、原理图、结构件图输出物包括代码说明、原理图、单元测试用例。三层设计最难把握的是一边压缩进度一边保评审质量。开发阶段排期紧张时最容易牺牲的是详细设计评审。我的建议是如果进度实在不够模块级评审可以抽检但总体方案评审必须全员到场输出物必须逐条对照需求清单销项。3.3 样机与测试问题单闭环最值钱设计活动完成后进入样机阶段。开发阶段的样机测试节奏通常是样机试制、单元测试、模块联调、系统集成测试、以及一轮内部自测。注意集成测试在开发阶段就要启动不要全部留给验证阶段否则问题集中爆发时你连定位问题是哪一层引入的线索都找不到。这里最值得展开的是问题单管理。样机测试必然产生问题单活动说明里对问题单管理的常见要求是每条问题必须有编号、等级、责任人、解决版本、回归结果。等级一般分严重、一般、建议三档。严重问题必须在当前样机版本解决并回归一般问题可以带病进入下一轮但要明确解决版本建议类问题集中评审后统一处理。我见过太多开发团队在问题单上翻车问题清单一堆但没人指定解决版本等到验证阶段才逐个返工。给一个最实用的建议每周做一次问题单评审会只干一件事——检查“已解决”的问题是否闭环、“待解决”的问题是否有人认领。五分钟看清单比月底补数据有用得多。3.4 跨功能并行活动采购、制造、财务、服务各自该干什么开发阶段活动说明里最容易被研发人员忽略的那部分是跨功能活动。实际上开发阶段后半段的进度瓶颈往往不在研发而在采购和制造。采购活动在开发阶段的重点是长周期物料识别与确认、供应商资格审核、试产物料备料。长周期物料指的是交货周期超过项目关键路径的物料比如定制外壳、专用芯片、特殊连接器。这类物料的启动信号不是“BOM 冻结”而是“BOM 初版可用”。制造活动的重点是可制造性分析、工艺流程设计、工装夹具设备清单输出。制造代表需要在详细设计阶段就介入提前发现“设计出来了但产线做不出来”的问题。财务活动不是只在月底出个报表。开发阶段的财务跟踪要回答两件事开发成本与实际支出偏差多少单位产品预测成本与目标成本差多少。服务活动的重点是安装与维护方案、备件策略、技术文档框架。这些文档如果等验证阶段再启动发布时一定来不及。跨功能活动与研发活动是并行的不是串行的。这也是开发阶段活动说明与普通研发计划最大的区别它不会只按“需求-设计-编码-测试”这条研发链路走而是同时铺开五条业务线。4. 把活动说明映射成 TR 评审和项目计划输出物倒推检查项4.1 开发阶段的技术评审分布TR4、TR5、TR6 分别审什么不同公司对 TR 的划分方式差别很大但既然这份文档叫“开发阶段活动说明”里面必然会有一张图或一张表来描述开发阶段涉及哪些技术评审。常见做法下开发阶段与 TR4、TR5、TR6 相对应只是位置和叫法各异。评审点常见关注点主要依据的输出物TR4模块或子系统级设计是否完备、接口是否清楚、关键技术风险是否受控总体方案设计书、接口文档、模块级设计说明TR5样机是否做出来、功能性能指标达成率、问题单状态样机实物、测试报告、问题单清单TR6可制造性、可服务性、发布准备度试产报告、工艺文件、服务文档、发布计划如果你的公司把 TR4 放在计划阶段末尾或者把 TR6 放在验证阶段开头都不用纠结。重点是把你自己的活动说明放桌面上把输出物和评审点画一条对应线。大部分团队在开发阶段“评审混乱”根源就是搞不清“这个评审点到底要看哪几个活动的输出”以及“这些活动的责任人在不在现场”。4.2 从输出物倒推检查项评审会才不会变成读 PPT我常用的方法是做三层映射每层之间用表格连接。第一层列出活动说明里所有与开发阶段相关的活动第二层为每个活动标出输出物第三层为每个输出物拆出评审要素和检查项。以总体方案设计为例活动输出物评审要素检查项示例总体方案设计总体方案设计书需求覆盖性是否覆盖需求跟踪矩阵中全部需求条目总体方案设计总体方案设计书接口完备性子系统间接口是否已定义格式是否可执行总体方案设计总体方案设计书风险受控关键技术风险是否识别是否有备选方案总体方案设计总体方案设计书资源估算开发资源估算与计划阶段承诺是否一致这套表做完评审会的过法就完全变了不再是每个人现场翻 PPT 凭感觉提问而是拿着检查项逐条销号。没通过检查项的输出物都不允许进入下一活动。检查项的来源必须能追溯到活动说明里的“输出物”字段这样文档、计划、评审三者才真正咬合。4.3 用活动说明排两层计划主计划定节点滚动计划排细活开发阶段的进度管理我会把它拆成两层计划来排。主计划只放三类节点DCP 决策点、TR 评审点、样机和试产里程碑。主计划的周期不用排得很细按周排列即可。滚动计划则要细到任务级每两周刷新一次任务来源就是活动说明里的活动清单。滚动计划排任务的规则是先取活动说明里的“触发条件”建依赖再按“参考周期”估工期然后把“责任角色”对应到具体人名。第一次排出来的工期千万不要直接信把它当成第一次估算等你跑完第一个双周用实际偏差修正后续估算。排期这种事多少有点玄学但活动说明能帮你把玄学范围从整段开发阶段缩小到一个具体活动上。我还会在滚动计划里单独加一列“依据活动编码”每个任务都能追溯到活动说明里的某一行。这样做的价值在计划偏差审计时特别明显哪个任务漏了一查就知道它对应的活动为什么没触发。5. 开发阶段活动落地避坑评审走过场、长周期物料失控与测试欠账以下几条是开发阶段推进中最高频的坑每条都遵循“现象、原因、解决”三段讲方便你直接对照排查。5.1 活动说明挂在共享盘里没人看进度全靠项目经理想当然现象项目启动三周后问团队成员“开发阶段要交付什么”十个人有九个答不全。任务排期靠项目经理拍脑袋活动说明只在做计划时被打开过一次。原因文档和 WBS 没有产生关联。活动说明是独立的一份 PDF项目计划是另一套 Excel两边的活动名称、编号、责任人都不一样团队成员自然觉得它是“制度文件”而不是“工作依据”。解决把活动说明裁剪成检查表挂到 WBS 的每个任务下面。具体做法是给 WBS 任务增加“依据活动编码”字段并在任务描述里附上输出物要求和模板链接。项目计划里还要加一列“完成标准”直接引用活动说明的输出物名称。文档一旦变成任务属性就不会再躺在共享盘里吃灰。5.2 详细设计评审被跳过“技术老大拍板”式做法现象开发进度落后项目组决定“详细设计评审不开了模块负责人确认过就行”。样机做出来后集成测试发现接口不匹配返工两周。原因进度压力之下评审被视为“流程负担”而不是“风险控制手段”。“技术老大已经看过了”这句话背后往往是没有留下可复查的评审记录参与者的意见没有被逐一确认。解决把 TR 评审做成阶段门禁活动说明定义的输出物不齐、检查项未清零下一活动不允许启动。这不是卡脖子而是给进度上保险。实际操作中我会在项目计划里写死一条规则详细设计评审未通过时样机试制任务不得排入正式计划。如果高层坚持抢跑请让决策人在偏差报告上签字而不是默认走流程。5.3 长周期物料启动太晚样机干等料现象详细设计完成了BOM 冻结了采购去下单才发现外壳交货周期要 45 天样机装配硬生生等了两周。整个团队没事干只能干等。原因采购启动依赖“BOM 冻结”这个动作而 BOM 要到详细设计结束才完成。活动说明里采购活动的触发条件写的是“BOM 初版可用”但没有人去确认 BOM 初版什么时候出于是长周期活动一直没有被触发。解决开工会后第一周就组织一次长周期物料预识别。设计的还只是雏形没关系用临时物料清单先把最长周期的那 20 项物料找出来采购当场确认交期锁定供应商。等 BOM 初版出来再做一次比对更新差异项。提前一个月启动样机干等料这种事基本不会发生。5.4 测试活动挤到发布前集中补问题单越补越多现象开发阶段只写代码不测试所有测试堆到验证阶段做。结果问题单爆发发布延期一个月测试团队天天加班开发团队忙着返工。原因团队潜意识里把“测试”放在“开发完成之后”而活动说明里的单元测试其实应该和编码并行。另一个因素更隐蔽测试环境从未被当作一个正式任务排进计划等需要做集成测试时环境还没搭好。解决在滚动计划里把单元测试和编码绑成同一个任务完成任务的定义是“代码写完且单元测试通过”。测试环境的准备要作为详细设计阶段的一项活动单独排期负责人在开工会时就指定。问题单管理按周评审严重问题不跨周。这样就可以保证开发阶段结束时问题单的解决率是受控的而不是积压到验证期。5.5 评审会变成“读 PPT”评审要素与输出不挂钩现象评审会用时两小时前一个半小时在翻 PPT最后半小时“原则上通过”遗留问题一堆没人跟踪。下一次评审时上次的遗留问题原封不动又出现。原因评审没有检查表。评审专家到场现看材料凭经验提问题会后又没有统一的遗留项跟踪机制。活动说明里的输出物和评审要素没有映射评审结论自然不可回溯。解决按第四章的方法把活动输出物逐项映射成评审检查项会前把材料发齐会中逐条销项。评审结论要明确三类结果通过、有条件通过、不通过。有条件通过时必须列出遗留项、责任人和解决期限并在下一次评审开始时先说遗留项进展。这套机制运行两个评审周期后评审会的专业度会明显不一样大家会愿意提前看材料、认真提意见。6. 把活动说明沉淀成团队资产模板库、裁剪原则与双周审计6.1 给每个带输出的活动配一份模板活动说明里每一个“输出物”字段都值得在组织层面配一套模板。总体方案设计书、详细设计说明书、问题单清单、试产报告这些模板不一定要重写可以先从最近一个成功项目的文档里抽出骨架再交给有经验的人补成标准结构。模板库里每份模板都标记它所对应的活动编码这样新项目开工时可以直接按活动编码取用不用到处翻旧项目。6.2 按项目规模做裁剪不是每个项目都要跑全量活动。5 人团队、三个月周期的小项目把设计、样机、测试、评审、采购这几类核心活动保住就够汇报类和文档美化类的活动可以砍掉。规模大的项目再逐步加回跨功能活动和阶段审计动作。裁剪的原则是输出物可以简化但评审门禁不能取消活动可以合并但责任角色不能缺位。6.3 双周偏差审计比里程碑复盘更管用项目每个双周对照活动说明做一次偏差审计应该触发的活动有没有触发、应该归档的输出物有没有归档、已解决的问题单有没有回归验证。审计不是追责而是早发现偏差。等里程碑总结时发现问题调整成本已经很高了。我刚带队时也不信一份阶段活动说明能起多大作用直到吃过一次开工不评审的亏。后来每个新项目启动第一件事就是把这份文档拆成检查表挂进任务系统项目计划从黑匣子变成台账。活动说明不是让你多走流程而是让项目组所有人在同一张地图上走路。希望帮到你。本文还有配套的精品资源点击获取
