企业官网建设流程全解析

简介：面向产品研发管理者、项目经理及质量/注册人员的IPD评审要素清单，围绕集成产品开发流程中的DCP与TR评审节点，解决“每个阶段评什么、看哪些交付物、由谁提供和把关”的问题。文件为1个docx，约33KB，以表格化条目组织，可按阶段直接查阅或改造为评审检查表。内容覆盖Phase0-1至Phase0-13的立项任务书、开发任命书、原始需求、技术概念、法规注册、市场分析、技术及生产可行性、风险管理、规格与总体方案、设计成果等评审要素，并延伸至TR1—TR6、概念评审、计划评审和发布评审，逐项列出查核要点、对应文档或交付物、资料提供部门及评审负责人。已有2700人学习，适合用于搭建研发评审模板、明确跨部门职责边界，或对照现有流程查漏补缺，提升评审准备与闭环效率。

1. 什么是IPD评审：把「拍脑袋」变成「过关打卡」

装修过房子的人多半有过这种体验：开工前没人认真数插座，瓷砖贴完了才发现厨房少两路电，这时候再改，砸墙的钱比当初省下的设计费贵十倍。IPD 集成产品开发的评审，干的就是「开工前把插座数清楚」这件事——它把一款产品从想法到上市的整个过程切成若干个关口，每个关口都要回答一句：现在这活儿，经不经得起后面继续花钱？

这些关口分成两类，名字很容易念混：一类叫 TR（技术评审），问的是「方案在技术上站不站得住」；另一类叫 DCP（决策评审），问的是「这项目还值不值得继续投人投钱」。搞懂这两条线，一份几十页、编号到 TR6 的评审要素表，就不再是天书。

2. IPD评审为什么存在：风险要被拦在花钱之前

2.1 钱是怎么一步步变多的

一款产品从想法走到上市，投入不是匀速增加的，而是像滚雪球。概念阶段几个人开几次会，成本几乎可以忽略；到了做样品、开模具、批量试制，每一步都是真金白银；再往后牵扯到注册资料、产线改造、市场推广，花的钱和前面完全不是一个量级。

更麻烦的是改动成本也走同一条曲线。概念阶段改一句话，可能只是重开一次会；等到批量试制阶段再改，图纸、工装、采购合同、检测报告要一起动，运气不好还得重新做一轮验证。行业里那句「越晚改越贵」，说的就是这个。评审存在的理由很朴素：把钱花出去之前，先逼所有人把该说的话说完，把该交的材料交齐。

IPD 的做法是把整个开发过程按阶段切开，常见的编号是从 Phase0 到 Phase3：Phase0 管立项与概念，Phase1 管计划，Phase2 管开发与验证，Phase3 管发布。每个阶段结束前设一个技术关口（TR1 到 TR6），每个大阶段结束前设一个投资决策关口（概念评审、计划评审、发布评审）。关口不会自己把关，得有人拿着要素表一条一条问。

2.2 TR和DCP：两条线，两个问题

TR 由技术线主导，参加的人是研发经理、产品经理、注册负责人、工艺和质量的骨干。它评的是「这套方案在技术上站不站得住」，结论通常是：通过、有条件通过、不通过。

DCP 由投资决策角色主导，也就是常说的 IPMT（集成产品管理团队）。它不怎么抠技术细节，它看的是「这个项目还要不要继续投人投钱」，结论可能是继续、暂停、砍掉、合并到别的项目里。

打个比方，TR 像体检报告，各项指标正不正常写得清清楚楚；DCP 像家庭会议，看完体检报告再决定这孩子还要不要接着学钢琴。体检合格不等于家里一定继续供，家里决定继续供也不等于体检没问题。两条线各管一段，谁也替代不了谁。

要素表里这个分工写得很实在。TR 阶段那几十条查核要点后面，跟着的是「资料提供部门」和「资料评审负责人」；DCP 阶段那十几条后面，跟着的往往是项目经理加 IPMT。同一个项目，同一批人，一会儿当被审的，一会儿当投票的，角色切换得清清楚楚。

2.3 一张要素表的四列骨架

翻这份要素表，会看到它其实是四列结构，只是原文排版挤在一起容易看漏：

