企业官网建设流程全解析

简介：这份文档面向硬件与医疗器械研发团队的产品经理、项目经理及研发负责人，聚焦IPD集成产品开发流程中DCP决策评审与TR技术评审要素的落地。内容以各阶段评审要素对应表为主线，从Phase0-1项目立项任务书、产品开发任命书、原始需求报告，到技术概念、法规注册评估、市场分析、技术与生产可行性评估，再到TR1至TR6的概念、规格、总体方案、设计成果、样品测试与批量试制评审，逐条列出查核要点、对应交付文档、资料提供部门与评审负责人，可直接对照检查评审准备是否完整。资源包为1个docx文件，约33KB，表格结构清晰，便于检索并二次编辑为团队模板。目前已有2698人浏览学习。读者可据此快速搭建评审要素清单，明确各部门交付责任，减少漏项与返工。

1. 从一次「评审会开完没人敢签字」说起：IPD 评审要素表要解决的真问题

有个团队复盘过一次延期：TR4 设计成果评审开了两个半小时，图纸、工装清单、样品生产工艺全摆在桌上，纪要写的是「原则通过，问题会后跟进」。三个月后量产，一个关键尺寸超差——研发说图纸评审时提过，制造说没收到变更通知，质量说检验标准里没这一条。三方都没说谎，问题出在没有任何一张表把「查核要点—交付物—资料提供部门—评审负责人」固定在一起，评审就变成了一场各自表态的会。IPD 集成产品开发各阶段评审要素说明要解决的就是这件事：把 Phase0-1 到 Phase3 的每一个 TR 技术评审点、每一个 DCP 决策评审点，拆成一条条能勾选、能追溯到人的要素。它适合正在搭研发流程体系文件的从业者，也适合课程设计或毕业设计里需要交一套完整产品开发流程的学生——结构可以照搬，要素按自己的产品改。

2. 评审体系分层：TR 技术评审、DCP 决策评审与 Phase 阶段的三层对应关系

很多团队把「评审」当成一个笼统动作，于是所有会都开成同一个样子：技术方案、成本、市场、注册搅在一起谈，谈完谁也不知道结论算不算数。IPD 的做法是把评审拆成两层——TR 管技术方案成不成立，DCP 管项目要不要继续投钱，Phase 编号则负责把这些评审和交付物一一对应起来。这三层各司其职，任何一层缺位，评审就会变成走过场。

2.1 TR1 到 TR6：六个技术评审点各自挡住什么风险

TR 是 Technical Review 的缩写，由项目经理组织，评审对象是技术方案本身，产出是评审记录加问题清单，它不直接决定项目生死。这份要素表把 TR 分成六段，每段卡住的风险类型完全不同：TR1 卡的是「需求到底成不成立」，TR2 卡的是「规格有没有确定下来」，TR3 卡的是「工程要素能不能整合、钱和时间够不够」，TR4 卡的是「图纸和工艺对不对得上」，TR5 卡的是「样品实测有没有达到设计值」，TR6 卡的是「能不能稳定量产」。

这张表最值得学的是它的「递进感」：越往后走，问题一旦未被发现，修复成本就高一个数量级。TR1 阶段发现需求定位错了，改一份报告就行；TR6 阶段发现量产工艺走不通，前面所有工装和试制投入基本都要重新做。所以 TR1 的要素数量最多（31 条），到 TR6 反而收敛到 8 条——不是后面不重要，是后面每一条都对应真金白银。

2.2 概念评审、计划评审、发布评审：三个 DCP 的决策输入

DCP 是 Decision Check Point，决策评审点，决策主体在表里写的是 IPMT。它和 TR 最大的区别在于问的问题不一样：TR 问「技术上对不对」，DCP 问「还要不要继续投」。所以 DCP 的输入不是原始技术数据，而是 TR 的评审结论。

概念评审排在 Phase0-12 到 Phase0-13 之间，它的输入是 TR1 评审结果的审查，再叠加产品性能与标准介绍、知识产权问题是否有解决办法、需求目标客户与需求量是否明确、市场情况分析、研发技术资源与竞争对手情况、产线及产能确认、营销策略是否可行、经济效益评估、风险响应计划，最后落到「概念阶段项目立项可行性」——项目概算、沟通计划、里程碑事件、开发团队及职责是否确认。计划评审的输入是 TR2 和 TR3 的评审结果审查，再叠加规格对供应链成本的影响、投资组合管理、开发资源匹配的优化。发布评审的输入是 TR4、TR5、TR6 三份评审记录的审查，再加上成本核算与收益评估、资源使用情况评价、市场营销战略与推广培训计划、预估销售额、宣传资料、培训计划、发布产品验收标准、销售任务书、产品上市后跟踪计划。

