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

我们想象的那么乐观。

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

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

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

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

• 拉取镜像更新是一个每个开发人员必备的技能，为什么还有人是不会的？

• 有没有做相应的培训，或者培训了，是否每个人都能够理解？

• 听的时候理解了，实际操作的时候是不是还是不会？

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

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

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

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

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

• 客户的部门和人员的数据量级是多少？

• 是所有用户还是特定用户，如果特定用户，是否有什么特殊的权限的设置?

• 客户使用的浏览器是什么版本？

• 选人控件本身有没有什么特殊数据范围或权限的设置？

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

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

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

开发：不能重现，我怎么排查呢？

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

• 系统出现异常提示是有日志记录的，是否有对日志进行过初步的分析？

• 操作的数据中有没有特殊数据，比如附件、富文本等？

• 是否能收集到客户用的系统以及浏览器的版本？

• 是否能收集到客户的操作系统的方式？
  

（编辑：通化站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!