四列里最容易被忽视的是最后两列的分离。写材料的人和审材料的人不是同一个人，这是要素表里最不起眼也最要命的设计。如果一份可行性报告由研发经理写、又由研发经理审，那这场评审就退化成自说自话，出了事连个复盘的口子都找不到。

还有一个细节值得留意：表里 Phase0-1 的项目立项任务书、Phase0-2 的产品开发任命书，标注的是「非评审内容」。意思是这两份东西是背景材料，供人查阅，不作为查核要点被打钩。分辨「哪些是背景、哪些是考点」，是读懂这类表格的第一课。

3. TR1到TR6：六个技术关口各自在问什么

3.1 TR1技术概念评审：这事值得做，也做得出

TR1 是整个技术线的第一道门，考量大、条目多，一口气列了三十条左右，可以归成四堆。

第一堆是需求。需求描述（产品定位）清不清楚、目标人群的规模有多大、需求特点与创新性描述是否到位、需求是短期还是长期、产品目标（上市时间、市场需求、定价估算）有没有写下来。里面还专门点了 $APPEALS 分析——这是 IPD 里常用的客户需求拆解工具，八个字母分别对应价格、可获得性、包装、性能、易用性、保障（质量与售后）、生命周期成本、社会接受度。它的价值不在名字洋气，而在于逼你把「客户说想要」拆成八个能被追问的维度，免得一句「用户体验要好」糊过去。

第二堆是方案。产品设计参考的样件分析做了没有、概念设计方案长什么样、概念阶段识别出哪些风险、应对措施是什么、产品怎么分类、配套器械怎么分类。样件分析这一条特别容易被敷衍——很多人直接拿竞品拆一遍就交差，却没写清楚「它哪一步做对了、我们打算怎么不一样」。

第三堆是合规与产权。注册法律法规信息、注册可行性与注册方案、法规风险与管理计划、专利可行性（含专利避险）。这部分由注册岗出材料，技术岗经常觉得「跟我没关系」，可一旦注册路径选错，后面所有设计都可能白做。

第四堆是市场与可制造性。竞争对手和竞品分析全不全、综合竞争性分析、竞争风险与管理计划、产品是否满足市场需求、设计可实现性、可靠性、可测试性、可制造性（从加工方案、工装、设备、人力四个角度分析）、加工成本估算、生产对环境的影响、全方位风险控制计划。

提示：TR1 的三十条不是均匀分布的，需求与方案那十几条是「必须现在答」，可制造性与成本那几条允许给区间估算，但要写清楚假设条件。

3.2 TR2规格评审与TR3总体方案评审：把「能做」翻译成「具体做成什么样」

TR1 说的是「这条路走得通」，TR2 要把它压缩成一组不能再含糊的数字和规格。

TR2 的条目看着少，但每条都很硬：法律法规评审、注册计划评审、产品型号设计与关键设计参数、外观设计、包装规格、材料规格、灭菌规格，以及关键产品特点的测试方法、测试标准与关键指标说明。这一串东西的共同点是——它们都会变成后面验收时的依据。材料写「医用级不锈钢」和写「某牌号、某硬度区间、符合某标准」，在 TR4 和 TR5 会变成完全不同的两场评审。

TR3 换了个视角，从「东西长什么样」转到「这件事怎么组织起来做」。各个工程要素的整合能力、研发成本预算、外协计划、资源投入计划、明确的进度计划、开发周期风险、开发成本风险，以及设计需求与包装需求的风险控制计划。说白了，TR3 是把一堆专业分工拼成一张能执行的表：谁在什么时间交什么，钱从哪儿出，哪一步可能拖期。

这两关最常见的翻车方式是「规格写得很漂亮，进度排得很乐观」。研发成本预算和外协计划一旦乐观过头，后面的 TR4、TR5 就会不断用「赶工」来还债，而赶工带来的设计变更，又会在 TR6 变成批量试制的异常。

3.3 TR4设计成果评审与TR5样品测试评审：图纸变成实物

TR4 是设计成果的验收。是否满足概念设计要求、设计关键尺寸和部件、设计图纸的审核、设计变更历史记录是否完整、工具刀具检具工装的设计与审核、设计方案的工艺确认、工序与设备与工艺装置是否明确、工艺重点难点是否已解决、生产计划与采购计划是否清晰可行、详细测试计划、器械加工需求是否明确。

