如何优化多次通宵加班后的项目发版复盘与反思过程？

本文共计3284个文字，预计阅读时间需要14分钟。

导航+将需求模糊，累死三军+不懂拒绝临时增加的需求+不可调试的代码+伪信息共享+技术债务+项目时间评估随意+不明确的发布清单+团队成员忙闲不均+bug处理不分等级+联调不足+结句+参考

导航

• 将帅无能,累死三军
• 不懂拒绝临时增加的需求
• 不可调试的代码
• 伪信息共享
• 技术债务
• 项目时间评估随意
• 不明确的发布清单
• 团队成员忙闲不均
• bug处理不分级
• 联调不充分
• 结语
• 参考

每一次版本的上线都应该像火箭发射一样严肃。

在过去十多年的程序员职业生涯中,为了保障项目的上线,加班加点是稀疏平常的事。特别是遇到较大的迭代版本,往往如临大敌,如果遇到一些意外的问题,有时候甚至会通宵达旦。

但是,很多时候总是关注项目bug的解决,却未曾从系统层面对每一次的超预期加班发版做出复盘。

最近,团队也是经历了几次不太顺利的发版工作(基本上持续到在凌晨2,3点),这引起了笔者的重视和反思。

上面是我们每次版本上线的测试流程。

为什么我们觉得自己做了万全的准备，却不能将发版时间控制在预期的范围之内呢？

对此,笔者利用工作之余,对导致发版加班的因素做了梳理,或许能与您产生共鸣。

将帅无能,累死三军

在一个技术团队中,至少要有一个人具备对团队的整体的技术架构和所涉及业务高度理解和敏感的人,或者说要从宏观上掌控全局的人。