軟體開發工作中有些項目時常被低估,許多開發上問題的根本多源自於這些低估。想要克服開發時的許多問題,就得明白這些項目容易被低估、而且意識到自己可能低估了。該做一些評估修正,才更有機會規避到這些問題。

開發範圍設定不夠周延

首先是容易被低估的,是軟體開發的範圍。簡單來講,也就是說,究竟要做多少功能,其實是容易被低估的。

通常,在開發軟體之前,會先從主功能發想起,因此,容易以為想像中的關鍵功能就是佔絕大多數的功能,當然也就容易以為完成關鍵功能,就大概完成了軟體。但是,一個完備的軟體需要很多配套的措施,有些功能時常在評估時會被忽略,但對軟體來說是重要的,像是設定功能、自動更新功能、……

低估了軟體開發的範圍,就會低估需要投入的工時,進一步就會低估需要的開發時間,當然也就低估了需要的開發成本。

愈是接近需求提出端,就愈容易低估開發的範圍。因為,需求提出者不見得自行會做完整的需求分析,他們會把焦點放在自己關注的事情、也就是心中想要的主要功能,但他們時常不會想到軟體要運行的全貌。所以當需求提出端和開發團隊協商開發時程及開發成本時,便時常因此出現明顯的落差,不是覺得開發團隊所估算的時程太長、就是開發成本太高。

而且,一旦低估了範圍,就容易讓開發專案的基礎想像和評估產生嚴重的偏差,但最後開發還是會回歸它原先該有的現實,回歸到該有的時程,耗去該有的成本。

需求變更的程度與頻率也容易被忽略

除了開發範圍容易被低估之外,需求的變更也時常被低估。需求提供者會低估自己在開發過程中變更需求的程度及頻率。他們時常會以為自己在開發初期即掌握了絕大多數的需求,設想了絕大多數功能的運作方式。但是,很遺憾地,這件事並不容易辦到。隨著軟體開發步伐的進展,需求提出者和開發團隊的討論、互動日漸密切、日漸增多,甚至隨著含有部份功能的軟體逐漸可以運作,需求提出者會逐漸對自己想要的軟體愈來愈了解。他們時常不能在開發之初,即了解自己需求的全貌,而是透過和開發團隊更多的討論,以及實際可運行的軟體,才愈來愈明白需求是什麼。這麼一來,當一開始設想的需求和之後所意識到的需求有所差異時,就必須透過需求變更來修正。

需求變更的程度及頻率時常被低估。不論是需求提出者或是開發團隊,都容易有個錯覺,即開發之初所提的需求,多半就是所有的需求了,殊不知愈到開發後期,需求變更的情況會時常發生,不見得是巨大的變更,但頻率不低。這使得開發團隊,需要花上比預期更多的時間來完成軟體。

除了需求提供者會低估需求變更的程度及頻率之外,開發團隊也會低估這兩件事。這使得開發時程及成本,也都會因此而低估。

忽視軟體測試時程與成本

在開發時程及成本的預估中,還有一項容易被低估,那就是軟體測試階段所佔去的時程及成本。許多人在觀念上太輕忽測試的重要性,總以為程式寫好了,就距離軟體完成不遠了,只需要略加測試,就可以準備發行了。但事實上,軟體測試是最省不了的環節,除非,你能夠接受軟體以差勁的品質狀態來發行。

偏重程式撰寫而輕忽測試,是很常見的通病,但是,這也會帶來對時程、對成本的嚴重低估。明明程式就寫得差不多了,軟體應該也差不多要完成了吧?這多半是許多人心裡的共通想法。但事實上,在測試修正的階段所花的時間,通常不亞於撰寫程式的時間,甚至更長。

測試的時間及成本取決於好幾個因素,但是,一般來說,大概起碼和撰寫程式的時間等長,更有人認為可能會到兩倍於撰寫程式時間之譜。

這麼長的測試修正時間,恐怕超乎不少人的想像,但實情的確是如此。看起來程式都有個樣子,軟體也基本上可以運作了。許多人都會認為即便有些地方會出錯,但距離完成應該不遠。但偏偏測試及修正十分耗費時間,找到一個臭蟲所需要的時間,通常是數倍、數十倍於寫下該段程式碼的時間。而且,往往需要長時間的偵錯,反覆不斷地執行驗證、重覆產生,才能找到讓該臭蟲發生的情境,此時也才能予以修正。

測試和修正,在許多人心裡可能是很沒有生產力的一個階段,但它絕對是必經的重要階段。並不是把程式碼寫好了,開發工作就接近尾聲了,測試修正的工作,一樣佔據著相當長的一段時間,並且沒有太多的靈藥可以縮短測試時間,因為品質最終還是會自己說話。

低估了測試修正的時間及成本,就會連帶低估整體開發的時程及成本,而這一項也正是很多人時常會低估的,而且在觀念中很難扭轉的。

最後要提的一個時常被低估的項目,是開發工時的單位成本。前面幾項容易被低估的項目,它們都是影響到工時,進而影響到整體時程及成本。而最後要提的這一項,則是每個開發工時的單位成本。

做一個軟體需要多少錢呢?它除了和總共需要多少工時有關之外,它同時也和每個工時需要花費多少錢有關。

對於一個公司內部自行開發的軟體來說,單位工時約略是投入人力的人力支出,也大概是薪資成本加上相關保險及福利的支出,這邊的疑義並不大,但對於一個外包專案來說,很常見到單位工時被低估的情況。

當我們將一個開發專案利用外包方式,委由外部的開發團隊來開發時,開發的報酬常常是基於工時預估的基準來做報價的。而委外方很容易用內部人員的薪資來做工時的單位成本估算,例如,委外方可能會以自己內部人員的薪資為基礎(例如一個月六萬元),來做為評估委外時人月工時的單位成本,因為心裡通常會想著,「如果我自己養人的話,大概需要付的就是這些錢」。但對承接方而言,不僅要考慮到人員的薪資、相關保險及福利的支出,也要考慮到必須要有利潤,而不能只從人員的薪資來計算。

在臺灣,倘若查詢一些組織所訂定的委外開發人員的報價基準,你會發現會和不少人心中的預期有滿大的落差。這是因為這些組織所訂定的報價基準是將種種環節,包括最後承接方應該要有的獲利都予以納入,而這才會是一個比較公平、合理的報價方式。

不少委外方之前也扮演過承接方的角色,但是一旦轉換成為委外方之外,就容易低估整體的時程以及單位工時的成本。

明明在承接方角色時就知道,其實一個軟體的開發需要的工時絕不會太短,而每個單位工時的成本也都不低;但轉換成為承接方之後,因為角色、心態的轉換,心裡想的是自己成本的降低,對於時程低估、對於總工時低估,對於每個工時該有的成本也低估。

在本文中,我列出了幾個在軟體開發專案中容易被低估的項目,這些項目低估的背後,都有一些既定的觀念,唯有意識到容易做出低估,才能提醒自己不要低估,也只有盡可能不要低估,才可以使專案的進行,更符合現實會發生的情況。

專欄作者

熱門新聞

Advertisement