「還不知道專案要做些什麼，就把 deadline 訂下來。」
這情況可列入惹怒開發團隊的 top 10 之一，然而，這真的不好嗎？
有問題的，不是訂下了 deadline，而是 deadline 沒有彈性，不能伸縮。
歷歷在目的故事
在軟體開發的世界裡面，最常聽到工程師的抱怨之一，就是：「已經決定好這個專案的 deadline，但其實大家都還不知道內容到底要做些什麼。」
所以總是戲稱：「都還不知道女朋友在哪裡，就已經訂好結婚的日期。」
然而，其實這未必是件壞事。
幫 deadline 換個名字好嗎？
「有目標，但是目標可以因應需求而改變」跟「沒有目標」，這兩件事是完全不等義的。
每個專案都該有個 「deadline」，即使還不知道做什麼跟怎麼做。這是實務上再正常不過的一件事。
我們針對兩個地方換個角度來看。
- 不要把它叫做「deadline」，把它當作一個重要/有意義的時間檢核點，這個時間點會有不同角色一起來看專案或產品新 feature 的發佈。
- 先有第一版的「deadline」, 才會有第一條基準線。以這一條基準線來當作基底，才會在釐清專案範圍時，知道這條基準線合不合理。
我們若要以時程的基準線為基底，不能變動。那就調專案範圍那條線。
我們若要以專案範圍那條線為基底，那你就要告訴相關負責人，時程那條線會怎麼變化。
以這兩條線（X軸為時間，Y軸為專案範圍）的伸縮，來找到初版可行的方案（可接受的時間內，預計完成的範圍，及其所對應的價值）。
搭配每個迭代團隊的產出情況，隨時評估跟原本方案的誤差有多大，離預期時程有多大，我們還可以怎麼調整這兩條基準線，或是斜率。
結論
沒有先出來一份基底，就沒有討論的素材，就沒法評估合理不合理，就沒法找到合理雙贏的可行方案。而時程，往往是一開始最能先決定的線，只要可以接受，這東西會調整，那先有素材跟關注點，就能早點進行 planning。（Plans were nothing, planning is everything.）
說真的，我比較喜歡有 deadline 還不知道要做什麼的專案，因為這樣代表要做什麼、能做多少範圍，我們還可以決定。
那種不合理的 deadline 搭配不合理的專案範圍，根本突破物理極限的 fixed scope, fixed schedule，才是難搞的。因為兩條線都釘死了，很容易會把方案變成「非 0 即 1」。而「非 0 即 1」往往結果一定都是 1，不會是 0。不要跟我說做不出來或不可能，就是時間內要出來。
參考
blog 與課程更新內容，請前往新站位置：http://tdd.best/
