接手现有软件项目时，第一目标是降低不确定性，而不是马上开始功能冲刺。前 30 天应让系统能够重复构建、能够观察，并具备足够安全的修改条件。
适用范围
当团队更换、文档缺失、线上事故频繁，或原团队没有留下可靠交接时，可使用这套方法。如果关键账号和生产权限尚未取得，先解决访问问题再承诺交付日期。
第 1-5 天：保护访问与恢复路径
盘点代码仓库、云服务、DNS、数据库、对象存储、队列、统计和第三方账号。记录每项资产的负责人和恢复路径，并在修改生产设置前创建可实际恢复的备份。
第 6-12 天：在隔离环境还原系统
记录运行时、依赖、环境假设和部署步骤。只能在一台旧服务器运行的系统，在进入功能排期前就已经存在交付风险。
第 13-20 天：梳理关键业务流程
优先跟踪资金、权限、订单、库存和数据丢失相关流程。明确输入、状态变化、外部依赖、失败信号和业务决策人。
第 21-30 天：定义第一个稳定里程碑
选择一个可验证的运行结果，例如可重复部署、安全处理支付回调、可靠执行后台任务或恢复库存流水。开始实施前先写清验收证据。
常见误区
不要在第一个里程碑同时进行框架升级、基础设施迁移和新功能上线。变化叠加后，团队会失去定位回归问题所需的证据。
相关服务
需要制定接手与恢复路线时，可查看现有软件项目接手与稳定。