失控的專案，就從失控的需求開始

相信在每個軟體開發人員的心目中，都很期望自己所參與的軟體專案可以如期完成──不論是將產品適時推到市場上，或是讓專案順利結案，讓客戶驗收付款。但在我們的生活中，難免會有一些不那麼如意的專案，它可能和計畫有所偏差，脫離了預期的軌道。

有些這樣子的專案，只是暫時脫軌，最後還是回到了正常的道路上，即使專案完成的時間晚於預計的時間，但發生的延遲程度還算可以接受。

最慘的情況，莫過於專案自從進度脫軌之後，就再也沒有看到它有重回軌道上的跡象，專案的時程持續發生延遲，原先所預計完成的時間點也一直向後調整，成本持續追加，對於何時才能夠將專案完成，沒有人有真正把握。

通常我們就會稱這樣的專案「失控」了。

專案進度落後，始終無法看到終點，距離完成目標遙遙無期，使得人人心慌
專案能順利如期完成當然是最理想的情況，但是，基於各種不可測的原因還有風險，專案難免受到衝擊而對時程產生影響，這種時候難免使得專案產生延遲的情況。

但延遲還不是最可怕的，最可怕的是，你不知道究竟還會再延遲多久。

延遲並非都無法管理。當你的專案被突發事件所影響，而造成時程不可避免的必須延遲時，你可能有能力重新估算一個時程，倘若重新調整後的計畫及時程都能夠照所預期的執行，那麼這個延遲就是一個能管理的延遲。

專案即使受到了突發事件的擾動，但只是暫時的，最終還是回到可以預測的狀態，即使難免有所延遲，但延遲的程度是可以預期的。

有些情況下，專案持續發生延遲，無論如何重新調整計畫、重新估算時程，都無法實現。如此一來，所做的計畫就沒有人會相信它是一份可以被執行的計畫，所估計的時程也沒有人會把它當真。專案除了發生了延遲之外，更嚴重的是，延遲是無法管理的，因為它無法估計、也無法施行任何矯正措施，使得這種情況獲得改善。對，這樣的專案完全是失去控制了。

要妥善管理需求的提出，否則將導致專案進度大失控

在剛入行的前幾年，我就有參與這種專案的經驗，那簡直像一場惡夢。

即使你覺得團隊裡的成員都是好手，但不知怎麼的，產品就是做不完。成員間的士氣愈來愈低落，業務們等待這個產品問世的心情愈來愈焦急，但它就是端不出來，最後他們對開發團隊回報的完成日愈來愈沒有信心。

他們描述開發團隊的狀況是：「像是進了山洞的火車，看不到火車開到那裡了，也不知道何時才能駛出山洞」。

專案會失控，不全然和開發成員的技術能力有關，甚至大多數時候都和技術能力無關。這樣說的話，究竟為什麼專案會失控呢？

很多專案之所以會失控，首要之惡就是失控的需求，也就是無法管理的需求。當然，做為程式設計者往往最不喜歡的就是需求的變更，但需求的變更在軟體開發的過程中幾乎是難以避免，而需求的變更並不意謂著需求的失控，因為需求的變更是可以被管理的。那麼什麼情況會造成需求的失控呢？

之前也談過需求管理的重要性，像是需求的確認，對開發專案的進行是相當重要。

需求未能確認的狀況有哪些？像是未能適度、充份的記錄需求，並且和客戶溝通，並且獲得客戶確認及承諾。

或甚至是，未能協助客戶探索、建立客戶真正的需求，使得所確認的需求，的確能滿足合乎客戶的真實需要。

未能確認需求而做的開發，即使其他的環節都沒有出現問題，等到客戶開始接觸到開發中的系統時，便會發現所做出來的東西，和他們心目中所想像的有所落差。

為了填補這個落差，就必須透過一連串的需求變更，將目前的產物變回他們所想像。

一連串的需求變更或許還可以在被管理及控制的範圍內，即使需求變更對現有架構及程式碼造成夠大的衝擊，也還是有可能在可被評估的範圍內。真正可怕的並不是一開始的需求確認不足，而是在開發的過程中，沒有辦法管理需求的變更。

最常見到的情況是，客戶或是（同樣做為代表客戶的）產品經理在開發過程中所發出來的需求變更，沒有或沒能去管理。

對需求變更沒有管理，可能是因為團隊的開發流程沒有管理。而對需求變更沒能管理，則很有可能是業務端或專案經理屈於某種壓力，所以無法管制需求的變更。最後的結果，就很容易演變成為對需求變更幾乎照單全收。

需求變更也需要管理，因為還要花額外的時間、人力去執行

如果在開發的過程中，任何一個時間點都可能有任意多的需求變更發生，像是客戶可以在任何時間點加入任意多、任意範圍的功能，那麼又有誰能預測，這軟體究竟何時才能開發完成呢？而需求無法收歛，就會失控，需求的失控，接下來絕對會使得專案也跟著失控。

每次需求的變更，都會造成程式碼必須做修改，甚至會牽動到架構，大幅讓程式碼受到影響。重新改寫程式碼需要時間；重新測試程式也需要時間。而且，程式碼只要一經修改，就有可能引起副作用，引發品質的問題。為了修正品質問題，又要再投入更多的時間。可以說，需求的變動就是會讓時程往後延。

但一般的需求變更是可以被管理的──即使會造成時程的往後遞延。像是，和客戶協議，不在範圍內的變更必須收費，並且同意接受時程的遞延。這使得專案完成的時程往後延的時間長短，也跟著可以被管理。

向客戶合理收費，是為了讓客戶也認可需求變更所需付出的代價。而且，除了金錢之外，時間也是無可避免的代價，天底下沒有改東西或加東西是不需要花時間的。

一般的需求變更可以被管理，但失控的需求變更則是沒有辦法管理的，所以，專案延遲的時間，當然也就無法管理。

有一些扮演規畫產品角色的人，喜歡在開發團隊的開發過程中，不斷為產品添加新的功能。產品的功能不是不可以擴充，但是，最起碼要有里程碑的概念。否則放任需求無止盡的變更，又要如何期待產品能正式問世的那一天？

事實上，需求的失控，是很常見到讓專案失控的眾多原因之一。

需求之所以失控，往往是因為沒有意識到必須對需求的變更做出管理，同時也低估了需求變更造成的影響。

需求的失控，除了讓一個個源源不絕的需求變更，持續讓專案完成日往後延之外，也會讓程式碼陷入持續變動所造成的品質危機中，而永不見天日的陰暗感覺，也會深深影響團隊成員的士氣，讓開發的效率變得較為低落。

因此，想要避免專案的失控，第一步便是要避免需求的失控。

在下一回中，我們還會繼續探討讓專案失敗的其他原因。