你好，我是鄭曄，《10x程序員工作法》專欄作者，火幣網首席架構師。
程序員是一個忙碌的職業，與這個職業聯繫在一起的詞兒，通常是忙碌、加班、熬夜、過勞、亞健康……當忙碌成爲了主旋律，“高效”一詞就自然浮出了水面。
可是，程序員工作效率是由編程能力決定的嗎？答案是“未必”。
這些年，我一直在研究一件事兒：爲什麼那些大師級程序員，可以兼顧 N 倍於一般人的工作，還有條不紊？他們究竟用了什麼工作法？根據我的觀察與總結，他們往往繞不開下面四個工作原則。
- 以終爲始
- 任務分解
- 溝通反饋
- 自動化一切
以終爲始
DoD
DoD（Definition of Done，完成的定義），從名字便不難看出，它就是爲了解決軟件開發中常見的“完成”問題而生的。DoD 本身並不複雜，它就是告訴我們怎樣算是完成了，儘量減少因爲歧義造成的各種浪費。
既然 DoD 是一個彌補理解差異的做法，那麼它就應該在人與人的協同工作中起作用。其中，最常見的做法是在團隊中確定好 DoD。比如：
特性開發完成，表示開發人員經過了需求澄清、功能設計、編寫代碼、單元測試，通過了測試人員的驗收，確保代碼處於一個可部署的狀態，相關文檔已經編寫完畢。
開發完成，表示開發人員編寫好功能代碼，編寫好單元測試代碼，編寫好集成測試代碼，測試可以通過，代碼通過了代碼風格檢查、測試覆蓋率檢查。
大家都是聰明人，一旦 DoD 確定好了，誰該做什麼事就一目瞭然了。
- DoD 是一個清單，清單是一個個的檢查項，用來檢查我們的工作完成情況。DoD 的檢查項，就是我們開發產品所需的一系列有價值的活動。比如：編寫代碼、編寫測試代碼、通過測試人員驗收等。
- DoD 是團隊成員間彼此彙報的一種機制。別把“彙報”想複雜了，最簡單的彙報就是說一句“這個功能做完了”。當我們有了 DoD，做事便只有兩種狀態，即“做完”和“沒做完”，根本沒有80%做完的說法。
- DoD 的檢查項應該是實際可檢查的：你說代碼寫好了，代碼在哪裏；你說測試覆蓋率達標了，怎麼看到；你說你功能做好了，演示一下。
在前面的討論中，我們所說的 DoD 只是從個人層面入手。在團隊層面，我們也可以定義 DoD，比如：
- 某個功能的 DoD，比如：這個功能特性已經開發完成，經過產品負責人的驗收，處於可部署的狀態。
- 一個迭代的 DoD，比如：這個迭代規劃的所有功能已經完成。
- 一次發佈的 DoD，比如，整個軟件處於可發佈狀態，上線計劃已經明確。
出自第03講|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 每天拿到一個需求，並不急於寫代碼，而是和郭曉一起做任務分解，分解到每個任務都很清晰之後，一個個任務完成就好了。當時郭曉雖然覺得工作很緊張，但思路卻非常清晰。有時，他也很奇怪，因爲在開始工作之前，他會覺得那個問題非常難以解決，結果一路分解下來，每一步都是清晰的，也沒遇到什麼困難就完成了。
任務分解是個好習慣，但想要掌握好它，大量的練習是必須的。我自己也着實花不少時間進行練習。隨着我的練習增多，我越發理解任務分解的關鍵在於“小”。小到什麼程度呢？有時甚至可以小到你認爲這件事不值得成爲一件獨立的事，比如，升級一個依賴的版本，做一次變量改名。這樣做好處就是，它保證了我可以隨時停下來。
我曾讀到過一個關於著名高爾夫球手“老虎”伍茲的故事。高爾夫球手在打球的時候，可能會受到一些外界干擾，一般情況下還好，如果他已經開始揮杆，這時候受到了干擾，一般選手肯定是繼續把杆揮下去，但通常結果是打得不理想。而伍茲遇到這種情況，他會停下來，重新做揮杆的動作，保證了每一杆的標準。
伍茲能停下來，固然是經過了大量的練習，但還有一個關鍵在於，對於別人而言，揮杆擊球是一個動作，必須一氣呵成，而對伍茲來說，這個動作是由若干小動作組成，他只不過是剛好完成了某個小動作，而沒有做下一個小動作而已。換句話說，大家同樣都是完成一個原子操作，只不過，伍茲的原子操作比其他人的原子操作小得多。
一個經過分解後的任務，需要關注的內容是有限的，我們就可以針對這個任務，把方方面面的細節想得更加清晰。很多人寫代碼之所以漏洞百出，一個重要的原因就是任務粒度太大。