企业官网建设流程全解析

简介：面向产品研发项目管理、质量与评审相关岗位的IPD阶段评审要素参考文档，围绕集成产品开发流程中DCP与TR评审如何落地，梳理从Phase0-1项目立项任务书到Phase0-13设计成果评审的关键查核点。文档以表格化方式呈现各评审阶段对应的评审要素、交付物或支撑文档、资料提供部门及资料评审负责人，并覆盖TR1技术概念、TR2规格、TR3总体方案、TR4设计成果、TR5样品测试、TR6批量试制等节点的审查要求，便于团队在评审前准备材料、明确责任分工并核对遗漏项。压缩包内为1个docx文件，大小约33KB，结构集中、查阅方便。已有2700人学习，适合需要搭建或优化IPD评审模板、统一评审口径的产品经理、项目经理及研发管理人员参考使用。

1. 从「谁交、谁审、谁签字」三个动作开始看这张表

第一次把这份 IPD 评审要素表摊开，多数人的第一反应是——不就是一张 Excel。真按它开过一次 TR 阶段的评审就会改口：TR1 一条就有 31 个查核要点，从 TR1 一路排到 TR6，中间夹着概念、计划、发布三个决策评审点，每一行还预先固定了「资料提供部门」和「资料评审负责人」两列。这两列才是这份资源的核心内容。它把 IPD 集成产品开发里最容易走形式的技术评审，明确归类成「谁交什么、谁审什么、审不过怎么办」的清单，还顺带标出了哪些动作不属于评审（立项任务书、任命书这类行政动作）。适合三类人：正在推 IPD 但评审会开成汇报会的产品负责人、要给研发定交付物清单的项目经理、以及被要求「补一套评审模板」的流程岗。下面按 TR 点和 DCP 点逐段拆，最后落到怎么把它变成能跑起来的清单。

2. TR1 到 TR6 的要素拆解：31 条查核点背后的交付物链条

这份表最有价值的地方，是它没有停在「TR1 技术概念评审」这种只给名称的层面，而是把每个 TR 点拆成带编号的查核要点，并给每条要点挂了交付物编号（Phase0-3、Phase1-15 这类）和责任人。读这张表要顺着三条线走：要素编号线、交付物编号线、责任人线。三条线只要断一条，评审就会变成「大家都知道有问题，但没人负责」。

2.1 TR1 的 31 条要素按六段分组，评审会才开得完

原料里 TR1-1 到 TR1-31 是按部门顺序排的：产品部、研发部、注册办、产品部、研发部、产品开发部、项目经理轮流上场。按这个顺序开会，讲到第 20 条基本就超时了，后面风险类要素往往被一句「大家看一下材料」带过。我一般把它重排成六段，每段给固定时长：

需求段里 TR1-6 明确要求做 $APPEALS 分析，这是 IPD 里比较标准的客户需求拆解工具，八个维度分别是价格、可获得性、包装、性能、易用性、保证程度、生命周期成本、社会接受度。很多团队在这一条上最容易应付，写成一句「客户关注性价比」就交差。实际评审时应该要求每个维度给出至少一条带来源的客户声音，哪怕是三条访谈记录，也比一句形容词有用。

法规段的 TR1-12 到 TR1-15 是最容易被研发跳过、被注册部门单独关起门来写的部分。注意 TR1-16 把专利可行性放在法规段而不是技术段，这个编排是有道理的：专利避险属于商业可行性判断，早于技术方案定稿，改设计比改专利便宜得多。

提示：TR1 是唯一一个要求「风险管理负责人」（TR1-31）当场确认的评审点。这一条不落实，后面 TR3、TR4 的风险控制计划就会变成没人维护的文档。

2.2 TR2 到 TR4：规格、总体方案、设计成果是一层层细化

