我想也許你早就聽說過“Deadline是第一生產力”這句話，哪怕以前沒聽說過，我相信看完本文後，再也不會忘記這句話，甚至時不時還要感慨一句：“Deadline是第一生產力！”。

在日常生活中，Deadline倒逼生產力的例子比比皆是，比如說：

• 上學時，臨近到要交作業的Deadline了，遊戲都顧不上玩了，急急忙忙趕作業。
• 工作中，專案釋出的Deadline臨近了，大家加班加點，熱火朝天趕著開發功能和修復bug。
• 生活中，快到了要報稅的Deadline了，每個人都急急忙忙趕在Deadline前把稅給報了。
  
  不管多拖延的人，快到了Deadline的時候，總能爆發出驚人的生產力。這就是為什麼我們總是說：Deadline 是第一生產力。

與之相反的例子也很多，一些沒有Deadline的事情，總會能拖則拖，直到不能拖為止，或者乾脆不了了之。比如說：

• 程式設計師常有一些絕妙的想法，比如寫一個開源專案，做一個App或者網站，結果因為沒有Deadline，結果總是開了個頭，就再沒結果了。
• 工作中很多專案，雖然有計劃，但是沒有強Deadline，結果需求一改再改，計劃總是在跟著調整延遲，一直不能上線。
• 比如說我這篇文章，打算寫很久了，但因為沒有Deadline一直拖著，最近終於給自己定了一個Deadline是這週末要寫出來，這才開始動筆。
  
  這些失敗的例子，歸根結底，一個很重要的原因就是沒有Deadline，導致不能發揮出生產力，或者生產力沒有用在正確的地方。

Deadline為什麼能創造出巨大的生產力？

為什麼Deadline這麼神奇，能創造出巨大的生產力？

無論是個人的事情還是專案，生產力低下，不能按時完成的原因，總結下來不外乎三種：

1. 想太多
2. 過於追求完美、關注細節
3. 不夠專注

想太多

回想一下你做過的事或者專案，是不是會有“想太多”的情況。這並不是說在動手做之前先思考不好，而是有時候，因為停留在想的時間太長，遲遲沒有動手，導致想的太多對於做成一件事反而會成為一種阻礙。

比如說想寫一篇文章，打腹稿打的太久，最後都模糊了當初要寫的觀點，真下筆的時候，很多思考完全用不上；想寫一個程式，設計了太久，不僅花了太多的時間在不必要的設計上，最後留給寫程式的時間就不多了；做一個專案，在需求上想太多，遲遲不能確定，最後留給後面設計和開發的時間很短。

當有了明確的Deadline，想太多的問題就會有明顯的改善，該寫的文章就動手寫起來了，程式差不多時間也就動手編碼起來了，需求也能早點明確下來。

過於追求完美、關注細節

追求完美、關注細節不是壞事，像喬布斯就以關注細節而聞名，但對一個專案來說，有時候過於追求完美、關注細節反而會導致專案失敗。

比如說想打造“完美”的產品，導致產品一改再改，遲遲無法上線；程式設計時考慮各種未來可能的需求，導致設計非常複雜，很難實現。

想象一下，如果你本來想做一個完美的產品、設計一個完美的架構設計，但是有個很嚴格的Deadline，必須要保證在Deadline前交付，那麼你是不是就不會那麼追求完美和細節，而是抓住最核心最主要的功能和設計，先保證能交付。

不夠專注

當一件事沒有明確的deadline時，就很容易被其他事情分心，比如說上上網、玩玩遊戲，只有在deadline臨近時，才能專注在要做的事情上，不再被那些無關緊要的事所分心。

借用時間四象限的理論，有了Deadline，你要做的事情就變成了“重要並且緊急”，否則就會變成“重要不緊急”甚至是“不重要不緊急”，以至於一拖再拖。

結合專案管理金三角來分析

我曾經在《怎樣平衡軟體質量與時間成本範圍的關係？》一文中提到了專案管理金三角的理論，也就是軟體質量和時間成本範圍三者之間是相互制約的關係。