我一般会跟团队强调一句：DCP 上不要再重复讲技术细节，技术细节在 TR 会上已经吵完了，DCP 上只回答三个问题——上一关的问题关掉了吗、下一阶段要投多少资源、投下去最坏的结果是什么。把这三个问题答清楚，决策记录才有价值。

2.3 Phase 编号与评审点的对应：为什么同一份 Phase0-5 会在 TR2 和 TR5 出现

第一次看这类表的人几乎都会卡住：Phase0-5 法规注册评估报告，怎么在 TR1、TR2、TR5 里都出现了？是不是编号写错了？不是。这里的 Phase 不是阶段名，而是交付物的编号段，Phase0-1 到 Phase0-13 是概念阶段的交付物序列，Phase1 段是规格与方案阶段，Phase2 段是设计与试制阶段，Phase3 段是发布阶段。同一份交付物在不同阶段被反复引用，编号保持不变，只在后面加「（更新）」。

理解这一点很关键：一套成熟的要素表，交付物编号是稳定的，变的是版本和引用位置。如果每进一个阶段就重新编一套号，追溯链就断了——这正是后面避坑章节要反复提的事。

3. 评审要素表的结构设计：五个字段如何支撑一张可追溯的表

这份表的列并不多：阶段、评审要素（查核要点）、评审点、对应的文档或交付物、资料提供部门、资料评审负责人。看上去很简单，但每一列背后都有设计意图，改动一列，整张表的可用性就会掉一个档次。这一章按列拆开讲，顺便说清楚我在实际使用时怎么调整。

3.1 从「查核要点」到「交付物」：一条要素必须能落到一份具体文件

要素表的每一行都应该是「看什么文件、看到什么算过」。表里做得好的例子是 TR1-6「需求分析（$APPEALS 分析）」，对应的交付物是 Phase0-3 原始需求报告——评审人拿到报告，翻到 $APPEALS 那一节，八维度是否齐全、每个维度的客户声音有没有出处，判起来很快。

做得不够的地方也有，比如 TR1-3「需求特点及创新性描述是否清楚」。这里的「清楚」是主观词，十个人有十种判法，最后往往变成主持人问一句「大家觉得清楚吗」，全场点头。我一般的处理是给这类要素补一条判定口径：创新性描述必须包含「与现有方案的技术差异点、差异点带来的量化收益、该差异点是否已被公开文献或专利覆盖」三句话，缺一句就算未通过。表里还有很多类似表述，比如 TR1-22「设计可实现性要求是否能够满足」、TR4-1「是否满足概念设计要求」，都需要在落地时补上判定口径。

补判定口径这件事，看着是给评审人加活，实际是给自己留退路。评审记录上写「TR4-2 关键尺寸未提供实测值，结论：不通过」，比写「讨论后认为还需完善」有用一百倍——前者能追，后者只能等下一次会议再吵一遍。

3.2 责任双列：资料提供部门与资料评审负责人必须分开的原因

表里有两列责任：资料提供部门和资料评审负责人。产品部的原始需求报告由产品经理提供，评审负责人也是产品经理；研发部门的技术可行性评估报告由研发经理提供，评审负责人是研发经理；法规注册评估报告由注册办提供，评审负责人是注册办副经理；样品质检报告由质量部提供，评审负责人是质量部经理；项目成本核算表由财务部门提供，评审负责人是财务经理；工装、工艺、量产相关的交付物由制造开发部提供，评审负责人是制造开发部部门经理；风险管理计划由项目经理提供，评审负责人也是项目经理；DCP 的决策角色是 IPMT。

看起来是「谁写谁审」，但它真正的价值在于把「写」和「判」两个动作都指定给了具名岗位。我见过太多团队只写提供部门，结果评审会上来的是部门里随便派的一个人，问什么都说「回去确认」，会开完等于没开。把评审负责人单独列出来，等于提前锁定一个必须到场、必须给结论的人。

3.3 编号规则：TR1-1 到 TR6-8 与「概念评审-1」的差异