TR2 规格评审的本质是把 TR1 的需求语言翻译成可测量的参数语言。看它的要素构成：TR2-3 产品型号设计与关键设计参数、TR2-4 外观设计、TR2-5 包装规格、TR2-6 材料规格、TR2-7 灭菌规格、TR2-8 测试方法、测试标准及关键指标。这六条有个共同特征——都必须带数值和测量方法。我见过太多规格书写成「表面光洁、无明显缺陷」，这种描述在 TR4 图纸评审时一定会引发争议，因为没人能判定它过没过。

一个可抄的写法是每条规格拆成三段：参数名 + 目标值区间 + 测量方法与设备。比如灭菌规格不能只写「无菌」，要写灭菌方式、剂量或温度时间曲线、验证依据的标准编号、抽检比例。TR2-8 要求把测试方法、测试标准、关键指标一起写清，就是防止后面 TR5 测试评审时才发现「当初没说清怎么测」。

TR3 总体方案评审则从单点规格跳到系统整合。TR3-1 各个工程要素整合能力的评审是个很抽象的说法，落到操作上就是问三件事：结构、电子、软件、耗材之间的接口定义齐不齐；外协件和自研件的边界在哪；哪些要素需要并行开发、依赖关系怎么排。TR3-2 到 TR3-5 是成本、外协、资源、进度四张计划，TR3-6、TR3-7 是两个风险（周期风险、成本风险）。这一组要素的隐含含义是：TR3 是「承诺点」，过了 TR3，后面计划评审就要把人和钱真正压上去。

TR4 设计成果评审的要素密度最高，从图纸、关键尺寸、图纸审核、变更历史，到工装刀具检具、工艺确认、工序设备、工艺难点、生产与采购计划、详细测试计划。这里面 TR4-4「设计变更历史记录是否完整」是条容易被忽略但很关键的要求。变更历史不完整，TR5 拿到样品后就没法判断「这个偏差是设计意图还是加工走样」。变更记录我一般要求至少四个字段：变更单号、变更前后的参数、变更原因、影响的下游交付物。

2.3 TR5 与 TR6：一个看数据能不能支撑冻结，一个看工艺能不能稳定

TR5 样品测试评审的九条要素可以分成两组。第一组是「证据」：TR5-1 工厂加工意见、TR5-2 样品质量检验结果、TR5-3 样品测试报告、TR5-5 测试数据、TR5-6 测试设备使用状况。第二组是「下一步」：TR5-4 测试实施标准、TR5-7 批量试制任务确认、TR5-8 注册计划更新、TR5-9 批量试制与采购计划。

注意 TR5-6 测试设备使用状况是被单独列成一条的。这条很有实操价值：样件测试数据异常时，第一怀疑对象往往不是设计，而是设备没校准、夹具没做好、量具精度不够。评审时如果不看设备状态，很容易把一次测量误差当成设计缺陷，把设计改回去，白折腾一轮。

TR6 批量试制评审的重点整体从「做不做得出来」转向「做不做得稳、做不做得起」。TR6-4 费用和预算平衡、TR6-5 人力资源等成本核算这两条直接把财务经理拉进评审，TR6-6 到 TR6-8 是量产工艺、量产与外购件采购计划、量产确认。这一组的关键判据是工艺窗口：同样的参数在试制批和生产批之间波动多大，良率下限是多少，超了下限走什么流程。原料里 TR6-3 临床测试结果归在产品部、由产品经理负责，这条与 TR5-8 的注册计划形成呼应，说明临床与注册是一条独立于研发的证据链，不能等到发布评审才补。

3. DCP 决策评审怎么开：三个决策点的材料包与放行判据

TR 和 DCP 是两条不同性质的线。TR 是技术评审，回答「方案行不行」；DCP 是决策评审，回答「继续投不投」。这份表把概念评审、计划评审、发布评审三个决策点单列，每个决策点第一件事都是「审查上一个 TR 的评审结果」，这个设计就是在防止决策会替技术评审承担责任。

3.1 概念评审与 TR1 的分工：决策点不看技术细节

