我以前聽過一句名言：“deadline是第一生產力”，這句名言，我不知出自誰之口，但我做為一位四歲的技術型創業公司的最上面的管理者，我可以擲地有聲的說，立足於專案開發而言，這是最大的謊言。如果哪個開發團隊打算利用“最後期限”來提高效率，做為同行，我會為他哭泣。

以下是我的思考：首先，“堆程式碼這件小事情”她不是簡單的堆砌工作，她需要一個系列的思考過程，沒有堆程式碼經驗的小夥伴可以腦補一下自己搞科研寫論文碼文章時的體驗和思考過程——她至少是分階段的：適應，準備，熟悉，起步，衝刺。

那，這句“deadline是第一生產力”的名言在什麼情況下成立並讓人深信不疑呢——我猜了一下，是這樣的：deadline其實是“衝刺”的代名詞。前面的工作已經準備好了，最後就剩下組織和衝刺階段，這個時候，所有的條件都具備了，只需要大家集體做衝刺，然後目標就完成了。所以，就給不懂行的管理者造成“deadline才是生產力”這個誤會。

當然，deadline還是很有作用的，很多時候，團隊的人都必須在一起，並且只能做執行（按規範），不能自己再去做選擇。有經驗的領導會知道什麼時候做deadline衝擊，並且為deadline做好準備。

架構一個程式需要系列的工作，包括前期熟悉業務，查詢資料，做測試模型，思索更有序的方法，前面的工作可能看不到，但是實際上為最後的交付工作做準備——你吃第四個包子的時候立刻就飽了，那你不能只吃第四個啊。

有的程式設計師哥哥有一個不太好的特質，老是完美主義，如果沒有專案經理盯著他，他總是在找最優雅的解決方案，整一個磨洋工。到了專案後半期，碰到deadline了，前期想好的方法拿過來用就可以了，前期還沒想好的，隨便哪個方案用就可以了。這樣會讓不懂行的專案經理覺得，最後deadline效率才最高，其實沒有前面的準備和積累，是不可能出來的。

一個好的專案管理，需要定義好專案週期，什麼時候研究，什麼時候消滅工作量，什麼時候衝刺，都需要規定好階段有節奏的進行，有經驗的專案經理會把專案劃分成一個個小週期，讓專案有節奏的迭代，既保證高質量，又不會長時間處於deadline狀態，造成壓力和效率低下。而沒經驗的專案經理只會不停叫，上週那麼快，這周怎麼這麼慢，你們是不是在偷懶。所謂強調996的專案經理就是這樣的人。

最後想說的與主題無關。但很重要，如果“低階的堆砌”只能保證穩定的輸出而已，那什麼樣的模式才會有高質量的結果輸出呢？答：符合思維規律的。一個程式設計師如果明白 “思考力的差距造成收入的差距”，你的收入也就上去了。

這個問題有兩種解釋，①早知道吃第十個燒餅時飽了，就不吃前九個了。沒有前面的積累哪來最後的結果。②騰訊既然是南山必勝客，為什麼不直接讓南山法院直接判定老乾媽全部財產歸騰訊呢。那tm是段子！段子懂不懂。你真敢定超短ddl，我就敢罷工，你知道什麼叫蝨子多了不咬，債多了不愁嗎，反正就是做不完，愛咋咋地

這種靠deadline來提高效率是很短見的，而且看到的很有欺騙性。

第一 technical debt: 在緊急的時候，很多方案會草率，如果牽扯到需要refactor全域性結構來實現程式碼重用，可能會用非常hacky的方式來處理。這樣的技術債務多了會把整個專案變為垃圾，而且說白了搶來的進度會成為以後的威脅來維持進度，永遠不會再有時間來最佳化程式碼的。按我的經驗，緊急情況下寫的程式碼，bug會很多，勉強釋出，欲速則不達。這種賭徒心態，做不好軟體工程。

第二, deadline對團隊的體力是很大的挑戰，這種挑戰如果不用時間彌補，效率和鬥志都會下降。第三，常在deadline拼時間本身暴露了專案管理的重大缺陷在agile管理時候這種極端誤判團隊進度本身就是技術事故。常幹這種事，專案經理該跑路走人了。

最後，團隊的效率是靠發揮每個人的長處，用透明的管理和獎勵來鼓勵積極性的，用agile的方式來合理分析進度，絕對不是靠壓榨時間作為長期策略這種自殘行為來提高的。

本人的公司, 所有隊員和經理都經過 DAD 訓練, Disciplined Agile Delivery. 這是agile的一種框架， 但推薦所有團隊至少去學一種，不要以為agile 就是隨機應變。垃圾的管理只會產生垃圾的團隊和企業文化。