一直都很喜欢《重来》系列，最近出了《重来3：跳出疯狂的忙碌》，第一时间在微信读书中阅读了，让我们印象比较深刻的就是「冷静」和「效率」，本文主要说说效率的问题。
书的作者是贾森·弗里德（Jason Fried）和戴维·海涅迈尔·汉森（David Heinemeier Hans-son），37signals 公司的创始人。他们推崇的一些理念和企业文化是很多国人所羡慕的,比如：
在很多人看来这些做法是不可思议的，即使是这样，这家公司从创业开始起就是持续赢利的。说明即便是远程办公，即便是不用 996 ，他们也能进行高效的协作和产出。这种高效是我们需要思考和学习的。
由于一些原因，一个项目几经周折，最后由产品团队来进行收尾，我也参与了部分代码的编写和一些遗留 Bug 的解决。当然也少不了加班加点，最近项目告一段落，思考下来，很有感触。
技术人的目标是要实现业务，所以要充分理解业务，再厉害的技术也是为了实现业务目标，否则就没有价值。理解业务才能做好规划和设计，才能以高效率的方式去编码，才能减少反复。
道理谁都明白，但一做起来，很容易只管技术细节，包括一些高级开发人员也是如此，最直观的体现就是：开发完功能，但不知道功能是干嘛用的。脱离了客户真实的使用场景去思考和验证，所有的点都完成了，面不一定是完成的。
我认为不管是哪个级别的开发人员，都应该对业务有深刻的理解，才能事半功倍。
没有哪个项目是不”急“的，越急越容易乱，越急越容易采用看起来很方便的方式去行事，因为梳理业务需要花时间、代码的架构设计需要花时间、前后端的规范定义需要花时间，最终就是钝刀子砍柴，又累又慢。
持续下去就会变成一种进退两难的境地，想重头进行梳理和调整，又怕”浪费“更多的时间，维持现状只会做更多的无用功。
所以，一旦发现有这种”急“的征兆，就一定要先冷静下来，做好规划和设计，再动手也不迟。很多时候”急“只是我们为自己偷懒找的一个借口而已，相比较分析、规划、设计、直接写代码是相对容易的事情。
开发人员通常都非常的自信，会很干脆的回答：问题搞定，绝对没有问题；这次真的没问题了。话音未落，测试就已经发现业务走不通或者其他的关联点又坏掉了。
代码写完就等于功能做完了，这是一个很大的误区，一种情况是业务不了解，不知道怎么验证；另一种情况是想着反正有测试，提交代码让测试进行验证。我对测试的理解是：
每个人都应该对最终结果负责，有责任和义务对自己的代码按照业务的角度去进行自测和验证。盲目以为快速提交代码就是效率高，殊不知，不停地反复，会造成多方资源的浪费，效率低下。
任何事情再怎么分解，都需要团队协作去完成，说团队的执行力不行，原因一定不是团队成员，而是团队 Leader ，目标是不是分解的很清楚，比如说：张三，你下楼去买点水果上来，只要张三有钱、能走路、知道水果摊在哪，就能去执行。所以，只要满足下面两点，就不存在执行力的问题：
目标清晰体现在双方的理解可以达成一致，所以需要尽可能的细化，越是宏观的，抽象的，不同的人理解就会不一样，理解不一致造成的反复是低效的一个很重要的原因，所以这一点非常重要。
有能力做到，需要 Leader 对成员有足够的了解，能够根据轻重缓急合理地分配任务。能让每个人既能胜任，又有所挑战，是一件挺难的事。
最后说说干扰，在《重来3》中也提到上班时反而没法完成工作，
问问人们在必须完成工作的时候会去哪儿，你极少能听到这个答案：办公室。没错。当你必须把工作做完的时候，你极少会去办公室。如果必须去的话，也是在清晨、深夜或周末的时候。只要>是没别人在的时候就行。而在这种时候，它甚至已经不算是“办公室”了，只是一个无人打扰的安>静空间。
常见的一些干扰：
曾经一段时间，我大部分的工作是下班后完成的，一天下来，回想一下，好像非常的忙，但又感觉什么事都没做。当然面对上面的一些干扰，也有一些解决方法：
作为一个技术人，要想办法去”偷懒“，正确地去”偷懒“，找到”偷懒“的途径和方法，这个过程是困难的，需要不断地思考、总结、实践，等真正学会了”偷懒“，也就高效了。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。