应用生命周期管理要落地，先得有一套能直接填写的阶段模板。本文按“立项与可行性—需求与范围—设计与架构—开发与集成—测试与验收—发布与上线—运行与运维—退役下线”八个阶段，给出阶段卡、交付物清单和评审角色分工三张空白表，并逐字段说明填写口径、必填与选填判断、完整填写示例，以及按团队规模裁剪和长期维护的方法。模板可直接复制到文档或工作项中使用。
要点总览（TL;DR）
- 模板按立项与可行性、需求与范围、设计与架构、开发与集成、测试与验收、发布与上线、运行与运维、退役下线八个阶段组织，每个阶段配一张阶段卡，写明目标、门禁、责任角色、通过标准与归档位置。
- 三张表分工使用：阶段卡定义门禁与归档，交付物清单逐项落实产出、责任人与评审人，评审角色表规定每场评审的主持人、决策人、记录人与知会人。
- 必填字段决定门禁能否被审计，阶段目标、评审门禁、责任角色、通过标准、归档位置以及交付物的编号、类型、责任人、状态不能空；知会人、评审人等字段可在风险可控、记录完整的前提下裁剪。
- 通过标准要写成可判断条件，常用“某角色确认某交付物”“某指标达到约定值”“遗留问题已关闭或已登记豁免”三种写法，避免模糊描述。
- 模板落地后按应用规模与风险等级裁剪阶段和门禁，记录版本号与变更摘要，每半年复核一次，出现组织调整或门禁反复卡点时即时修订。
可复制空白模板：阶段卡、交付物清单与评审角色表
三张表分工明确：阶段卡定义每个阶段的目标、门禁和归档位置；交付物清单逐项列出要产出什么、由谁负责、由谁评审；评审角色分工表规定每场评审由谁主持、谁决策、谁记录。建议先填阶段卡，再据此拆交付物清单，最后按评审活动配置角色。
表一：八阶段阶段卡（空白）
| 阶段 | 阶段目标 | 关键交付物 | 评审门禁 | 责任角色 | 通过标准 | 归档位置 |
|---|---|---|---|---|---|---|
| 立项与可行性 | ||||||
| 需求与范围 | ||||||
| 设计与架构 | ||||||
| 开发与集成 | ||||||
| 测试与验收 | ||||||
| 发布与上线 | ||||||
| 运行与运维 | ||||||
| 退役下线 |
表二：交付物清单（空白）
| 编号 | 交付物名称 | 所属阶段 | 类型 | 必填/选填 | 责任人 | 评审人 | 状态 |
|---|---|---|---|---|---|---|---|
表三：评审角色分工（空白）
| 评审活动 | 主持人 | 评审人 | 决策人 | 知会人 | 记录人 |
|---|---|---|---|---|---|
字段说明：每列填什么、怎么判断
模板能否被不同团队一致使用，取决于字段口径是否统一。下表逐列说明含义与判断方法，填写时以本表为准。
| 字段 | 填写口径 | 判断方法 |
|---|---|---|
| 阶段目标 | 该阶段结束时应达成的业务或技术结果 | 写成一句可验收的结果句，如“范围经业务方确认并冻结” |
| 关键交付物 | 支撑门禁判断的核心产出，与交付物清单编号对应 | 只列门禁必需项，完整清单放表二 |
| 评审门禁 | 进入下一阶段前必须通过的评审活动名称 | 与表三的评审活动一一对应 |
| 责任角色 | 对该阶段结果负总责的岗位 | 填岗位而非人名，人员变动时只改人员映射 |
| 通过标准 | 门禁放行的可判断条件 | 写成“谁确认了什么”，避免“质量良好”这类描述 |
| 归档位置 | 交付物与评审记录的存放路径 | 填到具体目录、知识库空间或工作项类型 |
| 交付物类型 | 文档、设计件、代码与配置、测试证据、发布记录五类 | 按产出形态归类，一类交付物只选一个主类型 |
| 状态 | 草稿、评审中、已通过、已归档 | 状态变更须有对应评审记录支撑 |
评审角色按职责边界划分：主持人组织评审、控制议程与时限，不代替决策人拍板；评审人从专业角度提出问题与意见；决策人对是否通过门禁作出最终判断并承担结果；知会人接收结论、不参与表决；记录人整理意见、结论和待办，形成可追溯的评审记录。角色可由同一人兼任，但决策人与记录人建议分开，避免结论与记录相互影响。
通过标准要写成可判断条件，常用三种写法：一是“某交付物经某角色确认”，如“需求范围经业务负责人书面确认”；二是“某指标达到阈值”，如“关键用例通过率达到约定值”；三是“某遗留问题已关闭或已登记豁免”。三种写法都要求能回答“谁、看什么、达到什么状态才算过”。
必填与选填：哪些字段不能空
必填字段决定门禁能否被审计，选填字段用于适配不同规模团队。裁剪的前提是风险可控、结论可追溯，不能因为团队小就省略决策与记录。
| 表 | 必填字段 | 可裁剪为选填的字段 | 裁剪前提 |
|---|---|---|---|
| 阶段卡 | 阶段、阶段目标、评审门禁、责任角色、通过标准、归档位置 | 关键交付物可只填编号引用 | 交付物清单已完整维护 |
| 交付物清单 | 编号、名称、所属阶段、类型、必填/选填、责任人、状态 | 评审人 | 该交付物不单独评审，随阶段门禁一并审 |
| 评审角色表 | 评审活动、主持人、决策人、记录人 | 知会人；小型应用可由主持人兼记录人 | 评审规模小、参与方少，且记录仍完整留存 |
必填字段缺失时按以下规则处理：门禁评审前发现缺失，退回责任人补齐后再排评审；评审后归档时发现缺失，标记为“归档不完整”并登记补正期限；涉及决策人与通过标准的缺失，视为门禁未通过，不得进入下一阶段。退役下线阶段的归档位置同样必填，用于后续审计与知识沉淀。
填写示例：一个应用从立项到上线的完整阶段卡
以下示例以一个通用内部业务应用为背景，演示立项、设计、测试、发布四个关键阶段的填法，其余阶段按同样口径补齐。示例中的角色与标准为演示情景，实际填写时替换为团队真实岗位与约定值。
| 阶段 | 阶段目标 | 关键交付物 | 评审门禁 | 责任角色 | 通过标准 | 归档位置 |
|---|---|---|---|---|---|---|
| 立项与可行性 | 明确业务价值与投入边界，获得启动授权 | D01 立项申请、D02 可行性说明 | 立项评审 | 产品负责人 | 业务负责人确认价值与预算范围，技术负责人确认可行性结论 | 项目知识库/立项 |
| 设计与架构 | 架构方案与接口约定经评审冻结 | D05 架构设计、D06 接口说明 | 设计评审 | 架构师 | 架构师与开发负责人确认方案，遗留问题已登记 | 项目知识库/设计 |
| 测试与验收 | 验证需求覆盖并形成验收结论 | D09 测试报告、D10 验收记录 | 测试验收评审 | 测试负责人 | 关键用例全部执行，遗留缺陷已关闭或登记豁免，业务方签署验收 | 项目知识库/测试 |
| 发布与上线 | 按计划完成上线并具备回退能力 | D11 发布方案、D12 上线记录 | 发布评审 | 发布负责人 | 发布方案与回退方案经确认，上线检查单逐项完成 | 项目知识库/发布 |
对应的交付物清单示例行：D01 立项申请，所属阶段立项与可行性，类型文档，必填，责任人为产品负责人，评审人为业务负责人，状态已通过；D09 测试报告，所属阶段测试与验收，类型测试证据，必填，责任人为测试负责人，评审人为业务方代表，状态评审中；D12 上线记录，所属阶段发布与上线，类型发布记录，必填，责任人为发布负责人，评审人为运维负责人，状态已归档。
对应的评审角色分工示例行：立项评审，主持人为产品负责人，评审人为业务负责人与技术负责人，决策人为业务负责人，知会人为财务对接人，记录人为项目助理；测试验收评审，主持人为测试负责人，评审人为开发负责人与业务方代表，决策人为业务负责人，知会人为运维负责人，记录人为测试工程师；发布评审，主持人为发布负责人，评审人为开发负责人与运维负责人，决策人为技术负责人，知会人为业务方代表，记录人为运维工程师。
这些阶段卡、交付物与评审记录需要在工具中承载状态流转和归档。ONES ALM 方案覆盖需求、基线、版本、变更、测试与发布的全生命周期管理，可将标准流程、评审节点和交付物模板沉淀为可复用资产；把测试用例、缺陷、版本和发布过程关联到需求链路，便于在评审时回溯交付结果和影响范围。团队可据此把上述表格配置为工作项类型与评审节点，让门禁状态与归档位置在系统中保持一致。
调整与维护：按团队规模裁剪并定期更新
模板的价值在于长期可用。落地后按应用规模与风险等级裁剪，并建立版本与复核机制，避免模板随人员流动而失效。
- 按规模裁剪：小型应用可合并设计与开发门禁，保留立项、测试验收、发布三道门禁；中大型应用保留全部八阶段，高风险应用在设计与发布阶段增加独立评审。
- 按风险分级：涉及资金、客户数据或对外服务的应用，交付物清单中的测试证据与发布记录设为必填；内部工具类应用可将部分设计文档设为选填。
- 版本管理：模板文件头部记录版本号、修订日期、修订人和变更摘要，每次调整保留历史版本，便于追溯门禁口径变化。
- 归档与交接：每阶段评审结束后，交付物与评审记录按阶段卡中的归档位置存放；项目交接时以归档目录为清单逐项核对，缺失项登记补正。
- 定期复核：建议每半年复核一次模板，出现组织调整、合规要求变化、评审反复卡在同一环节或交付物长期空缺时，触发即时修订。
维护时保持三张表的字段一致：阶段卡调整门禁，交付物清单与评审角色表同步更新；裁剪只改必填性与阶段数量，不删除决策人与记录人字段。这样模板在团队扩张或项目类型增加时仍可直接复用。
常见问题
小型团队只有几个人，八阶段模板能否直接简化使用？
可以简化，但简化的对象是阶段数量和部分选填字段，决策人与记录人字段应当保留。常见做法是合并设计与开发门禁，保留立项、测试验收、发布三道门禁；交付物清单中不单独评审的交付物可省略评审人，随阶段门禁一并审。裁剪后仍要在阶段卡中写清通过标准和归档位置，确保门禁结论可追溯。
评审角色可以由同一人兼任吗？哪些角色建议分开？
角色可以兼任，尤其在参与方较少的评审中。主持人可以兼记录人，但决策人与记录人建议分开，避免结论形成与记录整理相互影响。决策人承担门禁放行的最终判断，记录人负责整理意见、结论和待办，两者分开更利于后续审计时还原评审过程。
阶段卡、交付物清单和评审角色表之间如何保持同步？
以阶段卡为主表：阶段卡调整门禁时，交付物清单中对应交付物的评审人和状态字段同步更新，评审角色表中对应评审活动的主持人、决策人、记录人一并调整。交付物清单的编号要与阶段卡“关键交付物”列引用一致，评审活动名称要与阶段卡“评审门禁”列一一对应。三张表字段口径统一后，任一张表变更都能被另外两张表校验出来。
评审后发现交付物缺失或归档不完整，应该怎么处理？
按发现时点区分处理：门禁评审前发现缺失，退回责任人补齐后再排评审；评审后归档时发现缺失，标记为“归档不完整”并登记补正期限，由记录人跟踪闭环。涉及决策人签署或通过标准的缺失，视为门禁未通过，不得进入下一阶段。退役下线阶段的归档位置同样必填，用于后续审计与知识沉淀。
模板在工具中如何承载评审状态和归档？
可以把阶段卡配置为工作项类型，把评审门禁配置为状态流转节点，交付物与评审记录作为附件或关联对象挂在对应工作项下。ONES ALM 方案覆盖需求、基线、版本、变更、测试与发布的全生命周期管理，可将标准流程、评审节点和交付物模板沉淀为可复用资产，并把测试用例、缺陷、版本和发布过程关联到需求链路，便于评审时回溯交付结果和影响范围。