技术评审要素用 TRx-n 编号，比如 TR3-5「明确的进度计划」、TR4-4「设计变更历史记录是否完整」；决策评审要素用「XX评审-n」，比如概念评审-2「产品的相关介绍是否明确」、发布评审-10「发布产品验收标准」。两套编号不能混用，原因很实在：TR 要素归属于某个技术评审点，DCP 要素归属于某次决策会，混在一起之后，做覆盖率统计就没法区分「技术没评到」和「决策没依据」。

编号一旦发布就不要复用。删掉的要素保留空号，新增的要素往后续号，需要插入时用小数位（TR1-6.1）。这套规则听起来啰嗦，但它带来一个很实际的好处：两个版本的表放在一起，只要编号对得上就能逐条比差异；编号出现断档，八成是有人私下删了要素没通知——这是评审体系里最容易埋雷的地方。

3.4 三类要素要分开看：技术、商务、合规

同一张表里其实混着三种性质的要素。技术类比如 TR1-8「产品设计参考的样件分析」、TR2-8「关键产品特点的测试方法、测试标准及关键指标」；商务类比如 TR3-2「研发成本预算评审」、TR6-4「费用和预算平衡」、发布评审-7「预估销售额」；合规类比如 TR1-12「配套器械分类」、TR1-16「专利可行性分析」、TR2-1「法律法规评审」。

分开看的意义在于评审组织形式不同：技术类要素适合研发内部先过一遍，商务类要素需要财务和市场到场，合规类要素必须等注册办给结论，缺一不可。用同一套会议节奏处理三类要素，结果通常是合规类被草草带过，而它恰恰是后面最容易被推翻的一类。

4. 关键阶段落地：从 TR1 需求到 TR6 批量的可勾选清单

表设计好只是第一步，真正决定这套东西能不能用起来的，是每个阶段那些要素在评审会上怎么问、问到什么程度算过。这一章挑四个关键段落，把要素翻译成可以直接照着念的问题清单。

4.1 TR1 技术概念：七组问题把「想做什么」问成「能不能做」

TR1 一共 31 条要素，信息密度最大。按性质可以分成七组，逐组过一遍比逐条念效率高得多。

需求组是 TR1-1 到 TR1-7：需求描述与产品定位、适应症对应的患者规模、需求特点及创新性、产品目标（上市时间、市场需求、定价估算）、时效性（短期需求还是长期需求）、$APPEALS 需求分析、产品能否解决所提出的适应症及如何满足需求。这七条里最容易空转的是患者规模和定价估算，因为它们要求评审人拿数字说话。我的做法是要求需求报告里给出数据来源和测算口径，两个数字都必须带区间，只给一个点值的直接退回。

技术组是 TR1-8 到 TR1-11：参考样件分析、概念设计方案、概念设计中的风险及应对措施、产品分类。这一组的关键是「样件分析」，很多团队写成了竞品罗列。合格的写法是对每个样件说明它的结构方案、关键材料、制造工艺，以及我们打算沿用还是替换、替换的理由是什么。

法规组是 TR1-12 到 TR1-16：配套器械分类、注册信息、注册可行性及注册方案、法规风险与管理计划、专利可行性分析（含专利避险）。合规类要素最忌讳在会上临时问，我的习惯是在 TR1 会前一周把这几条单独发给注册办，让他们带着书面结论来，会上只做确认。

市场组是 TR1-17 到 TR1-21：是否符合整体产品组合规划、竞争对手与竞争产品分析是否全面、综合竞争性分析、竞争风险管理计划、是否满足市场需求。可行性组是 TR1-22 到 TR1-26：设计可实现性、可靠性、可测试性、技术风险管理计划、可制造性（从加工技术方案、工装、加工设备、人力资源四方面分析）。制造组是 TR1-27 到 TR1-29：加工成本与费用估算、生产对环境的影响评价、生产风险与管理计划。风险组是 TR1-30 和 TR1-31：全面风险分析与控制计划、风险管理负责人确认。

这七组走完，TR1 的结论才有分量。我在实际评审里会把每组设一个「阻塞项」——只要该组有一条不过，整组标记为未通过，不允许用「其他都挺好」把单条问题带过去。

4.2 TR2 规格与 TR3 总体方案：规格要能被采购和工艺接住，方案要能被资源接住