概念评审的 11 条要素里，概念评审-1 直接就是「对 TR1 评审结果的审查」，由项目经理汇报、IPMT 决策。后面的概念评审-2 到 -11 覆盖产品介绍、知识产权解决办法、需求目标与客户与需求量、市场情况、研发技术与资源与竞争对手、生产线与产能、营销策略、经济效益、风险识别与响应、项目立项可行性（概算、沟通计划、里程碑、团队职责）。

这组要素有个明显特征：全部是「是否明确」「是否识别」「是否制定」这类判断句，不是「参数是多少」。所以概念评审最容易出问题的地方在于，技术团队带着 TR1 的细节来，讲了四十分钟材料配方，IPMT 想问的三个问题——这个项目要多少钱、什么时候能上市、失败了损失多大——一个都没答。我的做法是给概念评审固定一页纸的决策摘要，只放四组数字：项目概算与分期投入、目标上市时间与关键里程碑、预期销量与定价区间、主要风险的敞口估算。

概念评审-11 里「沟通计划」这一项常被当成形式。但在跨部门项目里，沟通计划的实际内容是：谁在什么节点向谁汇报、异常升级路径是什么、IPMT 多久开一次会。这三件事写不清，项目出问题时就会在部门之间来回沟通。

注意：概念评审的结论只有四种——通过、有条件通过、不通过、终止。很多团队只准备前三种，遇到该终止的项目就变成「再观察一期」，观察的结果通常是多烧半年预算。模板里保留「终止」这一档，本身就是给决策者一个可以使用的选项。

3.2 计划评审：为什么要把 TR2、TR3 的结果一起审

计划评审的五条要素：TR2 结果审查、TR3 结果审查、规格对供应链成本的影响、投资组合管理、开发资源匹配的优化。前两条是技术门禁，后三条是资源门禁。

规格对供应链成本的影响（计划评审-3）是这套表里比较实用的一条。它要求把 TR2 定下来的规格和采购成本放在一张桌上对：某个材料规格提高一档，采购单价涨多少，是否触发独家供应，交期会不会拉长。我见过一个项目在 TR2 把公差收紧了一倍，TR3 预算没变，到 TR6 才发现只有一家供应商能做，单价翻了三倍，量产成本核算直接崩掉。这条要素的存在就是为了把这类问题提前到计划阶段暴露。

投资组合管理（计划评审-4）和开发资源匹配的优化（计划评审-5）属于组合层判断。落到操作上就是一张资源冲突表：本项目在接下来两个季度需要哪些关键角色、每个角色投入多少人月、和同期其他项目是否冲突、冲突时优先级怎么定。这张表如果会上没有，计划评审基本就是走过场，因为「资源已确认」这句话没有任何证据。

3.3 发布评审：12 条要素里有一半是上市准备，不是技术收尾

发布评审的 12 条要素分三段。第一段是技术收口：TR4、TR5、TR6 三次评审结果的审查，各自对应评审记录。第二段是经营核算：成本核算与收益评估、资源使用情况评价、预估销售额。第三段是上市准备：市场营销战略与营销策略、宣传资料、培训计划、发布产品验收标准、销售任务、产品上市后跟踪计划。

技术收口这一段有个细节值得注意：发布评审-1 到 -3 审查的是「评审记录」，不是重新看技术方案。这意味着 TR4、TR5、TR6 的会议纪要质量直接决定发布评审能不能开成。纪要按照固定结构来写会比较省事：结论、遗留问题清单（含责任人与关闭日期）、对下游交付物的影响、附件清单。缺少遗留问题清单的纪要，在发布评审时基本会被打回。

上市准备那一段里，发布评审-10「发布产品验收标准」和发布评审-12「产品上市后跟踪计划」是最容易被跳过的。验收标准写不清，销售拿到货后不知道什么算合格交付；跟踪计划不写，产品上市后的前三个月问题反馈没有归集入口，等发现系统性缺陷时已经铺货了。

最后一行「发布阶段产品文档归档移交」虽然不是编号要素，但它是整张表的收尾动作。归档清单建议直接由要素表生成：把交付物编号列去重，就是一份天然的归档目录。这件事在第 4 章用脚本做。

