爲什麼這麼忙，還依然做不好事情？

一直都很喜歡《重來》系列，最近出了《重來3：跳出瘋狂的忙碌》，第一時間在微信讀書中閱讀了，讓我們印象比較深刻的就是「冷靜」和「效率」，本文主要說說效率的問題。

書的作者是賈森·弗裏德（Jason Fried）和戴維·海涅邁爾·漢森（David Heinemeier Hans-son），37signals 公司的創始人。他們推崇的一些理念和企業文化是很多國人所羨慕的,比如：

在很多人看來這些做法是不可思議的，即使是這樣，這家公司從創業開始起就是持續贏利的。說明即便是遠程辦公，即便是不用 996 ，他們也能進行高效的協作和產出。這種高效是我們需要思考和學習的。

由於一些原因，一個項目幾經周折，最後由產品團隊來進行收尾，我也參與了部分代碼的編寫和一些遺留 Bug 的解決。當然也少不了加班加點，最近項目告一段落，思考下來，很有感觸。

業務的理解

技術人的目標是要實現業務，所以要充分理解業務，再厲害的技術也是爲了實現業務目標，否則就沒有價值。理解業務才能做好規劃和設計，才能以高效率的方式去編碼，才能減少反覆。

道理誰都明白，但一做起來，很容易只管技術細節，包括一些高級開發人員也是如此，最直觀的體現就是：開發完功能，但不知道功能是幹嘛用的。脫離了客戶真實的使用場景去思考和驗證，所有的點都完成了，面不一定是完成的。

我認爲不管是哪個級別的開發人員，都應該對業務有深刻的理解，才能事半功倍。

沒有哪個項目是不”急“的，越急越容易亂，越急越容易採用看起來很方便的方式去行事，因爲梳理業務需要花時間、代碼的架構設計需要花時間、前後端的規範定義需要花時間，最終就是鈍刀子砍柴，又累又慢。

持續下去就會變成一種進退兩難的境地，想重頭進行梳理和調整，又怕”浪費“更多的時間，維持現狀只會做更多的無用功。

所以，一旦發現有這種”急“的徵兆，就一定要先冷靜下來，做好規劃和設計，再動手也不遲。很多時候”急“只是我們爲自己偷懶找的一個藉口而已，相比較分析、規劃、設計、直接寫代碼是相對容易的事情。

開發人員通常都非常的自信，會很乾脆的回答：問題搞定，絕對沒有問題；這次真的沒問題了。話音未落，測試就已經發現業務走不通或者其他的關聯點又壞掉了。

代碼寫完就等於功能做完了，這是一個很大的誤區，一種情況是業務不瞭解，不知道怎麼驗證；另一種情況是想着反正有測試，提交代碼讓測試進行驗證。我對測試的理解是：

每個人都應該對最終結果負責，有責任和義務對自己的代碼按照業務的角度去進行自測和驗證。盲目以爲快速提交代碼就是效率高，殊不知，不停地反覆，會造成多方資源的浪費，效率低下。

任何事情再怎麼分解，都需要團隊協作去完成，說團隊的執行力不行，原因一定不是團隊成員，而是團隊 Leader ，目標是不是分解的很清楚，比如說：張三，你下樓去買點水果上來，只要張三有錢、能走路、知道水果攤在哪，就能去執行。所以，只要滿足下面兩點，就不存在執行力的問題：

目標清晰體現在雙方的理解可以達成一致，所以需要儘可能的細化，越是宏觀的，抽象的，不同的人理解就會不一樣，理解不一致造成的反覆是低效的一個很重要的原因，所以這一點非常重要。

有能力做到，需要 Leader 對成員有足夠的瞭解，能夠根據輕重緩急合理地分配任務。能讓每個人既能勝任，又有所挑戰，是一件挺難的事。

最後說說干擾，在《重來3》中也提到上班時反而沒法完成工作，

問問人們在必須完成工作的時候會去哪兒，你極少能聽到這個答案：辦公室。沒錯。當你必須把工作做完的時候，你極少會去辦公室。如果必須去的話，也是在清晨、深夜或週末的時候。只要>是沒別人在的時候就行。而在這種時候，它甚至已經不算是“辦公室”了，只是一個無人打擾的安>靜空間。

常見的一些干擾：

曾經一段時間，我大部分的工作是下班後完成的，一天下來，回想一下，好像非常的忙，但又感覺什麼事都沒做。當然面對上面的一些干擾，也有一些解決方法：

作爲一個技術人，要想辦法去”偷懶“，正確地去”偷懶“，找到”偷懶“的途徑和方法，這個過程是困難的，需要不斷地思考、總結、實踐，等真正學會了”偷懶“，也就高效了。