- 将帅无能,累死三军
- 不懂拒绝临时增加的需求
- 不可调试的代码
- 伪信息共享
- 技术债务
- 项目时间评估随意
- 不明确的发布清单
- 团队成员忙闲不均
- bug处理不分级
- 联调不充分
- 结语
- 参考
每一次版本的上线都应该像火箭发射一样严肃。
在过去十多年的程序员职业生涯中,为了保障项目的上线,加班加点是稀疏平常的事。特别是遇到较大的迭代版本,往往如临大敌,如果遇到一些意外的问题,有时候甚至会通宵达旦。
但是,很多时候总是关注项目bug的解决,却未曾从系统层面对每一次的超预期加班发版做出复盘。
最近,团队也是经历了几次不太顺利的发版工作(基本上持续到在凌晨2,3点),这引起了笔者的重视和反思。
上面是我们每次版本上线的测试流程。
为什么我们觉得自己做了万全的准备，却不能将发版时间控制在预期的范围之内呢？
对此,笔者利用工作之余,对导致发版加班的因素做了梳理,或许能与您产生共鸣。
将帅无能,累死三军在一个技术团队中,至少要有一个人具备对团队的整体的技术架构和所涉及业务高度理解和敏感的人,或者说要从宏观上掌控全局的人。
只有掌控全局,才能保持随时头脑清晰地做一些合理的决策,而合理地决策才是保障团队工作高效开展地基石。
这个最适合的人选就是团队负责人。
大版本迭代上线发版绝对是检验一个技术团队负责人是否合格的试金石。
不懂拒绝临时增加的需求懂得拒绝是一门艺术。
技术人不是一个没有灵魂的代码工具。"这是产品大大提的,我没法拒绝"。当出现问题的时候,我们经常听到技术同学这样说。
不合理的需求,对用户不友好的需求,低收益,高投入的需求,要敢于拒绝。当然,拒绝也是一门艺术,这就是与人沟通的艺术。如果经过深思熟虑,你能够给出比较合理的解释或者提出更有建设性的方案,我想这样才会更加容易让人接受。
在最近几次发版的当天，竟然还有新的需求增加。
需求必须被管理起来,拒绝口头需求。
随意增加需求,却不增加研发时间和延迟发版,最终压力都会转向研发,这也将影响发版的进度,是导致加班的一个因素。
不可调试的代码确保写的代码是可调式的。
如何保障代码的质量? 那就是自测试。在这么多年的职业生涯中,我逐渐摸索出一个确保代码质量的笨方法——单步调试。
比如,接口提供给前端或者第三方系统使用,我一般会写一些测试用例,对代码进行单步调试。这种方法非常有效,也确实避免了上线之后产生重大bug的出现。
但是上一次迭代,在接手的项目中,为一个函数新加了一个参数,没有做单步调试,结果在上线的之后,在一种特定场景下出现非预期的状况。
经过一步一步地增加日志分析,才发现这个参数在执行的阶段出现了null的情况。
带来的直接后果就是,多花了两个小时排查问题。
多么痛的领悟!
伪信息共享值得注意的是,对于一些跨系统或者接入第三方的对接中,可能很难做到全流程地调试。这种情况,可以分段调试,保证最终结果正确性。
分工导致信息不对称。
在一个团队中,因为分工的差异或者组织架构的层级问题天然会导致一些信息差异。
尽管我们大量使用IM工具,通过拉群的方式来减少沟通的成本,这也依然无法避免。
同时即便是针对同一件事情,再加上团队成员参差不齐,认知上本身也存在差异。
在我们日常开展研发中,有些需求或者方案的变更,很多时候不会以邮件的方式通知到每个干系人,也不会将打印成文,对相关人员进行宣导。
这种情况,一般我会建立一个UI文档和项目方案文档,这个文档是团队成员贡献地,并且都可以编辑。
通过这种方式,充分调动团队成员的智慧,围绕这个项目,进行信息补充和共享。
当然,这里依然需要人来负责推进和落地。否则,也是空谈。
技术债务文档和文字依然是沟通的最佳途径,不容易产生歧义。
软件和教堂非常相似——建成之后我们就在祈祷。
有时候我真的很佩服的我们的测试同学,因为每次上线一个新的功能,他们总是能测试早期的迭代版本中的一些问题。
这是典型的技术债务,可能之前有些功能迭代时间比较紧张,临时采取了一些不够优雅的方案,亦或是出现了一些问题这是临时修复了一下数据,没有深究根本原因。
这些技术债务就像一颗定时炸弹一样,指不定在哪一次版本上线之后爆发出来。
对于程序员来说,真正好的工作氛围应该是每个人都在很安静地各司其职,而不是大伙儿忙着救火。
对于我们这种项目制的团队,团队人数少,但却承担着比较多的项目。
我们只有非常努力地保障每一个项目的每一次迭代是高质量的,上线之后没有大的缺陷,也没有频繁的反馈问题,才能勉强让团队能够正常运转。
所以,每一次的方案都会反复斟酌和验证,然后小步快跑,而不可冒进。
同时,针对反馈的每一个问题都会抱着打破沙锅问到底的精神去寻找根本原因。
项目时间评估随意如果PO说这是个很小的改动，你不要信他。——《一个输入框你要做一周?》
每次开完产品原型评审会,就到了项目研发工期评估时间。
我们知道任务的拆分越细化,评估时间越准确。
一般我们会让团队各端的研发人员根据原型来拆分各自的任务,并给出一个评估时间。
多年的工作经验告诉我们,原型中一定存在缺失的逻辑或者隐含的逻辑。
在这个阶段多花一点功夫,对需求充分挖掘,充分和产品沟通,才能做好任务拆分,最终减少评估时间的误差。
但是,我见过太多拍脑袋的方式产生的评估时间，最终导致实际时间和预估时间大相径庭。
这样带来的直接后果就是,加班赶进度,测试不充分,上线当天bug比较多或者还存在漏做的需求,导致加班发版。
不明确的发布清单发版是一件很严肃的事情。
就像火箭发射任务一样,软件项目的发布也是有自己的流程。而这种流程也需要整理成发版清单,公之于众。这样做的目的是,建立大家的共同目标,同时知晓目前的进度。
团队成员忙闲不均
在技术团队里面，如果一项工作长期都依赖一个人，这样对团队高效协作不太有利。
这种现象在互联网公司普遍存在。
举个栗子，有个项目是前后端分离的，后端人员富余，前端只有一个人。那么这个项目的交付时间大概率有前端同学开发结束时间而定。
在发布版本的时候，遇到项目中不同模块出现的bug数量不均匀时，这种尴尬就出现了。
当bug都集中在一个人身上，而团队的其他成员只能干着急。
比较推崇的做法，就是安排至少两个人参与一项工作,或者至少有两人对这项工作比较熟悉。
BUG处理不分级发版的主动权应该牢牢地掌握在研发手里。
任何时刻,研发同学必须保持清醒,主动权应该牢牢掌握在自己手里,不能被bug牵着鼻子走。
在进行bug修复的过程中，研发人员很容易陷入与bug的纠缠之中，但是值得注意的是，时间在一分一秒流逝。
管理大师德鲁克说过,"卓有成效的管理者总是把重要的事情放在前面做(first things first),而且一次只做好一件事(do one thing at time)。"
通过四象限法则,我们将bug列表按照重要程度的优先级进行归类。
项目管理者必须勇敢站出来,要对bug列表进行识别和优先级划分，避免在一些不太重要的bug上浪费太多时间。
经过梳理,会发现实际上有一些无关痛痒的Bug完全可以延迟处理。
联调不充分软件产品研发是一项系统而复杂的工程。
复盘这次的产品迭代,由于缺乏统筹协调,加上时间紧张,联调的环节被大大缩水。
在微服务,前后端分离日益流行的当下,很多时候完成一个项目往往需要多个团队的协作。换句话说,我们的项目对外依赖很重。
值得注意的是,不同团队和服务并不是同时开展的。所以,每一次大跌代的项目干系人牵扯较多,但是各自都有自己的任务在推进。
除了埋头写代码,研发同学还是要发挥自己"一不怕苦,二不要脸"的精神去主动争取资源,主动去"搭讪"。
一切只为充分实现接口和服务的联调,沟通的过程是曲折的,但是最终保证了联调的畅通。
结语我们都在奔跑,但是短暂地停下来思考,是为了更好地再出发。
管理者都喜欢对工作进行量化。
最近在思考,有没有一种方法对发版进行量化。哪些指标可以反映是高效的发版?
有没有一套智能的bug系统,自动分析和预判出项目发版上线的一些缺陷并生成上线预测报告。
这份报告可以将一些重大问题提前暴露出来,并对问题进行自动分级,给研发人员一个参考,从而将发版的关口前移。
这里笔者只根据个人多年的工作经验,一点点思考和分享,抛砖引玉,欢迎大家怕批评和斧正。
参考- 《一个输入框你要做一周？》
- 《任务管理》
- 《卓有成效的管理者》
