開發時程規畫大剖析第3回─面對延遲，縮小規模最快見效

雖然許多人會透過加班來解決專案延遲的問題，但它終究非最佳良方。增加人力是個可行之道，但應該越早加入越好，因為專案的新成員，總是需要時間適應上手。

而事實上，每個專案成員都應該在專案發出可能延遲的訊號時，提前讓專案經理以及所有成員意識到，並且讓專案經理有機會開始規畫因應之道。

接下來，我們要談一個最現實的問題，倘若加班以及增加人力都無法挽救時程的延遲時，那麼專案該怎麼進行下去？

當延遲無法避免，降低傷害為上策
是呀，專案總得進行下去。軟體開發的故事，大多都不是童話故事。或許經過專案經理及所有團隊成員的努力，專案仍然無法準時在期限內完成，但這不完全意謂著是不努力的結果，例如被意外的事件影響到。

即使專案因為人為的疏失而造成了延遲，但延遲總是無法逃避的事實，與其在專案尚未結束之前便開始檢討，或者以更負面的說詞推託責任，不如試著面對專案即將或已經延遲的事實，試著降低傷害，這才是有正面意義的做法。

我曾在一個專案會議中，聽到客戶指著專案經理說：「你倒說說看，因為這樣子而造成專案延遲了，究竟是你們的錯還是我們的錯呢？」專案經理很平和地回答：「現在討論究竟是那一方的過錯，對於讓系統上線也沒有太大的幫助，如果真的非得是某一方的過錯，那就算是我的錯好了，讓我們繼續來討論下一個待解決的問題吧！」

很多人在專案面臨延遲時不知所措，便急著釐清責任甚至是畫分界線，確保專案的延遲責任與自己無關。但他們都忘了，讓系統上線或是讓產品交付才是最重要的事情。

專案的四個重要變數：成本、品質、時間和規模
有名的eXtreme Programming認為，軟體專案有四個重要變數中：成本、品質、時間和規模，想要調整其中任一項，就必須連帶跟著調整其他的變數。好比，你希望規模變大（例如希望擁有更多的功能），那麼可以選擇延長時間、提高成本（例如投入更多的人力）、或者在不改變時間及成本的情況下降低品質（當然，很少有人會選擇降低品質這一個選項）。

如果維持同樣的規模，你希望縮短時間，那麼大概就只能提高成本來達成了。事實上，eXtreme Programming的看法和現實情況也差相彷彿，但還是有不少人無法看清現實。

相信大家都有經驗，自己的客戶或老闆於專案進行中，期望在維持原時程的情況下，持續地擴增要開發的規模，卻也沒有增加相對應的人力。於是，專案執行的結果，不是時間超出了紋風不動的期限，就是品質低落導致遲遲無法結案。

上線日無法更動，先捨棄非必要功能
想要更動這四大因子中的一項，又期待其他因子不跟著連動，是很難做到的事情。事實上，這四個因子中，時間和規模相較於成本及品質，是比較好控制的。

所以，當規模增加時，得投入更多的時間，而當專案可能會延遲時，倘若時間是完全不可動搖的項目，例如系統上線日已經確定，相對應的活動也無法再更改，那麼想要準時的上線，削減系統規模雖然是逼不得已，但也應該是最有效的手段。

每個人都希望系統上線或產品發布時，能夠完成所有規畫的功能，但是受迫於既定的時程，對於系統或產品的功能勢必就得有所取捨。當你決定透過削減規模，來追求如期的上線或發布時，你必須試著逐一地評估所有未完成功能的重要性。

對某些人來說，每個功能的重要性都是五顆星，所以沒有一個功能可以削減。但是，這麼想其實無濟於事。你必須試著以中性的角度思考，究竟那些功能是真正不可缺少的功能，這功能可能是系統運作完全不可缺少的，也有可能是系統或產品所要強打的、可以與其他系統或產品建立市場區隔性的功能，這類的功能，我們稱為「必備（Must Have）」的功能。

相反的，有些被歸類為「有的話更好（Nice To Have）」的功能，這類功能的存在，或許是讓使用者的操作流程更為流暢，或許是提供更貼心的作用，但無論如何，少了這樣子的功能，使用者並不會覺得系統殘缺了一大塊。

所有的功能都可以依據它究竟有多麼重要，來一一排定優先順序。而你依據這個優先順序，逐一刪除掉最不重要的功能，直到必要的未完成功能得以如期完成為止。

分階段完成，可避免雙敗的局面
區分各個功能的重要性，以及逐一將它們從系統功能清單中移除，並不是難事，難的是要接受必須採取削減系統規模的事實，尤其是對於付錢買單的客戶而言，更是如此。

對承接外包開發專案的團隊而言，客戶付的是固定的價碼，希望得到的也是他們所預期得到的系統。在這種情況下，開發團隊需要做的便是試著和客戶溝通協調。

對開發團隊而言，希望爭取在首次上線日期無法更動的情況下，分階段完成承諾客戶需要的東西。開發團隊可以試著讓客戶明白專案開發進度不符預期，以及之所以超出預期的原因，爭取客戶的諒解，並且溝通在不更動上線日期的情況下，勢必削減系統規模的事實（因為通常在此時，加入新的人力已經緩不濟急）。

之前承諾客戶的系統功能，並不是不交付，而是分階段交付，先讓客戶能夠正式讓系統營運，之後再分批補足其餘的功能。

專案到了這種情況，其實客戶和開發團隊已經在同一條船上，系統能夠上線，雙方的壓力都能夠釋放許多，堅持一定要在勢必延遲的時程下，完成所有的預定範圍，有時便會顯得過於意氣用事，最後淪至雙敗的局面。

事實上，即使系統不夠完美，但能上線便是一個重要的里程碑。上線後，才更有機會碰觸到真正的使用者，得到更多來自使用者的意見回饋，很多時候，更會發現原先還未實作的功能，其實根本反而是多餘的。

干擾與誤差在所難免，爭取認同最重要
對於自有產品或系統的開發，雖然不需要跟外部的客戶溝通，但仍然少不了與內部客戶溝通的過程。其實自有產品、系統的開發，不論是系統規模或時程，多半比較有彈性。但面對不可更動的產品發表日或上線日，說服內部客戶削減系統範圍是比較明智的做法。

事實上，有時候這也讓內部客戶及開發團隊，得到1個新機會，重新思考每個功能存在的必要性。畢竟經歷過一段時間的開發，不論是內部客戶或開發團隊，都對即將問世的產品或系統有了更深一層的了解，在去蕪存菁的情況下，反而可以濾掉原先所設想的系統範圍裡，其實不是那麼必要的功能。

開發過程受到意外的干擾或者估計的誤差導致時程延遲，有時難以避免。但面對牢不可變的完成日，最好的解決手段便是試著縮小系統範圍。在縮小系統範圍的過程中，最重要的工作便是和客戶協調，以爭取認同，最終還是有機會如期交付一個可以接受的版本。

作者簡介─王建興
	清華大學資訊工程系的博士研究生，研究興趣包括電腦網路、點對點網路、分散式網路管理、以及行動式代理人，專長則是Internet應用系統的開發。曾參與過的開發專案性質十分廣泛而且不同，從ERP、PC Game到P2P網路電話都在他的涉獵範圍之內。