4. 把要素表变成能运行的清单：字段设计、编号规则与自动校验

一张纸面上的要素表，和一份能推动会议、能追责、能审计的清单，差的是字段。原始表有七列：阶段、评审要素、对应的文档或交付物、资料提供部门、资料评审负责人，加上评审点名称和交付物编号。这七列够开会，不够闭环，因为缺了结论、缺了问题追溯、缺了版本。

4.1 从七列补到十列：每个新字段都对应一个具体失效场景

字段里最容易写歪的是 reviewer。原表写的是「产品经理」「研发经理」「注册办副经理」这类岗位。岗位的好处是稳定，坏处是会上来的可能是刚接手的新人，一句「我回去确认」就让评审停摆。我的做法是岗位后面补人名和备份人，例如「研发经理（张三，备份李四）」，并且规定主责人缺席必须提前书面授权，授权记录进纪要附件。

result 字段的取值必须提前约定。TR 点用三档：通过、有条件通过、不通过。有条件通过的「条件」必须落成至少一条问题单，不允许只写「补充材料后通过」这种没有责任人的结论。DCP 点多一档终止，理由前面说过。

4.2 编号规则：Phase 编号和 TR 编号是两套坐标，别混用

这套表里其实有两套编号并行。Phase 编号标的是交付物，格式是「阶段-序号」，比如 Phase0-3 原始需求报告、Phase1-15 产品型号设计及关键设计参数、Phase2-19 图纸。TR 编号标的是查核要点，格式是「TRn-m」。两套编号的关系是多对多：一条要素可能引用一份交付物，一份交付物也可能被多个评审点复用。

复用最典型的是 Phase0-5 法规注册评估报告。它在 TR1-12 到 TR1-15 出现，在 TR2-1 以「（更新）」形式出现，在 TR5-8 又出现一次。这种复用不是冗余，而是提醒：法规评估报告是活文档，每个阶段都要更新版本。所以交付物编号只标身份，不标版本，版本用单独字段或文件名后缀管理。

文件命名我一般统一成这个格式：Phase{阶段}-{序号}_{名称}_v{主版本}.{次版本}.{扩展名}，例如Phase1-15_产品规格书_v1.2.docx。这条规则的好处是可以被脚本校验，省掉每次评审前人工翻目录。

# 交付物命名一致性检查：命名不合规的文件直接打印出来 # 规则：Phase{阶段}-{序号}_{名称}_v{整数}.{整数}.{扩展名} for f in ./deliverables/*; do base=$(basename "$f") if [[ ! "$base" =~ ^Phase[0-9]+-[0-9]+_.+_v[0-9]+\.[0-9]+\.[A-Za-z]+$ ]]; then echo "命名不合规: $base" fi done

这段脚本走的是白名单思路：只有完全匹配规则的文件才被放过，其余全部报出来。^Phase[0-9]+-[0-9]+_锁定前缀和阶段序号，_v[0-9]+\.[0-9]+强制版本号是两段数字，最后用扩展名收尾。放在会前跑的时机很关键——评审当天才发现的命名问题，通常伴随着「这份是最新版吗」的反复确认，十分钟就没了。参数上唯一需要调整的是目录路径，如果交付物按阶段分了子目录，把循环改成find ./deliverables -type f更省事。

4.3 用脚本按评审点拆清单，顺手把缺交付物的行摘出来

要素表在 Excel 里是一整张长表，但开会时每个人只关心自己那一段。手工筛选复制既慢又容易漏行，用十几行 Python 就能生成每个评审点一份的清单，同时把「有要素但没交付物」「有交付物但没负责人」的行单独导出。

