01
初步方案
什么保留，什么改变
逐组件决定重建、封装或下线。必须保持原样的，写下来。每一处有意改动，也写下来。
为什么重写会卡死。
团队膨胀，期限后移，旧系统继续跑——因为没人敢信新系统。
在运行
系统每天都在赚钱。传统做法却让它等上十八个月。
回归
没人列得出什么不能坏。于是要么全靠手测，要么干脆不测。
跑偏
重写变成了第二个产品，背着自己的需求池。客户用的还是旧系统。
项目进行期间
任何时候，你们都能看到这些。
放在哪里
你们的云。你们的代码仓库。
- 01 应用 Web 端、移动端和报表都跑在你们的账户里。
- 02 代码仓库 首次提交就已经是你们的。
- 03 托管 我们从不托管。我们离开时，没有任何合同需要解除。
工作本身
工作如何按序推进。
02
接口契约
先锁定接口
API、事件和报表先固定。集群按契约开发。新核心日后不能擅自发明接口。
03
并行重建
最高风险优先
最怕出问题的用户路径最先重建，每条都配测试，证明旧行为依然成立。
04
切换
关掉旧核心
流量逐组件迁移。旧路径只有在你们团队验收文件之后才关闭。
01
检查
什么不能坏，是测试，不是愿望。
每一条点名的用户路径，在集群动核心之前就有测试。每次变更都跑这些测试。没通过就停发，不管日期怎么说。
检查
检查不通过，拦下什么
- 01 发布 构建失败不发布，预发布环境也不发。
- 02 上线 安全或性能检查不通过，不上线。
- 03 切换 没有写好并演练过的回滚，不切换。
02
风险
重写不用你们盯，失败也不用你们扛。
一名主责工程师对结果负责，直到你们团队验收。不是你们要管的项目，也不是你们要追的供应商。
谁承担
交付风险只有一个负责人
- 01 工时 供应商多、经手的人多。每一次失手，后果都由你们承担。
- 02 UNIT01 一名主责工程师对结果负责，直到你们验收。
- 03 上线 几点切换流量由你们定。我们保证你们切得动。
03
验收
旧核心保留，直到你们团队验收。
部署不等于交付。运维手册、监控和未决风险先进你们的代码仓库。然后旧核心才熄灯。
验收
你们签字前，代码仓库里有什么
- 01 测试 随代码一起写，在你们的流水线里运行。
- 02 运维手册 怎么运营、找谁、怎么回滚。
- 03 风险 每个未决事项都有负责人。没有事后才暴露的问题。
初步方案里
开工前写下来的东西。
初步方案逐项写明这些内容。它是一份文件：你们可以接受、修改，也可以拒绝。
路线图
重建 / 封装 / 下线
初步方案里逐组件决定。不是第六个月才发现。
检查
必须照常工作的功能
点名的路径在我们动核心前就有通过标准。那是测试，不是清单。
改动
有意改动清单
验收写明哪些是新的。清单之外的改动就是缺陷。
主责工程师
一个实名的负责人
说了算的工程师写进合同。签约前你们就能见到。
文件
在你们的代码仓库里
代码、测试、运维手册、监控和未决风险。验收前就位。
知识产权
代码和品牌归你们
合同里约定转让。我们从不托管或扣留产品。
大家常问的问题
常见问题。
01
这怎么比我们自己的团队做还快？
你们的团队有本职工作，集群没有。它并行重建组件并写好测试，主责工程师把它约束在你们锁定的接口之内。
02
这是界面翻新吗？
只有当风险在界面时才是。通常风险在服务和数据里。初步方案会写明是哪种。
03
所有行为都保留吗？
你们点名的，我们保留，并用测试证明。其余的都是列明的改动，由你们验收。
04
能保留旧系统的一部分吗？
能。封装和下线是正经选项，不是失败。
05
原来的供应商还在怎么办？
可以，只要结果仍然只有一个负责人。第一周我们就会说明这样拆分是否安全。
06
运营团队什么时候接手？
在他们验收你们代码仓库里的文件时。不是某次部署完成的时候。
下一步
告诉我们什么必须上线，以及什么时候。
我们会回复一份初步方案：用你们的话写清什么叫完成、多少钱、什么时候。之后由你们决定。