企业官网建设流程全解析

简介：面向产品研发负责人、项目经理及流程质量人员，围绕IPD集成产品开发中的DCP与TR阶段评审，提供一套可直接套用的评审要素说明与完整模板。内容按Phase0-1至Phase0-13及TR1—TR6展开，逐项列出评审查核要点、对应文档或交付物、资料提供部门与评审负责人，并标注非评审内容，形成从评审输入、输出到责任落实的闭环参考，便于在立项、概念、规格、总体方案、设计成果、样品测试、批量试制等节点组织评审和分工，帮助团队理清评审节奏与交付物口径。包内为1个docx文档，约33KB，结构清晰，适合作为流程文件附件、评审检查表或内训材料使用，也便于按项目实际裁剪成阶段检查清单和责任矩阵。已有2697人学习，读者可据此快速搭建评审清单、明确交付物责任、减少漏项与反复沟通，提升IPD落地效率。

1. 评审会开成过场会，问题多半不在会上

做 IPD 评审的人常有一种错觉：会开得越整齐，产品就越靠谱。真实情况是，一场 TR 阶段评审如果只有 PPT 和点头，什么也拦不住；DCP 上如果只问一句“大家还有意见吗”，放行就变成了形式。这套评审要素说明要解决的，是把 Phase0 到 Phase3 之间每一次 TR 与决策评审该看什么、看谁的交付物、由谁签字，提前明确成一张可检索的台账。它适合正在做硬件或器械类产品开发、需要按阶段交文档的学生团队与中小研发组织——尤其是那种评审表有三十多行，却没人说得清第 17 行该归谁负责的情况。

2. 流程骨架：Phase0 到 Phase3 的四道决策门与六次技术评审怎么衔接

先看骨架再看要素。原始模板里出现了两套编号：一套是Phase0-1到Phase3-37，对应交付物；另一套是TR1-1到TR6-x，对应查核要点。两套编号如果混着用，追溯就会断。我一般按 3P 来读这份模板——Phase（阶段）定时间位置，Point（评审点）定会议，Person（责任人）定签字的人，三条线交叉出每一行要素的身份。

2.1 三层结构：阶段、评审点、查核要素

整个体系是三层，不是一层。最上面是阶段，Phase0 概念与立项、Phase1 规格与方案、Phase2 设计与试制、Phase3 发布与上市；中间是评审点，六个技术评审 TR1 到 TR6，加三个决策评审；最下面是查核要素，也就是每条具体问题。三层各自的粒度和使用者完全不同，混在一起写就会变成一份谁都不愿意填的表。

这张表的作用是让人一眼看出自己该关心哪一层。项目经理只盯阶段和评审点的时间窗，部门经理只盯自己那几条要素的交付物，IPMT 只在决策评审上出现。层次分不清的后果很具体：要素责任人被拉去参加决策评审，一坐两小时，最后发现跟自己没关系，下次就不来了。

2.2 TR 与决策评审的分工：技术评审判断可行性，决策评审决定是否投入资源

这是整套体系里最容易被写混的地方。TR 的结论应该是一张问题清单加一个“是否具备进入下一阶段的技术条件”的判断，它不分配资源；决策评审的结论才是资源承诺，是继续投、附条件投、还是停。原始模板里这个分工是清晰的：TR1 到 TR6 的主持人多是研发经理、产品经理、部门经理，而概念评审、计划评审、发布评审的裁决角色统一是 IPMT。

写成文字规则就是两条。第一，TR 不通过的后果是补件重评，不许绕过，但也不冻结预算；第二，决策评审不通过的后果是项目暂停或砍掉，此时再补技术文档已经没有意义，要补的是商业论证。把这两条写在要素表的表头，比写在流程文件第三页有用得多，因为评审现场的人只会看表头。

提示：TR 会上如果开始讨论“这个项目还值不值得做”，说明议题已经越界，应该停下来转决策评审，而不是当场投票。

2.3 一条需求从 Phase0-3 走到 Phase3-37 的完整路径

