我们从不缺流程和措施

最近部门内要做研讨,针对项目交付压力大,加班比较严重的问题。个人思前想后,有感而发整理一下思绪,记录如下。

做个类比,当前的情况就好比抗日初期。抗日初期国内充斥着速胜论和速亡论,作为对比就类似于”有措施立竿见影,迅速登上人巅峰”,”怎么弄都是瞎折腾,大不了挪个窝”的想法。但教员说抗日是持久战,我们的情况也是类似的,冰封三尺非一曰之寒,也是持久战。

论持久战,讲究战略/战术。

在战术上只能先保住基本盘,我们定义的基本盘不是交付进度,而是交付质量。抓核心交付件质量,无非首要就是代码质量,这里只谈需求-开发-测试中整套基本流程中的开发环节,开发人员从开发实现,到最终交付,正常是有两道坎的,一道是MR合并评审,一道是线下代码评审。线下代码评审,其实更多是整体上看需求实现,更偏流程的后期,很多时候对小问题能不改就不改,作用是有的,但不利于培养好的开发习惯,而且很多项目做得不到位(要和谐)或根本不做(反正跳过也能发布)。而关于MR合并评审,从公司平台上披露的统计信息看到,效果是无限趋向于零的。

这种情况,合理的解释是: 代码特别紧急(你不合并系统就要跪) 或者 人人都是开发者(我的代码就是BUG FREE) 。这涉及到两个方面,速度与激(质)情(量)。从经验角度看,代码晚两天合并也没问题,急于合并主要是因为测试驱动开发,后面可预见的修改还不少。至于质量嘛,人总会犯错的,人人都是开发者没错,但不是”人人都是合格的开发者”。

那为什么还是这样,还是要回到能力和意愿两个维度看,评审人员除了要有代码欣赏能力,也要有意愿(其实是坚持底线)。所以我们的建议是:

1.代码评审。审视各个项目的代码合入情况,对合入进行抽查。如果是不具备代码评审能力,可以进行专门培训、结对训练。如果是过于随意,考虑取消合入权限。

交付上线或多或少会遇到一些问题,特别当前项目战线长,交付频率高的情况,遇到问题怎么快速定位是关键,而且我们能依靠的手段主要是日志,日志打不打,怎么打是有规范的,所以关注点是有没有落到项目去。所以建议是:

2.应用日志 。项目可以用上日志平台的,要上日志平台、服务调用链。各项目需要自证符合日志规范,不符合的要进行修改。

回到战略,我们是谋求长治久安,还是得回到人身上。员工的期望的是:人来了能学到东西持续成长。项目的期望是:人跑了能留下东西造福后人。 所以这东西,靠人也不靠人,一方面需要靠人去完成项目,一方面要靠培训机制、知识管理来减少对人的依赖。所以建议是:

3.培训计划。以教促学,去年有开展,可以持续收集开展。有些同事觉得分享的内容有一定的项目局限性,所以没有太强的意愿参与,可以根据受众不同(有些内容针对个别项目,可以提高参与度)来优化。

4.知识管理**。当前有部分项目是集中后补的,这个要落到项目日常管理动作中去。可能PM要关心一下知识管理的周期性进展,落到开发组长,可能就更细致一下,例如小到某个配置,某个问题后要及时总结。对好的知识管理也要宣传,我个人就对当前每周的知识管理推荐就不大满意。

惭愧,回头来看,好像什么都是老生常谈。以前就有相关的要求呀,能不能来点干货? 干货是拿不出来了,因为我们从不缺流程和措施。