第620章 四周攻坚表（1/2）

请关闭浏览器的阅读/畅读/小说模式并且关闭广告屏蔽过滤功能，避免出现内容无法显示或者段落错乱。

周一上午，客户启动款到账，区域服务平台正式进入四周攻坚期。

项目组要在二十八天内完成两城数据清洗、样本迁移、接口联调和回退演练。技术团队分布在三地，客户资料又由不同部门提供，任何一个节点延误都会把后面的测试一起推迟。

许知微依据深夜纪要排出一张四周攻坚表。

表格不是把每天塞满会议，而是按结果倒排。第一周确认数据与环境，第二周完成样本迁移，第三周做接口联调和故障演练，第四周处理遗留问题并准备验收。每个阶段只保留一个主负责人，协作人员另列，避免所有人都在群里却没人作决定。

日报分成三级。正常进度在系统更新，不开会；影响单日任务的黄色问题进入次日晨会；可能改变试点范围、合同节点或数据安全的红色问题，十五分钟内通知李渊、项目经理和客户负责人。

为了避免所有人争着把问题降级，颜色由现场负责人初判，项目经理复核，涉及安全时由信息安全负责人拥有直接升级权。问题一旦标红，可以在事实查清后降级，却不能删除最初记录。这样既防止小事惊动所有人，也防止部门为了进度好看压住风险。

现场协调也写得具体。两城各设一名公司负责人和一名客户联系人，轮班表提前一周公布。夜间演练不允许白天已经连续工作的人继续值守，必要时启动备用班组。差旅、加班和调休由行政按真实记录处理，不把攻坚当作无限延长工时的理由。

项目经理看完，先删掉三次例行汇报。他比出差前更重视身体状态，也明白会议并不会自动降低风险：“周三和周五做完整进度会，其余时间按等级上报。遇到红色问题再临时召集。”

李渊同意，并增加一条：红色问题不能只报坏消息，还要写清当前影响、已采取措施和下一项需要决定的内容。负责人可以不知道最终答案，却不能只发一句“情况紧急”。

攻坚表发布当天，第一批数据便出现问题。客户A城提供的历史账户中有近两千条身份证字段缺失，超过合同约定比例。现场团队将问题标黄，销售却担心客户觉得公司挑剔，希望先清洗一部分再谈责任。

许知微按规则要求原样记录，没有把黄色改成绿色。问题若能在一天内补齐，不必升级给李渊；若客户拒绝补交，才会影响迁移范围。

客户下午补回大半数据，剩余部分确认作废，节点没有推迟。项目组第一次看见，按真实等级上报不会自动引来责备，也不需要靠隐瞒换取表面顺利。

第二天，B城接口测试出现短暂中断。值班工程师在十分钟内恢复，起初只准备写进日报。复核时发现中断源于第三方证书即将到期，若不更换，正式迁移时可能再次发生。问题从黄色升为红色。

许知微收到通知后，没有把十几条技术消息全部转给李渊。她要求现场负责人按模板补齐：当前服务已恢复，证书七天后到期，需要决定由谁联系第三方并承担更换窗口。

十五分钟晨会临时提前。项目经理与信息安全负责人线上加入，李渊只确认责任与时限，不插手证书操作。第三方当天下午完成续期，夜间测试通过。

本章未完，点击下一页继续阅读。