為什么這么忙，還依然做不好事情？-有解無憂

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

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

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

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

業務的理解

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

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

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

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

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

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

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

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

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

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

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

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

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

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

常見的一些干擾：

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

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

轉載請註明出處，本文鏈接：https://www.uj5u.com/gongcheng/228895.html

標籤：其他