專案時間不足 如何達成不可能的任務 (上)

| | | | |

    

工程與技術的妥協

在台灣，軟體定價通常是由市場供需機制決定，不見得可以考量到軟體開發的成本。當市場競爭愈激烈時，軟體的價格相對降低。當軟體專案把軟體價格當做專案成本估算的基礎時，這樣軟體開發就會沒辦法重視專業，只能讓外行（市場因素）領導內行（研發設計專業），軟體開發者的痛苦夢魘於是從此開始。

開發單位為了獲利，於是就必須想辦法降低開發成本，但因為軟體價格實在太低了，開發者只好捨棄一些可以增進或維持軟體品質的作業。結果軟體品質就會變成時間允許才能夠達到的理想，無奈現實通常是「時間總是不夠」。

從筆者在工作上的觀察中發現，不少的管理者會將這個問題焦點放在團隊生產力上，以提昇軟體的開發效率來縮短開發時間。不過，實際上卻不見軟體開發成果獲得到顯著地提昇。

生產力的迷思

通常，管理者會希望軟體開發者加班或是增派開發人力，來提昇軟體開發的生產力。軟體開發每日總工時增加了，照理說應該是可以增加軟體開發的效率，但卻也因此引發出新的問題。像是，隨著每日工作時數或開發人力增加軟體開發出錯的機率反而增加，反而降低了軟體開發的效能。

為什麼會這樣呢？綜歸一句話，生產力增加了卻讓軟體開發變得更複雜，使得團隊無法有效整合、發揮綜效。而這種現象又可從兩個方面來看，一方面是加班讓開發者身心耗弱、無法集中心力來完成任務，因此常因為工作疏忽而產生錯誤，反而讓問題變得更複雜，需要花更大的心力來解決。另一方面則是團隊規模變大，需要更多的溝通時間與成本來整合工作成果，因此每個人的工作量不減反增，同時又有意見分歧可能引發團隊衝突影響專案績效的風險。

理論上，壓縮專案時程可以運用趕工（crash）或作業重疊（fast tracking）的方式來減少開發時間。趕工讓工作者加班而增加開發成本，作業重疊則會增加工作產出重工（rework）的風險。因此，原本以為只要多付一些成本來支應加班的需求或加強風險管理就可以達到時程壓縮的目標。然而，由前面的分析我們卻可以發現到，軟體開發的複雜度經常超乎我們想像，由此可知，軟體專案的時程上的妥協其實是很難用成本來彌補的。

筆者最近才聽到朋友告訴我一個軟體專案失敗的案例。該專案是以另一個將近結案的專案為基礎。原來他評估勉強半年可以完成，本來公司把專案交由他負責，但最後專案經理卻因為客戶的意見而交由負責該客戶的業務來掛名，實際上專案由我的朋友來負責開發。

然而，當我的朋友才開始需求訪談時，專案經理卻告訴我的朋友他程式開發時間要在三個月內完成。而在我的朋友認為，應該研讀前一個專案的程式碼，以求了解程式架構以後才能根據客戶需求加以修改，那位專案經理卻以前專案「沒有問題」為由，要我的朋友立刻著手動手修改程式，後面再來處理其他問題。

雖然我的朋友還是在時限內完成了程式，不過，這時候問題才真正開始。客戶驗收後提出了上百個程式錯誤。這時候我的朋友才發現，這專案所依據快結案的專案本身就有很多問題，事實上，有3/4的bug都是那個專案本來就有的。

此外，客戶還提出了一些原先沒談到的需求，而那位專案經理則要求我的朋友要在不增加時間的情況下照單全收。因此，在需求不斷膨脹的情況下，這個專案最後還是失敗了。當然，最後那位專案經理把失敗的所有責任都推到我朋友身上。

相信任何有經驗的軟體開發者看到這故事都會了解，那個專案經理實在是太外行了。他以為軟體開發只是依據客戶的需要來產出程式，認為只要壓縮開發者的時間來產出更多的程式就可以解決問題。殊不知軟體開發在缺乏產能的情況下，再多的產出也只是徒增軟體的複雜度與風險，這樣要完成專案目標只能靠聽天由命了。(待續)