这份模板把应用生命周期拆成立项、需求、设计、开发、测试、发布、运维、退役八个阶段，用一张阶段门禁表固定记录交付物、评审门禁、评审角色和通过标准，再配一张角色职责表说明谁在评审中做什么。表格可直接复制到文档或在线表格中填写，字段说明、必填规则和完整示例保持一致，适合研发团队在项目启动前统一评审口径。
要点总览（TL;DR）
- 模板把应用生命周期拆成立项、需求、设计、开发、测试、发布、运维、退役八个阶段，用阶段门禁表和角色职责表两张空白表承载交付物、评审门禁、评审角色、通过标准与状态。
- 阶段、交付物、评审门禁、评审角色、通过标准为必填列，状态列评审前可空；角色职责表中的角色与评审职责必填，所属团队和签字/记录方式按团队习惯选填。
- 填写时交付物写名称加形态，评审角色区分主责、参与、决策，通过标准写成评审现场可逐条核验的条件，状态从固定取值中选择。
- 小型项目可合并设计与开发门禁，涉及外部合规审计的项目保留全部八阶段门禁；退役门禁用于确认数据迁移、账号回收和资产归档完成。
- 模板落地后由过程管理角色担任Owner，门禁增减由业务部门负责人审批，每半年或重大项目结束后复核执行率与条件闭环情况。
可复制空白模板：阶段门禁与交付物总表
先复制下面两张表。第一张按阶段逐行填写，每个阶段至少一行，阶段内门禁较多时可拆成多行；第二张按角色逐行填写，覆盖第一张表中出现的所有评审角色。两张表配合使用，前者回答“每个阶段交什么、谁来评、什么算通过”，后者回答“这个角色具体做什么、怎么留记录”。
表一：阶段门禁与交付物总表（空白）
| 阶段 | 交付物 | 评审门禁 | 评审角色 | 通过标准 | 状态 |
|---|---|---|---|---|---|
| 立项 | |||||
| 需求 | |||||
| 设计 | |||||
| 开发 | |||||
| 测试 | |||||
| 发布 | |||||
| 运维 | |||||
| 退役 |
表二：角色职责表（空白）
| 角色 | 所属团队 | 评审职责 | 签字/记录方式 |
|---|---|---|---|
复制后的使用说明
- 阶段行按项目实际裁剪：采用敏捷迭代交付时，可在“需求—设计—开发—测试”之间增加迭代评审行，阶段名称保持不变，用门禁名称区分。
- 同一阶段有多个门禁时拆行填写，例如“测试”阶段可拆为“测试准入”和“测试完成”两行，交付物和通过标准分别填写。
- 角色职责表按第一张表中实际出现的角色增删行，表中未出现的角色不保留，避免职责表与门禁表脱节。
- 状态列初始留空，评审后填写结论；表格作为受控文档时，建议在表头补充项目名称、版本号和更新日期。
字段说明：每一列填什么、怎么判断填对了
模板能否用起来，取决于每列是否有统一的填写口径。下表逐列给出定义、填写要求和常见错误，填写时以本表为准，示例章节也按同一口径展开。
| 字段 | 定义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 阶段 | 应用所处的生命周期阶段 | 从八个标准阶段中选一个，名称保持一致 | 自造阶段名，导致跨项目无法汇总 |
| 交付物 | 该门禁要求提交的成果 | 写名称加形态，如“需求规格说明书（文档）”“可执行安装包（代码产物）” | 只写“相关文档”，无法判断是否齐备 |
| 评审门禁 | 进入下一阶段前必须通过的评审节点 | 写门禁名称，并注明进入条件与退出条件 | 只写“评审通过”，未说明评什么 |
| 评审角色 | 参与该门禁评审的人员角色 | 区分主责角色、参与角色、决策角色，用分号隔开 | 只写部门名，无法定位到具体责任人 |
| 通过标准 | 判定门禁通过的依据 | 写成可核验的条件，如“缺陷遗留数为0且严重级缺陷已关闭” | 写“质量达标”等无法验证的表述 |
| 状态 | 门禁当前结论 | 从“未开始、评审中、通过、有条件通过、不通过”中取值 | 混用“完成”“OK”等多种写法 |
交付物字段建议同时记录存放位置，可在交付物名称后用括号标注文档库路径或代码仓库分支，便于评审时直接调取。评审角色字段中的决策角色只填一个，避免出现多人拍板却无人负责的情况。通过标准应写成评审现场能逐条勾选的条件，条件数量多时用编号列出。
必填与选填：哪些列不能空、哪些可按团队裁剪
六列中，阶段、交付物、评审门禁、评审角色、通过标准为必填，状态列在评审前可空。必填列空缺意味着门禁无法执行，应视为模板填写未完成，不能进入评审。角色职责表中的角色、评审职责为必填，所属团队和签字/记录方式可按团队管理习惯选填。
| 字段 | 必填/选填 | 空缺时的处理 | 适用场景 |
|---|---|---|---|
| 阶段 | 必填 | 补齐后再提交评审 | 全部项目 |
| 交付物 | 必填 | 无交付物的门禁应合并或取消 | 全部项目 |
| 评审门禁 | 必填 | 补齐进入与退出条件 | 全部项目 |
| 评审角色 | 必填 | 至少指定一名决策角色 | 全部项目 |
| 通过标准 | 必填 | 改为可核验条件后填写 | 全部项目 |
| 状态 | 评审前可空 | 评审后补填结论 | 全部项目 |
| 所属团队 | 选填 | 角色跨团队时建议填写 | 多团队协作项目 |
| 签字/记录方式 | 选填 | 有合规审计要求时必填 | 受监管或需留痕的项目 |
裁剪按项目规模和交付模式进行。小型项目可合并设计与开发门禁，保留需求、测试、发布三个关键门禁；涉及外部合规审计的项目应保留全部八阶段门禁，并为每个门禁补充签字记录。采用持续交付的项目可提高发布门禁频次，退役阶段门禁仍应保留，用于确认数据迁移、账号回收和资产归档完成。
填写示例：一条应用从立项到退役的完整记录
以下示例为演示情景，描述一款内部审批应用的完整生命周期记录，用于说明各字段如何对应填写，不代表真实项目数据。
| 阶段 | 交付物 | 评审门禁 | 评审角色 | 通过标准 | 状态 |
|---|---|---|---|---|---|
| 立项 | 立项申请书中含目标、范围、预算（文档） | 立项评审：进入条件为申请书提交，退出条件为评审结论形成 | 主责：产品负责人；参与：技术负责人、财务接口人；决策：业务部门负责人 | 目标与范围明确，预算获批，风险清单已列出 | 通过 |
| 需求 | 需求规格说明书、需求跟踪矩阵（文档） | 需求基线评审：进入条件为需求文档完成，退出条件为基线冻结 | 主责：需求分析师；参与：开发、测试代表；决策：产品负责人 | 需求条目均有验收标准，跟踪矩阵覆盖全部需求 | 通过 |
| 设计 | 架构设计说明书、接口设计文档（文档） | 设计评审：进入条件为设计文档完成，退出条件为评审意见关闭 | 主责：架构师；参与：开发、运维代表；决策：技术负责人 | 关键接口有定义，非功能需求有对应设计措施 | 通过 |
| 开发 | 源代码、单元测试报告（代码产物与记录） | 开发完成评审：进入条件为编码完成，退出条件为代码评审通过 | 主责：开发负责人；参与：测试代表；决策：技术负责人 | 代码评审意见关闭，单元测试通过率达到约定值 | 通过 |
| 测试 | 测试报告、缺陷清单（文档与记录） | 测试完成评审：进入条件为测试执行完毕，退出条件为遗留缺陷评估完成 | 主责：测试负责人；参与：开发代表；决策：产品负责人 | 严重级缺陷全部关闭，遗留缺陷有处理计划 | 有条件通过 |
| 发布 | 发布说明、回滚方案（文档） | 发布评审：进入条件为测试结论形成，退出条件为发布窗口确认 | 主责：发布经理；参与：运维、测试代表；决策：技术负责人 | 回滚方案可执行，发布窗口与业务方确认 | 通过 |
| 运维 | 运维手册、监控配置记录（文档与记录） | 上线后评估：进入条件为稳定运行满约定周期，退出条件为评估报告完成 | 主责：运维负责人；参与：开发代表；决策：产品负责人 | 关键指标达到约定阈值，告警配置覆盖核心链路 | 通过 |
| 退役 | 退役方案、数据迁移与归档记录（文档与记录） | 退役评审：进入条件为替代方案就绪，退出条件为资产回收完成 | 主责：产品负责人；参与：运维、安全接口人；决策：业务部门负责人 | 数据完成迁移或归档，账号与资源回收完毕 | 未开始 |
对应的角色职责表填写如下：
| 角色 | 所属团队 | 评审职责 | 签字/记录方式 |
|---|---|---|---|
| 产品负责人 | 产品团队 | 主持立项与测试完成评审，确认需求范围与遗留缺陷处理计划 | 评审记录中签署结论 |
| 技术负责人 | 研发团队 | 决策设计与开发门禁，确认技术方案与代码质量 | 评审记录中签署结论 |
| 测试负责人 | 质量团队 | 组织测试完成评审，提交测试报告与缺陷清单 | 测试报告附评审记录 |
| 运维负责人 | 运维团队 | 参与发布评审，负责上线后评估与退役资产回收 | 运维记录与评审记录关联 |
示例中“测试”阶段状态为“有条件通过”，对应通过标准中“遗留缺陷有处理计划”这一条，说明状态取值应与通过标准的判定结果一致，不能只写“通过”而忽略条件。退役阶段状态为“未开始”，表示该门禁尚未触发，属于正常留空。
调整与维护方法：模板落地后的修订与版本管理
模板投入使用后，需要明确谁有权修改、什么情况下修改、修改如何留痕。建议由质量或过程管理角色担任模板Owner，业务部门负责人审批涉及门禁增减的变更，技术负责人审批涉及交付物形态调整的变更。
触发修订的典型情况包括：组织引入新的合规要求、项目复盘发现某门禁长期空转、交付物形态随工具链变化（如测试记录从文档转为系统记录）、团队交付模式调整。每次修订应记录版本号、修订日期、修订人、变更内容和审批人，形成版本记录表。
| 版本 | 修订日期 | 修订人 | 变更内容 | 审批人 |
|---|---|---|---|---|
| V1.0 | 初始版本，八阶段门禁与角色职责 | |||
| V1.1 |
定期复核建议每半年或每个重大项目结束后进行一次，复核内容包括：各门禁的实际执行率、状态为“有条件通过”的门禁是否完成条件闭环、角色职责是否与组织架构一致。复核结论应回写到版本记录表，形成模板持续演进的依据。
当模板需要在多个项目间统一执行时，可以把阶段门禁、交付物模板和评审记录沉淀为可复用资产。ONES ALM 研发管理方案支持将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，并以数字线程贯通需求、开发、测试、变更与发布，支撑过程追溯与合规审计；需求、基线、版本和变更作为统一管理对象，测试用例、缺陷、版本与发布过程关联到需求链路中，便于在评审时定位影响范围。团队可将上述两张表的结构映射到工作项类型与文档模板中，让门禁状态随工作项流转更新，减少手工维护表格的重复劳动。
常见问题
团队规模小、角色由一人兼任多个岗位时，角色职责表怎么填？
角色职责表按评审动作填写，不按人头填写。同一个人兼任产品负责人和测试负责人时，在表中保留两个角色行，分别写明各自在评审中的职责和记录方式，评审记录中注明由同一人承担。这样门禁表里的评审角色列仍能准确指向职责，后续人员调整时只需改角色对应关系，不必重写门禁表。
需要留意的是，决策角色在单个门禁中只保留一个，兼任情况下也按门禁分别指定，避免出现同一门禁多人拍板却无人负责。
采用敏捷迭代交付，还需要保留八阶段门禁吗？
保留阶段框架，调整门禁频次和粒度。需求、设计、开发、测试可以在迭代内以迭代评审的方式执行，阶段名称不变，用门禁名称区分不同迭代；发布门禁可随持续交付提高频次；立项、运维、退役三个阶段门禁按项目节点执行。
这样做的目的是让跨项目的门禁数据仍可按八个阶段汇总，同时不要求每个迭代都走一遍完整评审。如果团队有外部合规审计要求，迭代评审的记录也要按门禁表的状态取值留痕。
门禁评审结论为“有条件通过”后，条件没有闭环怎么办？
“有条件通过”表示门禁已放行但附带待办条件，需要在门禁表中记录条件内容、责任人和完成期限，并在下一阶段门禁评审时作为进入条件之一核查。条件未闭环时，下一阶段门禁不应判定为“通过”。
建议在定期复核时专门统计“有条件通过”的门禁数量及闭环率，长期未闭环的条件应回到模板修订环节，判断是门禁设置过严还是执行环节缺少跟踪机制。
交付物从文档转为系统记录后，模板需要改哪些地方？
需要修改交付物列的形态描述和存放位置标注，例如把“测试报告（文档）”改为“测试报告（系统记录，附链接）”，并在字段说明中同步更新形态取值。通过标准的判定依据如果依赖系统数据，也应改为可核验的系统指标。
这类变更属于交付物形态调整，按模板维护规则由技术负责人审批，并在版本记录表中登记变更内容和生效日期，避免新旧项目混用不同口径。
把这两张表搬到研发管理工具里，能减少哪些手工维护工作？
表格搬到工具后，阶段门禁可以映射为工作项类型或评审节点，交付物映射为文档模板或附件要求，状态随工作项流转自动更新，减少在表格中手工改状态、核对交付物是否齐备的重复劳动。评审记录与需求、测试、发布数据关联后，评审时可以直接查看影响范围。
ONES ALM 研发管理方案支持将标准流程、评审节点、交付物模板和过程数据沉淀为可复用资产，并以数字线程贯通需求、开发、测试、变更与发布，支撑过程追溯与合规审计。具体配置方式需结合团队实际流程设计，模板本身仍是统一口径的依据。
