格子人生
很久未更新日誌了，真是忙碌的一年。具體的更新就不寫在這一篇里了，長話短說是：我很好。
長久以來，我就有病，很多病，強迫症是之一，尤其對於時間管理。在聽說「人生只有900個月，一張A4紙就能打印出來」之後，病得更重了。所以我一直尋求一些方法去靈活地、有效地規劃（Hack）自己的人生，讓更多有意思的事情發生在這30＊30的表格里。曾經做了一個僅供自己使用的時間跟蹤系統來分析自己的時間都花到哪裡了，由於代碼寫得很hacky，使用也太geeky（其實我就是懶得寫文檔），就沒有開源。如果有興趣的朋友可以去試試「RescueTime」，我是受到它的啟發做的，當然我做的就比較粗陋，功能性上比它多了一個強制加鎖，即，在一段時限內不能訪問黑名單內的網站。這是幾年前的故事。
之後的幾年，我接觸到了一些提高效率的「方法論」，當中包括 David Allen 的 「GTD」，以及Francesco Cirillo 的「番茄時間法」，當然還有一些未成大氣候的方法論，比如「Gamification」。也對他們進行了嘗試和研究。可是我並不是很喜歡當中的任何一個。
於是，我終於啟動了一個想了很久卻沒動作的項目，暫時定名為「OrgLife」，這個項目并不簡單，因為不僅僅是寫寫程序而已，我想要研究出一個對我來說切實可行的方法。而且即便是寫寫程序而已，我還要學好多東西才能做個稍微像樣點、不擋道的工具，我可不想再做個很buggy的工具湊合用，畢竟在用工具提高效率的時候，如果工具不好使降低了效率會讓人很沮喪。在這裡，我特指要學前端開發。雖然大學時代創業時包攬過從前端到後端的活兒，但前端是個非常活躍、日新月異的技術集，三四年沒碰的話就已經是老化的知識了……
剛剛我強調了我要找個對我管用的辦法，因為我不知道這個方法是否普世，但是有我這個時間管理強迫症的人還挺多的，昨天在看 Hacker News 的時候看到一個要做「SICP Distilled」的小夥子，也是個 LISP Hacker，去他博客一逛，發現他也跟我一樣，試圖在做一些 life hacking projects。所以或許，這個所謂的工具也好，方法也好，能夠讓一部份人先「富起來」：）
我預感這個項目會是一個戰線比較長的戰鬥，所以在完成 OrgLife 的第一稿之前我得有一些替代品來做輔助。於是這才是今天這一篇帖子的主題：一個暫時的關於時間管理的解決方案，或許適用于大部份病得還沒那麼重的「病友」。
缺失的一環
GTD 是目前時間管理最成體系的一個，建議對它不了解的病友先去做一些了解。它很靠譜，，，直到最後的執行這一環。老牌黑客 Kevin Mitnic 曾經說過，人是一個系統里最薄弱的構件。這話一點不錯，人是複雜的、不可預測的、存在很多弱點的。放在現在的語境里，我們就算完全按照 GTD 的理論走，最後不執行，還是白搭。這就是我說的「缺失的一環」，也就是一個能提高人的執行力的一種輔助。
很巧的是番茄時間法能比較好地促進人們執行，因為人們在掐表的情況下更傾向於全神貫注、在假想的deadline前把事情做好。這其實是個很簡單有效的hack，對我還蠻有效。於是我現在的工作流程是把這兩種方法有機結合了，即，在 GTD 最後加上番茄時間；或者也可以說把番茄時間法的 TODO 管理換成了 GTD。這樣一來，我就有了一個「管用」的體系。但是這還不夠好，先賣個關子，這裡就不分析了。
增強靈活性
「Context」，或者說環境，是 GTD 里一個重要的概念，它主要是幫助你在不一樣的環境下快速找到你要做的事情。這個所謂的環境實在是一個不太好掌控的東西，因為它的定義範疇太廣了。我的建議是不要太具體，但也不要太抽象。這兩個極端會發生同樣的事情，就是你最終放棄使用 GTD。如果太具體，管理成本就會變高，你的 GTD 會變得越來越難管理，最終只能放棄；如果太抽象，這個功能等於沒有用到，因為使用成本變高。所以怎麼才算適中？這個真的因人而異。我覺得事務比較少的人相比事務多的人來說，可以稍微抽象一些。這兩個極端都是有很明顯的特徵的，如果太抽象，那你的事務列表就會很長；如果太具體，那你的很多環境分類很少被用到。用面向對象的語言寫程序的同學，這是不是很似曾相識啊？
下面我用我自己目前的配置舉個例子：
這個界面是一款完全照搬 GTD 流程的軟件，叫OmniFocus 2。它並不是唯一的選擇，只是碰巧在我寫這篇博客的時候我正在調研這款軟件。你們也看到了，它的試用期快結束了，結束了之後，我還會繼續調研 org-mode，以及類似 Trello 的其他可選方案。
對這些 Contexts 做一些解釋：
- Errands：一些生活不得不做的瑣事，比如買菜、倒垃圾、整理房間之類的
- Working：工作相關
- Office：在辦公室要做的事情
- Low Energy：不太想幹事的時候可以做做的事情，一般是不太費腦的無聊的活兒
- Waiting：在 OmniFocus 里，Context 可以設置為 Waiting 狀態，可是這個狀態下的 context 用戶就看不到了，意思就是「這事兒不關我，等著吧」我不喜歡這個狀態，太被動了，所以我單獨另闢了一個 Waiting，卻使用跟其它 context 一樣的狀態。這樣我就能看到正在等的工作條目，並且可以在實時的時候催一催進度。
- Off Duty：離開辦公室時或回家路上要做的事情
- Learning：學習相關
- Reading：閱讀已成為我的習慣，但是有時我缺乏專注力，經常是一本書還沒讀完就開動了第二本第三本第四本，兩個禮拜之後又拿起了第一本接著看，這樣做其實倒也沒太多弊端，就是如果忘記前文還得翻到前面複習 目前為止我還不知道這是好是壞，因為複習可以加深記憶和理解，算是因機制而引起的反芻，是個副產品。所以這個 context 里我主要是放兩類事務：
- Hands Dirty：不動手肯定學不好東西，所有需要動手動腦的學習任務在這裡
- Family：家庭相關，有跟多是跟上面的雷同的，我就不再贅述了，說說不一樣的
- Reviewing Finances：我會邀請我的女朋友或家人也來參加，一般是一月一次，裡面是記錄了一些需要在檢查財政時要做的事情。
- Rushing Out：跟上面的「Off Duty」很像，只不過是說要出門前或出門之後在路上要做的事情
- Anytime：不受限制，任何時間都可以做的事情
適當地抽象化環境分類，可以一定程度上增強 GTD 的靈活性；交叉分類和多分類是我要說的「更進一步」，可惜目前我在調研的這個工具不支持一個事務多個分類（或者是 tag 系統）。而幾年前我摸過 org-mode，它支持 tag 系統，加上最近在寫 Clojure 和 CloJureScript，正好趁此機會撿起 Emacs 吧，Vim 我已經用了足夠久了，以至於現在沒她不行。而她的配置也是我目前為止維護得最久的一個開源項目（用 Eric Steven Raymond 「大教堂和市集」里提到的理論能很好地解釋為嘛我還在一直維護，因為維護者就是使用者）。雖然我也知道有 org-mode 的 Vim 移植，但是開放的心態總沒有錯 ；）
主次要分明
我要說的概念是「優先級」，這個概念在 GTD 以及相關輔助工具里是垂直的。在單獨的項目里有優先級，但是并沒有一個橫向的優先級概念，即，項目和項目之間是平等的關係。然而這顯然是不合常理的。所以我提出的另一個修正就是項目優先級。看圖：
上圖看上去沒什麼特別的，但是它們其實是按優先級從高到低排列的（請忽視第一個 Clojure，它本應該在 Learn and Share 里躺著的，但是截屏的時候沒注意到）。每個人的優先級可能都不太一樣，但是目前來說，我的是這樣。其中可能比較有爭議的是「Help Others」，居然倒數第二？是的，因為我覺得幫助別人的前提條件是顧好自己，就好像在飛機上氧氣罩落下時，你應該先戴好自己的面罩再幫助你身邊的小朋友。為什麼？因為我很難想像我自己的生活工作學習在一團糟的情況下還能好好幫助別人。小時候有很多歌頌黨員幹部的影視作品，他們很多人最終是身體垮了。在我看來一方面他們的精神可貴（宣（xǐ）傳（nǎo）部的工作很到位），另一方面他們因為自己在優先級上的不理智而縮短了「為人民服務」的時間，進而減少了好官在中國黨員中的比例。這是個悲傷的故事。
一些小竅門
不小視 Review
Review 這個環節是 GTD 里很重要但是又常常被人忽視的。因為人們覺得事情做好了就結束了，我一開始也這麼覺得。後來在軟件提醒之下做了一次 review，才發現一堆漏網之魚，一些沒有加截止日期和 context 的事務。Review 其實跟處理 inbox 是一個工作模式，只是一個在 Done 之前，一個在 Done 之後。謝耳朵說自己從來不忘記東西，我們也可以，只要你 review。
儘量自動化
使用這些工具也好，方法也好，都是有額外時間和處理開銷的。（誒！學計算機科學的病友，這個是不是又似曾相識？）我稱之為管理成本，為了儘量減小管理成本，我們應該更多地使用自動化工具，比如此前提到過的 IFTTT，還有就是各種腳本。在使用 OmniFocus 階段，我嘗試寫了幾個 AppleScript 自動腳本，感受是真tm糟糕。這也是我看向 Emacs org-mode 的另一個原因。
遞歸式批處理複雜事務
GTD 的一個「遊戲規則」是必須把事務拆分成可執行的小事務，這麼做很有道理，比方說如果有一個事務叫做「寫一個操作系統」，估計很少人在900個月的時間里能夠完成這個任務；但是如果你把它拆分成細小的組成部份，比方說「寫一個引導程序」，這就可執行得多。但是拆分並不總是那麼簡單。我的方法是遞歸式＋批處理。在番茄時間里遇到複雜的事務時就把它分成較細的事務，并扔進 inbox，然後繼續其它的事務。在下一個循環時，在處理較細的事務，以此類推直到把任務做完。這麼做其實是有一定的原因的。因為其實人跟單核計算機差不多，頻繁切換工作內容會降低效率，那些自稱能高效multitask的基本都扯淡＋裝逼。所以我就把處理大數據的軟件架構設計搬了進來，即 map+reduce。這裡就點到為止吧……
結語
就先分享到這兒，感覺是還有些東西忘了提，之前本想做個腦圖的，懶了。以後想到了再補充吧，洗洗睡了。希望對病友們有幫助。
另外，如果有病友對 OrgLife 感興趣，請跟我聯繫 ；）