阶段门评审是什么
阶段门在项目关键节点设置评审：立项门、方案门、上线门、结项门，每个门定义明确的交付物与放行标准。未通过则整改或终止，防止问题滚动到下游。门的价值在于允许项目被叫停：如果从来没有不通过的案例，通常说明标准过松或评审流于形式。
基本信息
| 常见门 | 立项门、方案门、上线门、结项门 |
|---|---|
| 输入 | 交付物清单、检查项、前置门的结论 |
| 输出 | 通过、有条件通过、不通过 |
| 执行主体 | 项目组提交，评审组或治理机构判定 |
| 关键要求 | 标准事前公布并版本化，评审结论留痕 |
典型使用场景
- 立项阶段确认业务论证与资源可行性，避免上线后才质疑必要性
- 方案阶段确认架构、成本与合规，防止实施中途返工
- 上线阶段确认测试、安全、回退与运营准备到位
- 结项阶段确认交付物归档与收益验证方式，为投资后回顾做准备
- 高风险或跨部门项目设置额外门，重点核查跨系统影响
上线门检查示例
上线门检查示例
# 每项都要有证据，检查项本身不能作为结论
[ ] 测试与安全验证完成（附测试报告与扫描结果）
[ ] 回退方案已验证（含触发条件与决策人）
[ ] 监控告警与值班就绪（完成告警实测）
[ ] 数据迁移与备份确认（含校验方式）
[ ] 干系人沟通完成（用户通知、客服口径）门的判定与后续
| 结论 | 含义 | 后续动作 |
|---|---|---|
| 通过 | 标准全部满足 | 进入下一阶段并归档材料 |
| 有条件通过 | 非关键项待补 | 限期整改，带条件放行并跟踪 |
| 不通过 | 关键项缺失 | 整改后重新评审或终止项目 |
门的标准要事前公布并版本化：事后追加标准等于给项目挖坑，会让团队对评审机制产生不信任，也会拉长评审周期。