程序員是一個忙碌的職業，與這個職業聯系在一起的詞兒，通常是忙碌、加班、熬夜、過勞、亞健康……當忙碌成為了主旋律，“高效”一詞就自然浮出了水面。

可是，程序員工作效率是由編程能力決定的嗎？答案是“未必”。

這些年，我一直在研究一件事兒：為什么那些大師級程序員，可以兼顧 N 倍于一般人的工作，還有條不紊？他們究竟用了什么工作法？根據我的觀察與總結，他們往往繞不開下面四個工作原則。

以終為始

任務分解

溝通反饋

自動化一切

下面，就給大家先介紹前兩個工作原則。

以終為始DoD

DoD（Definition of Done，完成的定義），從名字便不難看出，它就是為了解決軟件開發中常見的“完成”問題而生的。DoD 本身并不復雜，它就是告訴我們怎樣算是完成了，盡量減少因為歧義造成的各種浪費。

既然 DoD 是一個彌補理解差異的做法，那么它就應該在人與人的協同工作中起作用。其中，最常見的做法是在團隊中確定好 DoD。比如：

特性開發完成，表示開發人員經過了需求澄清、功能設計、編寫代碼、單元測試，通過了測試人員的驗收，確保代碼處于一個可部署的狀態，相關文檔已經編寫完畢。

開發完成，表示開發人員編寫好功能代碼，編寫好單元測試代碼，編寫好集成測試代碼，測試可以通過，代碼通過了代碼風格檢查、測試覆蓋率檢查。

大家都是聰明人，一旦 DoD 確定好了，誰該做什么事就一目了然了。

DoD 是一個清單，清單是一個個的檢查項，用來檢查我們的工作完成情況。DoD 的檢查項，就是我們開發產品所需的一系列有價值的活動。比如：編寫代碼、編寫測試代碼、通過測試人員驗收等。

DoD 是團隊成員間彼此匯報的一種機制。別把“匯報”想復雜了，最簡單的匯報就是說一句“這個功能做完了”。當我們有了 DoD，做事便只有兩種狀態，即“做完”和“沒做完”，根本沒有 80% 做完的說法。

DoD 的檢查項應該是實際可檢查的：你說代碼寫好了，代碼在哪里；你說測試覆蓋率達標了，怎么看到；你說你功能做好了，演示一下。

在前面的討論中，我們所說的 DoD 只是從個人層面入手。在團隊層面，我們也可以定義 DoD，比如：

某個功能的 DoD，比如：這個功能特性已經開發完成，經過產品負責人的驗收，處于可部署的狀態。

一個迭代的 DoD，比如：這個迭代規劃的所有功能已經完成。

一次發布的 DoD，比如，整個軟件處于可發布狀態，上線計劃已經明確。

精益創業：驗證產品特性的思考框架

精益創業提出“開發（build）-測量（measure）-認知（learn）”這樣一個反饋循環和最小可行產品的概念。

當你有了一個新的想法（idea）時，就把想法開發成產品（code）投入市場，然后，收集數據（data）獲取反饋，看看前面的想法是不是靠譜。無非得到兩種結果：好想法繼續加強、不靠譜的想法丟掉算了。不管是哪種結果，你都會產生新的想法，再進入到下一個循環里。在這個反饋循環中，你所獲得的認知是最重要的，因為它是經過驗證的。

我們能夠接觸到的大多數產品都可以放在這個框架內思考。當產品經理要做一個新產品或是產品的一個新特性，我們就可以用精益創業的這幾個概念來檢驗一下產品經理是否想清楚。

比如，你要做這個產品特性，你要驗證的東西是什么呢？他要驗證的目標是否有數據可以度量呢？要解決的這個問題是不是當前最重要的事情，是否還有其他更重要的問題呢？如果這些問題得到肯定的答復，那么驗證這個目標是否有更簡單的解決方案，是不是一定要通過開發一個產品特性來實現。

任務分解馬斯克的任務分解