結合前面的分析：

• “想太多”的問題本質上是在壓縮了你的有效時間和擴大了範圍，導致失控；
• “過於追求完美、關注細節”的問題本質上是擴大了範圍，導致失控；
• “不夠專注”則是一些不重要的事情擠壓了你的時間。

而當你的專案有強Deadline的時候，說明金三角的三條邊中，時間這條邊是固定住的，只能少不能多，那你就只能去調整範圍和成本另兩條邊。而成本很多時候也是不能動的，最終結果就是縮小範圍和有效利用時間。

所以說，Deadline之所以能提升生產力，歸根結底，是由於利用Deadline，倒逼著你縮小“範圍”，做當前最重要最有價值的事情；利用Deadline，讓你專注，不浪費時間在不重要的事情上。從而可以把Deadline，變成第一生產力。

如何在專案中應用好“Deadline 是第一生產力”？

既然Deadline是第一生產力，那是不是隻要凡事設定一個Deadline，就萬事大吉，自然就可以把事情做好？把專案完成好？

顯然也不是那麼簡單的事情！並不是隨便把一個時間點設成Deadline，就可以馬上激發生產力。

首先你的Deadline是否有一定的強制性？

Deadline之所以能成為Deadline，就是因為它具有一定的強制性，Deadline到了之後沒能完成會有一定後果。比如說你作業沒能按時交，那麼分數就會受影響；專案沒能按時交付，績效就會受影響。

很多優秀的程式設計師，在公司的專案中能高效的完成任務，相反自己在做Side Project的時候卻各種拖延，難以交付，就是因為無法給自己定一個Deadline，就算定了時間點，到時間沒能完成也不用承擔什麼後果，自然就難以將Deadline變成生產力。

有時候如果自己真的難以執行，可以讓家人朋友幫助監督，或者可以學學亞馬遜的逆向工作法（Working backwards），在打造一個新產品前，不是按傳統的需求、設計、開發、測試和釋出流程，而是先寫新聞稿，然後開新聞釋出會告訴大眾要打造一個什麼樣的產品，以及什麼時間釋出，再去設計開發。這樣在寫新聞稿的時候就想清楚你的產品要交付的最核心的功能是什麼，以及你的Deadline是什麼。

當你把要做的事情和Deadline當作牛逼吹出去了，要想不被人笑話，就要考慮為你吹過的牛逼奮鬥，保證在Deadline之前有所交付了。

然後你的Deadline是否具有可操作性？

成功的Deadline一定都是以科學的計劃為基礎的，否則不切實際的Deadline就會鬧出像“兩個女人5個月生孩子”這樣的笑話。

怎麼樣的Deadline才算具有可操作性呢？

首先Deadline的時間點不宜太遙遠。

當你的Deadline定的太過遙遠，只有在Deadline臨近的時候，才能發揮出作用，但可能已經太遲了。

傳統的瀑布模型開發軟體就是典型的例子。使用瀑布模型開發軟體專案，也會有一個專案釋出的Deadline，但是這個Deadline通常在幾個月甚至一年之後，結果通常就是開發過程前鬆後緊，剛開始不忙，臨到上線時加班加點。

後來針對這種情況，一個改善的方案就是設定里程碑，里程碑本質上就是把一個長的Deadline拆分成幾個短的Deadline，比如說需求分析完成是一個里程碑、開發完成是一個里程碑。這樣的藉助一個個里程碑，讓Deadline貫穿專案始終，持續的激發生產力。

然後Deadline到了必須要有交付。

很多人有追求完美的情結，即使Deadline到了，因為覺得產品不完美而不願意交付，所以寧可將Deadline不斷調整，一直延期，最終導致Deadline形同虛設。

完美是沒有止境的，在你眼裡不完美的東西也許在其他人而言，已經可以滿足需求了。Deadline的一個意義也在於通過Deadline，讓你在有限的時間內必須要有交付，倒逼著你放棄完美清潔，想清楚什麼是你應該交付的最重要的東西。

