頂尖開發人員的時間管理術

八小時其實非常短暫，只有480分鐘，28,800秒。身為專業開發人員，你肯定希望能在這短暫的時間裡盡可能高效率地工作，盡可能取得最多的成果。有什麼辦法能確保不浪費這寶貴的時間呢？怎樣才能有效地管理時間呢？

1986 年，我住在英格蘭薩里郡的小桑徹斯特，管理著Teradyne 在布拉科內爾的一支15人的開發團隊。每天，我都要忙於應付數不清的電話、臨時召開的會議、現場服務的問題以及各種干擾。為完成工作，我只能借助嚴格的時間管理原則。

● 我每天早上5 點起床，騎自行車上班，6 點可以到達布拉科內爾的辦公室。這樣，在一天的嘈雜開始之前，我有兩個半小時安靜的時間。

● 一到公司，我就擬定當天的計畫。以一刻鐘為單位，寫下這段時間要做的事情。

● 前3 個小時安排得滿滿的。從9 點開始，每小時都會留出15 分鐘的機動時間，這樣我就可以處理計畫之外最緊急的狀況，同時不會干擾到計畫內的工作。

● 午飯之後的時間沒有安排，因為我知道那時候工作節奏並不快，我也得靜心準備下午的工作。午後的這段時間難得沒有任何干擾，我會安心做最重要的事情，直到突發情況出現。

這種計畫也有不奏效的時候。每天早上5 點起床並不容易，有時突發事件需要一整天來處理，所以打亂了我的周密計畫。但大多數時候，即便工作堆積如山，我還是游刃有餘。

會議
會議的成本是每人每小時200 美元。這個數字包含了工資、福利、設備損耗等因素。下次開會的時候，不妨算算會議的成本，你會很吃驚的。

關於會議，有兩條真理：
1. 會議是必需的；
2. 會議浪費了大量的時間。

通常，這兩條真理同時適用於同一場會議。有些與會者認為這兩條總結得非常好，有些則認為它們是正確的廢話。

專業開發人員同樣清楚會議的高昂成本，他們同樣清楚自己的時間是寶貴的，他們同樣需要時間來寫程式，來處理日程表上的事務。所以，如果會議沒有立竿見影及顯著的成效，他們會主動拒絕。

立會
敏捷開發的武器庫中包含『立會（站著開會）』：在開會時，所有與會者都必須站著。

到場的人依次回答以下3 個問題：
1. 我昨天做了什麼？
2. 我今天打算做什麼？
3. 我遇到了什麼問題？

這就是全部的會議內容。每個問題的回答時間不應當超過20 秒，所以每個人的發言不超過1 分鐘。即便是10 個人的小組，開一次這種會議的時間也不會超過10 分鐘。Iteration 計畫會議

在敏捷開發的武器庫中，這大概是難度最高的會議了。如果做得不好，可能浪費大量的時間。開好這種會議需要技巧，這些技巧非常值得學習。

計畫會議用來選擇在下一輪的iteration 中要實現的開發任務。在會議召開前必須完成兩項任務：『評估可選擇任務的開發時間』及『確定這些任務的業務價值』。如果組織得宜，驗收／元件測試也應當在會議召開前完成，或者至少有個概略方案。

會議的節奏應該很快，簡明扼要地討論各個候選任務，然後決定要選擇還是放棄某項任務。會議在每個任務上所花的時間應該限制在5 到10 分鐘。如果需要更詳細的討論，則應當另選時間，挑出團隊中的一部分人專門進行討論。

照我的經驗，在每輪的iteration 中，這類會議所花的時間不應當超過5%。如果一周（40小時）為一個iteration 週期，這類會議的時間應當限制在2 小時之內。

Iteration 回顧和Demo 展示
這類會議在iteration 的末尾召開。團隊成員討論本輪的iteration 中什麼做得對，什麼做得不對。業務方可以看到最新工作成果的demo。如果組織不當，這類會議可能會浪費很多時間，所以不妨在最後一天下班前45 分鐘召開。花20 分鐘來回顧，花25 分鐘來展示。請記住，這類會議只牽涉到最近一兩周的工作，所以沒有太多內容要討論。

爭論／反對
Kent Beck 曾告訴我一個深刻的道理：「凡是不能在5 分鐘內解決的爭論，都不能靠辯論解決。」這類爭論之所以要花這麼多時間，是因為各方都拿不出『足夠有力的證據』來支持己見。所以這類爭論依據的不是『事實』，而是『信念』。

