關於工時預估之我見
——讀《終身成長》(mindset )有感
原文發表在 個人博客
結合 卡羅爾·德韋克 的《終身成長》談談工作中如何應用成長型思維把控工時預估。
- 固定型思維：認爲才能和水平是固定的。
- 成長性思維：認爲才能和水平是變化的。
二者區別的關鍵，把一個事物看成固定不變的還是發展變化的。
📺 情景設定
老大交給你一個任務，你估工時後答覆說3天做完，+1天給測試同學。做到第二天的時候，覺得好像三天做不完，於是第二天加班搞，第三天你很累，白天的工作效率降低了。第4天下午終於提測。從第二天開始，你精神一直繃着，還搞了個通宵，難免有些心力交瘁。
代碼交付測試你想喘口氣，測試同學發現一些問題，你要儘快修復。他提出一個你改一個，問題並不不難解，數量卻不少，在不斷的 fix 中，進度又拖後了半天。你有點懊惱：明明自己能力是足夠的，只要認真點就能避免的，當時到底是怎麼了會犯這樣的錯誤。你說下次要加倍努力，讓自己進步。同事喊你出去划水，你欣然答應，好像剛纔懊惱的人並不是你。
過了一週，老大又交給你一個類似的任務，而你，又上演了類似的表現，唯一的不同是，這並不是第一次。
📡 說說這裏面的問題吧
首先，你認爲的三天能做完，是在什麼樣的假設下呢？你看了這次的需求，將幾個字段在客戶端前臺輸入，然後後臺存起來。下一次訪問頁面的時候，要把之前存的內容展示出來。這是你熟悉的功能，上一次你只用了一天就做完了，這一次加一天仔仔細細的自測，再花點時間思考代碼可複用性，甚至你還能預留一天時間划水，是否帥氣的在提測郵件里加上一句“提前一天提測”完全取決於自己的心情了。Perfect !
典型的人月神話問題。
工時估計不準確，並不是問題。你的腦袋隨時會像一團棉花一樣變的混亂，臨時會有打斷你的事，會發現項目功能潛藏的判斷邏輯，等等，都是你預料外的變量。此時怎麼能咬定說計劃3天一定能完成呢？幾乎所有事情都在變化。
我們的工作環境裏充斥着這種“說到就一定能做到”的暗示。你的老大可能分享過一個故事：他做一個項目，答應客戶一個月交工，中途同事離開，項目進度延誤。在僅剩的最後一週裏，他連續加班，力挽狂瀾，如期交付，還得到了客戶和領導的一致好評。除了熱血沸騰的個人英雄主義，這個故事有沒有給我們傳遞什麼不對勁的邏輯？有。
你做到了，是因爲你努力，如果你沒能做到，那就是你不夠努力。換句話說，努力是你“做到”的重要要素，我同意這個說法。但這個說法會有副作用，它在傳播的過程中，會演變成“努力是唯一要素’。畢竟人腦記不住那麼多細節，你只被強調了這一個詞語，當你回想起如何才能加快項目進度時，你只想起來這一個詞，那它就變成了唯一。
我覺得上班時間本本分分寫代碼，適當的勞逸結合，不偷懶划水，可以算作努力。那種加班透支體力的，本應叫玩命。在這羣努力的工程師隊伍裏，很多人還是保證不了項目進度啊，這和開發過程中的變量事件緊密關聯，唯一確定的是一直不確定。所以我的結論是，
😎工時估計不準確，並不是個問題，而是個事實。認爲一個變化的事情是不變的，纔是問題。
再說第二個問題吧。錯誤的將進度與工作量混淆。你是個人，並非機器，加班意味着效率變低，所以並不是通宵加班一晚就可以完成1個工作日的工作。類似的，並不是加上10個人，就可以把項目耗時縮短十分之一，人多了，溝通成本陡然上升，情況並沒那麼樂觀。所以，
😎認爲工程師的生產力一直能線性輸出，纔是問題。
接下來，測試同學提出一個問題你改一個，如此被動的工作方式，一定存在某個問題。你懶，懶的天性？有沒有人給你分析過，你爲什麼懶？如果你覺得完成工作是一種“finish”，那你的代碼版本就成了“final”。代碼提測的時候，你認爲它結束了。既然能跑通了，再做改動意味着測試同學要重新覆蓋case，你也可能引入新的bug，所以權衡利弊之後，把代碼擱置一邊是正確的做法。除非程序跑不通，不然就不改這種省時省力的想法，把你的懶惰僞裝成“精明務實”。
聽起來沒錯，不妨聽聽另一種工作方式。你暫時把代碼交給測試了，提測郵件裏你提到了“手機號號段近期可能增加，該功能的手機號判斷的正則表達式需要蒐集資料加以完善，會繼續完善，辛苦測試同學持續關注”，雖然代碼提交了，但你繼續 review 自己的代碼，知道再也找不出問題，你才放心的把手挪開鍵盤，此時測試同學告訴你，測試過程中問題很少，可以上線了。你心想，不是問題少，而是她測試的這段時間，我默默修復了自己的尚未被發現的 bug。你清楚的踐行着，沒有完美的代碼這句箴言。
兩種方式的分叉點在哪裏呢？在於你“提測”的一瞬間，是否覺得代碼完全完成了。通常我們說提測或上線就算完成了，但你的代碼總歸還有機會被優化的，所以嚴格的說並沒有結束。套用之前的話，懶只是個現象，
😎覺得任務完成了就是結束了，纔是問題。
PS：兩種思維模式還帶來了不同的工作反饋，前者覺得做完了讓人興奮，後者覺得不斷優化讓人興奮，高下立判。實際工作中，KPI、目標導向實際上培養了更多前者。
下一個問題是，你認爲自己能力足夠，卻總是犯錯，所以感到懊惱。這反映出你是典型的固定型思維模式。你覺得當下你的能力是固定在一個level的，低於這個level的任務，都該被你完成，如果完不成，你就歸結爲自己不夠努力。世上那麼多事情不能被人控制，除了你自己，但現在你連自己也控制不了，所以你懊惱😡。持這種思維模式的人在成長上會固步自封。一旦項目上線，他們覺得木已成舟，值得自己付出精力的最近一次，是下一次開發的時候，而不是現在。所以他們忙着休息，卻沒有及時反思自己的工作方式。如你所見，下一次機會來臨，他還是會陷入到捉急的泥沼。
擁有成長型思維的人則不同，因爲堅信能力是不停發展變化的，所以他們更能在任務更替的間隙裏，回頭看哪些地方做的不夠好。大部分成長，發生在不工作的時候。當你有適當的空閒時間並且合理利用的時候，纔是成長髮生的時候。所以回顧下這裏的問題，
😎任務告一段落後，不知道及時總結提高，纔是問題。
🦆 總結下剛纔的核心思想
你能否按時交付足夠質量的代碼，取決於你是否用發展變化的眼光看待開發過程中的所有要素：你的能力本身，你的身體和大腦狀態，需求隨時可能變化，你的同事也許正準備請教你問題等等。如果你天真的覺得其中一個是恆定不變的，那你的工時估計就是有相當風險的。
PS：別覺得不懂技術的項目經理就不能很好地管理項目以及管理你，單純的技術能力對項目進度的影響，沒那麼大。
擴展閱讀
-
《終身成長》——卡羅爾·德韋克
-
《人月神話》——布魯克斯