交付，也不意味之交付一個漏洞百出半成品給大眾，而是通過縮小範圍，交付一個完成的最小可用的版本。

另外軟體的交付也分兩種，一種是內部的可供測試的版本，一種是外部的正式釋出的版本。比如像Chrome (Chrome Release Cycle) 的開發，會交付不同的版本給不同的使用者，比如每天交付的開發版本，但是隻是內部人員使用。還有Beta版本，只是給一部分測試使用者，最終交付給使用者的，已經是一個經過反覆測試完善的穩定版本了。

再有就是Deadline到了必須要有完整的交付。

前面說的里程碑的方案可以很好的解決Deadline太長的問題，但也有問題，那就是在里程碑的Deadline到了的時候，雖然有交付，但交付的產物並不是十分清晰。比如說需求設計里程碑到了，只是一些模糊不清的需求檔案。結果就只能是基於這種模糊不清的需求檔案，邊開發邊修改，導致後續因為需求修改而產生很多不必要的浪費。

所以Deadline到了的時候，不能交付一個半成品或者模稜兩可的結果，而必須是一個完整的結果，否則這樣的Deadline，生產力是大打折扣的。

最後再給你看一個在軟體專案中，應用好“Deadline 是第一生產力”的經典例子。

敏捷開發的時間盒子

可能你已經知道敏捷開發，每天都在用敏捷開發管理軟體專案，也許你還不知道什麼是敏捷開發，在這裡我並展開多講，只講其中的時間盒子（Time Boxing）概念。

在敏捷開發中，一個軟體專案的開發，是採用的迭代開發的模式，並不是一次交付完整的產品，而是通過一個個的迭代，每次交付一部分可以執行的產品，最終交付完整的交付。

每一個迭代都是一個固定時長的時間盒子，時間通常不會太長，1-4周左右，但每個迭代結束，都要求要交付可執行的產品。

這個時間盒子本質上就是一個個的Deadline，每次時間盒子的結束點就是一個Deadline。那這樣做有什麼意義呢？

首先，每次迭代前，你要計劃好：當前迭代要做哪些事情？deadline到了的時候能交付什麼？

因為有Deadline的壓力，每次迭代時間是有限的，而你又必須要交付，那麼就會倒逼著你在計劃的時候，會優先選擇當前優先順序最高的任務，專注在重要的事情上。

然後，在迭代的過程中，你要儘可能的提升效率，保證在Deadline之前能交付。

如果你想要在Deadline之前儘可能的交付更多的東西，那就會倒逼著你去提升效率。

所以你在設計的時候，只會做剛剛好的設計；所以你會寫自動化測試，從而提升測試的效率；所以你會採用像CI/CD這樣的工具，幫助你將很多工作自動化，提升效率。

最後，在迭代完成的時候，Deadline到了，你一定要有完整的交付。

前面說到了：在Deadline到了後，有交付、有完整的交付非常重要。這也會倒逼著你去思考如果提升釋出版本的質量。

要保證你有一個穩定的可交付的版本，在敏捷開發中有很多很好的實踐：

• 首先是要有充分的測試，完全人工測試顯然是跟不上快速迭代的節奏的，所以要有大量自動化測試來輔助，保證可以同自動化的方式覆蓋各種測試用例；
• 然後需求不能頻繁變更，這就意味著在一個迭代中，通常不會接受需求的變更；
• 還有就是採用分支的方式來開發新功能或開發bug，只有程式碼審查和測試通過才能合併，這樣你就有一個穩定的隨時可以釋出的分支。

敏捷開發的時間盒子，就是一個藉助Deadline來提升生產力的經典應用。藉助Deadline，倒逼著你專注於重要的事，倒逼著你提升效率，倒逼著你按時交付可執行的內容。

即使你不是採用的敏捷開發的時間盒子來開發專案，其中很多借助Deadline激發生產力的思想和方法，都可以借鑑到你的專案開發甚至是日常生活中。

Deadline就是第一生產力，希望你能理解和應用好Deadline，幫助你提升生產力。