混合式项目里，瀑布阶段门禁管的是“能不能进入下一阶段”，迭代产出管的是“这一阶段实际交付了什么”。两者脱节时，门禁评审容易变成补材料，迭代产出也难以支撑放行判断。本文提供两张可直接复制的空白表：阶段门禁与迭代产出映射表、治理清单，并说明字段口径、必填取舍、填写示例与维护方法。模板可以放在文档中填写，也可以借助ONES的项目计划、里程碑与迭代关联能力承载阶段和产出信息。
要点总览（TL;DR）
- 用一张“阶段—迭代映射表”把每个瀑布阶段门禁的准入条件、关联迭代、迭代产出物、证据位置、判定结果和放行结论逐行对应起来，门禁评审时按行核对即可。
- 治理清单在映射表基础上增加检查人、检查日期、例外说明、整改措施、整改责任人与关闭状态，形成从发现问题到关闭问题的记录链。
- 两张表通过门禁编号关联：映射表一个门禁项可对应治理清单多条检查记录，治理清单的判定结果回填到映射表的判定结果与放行结论。
- 最小可用字段集为门禁编号、门禁项、关联迭代、迭代产出物、证据位置、判定结果、放行结论；涉及多团队协作、外部验收或合规要求时再补充准入条件、评审方式与整改字段。
- 模板随阶段推进维护：迭代结束补产出、评审时记判定、整改关闭后回填放行结论，阶段放行后归档当期版本作为下一阶段复用基线。
可复制的阶段门禁与迭代产出映射表
映射表的作用是把每个瀑布阶段门禁拆成可检查的行，再为每行挂接该阶段内迭代的实际产出。填写时一个门禁项占一行；同一阶段有多个门禁项就写多行，同一门禁项对应多个迭代产出时可拆行或在一行内并列。下表为空白模板，可直接复制到文档或表格工具中填写。
| 序号 | 瀑布阶段 | 门禁编号 | 门禁项 | 准入条件 | 关联迭代 | 迭代产出物 | 产出类型 | 证据位置 | 责任角色 | 评审方式 | 判定结果 | 放行结论 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
表格左侧四列固定门禁本身，中间四列回答“哪个迭代交付了什么”，右侧四列记录证据、判定与放行。这样一行就能同时被阶段负责人和迭代团队看懂，评审时按行核对，不需要在阶段计划和迭代看板之间来回翻找。
治理清单空白模板
治理清单用于逐条跟踪门禁检查的执行情况，重点记录“查了什么、证据在哪、谁判定、结果如何、例外怎么处理”。它与映射表共享阶段、门禁编号和迭代产出，但增加了检查时间、判定人和整改闭环信息。下表为空白模板。
| 清单编号 | 对应门禁编号 | 检查项 | 检查标准 | 对应迭代产出 | 证据位置 | 检查人 | 检查日期 | 判定结果 | 例外说明 | 整改措施 | 整改责任人 | 整改期限 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
判定结果建议统一取“通过、有条件通过、不通过”三类，例外说明只在非“通过”时填写，整改措施与关闭状态配合使用，形成从发现问题到关闭问题的记录链。
字段说明：每个字段填什么、怎么取值
两张表的字段需要同名同义，映射表中的门禁编号、迭代产出、证据位置在治理清单中直接引用，避免同一件事出现两种叫法。以下按三组说明填写口径。
阶段与门禁字段
| 字段 | 填写内容 | 取值方式 |
|---|---|---|
| 瀑布阶段 | 该门禁所属阶段，如需求、设计、开发、测试、上线 | 按项目实际阶段命名，与项目计划中的阶段划分一致 |
| 门禁编号 | 门禁的唯一标识，如 G-REQ-01 | 阶段缩写加序号，全项目唯一，便于跨表引用 |
| 门禁项 | 本行要检查的具体事项 | 写成可判断的短句，如“需求基线已评审通过” |
| 准入条件 | 进入该阶段前必须满足的前提 | 列出可核验的条件，避免写“基本完成”这类模糊表述 |
| 检查标准 | 治理清单中判断通过的依据 | 与门禁项对应，写明数量、状态或文档要求 |
迭代产出与证据字段
| 字段 | 填写内容 | 取值方式 |
|---|---|---|
| 关联迭代 | 产出该交付物的迭代名称或编号 | 与迭代计划中的命名一致，一个门禁可关联多个迭代 |
| 迭代产出物 | 迭代实际交付的文档、功能、测试结果等 | 写具体名称，如“接口设计说明书 V1.2” |
| 产出类型 | 产出物的类别 | 可选文档、代码、测试报告、评审记录、演示等 |
| 证据位置 | 产出物存放或可查看的位置 | 写文档链接、目录路径或工作项编号，保证评审人可直接打开 |
| 责任角色 | 对该产出负责的角色 | 写角色名而非个人姓名，如“系统架构师” |
判定与例外字段
| 字段 | 填写内容 | 取值方式 |
|---|---|---|
| 评审方式 | 该门禁的检查形式 | 可选文档评审、会议评审、演示验收、自动检查 |
| 判定结果 | 本次检查的结论 | 通过、有条件通过、不通过 |
| 放行结论 | 阶段是否允许进入下一阶段 | 放行、暂缓放行、不放行 |
| 例外说明 | 未完全满足标准的原因与影响 | 非“通过”时必填，写明缺口和风险 |
| 整改措施 | 针对缺口采取的动作 | 写具体动作和完成标志 |
| 关闭状态 | 整改是否完成 | 开放、整改中、已关闭 |
字段间的引用关系是：映射表的门禁编号进入治理清单的“对应门禁编号”，映射表的迭代产出和证据位置进入治理清单的同名列，治理清单的判定结果回填到映射表的判定结果与放行结论。两张表通过门禁编号形成一对多关系，一个门禁项可以有多条检查记录。
必填与选填：最小可用字段集
必填字段的判断标准是“缺少它就无法完成一次门禁判定”。小团队或轻治理场景可以先保留最小字段集，随项目复杂度增加再补充选填字段。
| 字段 | 映射表 | 治理清单 | 说明 |
|---|---|---|---|
| 瀑布阶段 | 必填 | — | 定位门禁所属阶段 |
| 门禁编号 | 必填 | 必填 | 两表关联的主键 |
| 门禁项 | 必填 | 必填 | 检查对象 |
| 关联迭代 | 必填 | — | 建立阶段与迭代的对应 |
| 迭代产出物 | 必填 | 必填 | 判定所依据的交付物 |
| 证据位置 | 必填 | 必填 | 评审人可核验 |
| 判定结果 | 必填 | 必填 | 结论记录 |
| 责任角色 | 选填 | 必填 | 治理清单中用于追责与整改 |
| 准入条件 | 选填 | — | 复杂项目补充 |
| 产出类型 | 选填 | — | 便于分类统计 |
| 评审方式 | 选填 | — | 规范评审形式时填写 |
| 放行结论 | 必填 | — | 阶段推进的直接依据 |
| 例外说明 | 选填 | 必填（非通过时） | 记录缺口 |
| 整改措施、责任人、期限、关闭状态 | — | 选填 | 存在例外时填写 |
最小可用字段集为：门禁编号、门禁项、关联迭代、迭代产出物、证据位置、判定结果、放行结论，治理清单另加检查人和检查日期。项目涉及多团队协作、外部验收或合规要求时，再补充准入条件、评审方式、例外与整改字段。
填写示例：一个混合项目的完整一行
以下为演示情景，项目为虚构的“客户门户升级”，采用瀑布阶段划分、阶段内按迭代交付的方式，不对应任何真实客户。
映射表填写一行：瀑布阶段为“设计”，门禁编号 G-DES-02，门禁项为“核心接口设计完成并通过评审”，准入条件为“需求基线已冻结”，关联迭代为“迭代 3”，迭代产出物为“接口设计说明书 V1.2”，产出类型为“文档”，证据位置为“设计文档库/门户升级/接口设计”，责任角色为“系统架构师”，评审方式为“文档评审”，判定结果为“有条件通过”，放行结论为“暂缓放行”，备注为“支付接口超时策略待补充”。
治理清单对应填写两条：第一条清单编号 G-DES-02-01，检查项为“接口清单完整性”，检查标准为“覆盖需求基线中全部外部接口”，对应迭代产出为“接口设计说明书 V1.2”，证据位置同上，检查人为“质量负责人”，检查日期为演示日期，判定结果为“通过”，关闭状态为“已关闭”。第二条清单编号 G-DES-02-02，检查项为“异常与超时处理设计”，检查标准为“每个外部接口写明超时与重试策略”，判定结果为“不通过”，例外说明为“支付接口缺少超时阈值”，整改措施为“补充超时阈值与降级方案并更新文档至 V1.3”，整改责任人为“系统架构师”，整改期限为演示日期后三个工作日，关闭状态为“整改中”。
当第二条整改关闭后，将映射表该行判定结果更新为“通过”、放行结论更新为“放行”，并在备注中记录关闭日期。这一行完整展示了门禁、迭代产出、证据、判定和例外整改之间的联动。
模板调整与维护方法
模板需要随阶段推进持续更新，否则门禁记录会停留在评审当天，无法反映整改和放行的真实状态。维护动作可按以下清单执行。
- 阶段启动时：复制上一阶段映射表结构，替换阶段名称和门禁项，清空判定与放行列，保留门禁编号规则。
- 迭代结束时：将本次迭代产出物、证据位置补入映射表对应行，未挂接产出的门禁项标记为待补。
- 门禁评审时：在治理清单逐条新增检查记录，填写判定结果；非“通过”的记录同步填写例外与整改字段。
- 整改关闭时：更新治理清单关闭状态，回填映射表判定结果与放行结论，记录关闭日期。
- 阶段放行后：将当期映射表与治理清单归档为一个版本，文件名包含阶段名和日期，作为下一阶段复用的基线。
- 跨项目复用时：保留字段结构，按新项目的阶段划分调整门禁项和产出类型选项，删除与该项目无关的选填列。
维护责任建议由阶段负责人牵头、质量角色核对证据完整性、项目经理确认放行结论。若团队使用ONES，可将门禁项作为工作项或检查项记录，将迭代产出关联到对应迭代与项目计划，评审结论和整改状态在文档中留存；ONES瀑布项目管理方案支持按阶段分解计划、用里程碑标记决策点，并可在项目计划中关联迭代和研发任务，便于把映射表中的阶段、门禁与迭代产出放在同一项目视图下核对。
常见问题
一个瀑布阶段门禁项对应多个迭代产出时，映射表应该拆行还是并列填写？
两种方式都可以，取决于评审时怎么核对。如果每个迭代产出需要单独判定，建议拆行填写，每行保留相同的门禁编号、只更换关联迭代和迭代产出物，这样治理清单可以按产出逐条记录检查结果。如果多个产出共同支撑同一个判定结论，可以在一行内并列写出产出物名称和证据位置，治理清单仍按检查项拆条记录。拆行时注意门禁编号保持一致，避免同一门禁在两张表里出现不同编号。
门禁判定为“有条件通过”时，阶段能不能先进入下一阶段？
这取决于例外的影响范围。模板里把判定结果和放行结论分开，就是为了支持这种情形：判定为“有条件通过”时，放行结论可以填“暂缓放行”，等治理清单中的整改项关闭后再更新为“放行”；如果缺口只影响非关键路径，也可以由阶段负责人确认后填“放行”，同时在例外说明中写明遗留项和关闭期限。无论哪种处理，例外说明、整改措施、整改责任人和整改期限都应填写完整，并在关闭状态更新后回填映射表。
小团队字段填不全，能不能只用治理清单、不做映射表？
可以简化，但建议保留映射表的核心列。治理清单记录的是检查过程，映射表回答的是“这个阶段有哪些门禁、分别由哪个迭代的什么产出支撑”。如果只保留治理清单，阶段负责人需要从多条检查记录里自行汇总放行依据，阶段推进时容易遗漏门禁项。轻治理场景可以把映射表压缩到门禁编号、门禁项、关联迭代、迭代产出物、证据位置、判定结果、放行结论七列，治理清单保留对应门禁编号、检查项、检查人、检查日期、判定结果和关闭状态，其余字段按需补充。
模板在项目进行中调整了字段，已经填好的记录怎么处理？
建议按阶段冻结模板版本。当前阶段已经开始的映射表和治理清单沿用原字段结构，新增字段从下一阶段或下一次评审开始使用；如果新增字段属于必填项，先对当前阶段未关闭的记录做一次补填，再切换版本。归档时文件名包含阶段名、模板版本和日期，并在备注中说明本次调整了哪些字段、原因是什么。跨项目复用时保留字段结构，只调整阶段划分、门禁项和产出类型选项，避免每个项目各用一套叫法。
把这两张表放进项目管理工具时，门禁项和迭代产出分别对应什么对象？
常见做法是把门禁项作为工作项或检查项记录，把迭代产出物关联到对应迭代和项目计划，证据位置填写文档链接或工作项编号。ONES 的瀑布项目管理方案支持按阶段分解计划、用里程碑标记决策点，并可在项目计划中关联迭代和研发任务，便于把阶段、门禁与迭代产出放在同一项目视图下核对；评审结论和整改状态可以留在文档中。具体用哪种工作项类型、字段如何配置，需要结合团队现有项目模板确定，本文模板只约定字段口径，不限定承载工具。
