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