发布于 

关于增效,需要做好这两点

最近两会上都谈论到 996 的问题了,那我们实行 996 ,每个人每天都非常忙碌,是不是就效率很高呢?是不是很多时候都在做一些无价值的事情呢?是不是都在加着班写着 Bug 呢?我认为真相远没有我们想象的那么乐观。

春节后的几次公司会议上都在提「增效」,随着公司的发展,人数变多,各种成本也随之增高,所以通过各种方式来增效,才能有正向的发展。以目前我的观察来看,我觉得可以从两个方面入手:沟通和抓住关键点。

在《怎样提高开发效率》一文中主要说的是开发人员硬技能方面的提升,在上面提到的各种成本中,沟通成本是非常重要的一块,这属于软技能的范畴,也是最容易被忽视的。

沟通体现在很多个方面,这里主要想说下提问和 Bug 描述。

前不久,有项目团队同事在企业微信上问我:怎样拉取镜像来进行测试环境的更新?如果考虑到部门之间应该有良好的沟通的协作,我应该告诉他怎么操作,但为什么有这么低级的问题能被问出来,是一个值得思考的问题:

  • 拉取镜像更新是一个每个开发人员必备的技能,为什么还有人是不会的?
  • 有没有做相应的培训,或者培训了,是否每个人都能够理解?
  • 听的时候理解了,实际操作的时候是不是还是不会?

所有有章可循的、都应该形成规范,进行培训、然后考核,保证不同的人按照文档进行操作能够得出相同的结果,如果有开发人员能主动去探究其中的原理并举一反三,那便是锦上添花了。

对于 Bug 描述经常会出现这样的场景:

实施人员:表单上的选人控件加载部门树很慢;

开发:经过一系列的代码检查、运行调试后回复,我本地很快啊;

开发人员时间花了,但并没有解决问题,在描述 Bug 的时候,需要有更详细的场景和上下文信息,比如:

  • 客户的部门和人员的数据量级是多少?
  • 是所有用户还是特定用户,如果特定用户,是否有什么特殊的权限的设置?
  • 客户使用的浏览器是什么版本?
  • 选人控件本身有没有什么特殊数据范围或权限的设置?

有了更多的信息,开发人员就能有针对性地进行排查,也能更容易解决问题。

Bug 只要能重现,处理起来还比较容易,当遇到偶发 Bug 的时候,更是要尽量提供足够的信息,但很多时候描述却是这样的:

实施人员:客户点击某某操作时,会出现系统异常,我们有时操作也会出现,但不是每次都出现;

开发:不能重现,我怎么排查呢?

实施人员在一线,离现场更近,能知道更多的信息,所以在出现问题时需要尽可能多地提供信息:

  • 系统出现异常提示是有日志记录的,是否有对日志进行过初步的分析?
  • 操作的数据中有没有特殊数据,比如附件、富文本等?
  • 是否能收集到客户用的系统以及浏览器的版本?
  • 是否能收集到客户的操作系统的方式?

如果每个一线实施人员都能够去收集一些有用信息,做下初步的分析,然后将整个过程形成文字内容提交给开发,相信会大大提升解决问题的效率。

至于收集哪些有用信息,怎样来做初步分析,随着慢慢地沉淀,也一样可以形成标准的文档和操作手册。

除了沟通,另一个能提高效率的地方就是在工作中能抓住关键点,根据二八法则,抓住 20% 的关键点就能解决 80% 的问题。

下面是最近团队中发生的两个个事情,正好说明了关键点的重要:

  • 产品代码做重构优化,让开发人员按照思路写出类以及空方法,然后进行评审,但开发人员会比较容易关注细节,一动手就想着对象怎样映射,依赖注入应该怎么进行设置等等,浪费了时间;
  • 让开发排查一个 Bug,我便开会去了,一个多小时回来询问情况,得知还没有解决,还在继续调试代码分析原因,最后发现是一个配置项没有添加导致。

第一件事情的关键点是代码的思路,而不是实现,开发人员和产品负责人的目标和思想需要一致,也就是华为管理哲学中所说的「力出一孔」,如果方向偏了,努力越多,错的越远。

第二件事情的关键点是遇到问题的思考,想清楚之后再动手做,最终的做可能是检查配置、寻求其他人员帮助、或者代码调试。而不是任何问题一上来就进行代码调试。

最后总结下:

1、沟通在工作和生活中无处不在,想想沟通的目的,多换位思考;

2、除了上面说的提问和 Bug 描述,还有代码注释、代码提交备注、技术规范文档等等都属于沟通;

3、方向一致、目标明确做起事来才能最高效;

4、多思考、总结、复盘才能慢慢积累经验,经验丰富了才更容易找到关键点。

希望本文能对您有所启发和帮助!