還沒對象,就訂好婚期了?

「還不知道專案要做些什麼,就把 deadline 訂下來。」

這情況可列入惹怒開發團隊的 top 10 之一,然而,這真的不好嗎?

有問題的,不是訂下了 deadline,而是 deadline 沒有彈性,不能伸縮。

 

歷歷在目的故事

在軟體開發的世界裡面,最常聽到工程師的抱怨之一,就是:「已經決定好這個專案的 deadline,但其實大家都還不知道內容到底要做些什麼。」

所以總是戲稱:「都還不知道女朋友在哪裡,就已經訂好結婚的日期。」

然而,其實這未必是件壞事。

幫 deadline 換個名字好嗎?

「有目標,但是目標可以因應需求而改變」跟「沒有目標」,這兩件事是完全不等義的。

每個專案都該有個 「deadline」,即使還不知道做什麼跟怎麼做。這是實務上再正常不過的一件事。

我們針對兩個地方換個角度來看。

  1. 不要把它叫做「deadline」,把它當作一個重要/有意義的時間檢核點,這個時間點會有不同角色一起來看專案或產品新 feature 的發佈。
  2. 先有第一版的「deadline」, 才會有第一條基準線。以這一條基準線來當作基底,才會在釐清專案範圍時,知道這條基準線合不合理。

我們若要以時程的基準線為基底,不能變動。那就調專案範圍那條線。

我們若要以專案範圍那條線為基底,那你就要告訴相關負責人,時程那條線會怎麼變化。

以這兩條線(X軸為時間,Y軸為專案範圍)的伸縮,來找到初版可行的方案(可接受的時間內,預計完成的範圍,及其所對應的價值)。

搭配每個迭代團隊的產出情況,隨時評估跟原本方案的誤差有多大,離預期時程有多大,我們還可以怎麼調整這兩條基準線,或是斜率。

結論

沒有先出來一份基底,就沒有討論的素材,就沒法評估合理不合理,就沒法找到合理雙贏的可行方案。而時程,往往是一開始最能先決定的線,只要可以接受,這東西會調整,那先有素材跟關注點,就能早點進行 planning。(Plans were nothing, planning is everything.)

說真的,我比較喜歡有 deadline 還不知道要做什麼的專案,因為這樣代表要做什麼、能做多少範圍,我們還可以決定。

那種不合理的 deadline 搭配不合理的專案範圍,根本突破物理極限的 fixed scope, fixed schedule,才是難搞的。因為兩條線都釘死了,很容易會把方案變成「非 0 即 1」。而「非 0 即 1」往往結果一定都是 1,不會是 0。不要跟我說做不出來或不可能,就是時間內要出來。

參考


或許您會對下列培訓課程感興趣:

  1. 2019/12/21(六)~2019/12/22(日):演化式設計:測試驅動開發與持續重構 第七梯次(台北)
  2. 2020/1/4(六)~2020/1/5(日):Clean Coder:DI 與 AOP 進階實戰 第三梯次(台北)
  3. 2020/02/08(六):【針對遺留代碼加入單元測試的藝術】 第八梯次(台北)
  4. 2020/02/09(日):【極速開發+】 第九梯次(台北)
  5. 2020/02/28(五)~2020/3/1(日) C#進階設計-從重構學會高易用性與高彈性API設計 第三梯次(台北)

想收到第一手公開培訓課程資訊,或想詢問企業內訓、顧問、教練、諮詢服務的,請洽 Facebook 粉絲專頁:91敏捷開發之路