拿一条原始需求走一遍，路径就活了。需求从Phase0-3 原始需求报告进来，先做 $APPEALS 分析（价格、可获得性、包装、性能、易用性、保证、生命周期成本、社会接受度八个维度），确认患者规模与需求时效性；接着在Phase0-4出概念设计和风险应对，在Phase0-5出法规注册评估报告，把产品分类、配套器械分类、注册可行性和专利避险一次说清；然后Phase0-8技术可行性、Phase0-9生产可行性、Phase0-10风险管理计划三份文件补齐，才够格开概念评审。

概念评审通过后进入规格阶段，TR2 定型号、关键设计参数、外观、包装、材料、灭菌规格和测试标准；TR3 做总体方案，把研发成本预算、外协计划、资源投入、进度计划和开发周期风险整合到一起，随后是计划评审。Phase2 是文档量最大的阶段：TR4 看图纸、关键尺寸、设计变更历史、工装检具和样品生产工艺，TR5 收样品加工意见、质检报告、测试数据和批量试制任务，TR6 审批量试制意见、临床评估、成本核算、量产工艺和量产采购计划。最后发布评审确认成本收益、营销策略、预估销售额、验收标准、销售任务和上市跟踪计划，Phase3-37 之后文档归档移交。

这条路径的价值在于：任何一个交付物缺失，都能立刻定位到它属于哪个评审点、卡住了哪一步。反过来，如果只给一份“各阶段文档清单”而没有评审点归属，缺件就只能靠人回忆。

3. 要素表字段设计：让 31 条 TR1 查核点落成一张可追溯的台账

原始模板里 TR1 有 31 条查核要素、Phase0 有 13 份交付物，靠 Excel 手工维护必然错位——原文里 Phase0-12、Phase0-13 就穿插在概念评审和规格评审之间，Phase2-18 夹在 TR4 中间，这种编号漂移在人眼看来只是“排版问题”，在追溯时就是断链。把要素建成结构化数据，是这套方案能不能真正执行的关键动作。

3.1 五个必填字段与两套编号的绑定规则

每条要素至少要有五个字段：查核要点、对应交付物、资料提供部门、资料评审负责人、所属评审点。前四个来自原始模板，第五个是我建议补的——没有归属评审点，要素就无法被自动汇总成会议议程。编号规则也要固定：TRn-x只用于查核要点，PhaseM-y只用于交付物，两者之间的关系是多对一，即多条要素可以指向同一份交付物。

写成配置大概是这样，字段顺序就是台账的列顺序：

# review_items.yaml —— 单条评审要素的结构定义 - item_id: TR1-7 # 全局唯一，TRn-x 与 PhaseM-y 两套编号严禁互换 review_point: TR1 # 归属评审点，取值 TR1~TR6 或 DCP-CONCEPT/PLAN/LAUNCH stage: Phase0 # 归属阶段，决定它在流程时间轴上的位置 checkpoint: 产品或器械是否能解决所提出的适应证 # 查核要点，必须是一句可判断的话 deliverable: Phase0-4 # 对应交付物编号，指向需求要素分析文件 owner_dept: 研发部门 # 资料提供部门 reviewer: 研发经理 # 资料评审负责人 decision_role: IPMT # 该要素的最终裁决角色 mandatory: true # 缺此项即该 TR 不通过，不允许附条件 evidence_type: document # document / report / record / sample 四选一

mandatory这个字段是整张表的分水岭。31 条要素如果全部强制，TR1 会变成不可能完成的任务；如果全部可选，评审就没有约束力。我一般把涉及安全、法规、注册可行性和风险管理的条目设为强制，例如 TR1-11 产品分类、TR1-14 注册可行性及注册方案、TR1-25 技术风险分析管理计划、TR1-30 全方面风险分析及控制计划；把描述性、分析性的条目设为建议项，允许带问题过会。

3.2 责任矩阵：资料提供部门与资料评审负责人不能是同一人

