ALM阶段门禁责任角色模板用于把“谁在什么阶段、对哪份交付物、按什么标准、给出什么结论”固定成一张可核对的表。本文提供三张可直接复制的空白表：阶段门禁责任角色主表、角色职责说明表、门禁评审记录表，并逐字段说明填写口径、必填规则和一条完整示例。适用于需求、开发、测试、变更、发布等阶段设有评审节点的研发团队，可先复制空白表，再按字段说明填写，最后对照示例核对必填项。
要点总览（TL;DR）
- 模板以“阶段—门禁编号—交付物—责任角色—准入标准—决策结论”六列为主表，另配角色职责说明表和门禁评审记录表，三张表通过门禁编号关联。
- 责任角色对交付物质量负责，审批角色对门禁结论负责；两者可由同一人兼任，但需在表中分别记录并注明兼任情况。
- 主表六列均为必填，评审记录表的评审日期、参与人、意见闭环情况、批准人、结论与有效期缺失时结论不生效，需补录后由批准人重新确认。
- 决策结论限定为通过、有条件通过、退回、豁免四类，有条件通过与豁免需写明附加条件、期限或有效期。
- 模板裁剪先减门禁数量再减字段，保留阶段、门禁编号、责任角色、决策结论四列作为最小可用集，调整需记录版本与生效日期。
可复制空白模板：阶段门禁责任角色主表
模板由三张表组成，主表承载门禁主干信息，另外两张表分别补充角色定义和评审过程记录。三张表通过“门禁编号”关联，填写时先定主表，再补角色说明，最后在评审发生时记录评审表。
表一：阶段门禁责任角色主表（空白）
| 阶段 | 门禁编号 | 交付物 | 责任角色 | 准入标准 | 决策结论 |
|---|---|---|---|---|---|
表二：角色职责说明表（空白）
| 角色名称 | 角色类型 | 职责描述 | 对应门禁编号 | 兼任说明 |
|---|---|---|---|---|
表三：门禁评审记录表（空白）
| 门禁编号 | 评审日期 | 评审参与人 | 评审意见 | 意见闭环情况 | 批准人 | 结论与有效期 |
|---|---|---|---|---|---|---|
三张表的分工：主表回答“这个门禁管什么、谁负责、按什么标准判”，角色说明表回答“这些角色各自承担什么、是否允许兼任”，评审记录表回答“这一次评审实际发生了什么、结论是什么”。主表按阶段逐行填写，一个门禁一行；同一门禁多次评审时，主表保留一行，评审记录表按次数追加。
字段说明：每一列填什么、怎么判定
字段口径统一，模板才能在不同项目间横向比较。以下定义按主表、角色说明表、评审记录表的顺序给出，填写时以本表为准。
| 字段 | 含义 | 取值口径与判定依据 |
|---|---|---|
| 阶段 | 门禁所处的生命周期阶段 | 使用团队既有阶段名称，如需求、设计、开发、测试、发布。阶段名称需与项目计划中的阶段一致，不另造别名。 |
| 门禁编号 | 门禁的唯一标识 | 建议采用“阶段缩写-序号”格式，如 REQ-01、TST-02。编号一经使用不复用，门禁取消时保留编号并标注停用。 |
| 交付物 | 通过该门禁必须提交的成果 | 写到可单独评审的颗粒度，一份交付物一行或在一个单元格内分行列出。写“需求规格说明书 V1.2”而非“需求文档”；写“接口测试报告”而非“测试材料”。 |
| 责任角色 | 对交付物质量负责的角色 | 填角色名称而非人名，如“需求负责人”“测试负责人”。责任角色对交付物内容完整、版本正确负责，需在评审前完成自检。 |
| 准入标准 | 判定能否通过门禁的条件 | 写成可验证的判断句，包含对象和完成状态，如“交付物齐套且评审意见已闭环”“用例执行率100%，遗留缺陷均有处理结论”。避免“基本完成”“大致符合”等无法核对的表述。 |
| 决策结论 | 门禁评审的最终判定 | 限定为四类：通过、有条件通过、退回、豁免。有条件通过需写明附加条件和完成期限；豁免需记录批准人与有效期。 |
| 角色类型 | 角色在门禁中的身份 | 分为责任角色与审批角色。责任角色对交付物质量负责，审批角色对门禁结论负责。两者可由同一人兼任，但需在“兼任说明”中注明。 |
| 职责描述 | 角色在门禁前后的具体动作 | 写动作和产物，如“组织评审、汇总意见、确认闭环后提交审批”，不写“负责相关工作”这类笼统描述。 |
| 评审意见 | 评审中提出的问题与建议 | 逐条编号记录，每条注明提出人和处理要求。意见数量多时可附清单，记录表填汇总数与清单位置。 |
| 意见闭环情况 | 评审意见的处理状态 | 填“全部闭环”“部分闭环（附未闭环清单）”“未闭环”。部分闭环时需说明剩余意见的处理计划。 |
| 批准人 | 对本次结论签字确认的人 | 填姓名与角色，豁免情形必须填写。批准人与责任角色为同一人时，需在记录中说明。 |
关于责任角色与审批角色的区分，实践中容易混淆。责任角色是交付物的“作者方”，在评审前完成自检并回答评审提问；审批角色是门禁的“判定方”，依据准入标准给出结论。小团队中一人兼任两职是常见做法，但模板要求把两种身份分别记录，目的是在出现质量争议时能追溯到具体环节。
必填与选填：哪些字段缺失就不能过门禁
必填项缺失时门禁不能给出“通过”结论，这是模板的硬性规则。选填项用于补充说明，缺失不影响门禁判定，但建议在评审记录中注明未填原因。
| 表 | 必填字段 | 选填字段 |
|---|---|---|
| 主表 | 阶段、门禁编号、交付物、责任角色、准入标准、决策结论 | 无（六列均为主干字段） |
| 角色说明表 | 角色名称、角色类型、职责描述 | 对应门禁编号、兼任说明 |
| 评审记录表 | 门禁编号、评审日期、评审参与人、意见闭环情况、批准人、结论与有效期 | 评审意见（无意见时可填“无”）、意见明细清单位置 |
必填缺失的处理规则分三种情形。第一，主表字段缺失时，该行门禁视为未定义，不能进入评审，需由流程负责人补齐后再安排评审。第二，评审记录表必填项缺失时，本次评审结论不生效，需在补录后由批准人重新确认；补录需注明补录日期和补录人。第三，选填项缺失不阻断门禁，但连续多次缺失同一选填项时，应在模板复盘中评估是否将其调整为必填或删除。
“有条件通过”和“豁免”两类结论需要额外记录：有条件通过必须在结论栏写明附加条件和完成期限，并在意见闭环情况中跟踪；豁免必须记录批准人和有效期，有效期到期后门禁状态自动回到待评审。这两类结论的记录完整性直接影响后续审计，填写时应优先核对。
填写示例：一条完整门禁记录
以下示例为演示情景，展示一条测试阶段门禁从主表到评审记录的完整填写方式，团队可按自身流程替换阶段名称和交付物。
主表记录
| 阶段 | 门禁编号 | 交付物 | 责任角色 | 准入标准 | 决策结论 |
|---|---|---|---|---|---|
| 测试 | TST-02 | 系统测试报告；遗留缺陷清单 | 测试负责人 | 用例执行率100%；遗留缺陷均有处理结论且无阻断级缺陷；评审意见已闭环 | 有条件通过 |
角色说明记录
| 角色名称 | 角色类型 | 职责描述 | 对应门禁编号 | 兼任说明 |
|---|---|---|---|---|
| 测试负责人 | 责任角色 | 组织系统测试、汇总测试报告与遗留缺陷清单、评审前完成自检并回答提问 | TST-02 | 无 |
| 质量负责人 | 审批角色 | 依据准入标准核对交付物与意见闭环情况，给出门禁结论并签字 | TST-02 | 与测试负责人不为同一人 |
评审记录
| 门禁编号 | 评审日期 | 评审参与人 | 评审意见 | 意见闭环情况 | 批准人 | 结论与有效期 |
|---|---|---|---|---|---|---|
| TST-02 | 2025-06-18 | 测试负责人、开发负责人、质量负责人 | 共5条，其中2条涉及缺陷分级口径，3条为报告表述修改 | 全部闭环 | 质量负责人（张某） | 有条件通过；条件为遗留缺陷清单中2条一般缺陷需在发布前关闭，期限2025-06-30 |
逐项说明填写理由。阶段填“测试”，与项目计划中的阶段名称一致，便于按阶段汇总门禁通过率。门禁编号用“TST-02”，表示测试阶段第二个门禁，编号不复用。交付物写到可单独评审的颗粒度，测试报告和遗留缺陷清单分开列出，评审时可分别核对。责任角色填“测试负责人”而非人名，人员变动时模板不需修改。准入标准写成三个可验证条件，每条都能用“是/否”判断，评审时逐条核对。决策结论选“有条件通过”，因为存在2条一般缺陷未关闭，但均不阻断发布，附加条件和期限写入评审记录。角色说明表中把责任角色与审批角色分开，并注明不为同一人，保证判定独立性。评审记录中意见闭环情况填“全部闭环”，指评审意见本身已处理完毕，与遗留缺陷的后续关闭是两件事，后者写在结论与有效期栏。
调整与维护方法：按团队规模与流程裁剪模板
模板需要随流程变化调整，但调整应有规则，避免每个项目各填一套导致无法比较。裁剪的基本原则是先减门禁数量，再减字段；保留阶段、门禁编号、责任角色、决策结论四列作为最小可用集。
阶段数量与门禁粒度的裁剪
- 阶段数量按项目实际评审节点设定。小型项目可合并设计与开发阶段，但合并后需在阶段名称中注明合并范围，如“设计开发”。
- 门禁粒度以“一次评审能给出明确结论”为准。一个门禁对应多个交付物时，交付物需在同一评审中一并核对；若交付物分属不同责任角色且评审节奏不同，应拆成两个门禁。
- 裁剪后需检查主表与角色说明表的门禁编号是否一致，删除门禁时同步停用对应角色记录，保留历史记录不删除。
新增字段的评审与版本记录
- 新增字段需说明用途、取值口径和必填/选填属性，由流程负责人组织一次小范围试用，确认可填写后再纳入正式模板。
- 模板每次调整记录版本号、调整内容、生效日期和影响范围。已在进行中的项目可沿用旧版本至当前阶段结束，新阶段启用新版本。
- 字段口径变化时，历史数据保留原口径，不回溯改写；需要对比时在报表中注明版本差异。
模板定期复盘的触发条件
- 连续两个项目出现同一门禁反复“退回”，说明准入标准或交付物定义需要修订。
- 同一选填字段长期空白，评估转为必填或删除；同一必填字段频繁补录，评估其判定口径是否过严。
- 组织架构或角色分工调整后，复核角色说明表中的责任角色与审批角色是否仍然成立。
- 外部规范要求变化时，同步检查准入标准是否覆盖新增要求。
当门禁记录需要跨项目汇总和追溯时，可以把主表、角色说明和评审记录放到统一的工作项与文档中管理。ONES 的 ALM 方案覆盖需求、基线、版本、变更、测试与发布，以数字线程贯通需求、开发、测试、变更与发布，支撑影响分析、过程追溯和合规审计；标准流程、评审节点、交付物模板和研发过程数据可以沉淀为可复用资产，把规范从文档要求转化成项目中的执行流程。对于汽车等规范研发场景，该方案也可支撑 ASPICE 等要求的持续落地。团队可将门禁主表作为工作项字段、评审记录作为评审节点下的文档留存，使模板填写与项目执行保持同一份数据。具体配置方式需结合团队实际项目设置，模板本身仍按本文口径维护。
常见问题
小团队里责任角色和审批角色由同一人担任，模板怎么填？
在角色说明表中把两种身份分别登记为两行，角色类型分别填“责任角色”和“审批角色”，并在“兼任说明”栏注明由同一人担任。这样填写保留了身份区分，出现质量争议时仍能看清交付物自检与门禁判定分别发生在哪个环节。若团队后续拆分职责，只需修改兼任说明，不必重建表格。
门禁评审时交付物还没全部完成，可以先给“通过”再补交吗？
不建议。主表的交付物和准入标准是判定依据，交付物未齐套时准入标准无法逐条核对，此时给出“通过”会让记录与实际状态脱节。可选的做法是给出“有条件通过”，在结论栏写明缺少的交付物、补交期限和责任人，并在意见闭环情况中跟踪；期限到期仍未补齐时，门禁状态回到待评审。
同一门禁在项目中被评审了多次，主表和评审记录表怎么对应？
主表保持一行，门禁编号不变，决策结论更新为最近一次的有效结论。评审记录表按评审次数逐次追加，每次一行，填写各自的评审日期、参与人、意见闭环情况和批准人。这样主表反映当前状态，评审记录表保留完整过程，追溯时按门禁编号即可串起全部记录。
模板裁剪后，历史项目的门禁记录要不要按新版本改写？
不改写。字段口径或阶段划分变化时，历史数据保留原口径，新版本从生效日期起适用于新启动的项目或新阶段。需要跨版本对比时，在汇总报表中注明版本差异和生效时间，避免把不同口径的数据直接合并计算通过率。
门禁记录分散在多个项目里，怎么汇总查看各阶段的通过情况？
可以把主表字段作为工作项属性、评审记录作为评审节点下的文档留存，使模板填写与项目执行使用同一份数据。ONES 的 ALM 方案覆盖需求、基线、版本、变更、测试与发布，以数字线程贯通各环节，支撑影响分析、过程追溯和合规审计；标准流程、评审节点和交付物模板可沉淀为可复用资产。具体配置需结合团队项目设置，模板口径仍按本文维护。
