?
　　日常談話中有多少次你在談到deadline（期限）時，曾至少有一個人對這個概念嗤之以鼻？我已經聽過太多次了，甚至連我自己也這么干過，不過現在我想改正這一習慣。
　　軟件領域較之于傳統的印刷媒體（print media）有很大的不同，而deadline的概念就是從傳統的印刷媒體中得來。然而，不能僅因為目前在軟件領域尚無通用的deadline概念，就以為該摒棄這個概念，或以為它沒有價值。
　　就工作的規劃和并行處理來說，deadline是極其重要的。如果沒有預計的完工期限，所有團隊都必須連軸工作，同時也會大大減少交付次數。而且如果不明白deadline的真正含義，那么deadline可能會讓人感到沮喪，甚至產生相反的效果。
　　問題及解決方案
　　以下是根據我的經驗總結出來的，在工程公司中與deadline最為相關的問題，以及最有可能解決問題的辦法。
　　1）對deadline的理解因人而異
　　A：“下周才是deadline，我還有大把的閑余時間！”
　　B：“為什么要擔心這個？沒關系的，deadline什么的當不得真。”
　　A：“但我不想被炒魷魚啊！”
　　這組對話就很形象地展示了對同一個deadline，A和B兩人在理解上有著巨大的差異，這也會導致整個團隊在努力實現deadline時出現困惑與挫敗感。
　　事實上，deadline必須要有號召力，每個人都得知道deadline重要的原因，他們必須明白錯過deadline會對整個圈子有什么樣的影響，包括對其他團隊的、對客戶的或者對公司整體的影響。
　　更重要的是，那些達成的deadline需要熱烈的慶祝，而這一點常被忽視掉。比起責備那些錯過deadline的員工，建立起為達成deadline慶祝的企業文化才是上上之策。
　　2）在項目的生命周期中過早設定deadline
　　A：“嘿，我們得完成這項工作【插入一個真的非常難的未知項目】，什么時候能干完？”
　　B：【快速搜了一下到底是什么工作】“額，我不確定。”
　　A：“我需要一個確切的deadline。”
　　B：“三，呃四個……月嗯周……月吧，四個月！”
　　A：“好極了，到時候見。”
　　向一個各方面都屬于未知狀態的項目要求一個deadline簡直后患無窮，也讓項目涉及到的員工壓力很大，為項目立起了失敗flag。所以，先深呼吸，耐心等兩天，讓大家完成探索工作。雖然搜集信息花費了時間，但之后我們卻能給出有意義的評估，這些信息會幫助我們設定更加準確的deadline。
　　3）deadline更新頻度不夠
　　A：“這個項目要在5天內完成，目前進度ok嗎？”
　　B：“有一點落后，不過不要緊，我們會按期完工的。”
　　A：“好極了！”
　　【4天23小時后】
　　A：“再檢查一下項目，準備好發布了嗎？”
　　B：“額，還沒，出了點問題，目測還得一個禮拜。”
　　A：“$%@！*”
　　在這個案例中，在新問題出現時，開發人員并未調整或重新評估deadline，B沒能立即提出問題，而是等到deadline才告知他人，于是A也受此牽連，而整個團隊也會因為要趕工另一個deadline而倍感壓力。
　　設定deadline不應當是為了強迫員工超額負荷，把人當牲口用，而應用以設定外部對項目的預期，讓計劃呈現可預期性。Deadline必須盡可能準確地反映現實情況，否則一旦出現信任危機，這個概念也就失去了傳遞可預期性的功能。當然，我不提倡每小時或每天更新deadline的行為，但也許每周更新，或至少按標準計劃的節奏來更新是個不錯的主意。
　　更新deadline并不拘于延長時間，也可以縮短周期。至于具體怎么做，又或者兼而有之，都得工程師和產品團隊商榷后確定。
　　4）未將所有“已知工作”都納入考慮范圍，僅考慮到了有趣的那些
　　A：“這個功能多久能交付？”
　　B：“兩周。”
　　【兩周后】
　　A：“怎么沒完工？”
　　B：“額，技術上來說已經完工，我們現在在測試，要給它新建一個部署機制，會先發布一個beta版。另外上周我休假了。”
　　在設定這個deadline時，相關人員對要完成的工作以及要投入的時間缺乏完整的理解，更別提該案例中B也出現了上面第三條的問題。
　　在設定deadline時，我們應當確保將所有已知的挑戰都涵蓋在內，是否會因某個已知原因而浪費一些時間，比如說度假、公司斷網、因為生日派對宿醉而遲到？
　　另外我們是否可能遺忘了某些不起眼的任務？這個項目打算寫多少測試？如何將這玩意兒發布到生產環境中？跟著這些問題放慢腳步，仔細思考下整個過程以及可用的資源。這樣做會讓設定deadline簡單得多，同時這樣設定出的deadline也更經得起考驗。
　　關于評估：令人不適，但卻是必要的
　　工程師所設定的deadline很大程度上是通過評估形成的，也就是說團隊中的每個人都要習慣犯錯，犯很多錯——將自己知道不對或是沒信息的地方說出來，可能會很困難。
　　我們必須達成共識，盡可能準確地作出評估，并隨著時間評估地越來越準確。評估是一項技能，反復使用會熟能生巧。初期可能會讓人不適，但這是我們需要做到的。
　　評估任務
　　在定下大型項目的交付時間前，我們應當將整個項目拆分成小的任務，每個任務應當能在約五個工作日內完成。
　　以下問題對評估任務十分有用：
　　這個項目是新建的，還是之前就有的？這部分代碼質量如何？我對這部分代碼的熟悉程度如何？對涉及的編程語言熟悉程度如何？與其他代碼段在哪里有接觸或集成點？現有的測試覆蓋率如何？這項工作是否涉及關鍵業務（寫入路徑、計費、負載均衡器、注冊）？之前是否有人參與過這項工作？他們有何想法？有哪些問題需要做出權衡？這項任務的目標是什么？這項任務究竟是否需要完成？
　　評估工程項目
　　工程項目通常被視為一個較大的任務，可以讓多人并行完成。
　　下面這些問題有助于評估項目：
　　我們實際要在這個項目上花費多久時間？這個工程項目的目標是什么？是否有已知會安排的休息時間？所有要完成的任務有哪些？是否對其他團隊有依賴，還是障礙性的？項目中是否有任務對其它任務產生障礙？該項目是否需要新的基礎設施或硬件？該項目的完工標準是什么？
　　完工標準
　　即便要知道某項工作是否完工都是很困難的，團隊中不同角色可能會有不同的“完工”標準，因此我們需要指定某個項目的具體完工標準。
　　下面是典型完工標準的一些樣例：
　　部署到生產環境；全自動化測試；與公司內部或第三方人員溝通；在公司內部或外部進行了一定量的測試；為生產環境編制文檔；完成對銷售或推廣團隊的講解；發布登錄頁面；分析并追蹤；操作運行手冊與系統可觀測性。
　　總結
　　隨著公司的壯大與管理能力日趨成熟，交付能力成為必須，而deadline是其中主要的工具之一，合理善用將有無與倫比的功效。不過，想要利用deadline，還需時日在實踐中慢慢磨合。因此我建議：工程類公司應當將其視為一個活生生、有生命力的東西，不間斷地去學習了解，并通過文檔在全公司內部，乃至與整個行業分享經驗
?