技術爭論很容易走入極端。每一方都有各種說法來支持自己的觀點，只是缺乏資料。在沒有資料的情況下，如果觀點無法在短時間（5～30 分鐘）內達成一致，就永遠無法達成一致。唯一的解決方法是『去取得資料，讓資料來說話』。

有人會試著借助個人能力贏得爭論。他們可能會提高嗓門，近距離與你對視，或者擺出不屑的姿態。但這都不重要，長期來看，強迫是無法解決爭論的，最終還是需要資料。

有人會表現得非常被動。他們同意結束爭論，之後卻消極對待結果，拒絕為解決問題出一份力。他們會安慰自己說：「既然其他人想要這麼做，就這麼做吧。」這可能是非專業的行為中最糟糕的了。千萬千萬不要這樣做。如果你同意了，就必須拿出行動來。

該怎麼得到解決問題所需要的資料呢？有時候可以做一些實驗，也可以做些模擬或是建立模型。但是有時候，最好的辦法是拋硬幣來決定到底該如何選擇。

如果問題解決了，這個選擇就是對的。如果遇到了麻煩，你可以退回來選擇另一條路。明智的做法是，選定一個時間點或者設定一系列標準，來決定什麼時候該放棄。

要小心這類型的會議：它們的目的只是發洩情緒，或者讓大家選邊站。如果會議上只有一面之辭，就要避免參加。

如果爭論必須解決，就應當要求爭論各方在5 分鐘內向大家表明問題，然後大家投票。這樣，整個會議花的時間不會超過15 分鐘。

專注力Manna
如果你從本節中察覺到一些新時代形而上學或者Dungeons & Dragons（龍與地下城）的色彩，請一定要原諒我。我只是在這個主題之上，表達出我的想法而已。

程式設計是需要持續投入精力和專注力的智力活動。專注力是稀有的資源，它類似manna（本書之後會將manna 翻譯為『點數』）。如果你用光了自己的專注力點數，必須花一個小時或更多的時間做不需要專注力的事情，來補充它。

我不知道該怎麼描述專注力點數，但是我感覺它是有形（或許無形）的，並能影響專注力的集中和發散。無論如何，你肯定可以察覺到專注力點數的存在，也同樣可以感覺它是否已耗盡。專業開發人員會學習安排時間，妥善使用自己的專注力點數。我們選擇專注力點數充裕的時候進行程式設計，在專注力點數匱乏時做其他事情。

專注力點數也會隨時間流逝而減少。如果不及時使用，它就會消失（無法存下來）。會議之所以具有巨大的破壞力，原因之一就在於此。如果你所有的專注力點數都用在了會議之上，進行程式設計時就大腦空空了。

憂慮和分神也會消耗專注力點數。昨天晚上的夫妻吵架，今天早上的汽車刮痕，上周忘記付款的帳單，都會迅速耗光你的專注力點數。

睡眠
睡眠的重要性怎麼強調都不為過。美美的一覺醒來，我的專注力點數是最充裕的。好好睡上7 小時，我就有足夠的專注力點數去做好8 小時的工作。專業開發人員會安排好他們的睡眠，保證清晨有飽滿的專注力點數去上班。

咖啡因
毋庸置疑，對某些人來說，適量的咖啡因可以幫他們更有效地使用專注力點數。但是請小心，咖啡因也會給你的專注力找麻煩。太多的咖啡因會把你的專注力偏轉到奇怪的方向。太濃的咖啡會搞得你一整天都沉溺於不重要的事情。

咖啡因的用量和接受程度因人而異。我個人的做法是，早上一杯濃咖啡，中午一罐無糖可樂。有時候會加倍，但通常這就是上限了。

恢復
在你不集中專注力的時候，專注力點數可以緩慢恢復。漫步一段長路，與朋友聊天，看看窗外，都有助於恢復專注力點數。

有些人選擇沉思、反省，也有些人選擇小睡一會兒，還有人選擇聽podcast 或翻翻雜誌。

我發現，一旦專注力點數耗盡，你就無法控制專注力。你仍然可以寫程式，但是多半寫出來的程式需要在第二天重寫，或者在幾周或幾個月之後備受這段程式碼的煎熬。所以，更好的辦法還是花30～60 分鐘來換換腦子。