原始模板里每一行都写了两列：资料提供部门和资料评审负责人。这两列如果指向同一个人，评审就退化成自审。实操中的做法是：提供部门出文档，评审负责人出结论，两者在组织上至少隔一层。比如 TR4-3 设计图纸的审核，图纸由研发部门出，审核意见由研发经理签；TR5-2 样品质量检验结果，报告由质量部出，签字的是质量部经理，但结论要过 TR5 会议。

这张矩阵看着简单，但它解决了评审会最常见的时间黑洞：会上现看材料。预审意见必须在会前形成文字，会上只处理分歧项，31 条要素的会就能压到 90 分钟以内。

3.3 用一段校验脚本把编号错位挡在会前

人工核对编号与阶段是否匹配，做十次会错三次。我的做法是写一支几十行的校验脚本，把要素表当数据来验，会前跑一遍，输出问题清单。

import yaml # TR 与阶段的固定绑定关系，依据流程文件而非个人习惯 STAGE_OF_TR = { "TR1": {"Phase0"}, "TR2": {"Phase1"}, "TR3": {"Phase1"}, "TR4": {"Phase2"}, "TR5": {"Phase2"}, "TR6": {"Phase2"}, } def check_items(path): with open(path, encoding="utf-8") as f: items = yaml.safe_load(f) errors, seen = [], set() for it in items: iid = it["item_id"] if iid in seen: # 编号重复会让追溯矩阵对不上行 errors.append(f"{iid}: 编号重复") seen.add(iid) rp = it["review_point"] if rp in STAGE_OF_TR and it["stage"] not in STAGE_OF_TR[rp]: errors.append(f"{iid}: 阶段 {it['stage']} 与 {rp} 不匹配") # 典型错位 if not it.get("deliverable"): errors.append(f"{iid}: 缺交付物，评审时无法举证") # 无证据项 if not it.get("reviewer"): errors.append(f"{iid}: 缺资料评审负责人") # 无人签字 # 统计每个评审点下的强制项数量，用于排会议时长 stat = {} for it in items: if it.get("mandatory"): stat[it["review_point"]] = stat.get(it["review_point"], 0) + 1 return errors, stat if __name__ == "__main__": errs, stat = check_items("review_items.yaml") print("问题数:", len(errs)) for e in errs: print(" -", e) print("各评审点强制项:", stat)

这段脚本只做三件事：查重、查阶段绑定、查空字段。STAGE_OF_TR是唯一需要人工维护的常量，其余全部自动。返回的stat用来估算会议时长——强制项超过 20 条的评审点，通常要拆成两场，否则后半段必然草草收尾。脚本不负责判断内容质量，那是评审负责人的事，工具只保证“该到场的材料和人都在场”。

注意：脚本跑通不代表要素表可用。编号对了但查核要点写成“需求是否清晰”这种无法判断的句子，评审照样会变成聊天。

4. 决策评审判据：DCP 上到底按什么标准放行、附条件放行还是打回

TR 的结论相对客观，有交付物就有分；决策评审难在它要在一个小时里决定几十万甚至更多的资源去向。原始模板给出的判据是清单式的：概念评审看需求目标、市场分析、知识产权、生产线能力、营销策略、经济效益、风险响应、项目概算与团队职责；计划评审看 TR2 和 TR3 的结论、规格对供应链成本的影响、投资组合、资源匹配；发布评审看 TR4/TR5/TR6 的评审记录、成本核算、资源使用、营销战略、预估销售额、验收标准和销售任务。清单有了，但没有量化口径，裁决就只能靠嗓门。

4.1 三个决策点的判据维度设计

我的做法是把每个决策点的判据收敛成四个维度，每个维度 1～5 分，避免出现十几个维度互相抵消。概念评审的四个维度是需求与市场、技术可行性、成本与资源、风险与合规；计划评审把“技术可行性”换成“方案成熟度”，把“需求与市场”换成“规格与供应链匹配”；发布评审则替换为“质量与量产就绪度”“商业回报”“上市准备度”“合规与文档完整性”。

