當時程延遲之後

在上一回中我們探討了時常被低估所需時間的工作類型，像是測試及修正所需的時間、以及需求變更可能造成的時程變化。另外，我們也提到了開發時程規劃中可能暗藏的不穩定因素，例如程式員為了讓表面上如期完成而暗藏在系統中的地雷，以及身兼多個開發專案中工作的程式員，很容易因為某個專案的工作延遲，造成了其他專案同步發生延遲的情況。雖然許多人都會透過加班來試著解決專案延遲的問題，但它終究非最佳良方。增加人力是個可行之道，但應該愈早加入愈好，因為專案的新成員總是需要時間適應上手。而事實上，每個專案成員都應該在專案有可能延遲的訊號時，提前讓專案經理以及所有成員都意識到，並且讓專案經理有機會開始規劃因應之道。

接下來，我們要談一個最現實的問題，倘若加班以及增加人力都無法挽救時程的延遲時，那麼專案該怎麼進行下去？是呀，專案總得進行下去。軟體開發的故事，大多都不是童話故事。或許經過專案經理以及所有團隊成員的努力，專案仍然無法準時在期限內完成，但這不百分之百意謂著這是不努力的結果，例如或許只是被意外的事件所擊中。

即使專案因為人為的疏失而造成了延遲，但延遲總是無法逃避的事實，與其在專案尚未結束之前便開始檢討，或者更負面的說推託責任，不如試著面對專案即將或已經延遲的事實，試著降低延遲所造成的傷害，這才是有正面意義的做法。我曾在一個專案會議中，聽到客戶指著專案經理說：「你倒說說看，因為這樣子而造成專案延遲了，究竟是你們的錯還是我們的錯呢？」專案經理很平和的回答：「現在討論究竟是那一方的過錯，對於讓系統上線也沒有太大的幫助，如果真的非得是某一方的過錯，那就算是我的錯好了，讓我們繼續來討論下一個待解決的問題吧！」很多人在專案面臨延遲時，時常會不知所措，便急著釐清責任甚至是劃分界線，確保專案的延遲責任與自己無關。但他們都忘了，讓系統上線或是讓產品交付才是最重要的事情。

有名的eXtreme Programming認為，軟體專案有四個重要變數中：成本、品質、時間和規模，想要調整其中任一項，就必須連帶跟著調整其他的變數。好比，你希望規模變大（例如希望擁有更多的功能），那麼你可能可以選擇延長時間、提高成本（例如投入更多的人力）、或者在不改變時間及成本的情況下降低品質（當然，很少人會選擇降低品質這個選項）。如果維持同樣的規模，你希望縮短時間，那麼就大概只能提高成本來達成了。事實上，eXtreme Programming的看法和現實情況也差相彷彿，但還是有不少人無法看清現實。

相信大家都有經驗，自己的客戶或老闆於專案進行中，期望在維持原時程的情況下，持續的擴增要開發的規模，但卻也沒有增加相對應的人力。於是，專案執行的結果，不是時間超出了紋風不動的期限，就是品質低落導致遲遲無法結案。想要更動這四大因子中的一項，卻又期待其他因子不跟著連動，簡直是很難做到的事情。事實上，這四個因子中，時間和規模相較於成本及品質，是比較好控制的兩個因子。

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

每個人都希望系統上線或產品發佈時，能夠完成所有規劃的功能，但是受迫於既定的時程，對於系統或產品的功能勢必就得有所取捨。當你決定透過削減規模來追求如期的上線或發佈時，你必須試著逐一的評估所有未完成功能的重要性。對某些人來說，每個功能的重要性都是五顆星，所以沒有一個功能可以被削減掉。但是，這麼想其實無濟於事。你必須試著以中性的角度來思考，究竟那些功能是真正不可缺少的功能，這樣子的功能可能是系統運作完全不可缺少的，也有可能是你的系統或產品所要強打的、可以與其他系統或產品建立市場區隔性的功能，這類的功能我們稱為「必備（must have）」的功能。相反的，有些被歸類為「有的話更好（nice to have）」的功能，這類的功能的存在，或許是讓使用者的操作流程更為流暢，或許是提供更貼心的作用，但無論如何，少了這樣子的功能，使用者並不會覺得系統殘缺了一大塊。所有的功能都可以依據它究竟有多麼的重要來一一的排定其優先順序。而你可以依據這個優先順序，逐一的刪除掉最不重要的功能，直到你認為這些未完成的功能得以如期完成為止。

區分各個功能的重要性，以及逐一將它們從系統功能清單中移除並不是難事，難的是要接受必須採取削減系統規模的事實，尤其是對付錢買單的客戶而言更是如此。對承接外包開發專案的團隊而言，客戶付的是固定的價碼，希望得到的也是他們所預期得到的系統。在這種情況下，開發團隊需要做的便是試著和客戶溝通協調。對開發團隊而言，希望爭取的是在首次上線日期無法更動的情況下，分階段來完成承諾客戶完成的東西。開發團隊可以試著讓客戶明白專案開發進度不符預期，以及之所以超出預期的原因，爭取客戶的諒解，並且溝通當不更動這上線日期的情況下，勢必削減系統規模的事實（因為通常在此時，加入新的人力已經緩不濟急）。所承諾客戶的系統功能，並不是不交付，而是分階段交付，先讓客戶能夠正式讓系統營運，之後再分批補足其餘的功能。專案到了這種情況，其實客戶和開發團隊已經在同一條船上，系統能夠上線，雙方的壓力都能夠釋放許多，堅持一定要在勢必延遲的時程下完成所有的預定範圍，有時便會顯得過於意氣用事，最後淪至雙敗的局面。事實上，即使上線的系統不夠完美，但能上線便是一個重要的里程碑。上線後，才更有機會碰觸到真正的使用者，得到更多來自於使用者的意見回饋，很多時候，更會發現原先還未實作的功能，其實根本反而是多餘的。

對於自有產品或系統的開發，雖然不需要跟外部的客戶溝通，但仍然少不了與內部客戶溝通的過程。其實自有產品、系統的開發多半比較有彈性
－ 不論是系統規模或時程。但面對不可更動的產品發表日或上線日，說服內部客戶削減系統範圍是比較明智的做法。事實上，有時候這也讓內部客戶以及開發團隊重新思考每個功能存在的必要性，畢竟經歷過一段時間的開發，不論是內部客戶或開發團隊，都對即將問世的產品或系統有了更深一層的了解，在去蕪存菁的情況下，反而可以濾掉原先所設想的系統範圍裡，其實不是那麼必要的功能。

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

Posted at 11:36下午 十月 05, 2009 by Chien-Hsing Wang in General  |  迴響[5]