特斯拉的創始人伊隆·馬斯克（Elon Musk）同時還創建了太空探索公司 SpaceX。SpaceX 有一個目標是，送 100 萬人上火星。美國政府曾經算過一筆賬，把一個人送上火星，以現有技術是可行的，但需花費 100 億美金。如果送 100 萬人上火星就要 1 萬萬億，這筆錢相當于美國 500 年的 GDP，貴到連美國政府都無法負擔。

馬斯克怎么解決這個問題呢？他的第一步是準備把人均費用降到 50 萬美元，相當于一個人在地球上房子的錢。把原來的 100 億降到 50 萬，降低 2 萬倍即可。

當然，降低 2 萬倍依然是一個聽起來很遙遠的目標。關注點來了，馬斯克的第二步是，把 2 萬分解成“20×10×100”，這是一道簡單的數學題，也是馬斯克三個重點努力的方向。

“20”：現在的火星飛船一次只能坐 5 個人，馬斯克打算把火箭造大一點，一次坐 100 人，這樣，就等于把成本降低 20 倍。如果你關注新聞的話，SpaceX 確實在進行這方面的嘗試。

“10”：馬斯克認為自己是私營公司，效率高，成本可以降到 1/10。事實上，SpaceX 的成本目前已經降到了同行的 1/5。

最后的 100 是什么呢？就是回收可重復使用的火箭。如果這個目標能實現，發射火箭的成本就只有燃料成本，這也就是我們頻頻看到 SpaceX 試飛火箭新聞的原因。

這么算下來，你是不是覺得馬斯克的目標不像最開始聽到那樣不靠譜了呢？正是通過將宏大目標進行任務分解，馬斯克才能將一個看似不著邊際的目標向前推進。

微操作

在ThoughtWorks 工作時，我的 Sponsor 是 ThoughtWorks 現任 CEO 郭曉（Sponsor，類似于工廠里師傅帶徒弟的關系），他也是寫代碼出身的。他和我講過他和 Wiki 的發明者 Ward Cunningham 一起結對編程的場景。

Ward 每天拿到一個需求，并不急于寫代碼，而是和郭曉一起做任務分解，分解到每個任務都很清晰之后，一個個任務完成就好了。當時郭曉雖然覺得工作很緊張，但思路卻非常清晰。有時，他也很奇怪，因為在開始工作之前，他會覺得那個問題非常難以解決，結果一路分解下來，每一步都是清晰的，也沒遇到什么困難就完成了。

任務分解是個好習慣，但想要掌握好它，大量的練習是必須的。我自己也著實花不少時間進行練習。隨著我的練習增多，我越發理解任務分解的關鍵在于“小”。小到什么程度呢？有時甚至可以小到你認為這件事不值得成為一件獨立的事，比如，升級一個依賴的版本，做一次變量改名。這樣做好處就是，它保證了我可以隨時停下來。

我曾讀到過一個關于著名高爾夫球手“老虎”伍茲的故事。高爾夫球手在打球的時候，可能會受到一些外界干擾，一般情況下還好，如果他已經開始揮桿，這時候受到了干擾，一般選手肯定是繼續把桿揮下去，但通常結果是打得不理想。而伍茲遇到這種情況，他會停下來，重新做揮桿的動作，保證了每一桿的標準。

伍茲能停下來，固然是經過了大量的練習，但還有一個關鍵在于，對于別人而言，揮桿擊球是一個動作，必須一氣呵成，而對伍茲來說，這個動作是由若干小動作組成，他只不過是剛好完成了某個小動作，而沒有做下一個小動作而已。換句話說，大家同樣都是完成一個原子操作，只不過，伍茲的原子操作比其他人的原子操作小得多。

一個經過分解后的任務，需要關注的內容是有限的，我們就可以針對這個任務，把方方面面的細節想得更加清晰。很多人寫代碼之所以漏洞百出，一個重要的原因就是任務粒度太大。