import pandas as pd from pathlib import Path # 列名固定，避免各阶段自己加列导致脚本失效 COLS = ["review_point", "item_id", "check_item", "deliverable_id", "deliverable", "owner_dept", "reviewer", "result", "issue_id", "close_date"] # dtype=str 很关键：否则 TR1-1 会被识别成日期，Phase0-3 可能被转成数字 df = pd.read_csv("ipd_review_items.csv", dtype=str).fillna("") # 缺交付物或缺评审负责人的行，是会上必然卡住的地方，先摘出来 orphan = df[(df["deliverable_id"] == "") | (df["reviewer"] == "")] orphan.to_csv("orphan_items.csv", index=False) # 按评审点拆成独立清单，sort=False 保持原表的阶段顺序 out = Path("checklists") out.mkdir(exist_ok=True) for point, g in df.groupby("review_point", sort=False): lines = [f"# {point} 评审清单", "", "| 要素编号 | 查核要点 | 交付物 | 提供部门 | 评审负责人 | 结论 |", "| --- | --- | --- | --- | --- | --- |"] for _, r in g.iterrows(): lines.append("| {item_id} | {check_item} | {deliverable_id} {deliverable} | " "{owner_dept} | {reviewer} | {result} |".format(**r)) (out / f"{point}.md").write_text("\n".join(lines), encoding="utf-8") print(f"总要素 {len(df)} 条，缺交付物或缺负责人 {len(orphan)} 条")

逻辑上有三个点值得说。第一，dtype=str不是可选项。要素编号带连字符、交付物编号带字母前缀，pandas 默认推断类型时会把这些列变成 object 甚至日期，读回来再写出去就变形了。第二，fillna("")把空单元格统一成空字符串，后面判空只需要一种写法，不用同时处理 NaN 和 None。第三，groupby(sort=False)保证输出顺序和原表一致，评审按 Phase 顺序推进时不会出现 TR6 排在 TR2 前面的尴尬。

参数上最需要按项目改的是review_point的取值。原表里同一个概念评审出现了「概念评审」「概念评审-1」两种写法，如果直接 groupby 会拆成两组。所以入库前先做一次取值清洗，把所有评审点名字统一成固定枚举：TR1、TR2、TR3、TR4、TR5、TR6、概念评审、计划评审、发布评审。这一步做完，后面所有统计才有意义。

提示：清单生成的产物建议进版本库，每次评审前提交一次。半年后回看某个要素的结论变化，比翻聊天记录可靠得多。

5. 避坑与排查：五条踩过的坑，每条都带修法

要素表本身不难，难的是它落地时的组织行为。下面五条都是实际项目里反复出现的，按「现象 → 原因 → 解决」写，能对号入座就直接改。

5.1 表本身的三类翻车

坑一：把查核要点当成通过标准。现象是会上逐条打勾，31 条全勾完，结论「TR1 通过」，半年后量产发现灭菌验证压根没做。原因是要素表回答的是「有没有这份东西」，不回答「这份东西够不够」。TR1-15 写的是「注册方面的法律法规风险和管理计划」，有一份两页的风险表也算有。 解法是给每条要素加一列判据，只写一句话：什么情况算过。比如 TR1-6 的判据可以是「八个维度中至少六个有客户来源支撑」。判据列不需要一次写完，从 TR1 和 TR4 这两个最容易出问题的点开始补，两个项目跑下来就有了一套能复用的判据库。

坑二：一份交付物被三个评审点引用，版本各说各话。现象是 TR1 用的法规评估报告是 v1.0，TR2 要的是更新版，TR5 又提了一次，三份文件散在三个人的电脑里。原因是交付物编号只标身份不标版本，大家默认「编号一样就是同一份」。 解法是把交付物拆成「编号 + 版本 + 更新记录」三件套，每次更新在表里新增一行而不是改原行，保留历史。归档时按编号取最新版本，历史版本单独放一个目录留档。

坑三：评审负责人写岗位，到会的是新人。现象是会上讨论到关键要素，参会人只能说「我回去问一下」，结论挂起。原因是责任人列写的是「研发经理」这种岗位名，而组织里默认派代表参会。 解法是责任人必须落到具体人，并写备份人。会议通知里带一句：主责人无法出席需提前书面授权，授权记录作为纪要附件。这一条执行两次，参会质量会明显不一样。

