我與時間管理的故事
這是上家公司，在團隊做的分享，還是挺有意思的，特此分享。
初識樹狀文件
記得剛來團隊那會, 每天早上有個站會, 站會的任務就是把今天要做的事情寫到樹狀文件裡面, 剛開始這樣做我是不太認同的, 因為在以前的公司並沒有這麼做過, 在之前的公司最多也就是寫寫週報, 然而對於週報而言,當時我也是比較反感的, 因為那時覺得寫這些東西根本沒有多少意義,寫這個就是為了給領導看的, 然而之前寫了也沒人給反饋, 所以導致那時我對寫這些東西是十分的不認同
然而不管認不認同吧, 既然團隊有這個要求,也只好按照要求去寫了, 記錄的方式倒是很簡單, 就是把要做的事情寫到文件裡面, 然後記錄下這件事的狀態, 一般用的狀態是todo,done和cancel
在我按照團隊的要求記錄了一段時間後就感到現在的記錄方式和之前公司寫週報的方式是很不一樣的, 之前是每週五下班前把本週做的工作和下週的工作計劃用微信傳送給我們的Leader, 然後Leader彙總後傳送給管理層, 而現在我們團隊的做法讓我覺得記錄這些並不是為了給誰看而寫, 而是為了幫我更好的理清我要做的事, 以及不會把要做的事情忘記
當然, 讓我能夠在短時間內認同這一點, 還要感謝團隊和亮哥開發的樹狀文件工具, 因為它的記錄方式讓我覺得是非常友好和方便的
這樣做的時間越久, 我就越堅信每天把要做的事情記錄下來是很有意義的, 因為有了這些記錄的內容,我們以後就可以很方便的進行檢視, 儘管現在可能沒有什麼用, 但以後就說不定了
比如: 前段時間亮哥code view了我半年前的一個專案程式碼, 裡面有一段很難理解的程式碼, 然後亮哥問我那段程式碼是怎麼回事, 然而由於時間太久, 導致現在讓我去想我也想不出當時為什麼那樣寫的, 然後我只好去查git, 但是當時git一次提交的內容太多了, 導致提交的資訊也沒能很好的解釋清楚那段程式碼到底是做什麼的, 後來通過拿git的提交時間, 在當時的任務列表裡面找到了那段程式碼相關的解釋, 不過可惜的是, 當時寫的資訊比較少, 所以也只是知道那段程式碼是為了解決某個bug才那樣去寫的
所以說記錄是很有必要的, 不過把內容記錄的詳細點也是很重要的, 不然就有可能發生像我前面說的那樣
另外因為每天記錄了當天做的事情, 因此當團隊需要寫週報的話, 那基本上就不需要花多少時間去回憶做過的事情了,只需要把之前記錄下來的整理和修改一下就可以了
Todo與四象限
當你有過一段時間這樣的記錄後, 你會發現其實記錄不僅僅是為了防止忘記還有什麼事情沒做, 更是為了讓你知道你現在做到了哪
想起某次分享會上, 亮哥對GTD也就是任務管理做了一次分享, 在那次分享之後, 我對記錄和知識管理更加著迷, 那之後不久, 很偶然的, 我學了四象限, 它是用來區分任務的緊急程度的
記得當時我做過一次關於四象限的分享, 那時我以為我會將四象限用上很長一段時間, 但那之後的一段時間裡, 我發現在實際的工作中,我更多的是在自我挑選任務, 而不是根據任務的緊急程度去做事,因此我在使用四象限的過程中, 常常將所有事情都給放在了重要且緊急,或者不緊急但重要裡面, 最後的結果就是, 我的四象限與Todo列表基本上沒有什麼區別了, 然後我就在想, 既然這樣,那乾脆還是使用原來的方式做個Todo列表好了, 於是四象限就這樣被我拋棄了
在放棄四象限後,我得出了幾點, 很多時候你是無法控制住自己先去做哪些事情, 然後再去做哪些事情的, 儘管你可能知道某件事相對於另一件事來說更重要一些, 但是四象限根本就沒有辦法控制你不去做某件事情, 或者去做某件事, 也就是說如果一個人能夠控制住自己, 那麼就算是使用最簡單的Todo列表也能很好的根據自己的價值觀做出選擇並加以執行, 相反如果不能控制住自己, 那麼就算有四象限也將是一個虛設
儘管我說我拋棄了四象限, 但這麼說也不全對, 因為在某些情況下, 我還是會按照四象限推崇的以任務的重要程度來區分先後順序, 只不過是我沒有再去將任務分為4塊, 對比使用四象限和現在的區別就在於, 現在使用任務的重要程度來區分先後順序的比例減少了, 更多的是由自己當下發揮
現在我使用任務的重要程度來區分先後順序的常見慣例是, 我正在做某件事, 突然接到一個新任務, 那麼這時我就會按照任務的重要和緊急程度來決定是否要放下手上的這件事而去做新接的任務
不過我, 除了考慮任務的重要和緊急程度, 還會去想的一個問題就是, 如果現在不做這件事, 是否會影響之後任務的執行, 另外如果新接的這個任務能夠在幾分鐘內完成或者這件事並不需要我來完成, 而是需要我轉告給另一個同事, 那麼這時我也會放下當前正在做的事情, 去做新接的任務
不過當你真正做任務管理的時候, 你會發現我們除了考慮任務的重要緊急程度以外, 還有很多其他的方案可以選擇, 並且如果你真的完全按照任務的重要和緊急程度去做, 也不見得就好, 因為任務的重要程度是會變化的, 也許某件事對於今年來說是重要的, 但有可能後來因為某些原因導致那件變得沒有多少必要了, 所以留有一定的自由選擇也是很有意義的
在任務管理方面我主要使用的方法是, 收集, 記錄, 整理, 執行, 當然, 如果要做的那件事很夠在1,2分鐘內就完成, 那麼我就不會去記錄, 而是直接把它做完
時間記錄法
其實, 我除了每天會去寫任務列表外, 還有一件比較重要的就是, 我會把每件事花費的時間記錄下來
記錄的方式是參考的柳比歇夫的時間記錄法, 柳比歇夫是一位蘇聯的昆蟲學家, 但大多數人認識他的原因並不是因為他是昆蟲學家, 而是因為他的時間記錄法, 有本書叫做<奇特的一生>, 裡面講述了柳比歇夫56年如一日的通過記錄每天的時間花費情況做統計, 然後將統計後的結果進行分析, 最後根據分析的結果去安排自己的時間
時間記錄法的規則很簡單, 就是將每天做的事情和花費的時間記錄下來, 這些記錄下來的會被作為下一次計劃任務時的一個參考, 如果是按照柳比歇夫的做法, 那麼我們還需要定期對這些做過的事做一次回顧
在使用時間記錄法的一段時間後, 我通過記錄的這些資料瞭解到自己在哪些方面浪費的時間比較多, 以及每天真正花在做事的時間上有多少, 當有一定的資料後, 我就可以算出平均每天有多少時間是有效的, 有效時間, 指的是, 拋除那些不可工作後的時間, 比如走路,喝水, 等
當我知道了自己每天有多少有效時間後, 我就可以拿當天記錄的資料與有效時間做個比較, 看是多了還是少了, 如果是少了, 那麼就應該去看是在哪些地方花費的時間比較多, 並做好總結避免下次再出現這種情況
通過時間記錄法, 我們還可以瞭解到某類事情需要花費多少時間,比如之前我看某種型別的書籍需要花費3小時, 那麼在下一次我要看類似書籍的時候就能夠估計出一個大概的時間了, 如果我之前沒有做過這方面的記錄, 那麼我就只能是瞎猜
有了資料後, 我可以更合理的去安排下一次計劃, 不至於將一天安排的過多或過少, 之所以可以更合理的去安排下一次的計劃, 就在於我之前做過類似的事情, 並有相關的記錄, 因此現在再去做類似的事情心裡肯定是有個大體的數的
時間記錄法還有一個好處, 那就是你能夠分析出, 你對某類事情的興趣增減情況
番茄工作法
在工作中, 我們常常會因為無法專注的去做某件事而苦惱, 那麼這時可以考慮番茄工作法
番茄工作法是一套工作流, 其目的是提高專注力, 以及合理的安排休息時間, 番茄工作法的原理是將一天分為多個番茄, 一般每個番茄為25分鐘, 每做完一個番茄就休息5分鐘, 一旦開始某個番茄, 就不能被中斷, 如果被中斷, 那麼這個番茄將被作廢, 需要重新開始, 在你準備使用番茄時, 需要確保你的時間不會被他人打擾, 如果無法確定那麼就不要使用了
不過在實際情況中, 往往25分鐘是不可能的, 比如我在程式設計中, 往往一寫就是幾個小時, 比如5月1號的下午, 我從4點左右開始寫某個東西, 結果一寫就到晚上7點左右了, 當然長時間做電腦旁是不太好的, 但往往就控制不住自己, 比如寫到一半多的時候, 就想著都快寫完了, 乾脆寫完好了, 反正很多時候就是這樣
儘管說番茄工作法的時間分配並不適合我, 但是我依然喜歡番茄工作法, 因為雖然我可以長時間的去做某件事, 但是並不代表我可以始終專一的去做那件事, 時常在做那件事時, 做著做著就去弄了和它不相關的東西, 正因為有這一點, 我才認為說, 番茄工作法對我依然是有益的, 只是它和四象限一樣我不需要完全去按照官方推薦的做法去執行而已
另外它推薦的休息時間, 也是比較不錯的, 因為長時間的工作真的不是太好, 儘管我現在還沒有做到, 但我現在也在開始準備往這方面去考慮, 怎麼安排會比較合適
在你剛開始使用番茄工作法時, 可能會產生一些焦慮感, 容易讓你去想現在還剩多少時間, 不過在你使用一段時間後, 焦慮感會逐漸消失, 當然這也可能是我個人情況, 如果你沒有產生自然是好的, 如果產生了也不必驚慌
結語
有一天你會發現, 不管我們如何做時間管理, 我們永遠都不可能會有將任務做完的一天, 甚至會讓你的事情變得越來越多,所以在裝進杯子裡面之前, 看看裝進去的是什麼, 不要為了裝滿杯子, 而把什麼都往裡面塞
然後問問自己,需要那麼多時間做什麼, 因為如果你不知道你為什麼要那麼多時間, 那就是給你很多空閒的時間, 那也只會是浪費
關於時間的分享就到這了, 最後我還想說的是:
有時我們容易過早的去拒絕一些新鮮的事物, 但這樣做的結果就是, 我們少了一種新的可能性, 在沒有實際用過它之前, 我們往往不知道它到底有什麼用, 或者說用還是不用它,對我們有什麼改善, 然而如果你沒有去用它, 是不太可能想明白的, 理性的做法是自己試驗一段時間，看看是否真的有效
給它一個公平的機會, 也給自己一個改變自己的機會, 不管現在你認為它是好的還是壞的