肌肉專注力
搏擊、太極、瑜伽之類的體力活動使用的專注力是不同的。即便需要全神貫注，這種專注力也不同於程式設計時所需要的專注力，因為它們需要的是肌肉的專注力，而程式設計需要的是心智的專注力。不過，肌肉專注力有助於改善心智專注力，而且不僅僅是簡單的恢復。我發現，定期訓練肌肉專注力，可以提升心智專注力的上限。

我訓練肌肉專注力的辦法是騎腳踏車。我會騎1～2 小時，大約20～30 英里。我通常沿著德斯普蘭斯（Des Plaines）河邊的小路一直騎，這樣就不用擔心撞到汽車。

有些人選擇『做手工』來訓練，比如做木工、製作模型、清理花園。無論做哪樣的選擇，這類活動都要動用肌肉專注力，繼而提升心智專注力。

輸入與輸出
關於專注力，我知道的另一個重點是平衡輸入與輸出。程式設計是一項展現創意的活動。我發現，如果能接觸到其他人的創意，我的創意也最旺盛，所以我閱讀『大量的科幻小說』。這些作者的創意會激發我對軟體的創意。

時間拆分和番茄工作法
我用來管理時間的有效辦法之一，是使用眾所皆知的番茄工作法（pomodorotechnique.com）。其基本思想很簡單：

把廚房用的計時器（通常它的形狀很像番茄）設定到25 分鐘。倒數計時期間不要讓任何事情干擾你的工作。如果電話響了，接起來並禮貌告訴對方，請在25 分鐘之後再打來；如果有人來打斷你問問題，禮貌地問他是否能過25 分鐘再來問。無論什麼干擾，都必須等到25 分鐘結束後再處理。畢竟，幾乎沒有事情會緊急到25 分鐘都等不了。

計時器響起時，立刻停下手上的工作，轉去處理這25 分鐘內遇到的其他事情。之後休息5 分鐘左右。然後，再把計時器設定為25 分鐘，開始一個新的番茄時間段。每完成4 個番茄時間段，就休息30 分鐘左右。

論述這個技巧的資料有很多，我建議你去讀一讀。不過，看過上面的描述你應該明白它的要點：使用這個技巧，你的時間可以分為番茄時間和非番茄時間。番茄時間是有生產效率的，你可以真正做點事情。用於應付干擾、參加會議、休息等非工作事宜的時間，則屬於非番茄時間。

一天中你有幾個番茄時間段？在不錯的情況下，你可以有12 到14 個番茄時間段，糟糕的情況下可能只有2 到3 個。如果你把情況記錄下來並且畫圖表示，就可以很清楚地知道，每天有多少時間是有效率的，有多少時間是花在雜事上的。

有些人覺得這個辦法相當受用。他們用番茄時間段為單位，估計工作量，然後計算與測量每週的『番茄速度』。但這只是錦上添花。番茄工作法的真正好處在於，在25 分鐘的高效率工作時間段裡，你有勇氣和力量去拒絕任何干擾。

要避免的行為
有時候你工作時會心不在焉。很可能是因為要做的事情讓人恐慌、難受，或者厭煩。你可能會認為，工作是你被迫面對的，自己無從脫身。或者，你根本就不喜歡這份工作。

優先順序錯亂
無論什麼原因，我們都可以找到辦法逃避真正的工作。你說服自己有些工作更緊急，所以轉而去處理，這種行為叫做優先順序錯亂──提高某項任務的優先順序，之後就有藉口延後真正急迫的任務。優先順序錯亂是自我麻醉的謊言，因為不能面對真正需要做的事情，所以我們告訴自己，其他事情更重要。我們知道這不是真的，但還用它來欺騙自己。

其實這不是在欺騙自己：我們真正做的是準備謊言──如果有人問自己在做什麼事情，為什麼這麼做，我們就會擺出這些謊言。我們是在為他人對自己的判斷尋找理由和藉口。顯然，這不是專業的行為，專業開發人員會評估每項任務的優先順序，排除個人的喜好和需要，按照真實的緊急程度來執行任務。

死胡同（Blind Alleys）
所有的軟體工匠都會遇到死胡同。比如你做了決定，選擇了一條走不通的技術道路。你對這個決定越堅持，浪費的時間就越多。如果你認為這關係到自己的專業信譽，就永遠也走不出來。

