最近两会上都谈论到 996 的问题了，那我们实行 996 ，每个人每天都非常忙碌，是不是就效率很高呢？是不是很多时候都在做一些无价值的事情呢？是不是都在加着班写着 Bug 呢？我认为真相远没有我们想象的那么乐观。
春节后的几次公司会议上都在提「增效」，随着公司的发展，人数变多，各种成本也随之增高，所以通过各种方式来增效，才能有正向的发展。以目前我的观察来看，我觉得可以从两个方面入手： 沟通和抓住关键点 。
在《怎样提高开发效率》一文中主要说的是开发人员硬技能方面的提升，在上面提到的各种成本中，沟通成本是非常重要的一块，这属于软技能的范畴，也是最容易被忽视的。
沟通体现在很多个方面，这里主要想说下提问和 Bug 描述。
前不久，有项目团队同事在企业微信上问我：怎样拉取镜像来进行测试环境的更新？如果考虑到部门之间应该有良好的沟通的协作，我应该告诉他怎么操作，但为什么有这么低级的问题能被问出来，是一个值得思考的问题：
拉取镜像更新是一个每个开发人员必备的技能，为什么还有人是不会的？
有没有做相应的培训，或者培训了，是否每个人都能够理解？
听的时候理解了，实际操作的时候是不是还是不会？
所有有章可循的、都应该形成规范，进行培训、然后考核，保证不同的人按照文档进行操作能够得出相同的结果，如果有开发人员能主动去探究其中的原理并举一反三，那便是锦上添花了。
对于 Bug 描述经常会出现这样的场景：
实施人员：表单上的选人控件加载部门树很慢；
开发：经过一系列的代码检查、运行调试后回复，我本地很快啊；
开发人员时间花了，但并没有解决问题，在描述 Bug 的时候，需要有更详细的场景和上下文信息，比如：
客户的部门和人员的数据量级是多少？
是所有用户还是特定用户，如果特定用户，是否有什么特殊的权限的设置?
客户使用的浏览器是什么版本？
选人控件本身有没有什么特殊数据范围或权限的设置？
有了更多的信息，开发人员就能有针对性地进行排查，也能更容易解决问题。
Bug 只要能重现，处理起来还比较容易，当遇到偶发 Bug 的时候，更是要尽量提供足够的信息，但很多时候描述却是这样的：
实施人员：客户点击某某操作时，会出现系统异常，我们有时操作也会出现，但不是每次都出现；
开发：不能重现，我怎么排查呢？
实施人员在一线，离现场更近，能知道更多的信息，所以在出现问题时需要尽可能多地提供信息：
系统出现异常提示是有日志记录的，是否有对日志进行过初步的分析？
操作的数据中有没有特殊数据，比如附件、富文本等？
是否能收集到客户用的系统以及浏览器的版本？
是否能收集到客户的操作系统的方式？
如果每个一线实施人员都能够去收集一些有用信息，做下初步的分析，然后将整个过程形成文字内容提交给开发，相信会大大提升解决问题的效率。
至于收集哪些有用信息，怎样来做初步分析，随着慢慢地沉淀，也一样可以形成标准的文档和操作手册。
除了沟通，另一个能提高效率的地方就是在工作中能抓住关键点，根据二八法则，抓住 20% 的关键点就能解决 80% 的问题。
下面是最近团队中发生的两个个事情，正好说明了关键点的重要：
产品代码做重构优化，让开发人员按照思路写出类以及空方法，然后进行评审，但开发人员会比较容易关注细节，一动手就想着对象怎样映射，依赖注入应该怎么进行设置等等，浪费了时间；
让开发排查一个 Bug，我便开会去了，一个多小时回来询问情况，得知还没有解决，还在继续调试代码分析原因，最后发现是一个配置项没有添加导致。
第一件事情的关键点是代码的思路，而不是实现，开发人员和产品负责人的目标和思想需要一致，也就是华为管理哲学中所说的「力出一孔」，如果方向偏了，努力越多，错的越远。
第二件事情的关键点是遇到问题的思考，想清楚之后再动手做，最终的做可能是检查配置、寻求其他人员帮助、或者代码调试。而不是任何问题一上来就进行代码调试。
最后总结下：
1、沟通在工作和生活中无处不在，想想沟通的目的，多换位思考；
2、除了上面说的提问和 Bug 描述，还有代码注释、代码提交备注、技术规范文档等等都属于沟通；
3、方向一致、目标明确做起事来才能最高效；
4、多思考、总结、复盘才能慢慢积累经验，经验丰富了才更容易找到关键点。
希望本文能对您有所启发和帮助！