5.2 会议与执行层面的两个坑

坑四：TR 和 DCP 合并开，决策变成追认。现象是一次会议两小时，前半段过技术，后半段直接决策投钱。原因是排期紧张，或者项目已经超期，想省一次会。 后果是技术遗留问题在决策时被一句「后续跟进」带过，等到 TR4 才发现方案有硬伤，此时预算已经花掉大半。解法是硬门禁：TR 必须先出结论（含遗留问题清单和关闭责任人），DCP 才能排期，DCP 上只判断「遗留问题是否可接受」，不重新讨论技术方案。发布评审-1 到 -3 审查评审记录这个设计，本质上就是这个门禁的书面化。

坑五：问题靠记忆闭环，同一个坑踩两次。现象是 TR3 提过的成本风险，TR6 又原样提了一遍，中间没人跟踪。原因是没有唯一问题编号，也没有关闭判据，问题散落在各次纪要正文里。 解法是问题单号 Q-TR{n}-{序号}，关闭时必须提交证据（补充的测试数据、修订后的图纸版本、更新后的计划），把证据链接写进 close_date 那一行。评审开场先花五分钟过上次的未关闭问题，比讲新内容更有价值。

注意：这五条里，坑一和坑四的杀伤力最大。前者让评审变成盖章，后者让决策失去纠错窗口。如果你的项目只来得及改两件事，先改这两个。

6. 进阶用法：用三列数据做一次评审有效性验证

要素表跑过两三个项目之后，会积累出一批结论数据。这时候可以做一件很有价值的事：不看你开了多少会，只看三列数据的关系——要素、交付物、结论。我用一个很小的脚本做这件事，输入还是那张 CSV，输出两张表。

import pandas as pd df = pd.read_csv("ipd_review_items.csv", dtype=str).fillna("") # 视角一：哪些要素从没挂过交付物，属于「问了但没人交」 no_doc = df[df["deliverable_id"] == ""][["review_point", "item_id"]] # 视角二：哪些交付物被反复引用，属于跨阶段活文档，必须管版本 reuse = (df[df["deliverable_id"] != ""] .groupby("deliverable_id")["review_point"] .nunique().sort_values(ascending=False)) # 视角三：结论分布，重点看「有条件通过」占比 rate = (df.groupby("review_point")["result"] .value_counts(normalize=True).unstack(fill_value=0)) print(reuse.head(10)) print(rate.round(2)) print("无交付物要素：", no_doc["item_id"].tolist())

第一张表看的是断链。要素没有交付物，意味着这条查核点在会上只能靠口头回答，事后无法审计。跑一遍通常会发现，断链集中在风险类和计划类要素上，因为这类内容天生不容易做成一份文档。

第二张表看的是复用度。被三个以上评审点引用的交付物，就是整个流程的活文档，比如法规注册评估报告、风险管理计划。这类文档必须指定唯一维护人，并且规定更新触发条件——法规变化、规格变更、风险等级调整，任一发生就出新版本。

第三张表看的是结论结构。一个健康的项目，「通过」占比在六到七成，「有条件通过」两到三成，「不通过」偶尔出现。如果「有条件通过」长期高于三成，说明前面的评审没有拦住问题，把判断推给了下一次会议；如果「不通过」从来没出现过，那要么项目质量好得反常，要么评审结论被统一修正过，两种情况都值得查一次原始纪要。

我自己的习惯是每个季度挑一个已结项的项目回跑一遍这三张表，只看两个数：断链数和有条件通过占比。有一次回跑发现某个 TR4 的十二个要素里有五条从没挂过交付物，翻了纪要才发现那五条当时是「集体口头确认」。从那以后我每次生成新清单，都先把无交付物的行导出来贴在会议通知后面，让每个人会前就知道哪几条只能靠嘴说。

这套东西的价值不在模板多完整，在于它逼着每个查核要点找到一个交付物、一个责任人、一个结论。要素表本身可以照抄这份资源，判据库得自己攒。希望帮到你。

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