TR2 的定位是「把需求翻译成数值」。要素包括法规评审与注册计划、产品型号设计与关键设计参数、外观设计、包装规格、材料规格、灭菌规格，以及关键产品特点的测试方法、测试标准与关键指标。这一阶段最典型的失败是规格表只有功能描述没有公差范围，采购拿着它无法询价，工艺拿着它无法排工序。我的判定口径是：每条关键设计参数必须给出目标值、允许区间、测量方法和测量设备，四项缺一不可。

TR3 的定位是「把规格翻译成承诺」。要素包括各工程要素整合能力的评审、研发成本预算、外协计划、资源投入计划、明确的进度计划、开发周期风险评估、开发成本风险、设计需求与包装需求及设计参数的风险控制计划。这里要特别注意，TR3 的交付物不是一份漂亮的甘特图，而是资源与时间的双向承诺：进度计划里每个里程碑都要对应到具体的人和具体的资源，外协计划里每个外协件都要有备选供应商。

计划评审紧跟在 TR3 之后，它把 TR2 和 TR3 的结论再往上抬一层，加上规格对供应链成本的影响、投资组合管理、开发资源匹配的优化三条。到这一步，DCP 关心的已经不是「能不能做」，而是「这个项目在整体盘子里的优先级该不该往前提」。

4.3 TR4 设计成果与 TR5 样品测试：图纸、工艺、测试数据三者对齐

TR4 是整张表里最容易出问题的一段，因为它同时牵扯研发和制造两个体系。要素包括是否满足概念设计要求、设计关键尺寸和部件、设计图纸的审核、设计变更历史记录是否完整、工具刀具检具工装的设计与审核、设计方案的工艺确认、工序设备工艺装置是否明确、工艺重点难点是否已解决、生产计划与采购计划是否清晰可行、详细测试计划、器械加工需求是否明确。

这一段的核心是「三方对齐」：图纸上的关键尺寸，工艺文件里要有对应的工序和检具，测试计划里要有对应的测量项。我在评审时会让三方各拿一份，逐条对关键尺寸清单，对不上的当场标记。TR4-4 设计变更历史记录是经常被跳过的一条，但它是后面追溯的唯一依据——变更记录不完整，等于把整条追溯链剪断了。

TR5 转到实物验证：收集工厂对样品的加工意见、样品质量检验结果、样品测试报告、测试实施标准、测试数据、测试设备使用状况、批量试制任务确认、注册计划更新、批量试制计划与采购计划确认。这一阶段两个坑最常见：一是测试数据只给结论不给原始值，二是测试设备的使用状况没有记录（设备校准过期，数据全部作废）。所以我一般要求在测试报告首页附一张设备清单，写明设备编号、校准有效期、本次使用日期。

4.4 TR6 与发布评审：把「能做出来」变成「能卖出去」

TR6 的八条要素收得很紧：批量试制意见收集（含产品与器械）、批量试制质量检验结果、临床测试结果、费用和预算平衡、人力资源等成本核算、批量生产的生产工艺、量产计划与外购件采购计划、量产确认（含器械与产品）。到这一步，技术问题基本已经收敛，真正的风险转移到成本和产能上，所以项目成本核算表由财务经理出、量产工艺和采购计划由制造开发部出，各自的结论要能独立成立。

发布评审是最后一个 DCP，十二条要素分三类。追溯类是发布评审-1 到 -3，分别审查 TR4、TR5、TR6 的评审记录；经营类是成本核算与收益评估、资源使用情况评价、市场营销战略与营销策略、预估销售额、销售任务；交付类是宣传资料、培训计划、发布产品验收标准、销售任务书、产品上市后跟踪计划。发布阶段还有一件事容易被漏掉：产品文档归档移交，责任人写的是项目经理。归档不是把文件塞进共享盘，而是按交付物编号建目录，保证后面任何人拿到一个编号就能找到最新版本。

5. 避坑与排查：评审要素表最容易出问题的五个点

要素表这类文档，做出来不难，难的是半年后还能用。下面五条是我在不同项目里反复见到的失败模式，每一条都按现象、原因、解决办法写，照着排查基本能避开大半。

5.1 现象：评审会开成表态会，纪要里全是「原则上通过」

原因：要素写成了主观题。「是否清楚」「是否充分」「是否可行」这类表述没有判定口径，评审人只能凭感觉投票，主持人为了避免冲突也不愿意给否定结论。

解决：给每条主观要素补判定口径，格式统一为「必须包含 A、B、C 三项，缺项即不通过」。同时规定评审记录必须写三样东西——通过的要素编号、不通过的要素编号及原因、遗留问题的责任人和关闭时间。纪要里出现「原则通过」四个字，视为记录不合格，退回重写。

