HANDOVER CHECKLIST / 项目交付
上线之前，把系统可接管所需材料逐项交清
交付不等于发送一个代码压缩包。真正可接管的系统需要说明代码对应的版本、怎样构建和部署、账号由谁持有、哪些组件受许可限制，以及上线时仍有哪些已知问题。
SCOPE / 项目范围
先看这类项目通常包含什么。
- 01代码与版本
仓库、分支、提交版本、构建方式和第三方依赖保持对应。
- 02设计与测试
原型、设计源文件、验收脚本、测试记录和未通过项可追踪。
- 03部署与数据
环境结构、发布步骤、备份恢复、迁移记录和回滚方式写清楚。
- 04账号与限制
域名、云资源、应用商店、接口账号、许可证和已知问题明确归属。
DECISIONS / 关键判断
开始开发前，先把这些问题回答清楚。
交付物对应上线版本
避免代码、文档和生产环境分别停在不同时间点。
敏感信息安全移交
密钥和密码通过约定的安全渠道交付，不放进普通文档。
遗留问题公开确认
区分缺陷、已接受限制和后续需求，并记录处理决定。
WORKED EXAMPLE / 填写示例
交付核对时，不只问“有没有”，还要问“能否接管”
示例：一套小程序、管理后台和接口服务准备转入正式运维。
生产版本对应明确提交，构建产物可以从该版本重复生成。
新负责人能在预发布环境完成一次部署、健康检查与回滚。
域名、云资源、小程序、支付和消息账号均由约定主体控制。
已知限制、观察项和后续需求分别记录，不混入已完成范围。
- 01按系统组件建立交付目录
- 02在预发布环境完成接管演练
- 03双方确认版本、账号与遗留事项
BOUNDARY / 项目说明
清单帮助确认可接管性， 具体权属仍以合同和许可为准。
FAQ / 常见问题
怎样确认系统已经完成移交
01
拿到源代码就算完成交付了吗？
不算。还要确认对应版本、依赖、构建部署方法、环境配置边界以及必要的设计和测试材料。
02
账号和密钥应该放进交付清单吗？
清单应记录账号用途、归属和交接状态；实际密码与密钥应通过受控渠道传递，不直接写在普通表格中。
NEXT / 继续了解
从相关服务、案例或资料继续判断。
PROJECT CONTEXT / 项目沟通
问题已明确，直接讨论首期范围。
不用先整理完整需求文档，说明当前做法、使用角色、预算与首期目标即可。