维度收敛的好处是可比。三个项目同时上概念评审，四个维度打分拉出来，IPMT 不需要听三遍汇报就能横向比较。坏处是颗粒度变粗，所以每个维度下面必须挂 3～5 条支撑证据，证据就是前面台账里的交付物编号——这也是为什么第 3 章要先把台账建起来，判据和证据是一套东西的两面。

4.2 加权评分与三档结论的判定逻辑

四维加权，权重按项目类型调，器械类项目我通常把风险与合规压到 0.25 以上。判定分三档，且设一票否决项，比如注册路径不成立、核心专利存在侵权风险、关键原材料无二供，命中即打回，不看总分。

# DCP 放行判定：加权总分 + 一票否决 + 短板约束 WEIGHTS = {"需求与市场": 0.25, "技术可行性": 0.30, "成本与资源": 0.20, "风险与合规": 0.25} def dcp_decision(scores, veto_items=None, threshold=3.5): """ scores: {维度: 1~5 分}，维度必须与 WEIGHTS 的键一致 veto_items: 命中的否决项名称列表，为空表示未触发 threshold: 加权总分放行线，默认 3.5（满分 5） """ total = sum(WEIGHTS[k] * v for k, v in scores.items()) if veto_items: return "打回", round(total, 2), f"触发否决项：{'、'.join(veto_items)}" # 短板约束：任一维度低于 2 分，说明存在结构性缺陷，不放行 if min(scores.values()) < 2: return "打回", round(total, 2), "存在短板维度" if total >= threshold: return "放行", round(total, 2), "" if total >= threshold - 0.5: return "附条件放行", round(total, 2), "低分维度须列入行动项并限期关闭" return "打回", round(total, 2), "加权总分未达线"

threshold设 3.5 是个经验值，意思是“平均每个维度在中等偏上”。真正需要调的是WEIGHTS：概念阶段技术不确定性高，技术可行性权重可以到 0.35；到了发布评审，质量和合规的权重必须压过成本。veto_items建议单独维护一张清单，每次评审前由法规和知识产权角色确认，不要临时在会上提出——临时否决最容易引发争议。

4.3 附条件放行之后，行动项必须有责任人和关闭日期

三档结论里最容易失控的是“附条件放行”。它听起来像通过，实际是把风险推到下一阶段。我的规则是：附条件放行的行动项不得超过 5 条，每条必须有责任人、关闭日期和验证方式，且在下一个评审点的第一项议程里逐条核对。超过 5 条就直接打回重评，因为那说明方案本身没准备好，而不是差几个补充说明。

发布评审的附条件要更严。原始模板里发布评审有 12 条判据，其中成本核算与收益评估、发布产品验收标准、产品上市后跟踪计划三条属于硬约束，任何一条缺失都不该附条件放行。上市之后的跟踪计划缺失，等于把问题留到没有评审机制保护的阶段，那时候再补救，代价远高于晚两周发布。

提示：附条件放行的行动项清单，建议直接复用第 3 章的要素表结构，只是把review_point换成下一阶段的值，这样闭环检查可以自动完成。

5. 避坑与排查：评审体系执行不畅时最容易出问题的五处

这套模板本身不复杂，复杂的是落地。下面五条是我见过或亲手遇到过的问题，每条按现象、原因、解决办法写，遇到对应症状可以直接对照排。

5.1 要素表设计阶段的问题

问题一：编号与阶段错位，追溯链断裂。现象是评审时有人问“这份报告属于哪个评审点”，全场沉默，或者翻半天 Excel 找不到。原因是模板在迭代中不断插入新条目，Phase0-12、Phase0-13被插到概念评审之后，Phase2-18被插在 TR4 中间，编号顺序与时间顺序脱钩。解决办法是把编号与阶段的绑定关系写成常量（如 3.3 节的STAGE_OF_TR），新增条目只能追加不能插队，插入位置用小数或后缀区分，例如Phase2-18a。

