应用生命周期评审门禁要落地，关键是每个阶段都有一张能直接填写的清单：谁负责、交什么、按什么标准判定通过。本文给出覆盖立项、需求与方案、开发与集成、测试与验收、上线发布、运行与变更、退役下线七个阶段的空白表格，并说明字段口径、必填划分、完整填写示例与维护方法。模板为通用框架，阶段划分与交付物可按组织流程裁剪。
要点总览（TL;DR）
- 模板由阶段门禁总表和单阶段明细表组成，总表纵览七个阶段的门禁安排，明细表逐项记录交付物状态。
- 必填字段聚焦“缺了就无法判定门禁”的项：阶段、门禁名称、责任角色、交付物名称、通过标准、结论、交付物编号、责任人、状态。
- 责任角色对门禁整体结果负责，评审人对具体交付物给出专业判断，两者可以兼任但字段应分开填写。
- 通过标准要写成可核验的条件，结论只取“通过”“有条件通过”“退回”三种值，便于追溯卡点。
- 模板每半年复核一次，阶段调整与交付物增删需经审批并保留版本记录，历史项目按当时版本核对。
可复制空白模板：阶段门禁与交付物清单表
模板由两张表组成：阶段总表用于纵览全生命周期的门禁安排，单阶段明细表用于记录某一门禁下每项交付物的状态。建议先填总表确定门禁结构，再为每个门禁复制一张明细表。
表一：阶段门禁总表
| 阶段 | 门禁名称 | 评审类型 | 责任角色 | 交付物 | 通过标准 | 结论 |
|---|---|---|---|---|---|---|
| 立项 | ||||||
| 需求与方案 | ||||||
| 开发与集成 | ||||||
| 测试与验收 | ||||||
| 上线发布 | ||||||
| 运行与变更 | ||||||
| 退役下线 |
表二：单阶段门禁明细表（每个门禁复制一张）
| 交付物编号 | 交付物名称 | 类型 | 责任人 | 评审人 | 状态 | 存放位置 |
|---|---|---|---|---|---|---|
两张表通过“阶段＋门禁名称”关联：总表一行对应明细表一组行。交付物编号建议采用“阶段缩写-序号”格式，例如“REQ-01”，便于跨表引用和变更追溯。
字段说明：每个字段填什么、怎么判断
字段口径统一，模板才能在多人填写时保持一致。下表逐项说明含义与填写方式，示例章节沿用同一口径。
| 字段 | 填写内容 | 判断口径 |
|---|---|---|
| 阶段 | 生命周期阶段名称 | 使用组织统一命名的阶段，如“测试与验收”，避免同一阶段出现多种叫法 |
| 门禁名称 | 该阶段评审点的名称 | 采用“阶段＋评审对象”命名，如“方案评审门禁”“上线准入评审”，名称能直接看出评审什么 |
| 评审类型 | 评审的组织形式 | 可填“技术评审”“管理评审”“合规评审”等，按组织既有分类填写 |
| 责任角色 | 对门禁整体结果负责的角色 | 填岗位或角色名，如“产品负责人”“测试负责人”，不填个人姓名 |
| 交付物 | 通过门禁必须提交的成果 | 在总表中列关键交付物名称，完整清单放明细表 |
| 通过标准 | 判定门禁放行的条件 | 写成可核验的条件，如“需求文档评审意见全部关闭且基线已建立” |
| 结论 | 本次评审结果 | 只能取“通过”“有条件通过”“退回”三种值 |
| 交付物编号 | 明细表内唯一标识 | 阶段缩写加序号，全表不重复 |
| 交付物名称 | 具体成果名称 | 与总表交付物名称一致，可细化到单份文档或单个制品 |
| 类型 | 交付物形态 | 取“文档”“记录”“制品”“审批单”四类之一 |
| 责任人 | 交付物的编写或产出角色 | 与评审人分开，责任人对内容质量负责 |
| 评审人 | 对交付物作出评审结论的角色 | 可与责任角色不同，也可由门禁责任角色兼任，需在模板中明确 |
| 状态 | 交付物当前进展 | 可填“未开始”“编写中”“待评审”“已通过”“已退回” |
| 存放位置 | 交付物的归档地址 | 填文档库路径、制品库地址或审批系统单号，保证评审时可查 |
“责任角色”与“评审人”的区分是这套模板的核心：责任角色对门禁整体负责，组织评审并汇总结论；评审人对具体交付物给出专业判断。两者可以由同一人承担，但字段要分别填写，避免出现无人对结论负责的情况。
必填与选填：哪些字段不能空
全部字段都强制填写会抬高维护成本，字段全部放开又会让清单失去约束力。建议按“缺了就无法判定门禁”这一标准划分必填项。
| 字段 | 必填/选填 | 缺失后果或适用情形 |
|---|---|---|
| 阶段 | 必填 | 缺失则无法定位门禁所属环节，总表与明细表无法关联 |
| 门禁名称 | 必填 | 缺失则评审记录无法被检索和复用 |
| 责任角色 | 必填 | 缺失则门禁无人组织，评审容易拖延 |
| 交付物名称 | 必填 | 缺失则无法判断门禁是否具备评审条件 |
| 通过标准 | 必填 | 缺失则结论依赖主观判断，争议难以收敛 |
| 结论 | 必填（评审后） | 评审前可空，评审结束必须填写，否则门禁状态不明 |
| 交付物编号 | 必填 | 缺失则变更和追溯时无法精确引用 |
| 责任人 | 必填 | 缺失则交付物无人产出，进度无法跟踪 |
| 状态 | 必填 | 缺失则无法汇总门禁准备度 |
| 评审类型 | 选填 | 组织只有一种评审形式时可不填 |
| 评审人 | 选填 | 由责任角色统一评审时可省略，多人评审时建议填写 |
| 存放位置 | 选填 | 交付物统一归档在固定库时可不逐项填写 |
按阶段调整必填项时，可遵循两条做法：早期阶段（立项、需求与方案）强化“通过标准”和“评审人”，因为此时方案分歧多、需要明确判断依据；后期阶段（上线发布、退役下线）强化“存放位置”和“结论”，因为此时更关注可追溯与责任留痕。调整结果应写入模板版本说明，而不是各团队自行删改。
填写示例：一个应用从立项到上线的完整清单
以下为演示情景：某内部业务应用计划重构并上线新版本，团队约二十人，涉及产品、开发、测试、运维四类角色。示例仅用于说明模板用法，不代表任何真实项目。
阶段门禁总表（已填写节选）
| 阶段 | 门禁名称 | 评审类型 | 责任角色 | 交付物 | 通过标准 | 结论 |
|---|---|---|---|---|---|---|
| 立项 | 立项评审门禁 | 管理评审 | 产品负责人 | 立项申请单、业务价值说明 | 业务目标、范围边界与预算已确认，立项申请单完成审批 | 通过 |
| 需求与方案 | 方案评审门禁 | 技术评审 | 技术负责人 | 需求规格说明、技术方案、接口清单 | 需求评审意见全部关闭，技术方案覆盖全部需求项，接口清单经上下游确认 | 有条件通过 |
| 测试与验收 | 验收评审门禁 | 技术评审 | 测试负责人 | 测试报告、缺陷清单、验收记录 | 遗留缺陷均为低优先级且有处理计划，验收用例执行率100% | 退回 |
| 上线发布 | 上线准入评审 | 管理评审 | 运维负责人 | 发布方案、回滚预案、上线审批单 | 发布方案与回滚预案经评审，上线审批单完成签批，监控告警已配置 | 通过 |
单阶段明细表示例：测试与验收门禁
| 交付物编号 | 交付物名称 | 类型 | 责任人 | 评审人 | 状态 | 存放位置 |
|---|---|---|---|---|---|---|
| TST-01 | 系统测试报告 | 文档 | 测试工程师 | 测试负责人 | 已通过 | 项目文档库/测试/报告 |
| TST-02 | 缺陷清单 | 记录 | 测试工程师 | 开发负责人 | 待评审 | 缺陷管理系统 |
| TST-03 | 验收记录 | 审批单 | 产品负责人 | 业务代表 | 已退回 | 审批系统单号 |
| TST-04 | 回归测试制品包 | 制品 | 开发工程师 | 测试负责人 | 已通过 | 制品库/版本号 |
示例中“方案评审门禁”给出“有条件通过”，表示方案主体可放行，但接口清单中两项待上下游书面确认，需在开发与集成门禁前闭环；“验收评审门禁”给出“退回”，原因是验收记录缺少业务代表签字，退回后由产品负责人补充材料并重新提交评审。结论字段配合状态字段，能清楚看出门禁卡在哪一项交付物上。
当门禁与交付物数量增多，评审记录散落在文档、邮件和审批单里，追溯成本会明显上升。ONES 的 ALM 方案以数字线程贯通需求、开发、测试、变更与发布，支撑影响分析和过程追溯；也可将标准流程、评审节点、交付物模板沉淀为可复用资产，让门禁清单在项目执行中持续沿用。是否引入工具承载，取决于团队规模与合规要求，清单本身仍应先定清楚。
调整与维护：让模板跟着组织变化走
模板一旦发布就长期不变，会逐渐与实际流程脱节；频繁改动又会让历史记录失去可比性。建议用明确的触发条件和审批方式管理变更。
- 新增或合并阶段的触发条件：出现新的交付形态（如新增数据合规审查）、组织调整导致职责重新划分、或连续两个季度出现门禁反复退回且原因集中在同一环节时，启动阶段结构调整评估。
- 交付物增删的审批方式：由门禁责任角色提出变更申请，说明增删理由与影响范围，经质量或流程负责人审批后生效；涉及合规要求的交付物删除需额外留痕。
- 版本与变更记录字段：在模板中增加“模板版本”“变更日期”“变更人”“变更说明”四个字段，每次调整保留旧版本，历史项目仍按当时版本核对。
- 定期复核节奏与责任人：建议每半年复核一次，由流程负责人组织，各阶段责任角色参与，重点检查通过标准是否仍可判定、必填项是否被普遍绕过。
- 复核输出：形成一份复核记录，列明保留、修改、废止的条目及理由，作为下一版本模板的输入。
维护的目标是让清单始终能回答三个问题：这个门禁由谁负责、要交什么、凭什么放行。只要这三点清晰，阶段数量和交付物明细可以随组织实际需要增减。
常见问题
阶段划分和门禁数量必须按模板的七个阶段来吗？
不需要。模板给出的七个阶段是通用参考框架，组织可以按自身研发流程合并、拆分或重命名阶段。调整时建议保持“阶段—门禁—交付物—责任角色—通过标准”的对应关系不变，并在模板版本说明中记录调整原因和生效范围，避免历史项目与新项目混用同一版本。
责任角色和评审人由同一人担任时，字段还需要分开填吗？
建议分开填写。责任角色对门禁整体结果负责，包括组织评审和汇总结论；评审人对具体交付物给出专业判断。两者由同一人承担时，在明细表中分别填写同一角色名即可，这样在人员变动或职责调整时，能清楚看出哪些判断由谁作出，避免门禁结论无人负责。
评审结论为“有条件通过”时，后续应该怎么跟踪？
“有条件通过”表示门禁主体可放行，但存在需要闭环的条件。建议在明细表中将相关交付物状态标为“待评审”或“已退回”，并在总表结论旁注明条件内容和闭环期限。下一个门禁评审前，由责任角色核对条件是否关闭；未关闭的条件应作为下一门禁的输入项，而不是默认延续。
交付物清单需要和工具中的工作项一一对应吗？
不要求一一对应。清单可以先以文档或表格形式存在，再按团队需要将门禁、交付物和评审记录映射到工作项或文档库中。ONES 的 ALM 方案支持将标准流程、评审节点和交付物模板沉淀为可复用资产，但清单本身的结构和字段口径仍应先由组织确定，工具承载是后续落地方式。
模板运行一段时间后，发现必填项经常被绕过，应该怎么处理？
先区分是字段设计问题还是执行问题。若某个必填项在多数项目中无法及时填写，说明它可能不适合作为门禁前置条件，可评估调整为选填或移到评审后补充；若是执行意愿问题，则应在复核记录中列明绕过情况和影响，由流程负责人决定是否保留必填并加强检查。调整结果写入版本说明，保持历史可比性。