这里有一条最容易被跳过：设计变更历史记录是否完整。变更记录不完整，等于把项目的记忆抹掉了。半年后有人问「这个尺寸当初为什么改」，全组只能靠回忆，这就是典型的玄学时刻。

TR5 转向样品。收集工厂方面对样品的加工意见、样品质量检验结果、样品测试报告、测试实施标准、测试数据、测试设备使用状况、批量试制任务确认、注册计划更新（需要注册的产品）、批量试制计划与采购计划确认。注意 TR5 里出现了「意见反馈表」这种交付物——它不是结论，是把加工端看到的问题原样端上桌。很多团队只交一份漂亮的测试报告，把车间提的问题过滤掉，下一关就得付利息。

3.4 TR6批量试制评审与六个关口的总览

TR6 是技术线的最后一道门，问的是「能不能一批一批稳定做出来」。条目包括：收集对批量试制的意见（产品与器械都要）、批量试制质量检验结果、临床测试结果、费用与预算平衡、人力等成本核算、批量生产的生产工艺、量产计划与外购件采购计划、量产确认（含器械与产品）。

从 TR1 到 TR6，问题的颗粒度一路变细：从「这事值不值得做」，到「能不能稳定重复地做」。把六关放在一起看，脉络就出来了：

4. DCP决策评审：不评技术，只评还值不值得投钱

4.1 三道资金管控关口：概念评审、计划评审、发布评审

概念评审放在 TR1 之后，一共十几条：对 TR1 评审结果的审查、产品相关介绍（性能、标准）是否明确、涉及的知识产权问题有没有解决办法、需求目标与客户与需求量是否明确、市场情况分析、研发的技术与资源与竞争对手情况、生产线及生产能力确认、市场营销策略是否切实可行、市场经济效益评估、风险识别与响应计划、概念阶段对项目立项可行性的整体评估（项目概算、沟通计划、里程碑事件、团队职责是否确认）。

计划评审条目少但位置关键：TR2 评审结果的审查、TR3 评审结果的审查、规格对供应链成本的影响、投资组合管理、开发资源匹配的优化。后两条是 DCP 独有的味道——它不只盯这一个项目，还要看这个项目在公司一堆项目里排第几、占了多少资源。

发布评审是最长的一次，十几条：TR4、TR5、TR6 三次评审结果的审查，成本核算与收益评估，资源使用情况评价，市场营销战略与策略，预估销售额，宣传资料，培训计划，发布产品验收标准，销售任务，产品上市后跟踪计划，以及最后的产品文档归档移交。发布评审结束时，项目从「开发」正式交给「经营」。

4.2 DCP和TR到底差在哪

看懂这张表，就明白为什么一份要素表里，同一条 TR 结论会被引用两次：一次在 TR 现场被技术专家挑刺，一次在 DCP 现场被决策者当作投资依据。前者关心「对不对」，后者关心「值不值」。

4.3 要素表怎么用起来：一条数据的结构

要素表如果只是拿来读，价值有限；把它变成可检索的数据，才能真正盯住进度。一条评审要素拆开大概长这样：

# 一条评审要素的最小结构：问题、证据、责任人、结论 review_item = { "id": "TR1-23", # 要点编号，对应要素表行号 "stage": "TR1", # 所属技术关口 "question": "产品可靠性要求是否能够满足", # 查核要点 "deliverable": "Phase0-8 技术可行性评估报告", # 证据文件编号与名称 "owner_dept": "研发部门", # 资料提供部门 "reviewer": "研发经理", # 资料评审负责人 "result": None, # pass / conditional / fail "gap": "", # 有条件通过时必须写清待补事项 }

字段的用法值得说两句。id是追溯的锚点，后面所有会议纪要、整改单都挂在这个编号上，半年后还能查得到。deliverable是证据，没有它这条要点就不该被打钩。owner_dept和reviewer必须不同人，这是防止自己给自己发合格证。result只有三种取值，别发明第四种；gap是「有条件通过」的后悔药，没有它，条件就等于没有。