问题二：查核要点写成无法判断的形容词。现象是会上对“需求是否清晰”争论半小时，最后主持人说“基本清晰”收场。原因是要素描述停留在了标题级，没有给出判断依据。解决办法是每条要素后面跟一句“判断依据”，比如 TR1-6 需求分析的判断依据是“$APPEALS 八个维度均有结论且标注了数据来源”，TR1-23 可靠性要求的判断依据是“有明确的可靠性指标、验证方法和试验计划”。判断依据不需要长，一句话能指向证据即可。

问题三：所有要素都设成强制项，评审变成不可能完成的任务。现象是每次 TR 都有十几条挂红，久而久之大家对红色麻木，强制项失去威慑力。原因是设计时没有区分“必须有的证据”和“最好有的分析”。解决办法是强制项控制在总条目的三分之一以内，且集中在安全、法规、风险、成本四类；其余设为建议项，允许带问题过会，但要在会议纪要里留痕。

5.2 评审执行阶段的问题

问题四：会上第一次看材料，评审退化成朗读会。现象是三小时的会只审完前五条要素，剩下的“大家回去看一下”。原因是预审环节缺失，或者预审只走了形式。解决办法是把预审意见作为上会门槛：资料评审负责人未提交书面预审意见的要素，本次会议不予审议，直接顺延。这条规则执行两次之后，预审率会自然上来，因为它把成本转移给了该负责的人。

问题五：决策评审和 TR 混着开，结论互相污染。现象是技术问题还没结论，资源已经承诺出去了；或者项目该停，却因为“技术上都做完了”而继续投。原因是会议议程没有隔离，主持人图省事合并。解决办法是物理隔离：TR 由部门经理主持，输出问题清单；决策评审单独排期，由 IPMT 裁决，输入只有 TR 结论和四维评分。两次会议之间至少隔一个工作日，让结论沉淀。

问题六：发布评审通过了，文档却没归档。现象是上市三个月后要做变更，找不到当时的验收标准和设计变更历史。原因是发布评审的判据里没有把“归档移交”设成硬门槛。解决办法是把Phase3-37 产品上市跟踪计划和文档归档移交列为发布评审的最后一条强制项，项目经理签字确认归档清单完整，否则不放行。

6. 验收与答辩：用一页追溯矩阵证明评审确实在闭环

这套东西做完，怎么证明它是有效的，比怎么讲它更重要。答辩或者内部验收时，最忌讳的是把 37 份交付物清单从头念一遍——听的人记不住，也判断不了真假。我一般只准备一页纸：左边是六个 TR 加三个决策评审，右边是四个指标，每个指标给一个当期数值和目标值。

这一页纸的讲法有讲究。先说追溯率，因为它证明表不是拍脑袋写的；再说齐套率，证明每个评审点真的在收材料；最后说闭环率，这是唯一能证明评审有后果的指标。三个数字连起来，逻辑是“要素有归属、归属有证据、证据有结论”，比讲十页流程都管用。

答辩时还有一类问题一定会被问到：这套模板换个项目还能用吗。答案的关键是分清哪些是骨架、哪些是可裁剪的肉。阶段划分、TR 与决策评审的分工、两套编号的绑定规则属于骨架，不能动；具体要素条目、强制项比例、四维权重属于可裁剪部分，换行业就得重调。比如这套模板明显偏器械类，出现了灭菌规格、植入物生产订单、临床评估报告这些条目，换成纯软件项目，TR5 和 TR6 的要素要整体替换，但评审点的位置和决策评审的判据维度不用变。

还有一个小技巧：答辩演示时不要打开 Excel，而是打开校验脚本跑一遍，让评审老师看到编号错位被自动拦下来的过程。静态的表格证明不了什么，一次实时校验的说服力要强得多。

从那以后我每次整理评审要素表，都强制先跑一遍编号与阶段的交叉校验，再谈内容写得好不好——编号错了，内容再细也是白搭。希望帮到你。

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