5.2 现象：TR5 会上拿出来的测试报告，用的还是概念阶段的需求版本

原因：同一份交付物跨阶段复用，编号没变，但版本没有标记。表里那些「（更新）」如果只写在纸面上，实际文件命名里没有体现，就会出现新旧混用。

解决：交付物编号后面强制带版本号，命名规则统一为「编号_名称_V版本_日期」，比如 Phase2-18 样品测试报告 V1.2 就能一眼看出是哪一版。归档时保留历史版本，不允许覆盖。评审会开场第一件事是核对每份交付物的版本号与日期，对不上的先搁置。

5.3 现象：评审负责人换了岗位，这条要素就再也没人管

原因：责任挂到了人头上而不是岗位上。表里写「研发经理」，实际执行时被理解成「当时那位研发经理」，人一走，要素就悬空。

解决：责任列写岗位名，另附一张岗位对照表登记当前在岗人员，由项目经理每季度更新一次。岗位空缺时，其要素默认由上一级负责人代管，不允许出现无主要素。这条看着是行政工作，但它决定了整张表在人员流动后还能不能用。

5.4 现象：DCP 上要决策，翻不出对应的 TR 评审记录

原因：TR 评审记录没有编号，也没有和 DCP 要素建立引用关系。发布评审-1 到 -3 要求审查 TR4、TR5、TR6 的评审记录，如果记录本身只是一份会议纪要文档，找起来就等于大海捞针。

解决：评审记录单独编号，格式为「TRx-记录-序号」，并在 DCP 要素的备注列写明引用的记录编号。决策材料第一页放一张追溯表，列出本次决策引用了哪几份 TR 记录、每份记录的结论是什么、未关闭问题有几条。

5.5 现象：要素表定稿后放进共享盘，两年没人动过

原因：没有变更机制。产品形态在变、法规要求在变、组织架构在变，要素表却停在定稿那一天，最后大家干脆不用它。

解决：指定一个要素表维护人（通常是项目经理岗），规定每完成一个完整项目周期做一次复盘，把评审中反复出现但表里没有的问题补成新要素，把连续三个项目都没触发过的要素标记为待观察。变更走版本号，每次变更留一行说明改了什么、为什么改。没有变更记录的版本不予承认。

6. 验收与答辩：抽一条 TR 主线跑通，比讲十页方法论管用

这套东西做完，怎么证明它真的能用？我的做法是不做全面汇报，只抽一条主线跑一遍。具体来说，从要素表里任选一个已经完成的阶段，比如 TR4，然后按四步核对：这一步的每条要素能不能在交付物清单里找到对应文件；每份文件能不能找到明确的资料提供部门和评审负责人；每个负责人能不能拿出签字或书面结论；每条不通过的要素能不能找到关闭记录。四步全部走通，这一段就是合格的；中间任何一步断掉，断在哪里就补哪里。

答辩场合最常被问的一个问题是「这套表和你随便找个模板有什么区别」。我的答法是不解释结构，直接给一条追溯链：拿 TR6-6「批量生产的生产工艺」往上追，它对应 Phase2-29 量产生产工艺，再往上追到 TR4-6「设计方案的工艺确认」和 TR4-7「工序、设备、工艺装置是否明确」，再往上追到 TR3-1「各个工程要素整合能力的评审」，最后落到 TR1-22「设计可实现性要求是否能够满足」。一条链走完，评审要素不是孤立的检查项，而是同一条技术判断在不同阶段的反复确认——这个说法比任何结构图都有说服力。

还有一个技巧：如果时间只够讲五分钟，就讲 TR1 的 31 条怎么分组。分组这件事最能体现设计者对业务流程的理解程度，因为分组依据不是编号顺序，而是「这条要素在回答哪个部门的问题」。听懂分组逻辑的人，基本就认可这套表是干过项目的人做的。

我第一次独立维护这类要素表时，踩过的最大一个坑是把所有要素平均用力，31 条每条都认真评，结果会开到晚上十点，真正的关键项反而没时间深挖。从那以后我每次组织评审都强制走一遍「阻塞项标注」——会前把要素分成阻塞项和参考项两档，阻塞项不过不许进入下一阶段，参考项只记录不阻塞。评审时间砍掉一半，结论反而更硬。希望这套结构能帮到你，剩下的就是按自己的产品把要素一条条改成能判定的话。

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