实际跑起来，最有用的一步是把所有result为conditional的条目筛出来，看看哪几条挂在同一个部门身上。同一个部门反复有条件通过，通常不是态度问题，是流程给他的时间不够。

5. 常见误区与易混概念：五组最容易念混的说法

5.1 误区一：TR 过了项目就过了

易混点：把技术评审的「通过」当成项目的「放行」。为什么混？因为两场会往往挨着开，人还是那批人，会议室都没换。怎么区分？看结论的用途：TR 的结论是给下一阶段的设计当输入，DCP 的结论才是决定资源给不给。TR1 全过、概念评审仍然可能判「暂停」，这在要素表里写得很清楚——DCP 的第一条就是「对 TR1 评审结果的审查」，是审查，不是抄写。

5.2 误区二：要素表是检查清单，逐条打钩就算评完了

易混点：把「有没有」当成「行不行」。为什么混？表格天然长成待办清单的样子，一行一个钩看着很爽。怎么区分？要素表里绝大多数条目是问句，问句要求回答，不要求打钩。「产品可靠性要求是否能够满足」这条，勾上不等于满足，得拿出可靠性指标、验证方法和结论。能打钩的是「材料交没交」，不能打钩的是「材料里的东西站不站得住」。

5.3 误区三：交付物和评审记录是一回事

易混点：认为交了一份报告，就等于完成了这次评审。为什么混？因为文件名里常带「评审」二字，比如技术可行性评估报告。怎么区分？交付物是被审对象，评审记录是评审过程。前者回答「我们做了什么」，后者回答「谁在什么时候提了什么意见、最后怎么处理」。只留交付物、不留记录，等于只留下结论，丢掉了推理过程。

5.4 误区四：提供资料的部门就是评审负责人

易混点：把「谁交材料」和「谁审材料」合并。为什么混？要素表里这两列挨着写，扫一眼很容易连读。怎么区分？看角色定位：提供部门对材料的完整性负责，评审负责人对材料的可信度负责。研发部门交可行性报告，研发经理签「这份报告我认」；如果换成研发部门自己签自己，那这条要点就等于没设。

5.5 误区五：TR 必须严格串行，一步都不能跳

易混点：以为 TR1 没闭环就不能碰 TR2 的任何事。为什么混？编号是 1 到 6，看着就像必须按顺序走完的关卡。怎么区分？看题目本身：TR2 的规格评审和 TR3 的总体方案评审常常并行推进，TR4 的工艺确认也可以在样品出来之前先做一部分。真正不能跳的是「结论不能空着」——某一关可以有条件通过，但不能没有结论就往后走，那才是后面所有返工的源头。

6. 什么时候该用这套评审，什么时候别硬套

这套东西最适合的场景，是产品要做实物、要走注册或认证、供应链长、一次失败代价高的项目。器械、设备、耗材这类东西，图纸改一个尺寸可能牵动工装、材料、检测方法三件事，评审要素表在这里几乎是把血泪经验提前写成了问题。研发人员流动快、外包环节多的团队也合适——表上写着谁提供、谁评审，人走了，责任留着。

反过来，下面这几种情况硬套会很难受：

有个真实的教训值得说一说。早些年在模拟项目X做一次样品评审，图省事把 TR5 和 TR6 合并成一场会，想着反正样品和试制隔得不远。会上材料堆了一桌，两份报告翻来翻去，最后谁也没看清「测试数据」和「批量试制意见」到底对不上在哪，等到量产才暴露出工艺参数没锁死的问题，返工花的时间比单独开两场会多了好几倍。从那以后我每次排评审计划，都强制走一遍「这个关口要回答的那句话，在这张桌子上有没有人能答」的把关程序；答不上来，就不合并。

这份 IPD-DCP 与 TR 各阶段评审要素表模板把这些关口、查核要点、对应交付物、资料提供部门和评审负责人逐条列全了，从 TR1 的三十条一直到发布评审的归档移交，拿来就能对着自己项目一条条过。真要用的时候，别急着从第一条读到最后一条，先找到你手上项目卡在哪一关，再把那一关的条目抄进自己的会议议题里，比通读三遍有效得多。希望帮到你。

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