Archive for 四月, 2008

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

軟體專案開發常常會面臨時間不足的問題。 大多數軟體開發人員都不希望青春浪費在無意義且永無休止的加班上,然而,現實就是如此殘酷,受限於市場競爭壓力的考量,為了爭取案子,常常會不得不遷就營運觀點,而放棄工程與技術的堅持,因而使得專案無法爭取到合理的開發時間。

 

工程與技術的妥協

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

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

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

 

生產力的迷思

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

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

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

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

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

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

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

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

 

開發產出與產能之平衡

由此可知,在專案開發時間不足的情況下,生產力迷思下的程式產出,其實多半無法具有實質效用。開發者在龐大時間壓力難有思考的空間,將使他的產能逐漸耗竭殆盡。即使在剛開始,一時滿足了客戶的需要,然而長久下來,卻在無形之中增加了專案的複雜度,最終只會在耗盡開發者的青春與熱情之後,得到專案失敗的苦果。

因此,在專案時間不夠的情況下,要達成不可能的任務必須要提昇軟開發的產能,必須讓開發的產出與產能可以相互配合。

至於如何增進良好設計架構的產能呢?依我軟體專案開發的實務經驗來看,關鍵在於必須同時兼顧客戶價值與開發風險。而要做到這一點則必須要讓開發者與客戶充分溝通。

我常常觀察到許多開發者習慣把客戶提出來的功能直接當做軟體需求規格,卻沒有深入分析客戶真正遇到的問題。他們以為問題領域、業務流程或現場作業等知識是客戶的專業,開發者無從介入,因此往往在不知客戶要求之所以然的情況下,直接把客戶的話轉換成軟體規格。

然而,客戶所知道的並不是軟體需求(requirements),他們對系統的觀點只能顯露出他們對系統的需要(needs)。需要是抽象而片斷的,本身是非結構化的,而可用的軟體需求卻必須是具體而完整一致的,具備結構化的特性。

因此,如果開發者沒有針對客戶需要分析他們的問題,設計解決方案,只是直接把客戶的想法直接轉成軟體規格的話,客戶心中想的那朵雲,隨時都會變幻出各種不同的形狀,需求不斷變動乃是必然。如果開發者沒做適切的分析及設計,只靠技術是很難滿足客戶多變的渴望與需要的。

事實上,軟體開發是知識與腦力密集的工作。自許為知識工作者,重要的不在於產出的數量,而在產出的品質。要讓產出具有足夠的品質,必須要在問題領域的分析投入足夠的時間,才可能為客戶設計出可以解決他們問題的軟體,為客戶創造價值;軟體也才能具備足夠彈性適應客戶千變萬化的需求,有效地降低開發風險。

 

正確的溝通

於是,當我們用以上的思路來看軟體開發時,縱使專案沒有足夠的開發時間,我們依然要會從客戶的立基點中去思考問題,並從中找出最可行的技術來創造客戶的最大價值。同時,在這樣的情況下,開發者展現了足夠的專業,客戶也會很自然地信任開發者誠意與專業,形成了良性的雙向溝通。

在這種客戶與開發者良性溝通的情況下,客戶可以決定了時程、成本、品質等限制條件,而專案範疇的限制條件則應該由開發者與客戶溝通後依業務需求及技術架構的取捨來決定。

也就是說,客戶提出他的問題、以及希望解決的時限及願意付出的成本。開發者則針對問題分析出需求規格、發展出技術架構,並據此實作出軟體後再交由客戶驗收。然後,客戶再依軟體實際使用狀況予以回饋,開發者再依照客戶的意見反覆地演化系統,使軟體更趨於完善。

理想狀態是,客戶應該優先提出最關鍵及最核心的業務問題,而開發者則必須針對這些問題分析,發展出軟體需求、找出解決問題應採用的技術與方法、優先將最高風險及最核心的架構與程式實作出來。如此客戶最重要的問題可以優先被解決,而開發者也可以針對客戶問題而設計,而不會浪費時間與成本在過度設計上,降低了軟體開發的風險與複雜性,使得產出與產能可以相互配合。

開發產出與產能相互平衡,才不會偏廢於需求面或技術面,使技術可以面對現實地解決客戶的問題。就算開發時間真的不夠,至少也可以用空間換取時間呀。無論如何,客戶至少都會擁有一個可用的系統,而不是一堆無法正常運行的程式碼與文件。

發表迴響