慎重的態度和累積的經驗可以幫助你避開某些死胡同，但是沒辦法完全避免。所以你真正需要的是，在走入死胡同時可以迅速意識到，並有足夠的勇氣走回頭路。這就是所謂的坑法則（The Rule of Holes）：如果你掉進了坑裡，別挖。

專業開發人員不會執著於不容放棄也無法繞開的idea。他們會保持開放的頭腦來聽取其他意見，所以即便走到盡頭，他們仍然有其他選擇。

泥潭
比死胡同更糟的是泥潭。泥潭會減緩你的速度，但不會讓你徹底停下來。泥潭會阻礙你前進，但如果使盡全力，你仍然可以取得進展。泥潭之所以比死胡同更麻煩，是因為在泥潭中，你仍然可以看到前進的道路，而且看起來總是比走回頭路更短（雖然實際上不是這樣）。

我曾經看過產品因為陷入泥潭而報廢，公司因為陷入泥潭而破產。我也看過原本小步快跑的團隊，在幾個月內被泥潭搞到步履蹣跚。除了泥潭，沒有其他任何東西能夠對開發團隊的效率產生如此深遠且長期的負面影響，絕沒有。

真正的問題在於，泥潭和死胡同一樣是無可避免的。慎重的態度和累積的經驗有助於避開泥潭，但無法徹底避開每一處泥潭。

在泥潭中繼續前進的危害是不易察覺的。面對簡單問題，你給出解決方案，保持程式碼的簡單、整潔。之後問題不斷擴展，越來越複雜，你仍在擴展程式碼庫（code base），盡可能保持整潔。某天，你發現自己從一開始就做了錯誤的選擇，在需求變化的方向上，程式跟不上變化的腳步。

這就是轉捩點！你可以回頭修正設計，也可以繼續走下去。走回頭路看起來代價很高，因為要把已有的程式碼推翻重來，但是走回頭路絕對是最簡單的方法。如果繼續前進，系統就可能陷入泥潭，永遠不得脫身。

專業開發人員對於泥潭的恐懼遠遠大於死胡同。他們無時不刻留意著顯露出來的泥潭，然後運用各種努力，儘早儘快地脫身。

發現自己身處泥潭還要固執前進，是最嚴重的優先順序錯亂。繼續前進無異於欺騙自己，欺騙團隊，欺騙公司，欺騙客戶。你一邊走向大家共同的煉獄，一邊告訴其他人，所有問題都會獲得解決。

結論
專業開發人員會用心管理自己的時間和專注力。他們知道優先順序錯亂的誘惑，他們也珍惜重視自己的聲譽，所以會抵制優先順序錯亂。他們永遠有多種選擇，永遠敞開心扉聽取其他解決方案，他們從來不會執著於某個無法放棄的解決方案。他們也不斷警惕著正在顯露的泥潭，一旦看清楚，就會避開。最糟糕的事情，莫過於看到一群開發人員在徒勞地拼力工作，結果卻陷入越來越深的泥潭。（摘錄整理自第九章）

---

延 伸 閱 讀

無瑕的程式碼──敏捷軟體開發技巧守則（Clean Code）

---

無瑕的程式碼番外篇──專業程式設計師的生存之道
（The Clean Coder）
Robert C. Martin／著；博碩文化／編譯；陳錦輝／審校
博碩文化出版
售價：360元

作者簡介：Robert C Martin

Robert C. Martin，人稱Uncle Bob，早在1970年，他就已經是一位程式設計師。他目前是他所創辦的Object Mentor公司的總裁，這是一間跨國性的顧問公司，透過在軟體開發與管理方面，具有豐富經驗的顧問們，幫助企業完成他們的專案。Object Mentor提供全球各大企業各種服務，包括流程改良諮詢、物件導向軟體設計諮詢、訓練以及技能發展等。
Martin在各種期刊上已發表過數十篇與各種行業有關的文章。他也是國際會議常見的演講者與商業產品展示的行家。
身為一位軟體開發企業的領導者，Martin曾擔任C++ Report 三年的總編輯，並且也是Agile 聯盟的第一任主席。
Robert 也是Uncle Bob Consulting 公司的創辦人，並且與他的兒子Micah Martin 合組了一間The Clean Coders公司。