面對完成軟體專案的最後一道障礙

文/王建興(清華資工所博士班研究生)/iThome 2010-12-30

專案為何難以收尾第1回若需求分析沒作好,到最後仍要應付用戶端因此提出的大量變更請求,甚至要改變之前的設計、架構,付出頗大的代價

俗話說,萬事起頭難,但只要能開始、進入軌道後,一切就會慢慢順利起來。

對軟體開發專案而言,能啟動一個專案開始執行,雖然通常意謂著有新的潛在機會可望開拓,但相對於專案的啟動,要完成一個軟體專案的難度,一般來說,比開啟一個新的專案執行,來得難上許多。

對參與過軟體專案開發的人來說,不論只是專案的利害關係人,或者本身即為開發團隊中的一員,對於專案進入結束階段的那些經驗,大多留下深刻的印象。深刻的印象是什麼呢?我想許多人恐怕都會說:軟體專案的收尾,怎麼會這麼難啊!

開發後的成果不如預期,該怎麼辦?

每當開啟一個新的軟體專案之後,通常利害關係人和開發團隊都會對新的專案寄予厚望。一方面滿心期盼著專案一旦完成之後,所能帶來的好處,另一方面,對於過去一些專案上的挫折經驗,也都懷著昨日種種昨日死,今日種種今日生,務必一洗過去的所犯下種種錯誤的志向。

可是,許多人或許都會發現,就算專案啟動時,大家都歃血立誓,決心要讓專案順利完成,但就好像擺脫不了的輪迴命運一樣,許多過去遇上的負面情境,仍是一而再、再而三,在我們的專案執行過程中反覆出現,其中「專案難以收尾」的這種情況,是很多人都會遇上的共通悲慘遭遇。

專案難以收尾,常見的情境有那些呢?

一個時常見到的情況是,因為軟體已經開發接近尾聲了,所以具體的產物也愈來愈成形,而這個時候,客戶或者代表使用者的關係人,也就愈能更真實地目睹、接觸到即將完成的軟體、甚至有機會去操作。

這時候,可能發生兩種情況:

  1. 第一種是,客戶發現做出來的東西和他們預期的有所落差,甚至落差很大,所以客戶開始要求要修改開發團隊所做出來的產物,以便和他們的需求相符。
  2. 而第二種情況是,雖然開發團隊做出來的東西,的確就是當初開發團隊將他們的需求白紙黑字所記錄下來,也請他們親筆畫押確認過的東西,但是,客戶當初的設想的確是有所不足之處,必須要再做一些調整、甚至是補強、擴充,才有可能真的滿足客戶的需要,甚至使團隊所開發出來的軟體能真正的派上用場。

不少人都有碰過第一種情況。會發生這種情況,大多的問題出在需求了解的環節之上。和客戶訪談、討論需求的需求分析人員,沒有準確的了解、分析出客戶的需求,以致於造成後續的系統分析、設計、開發全部因此出了偏差,在開發的過程中又沒有讓客戶分段審查、確認的矯正措施,導致一直到了開發末期,才讓客戶發現這驚而不喜的結果。當然,因為做的東西不對,客戶端勢必發出可觀的變更請求,開發團隊持續為了這些變更請求,疲於奔命。收尾?當然很困難,因為這尾巴究竟有多長,還很難說。

第二種情況大多數人也不陌生。雖然問題並不出在對需求的認知錯誤,卻出在沒有誘導、協助客戶表達出正確的需求。開發團隊沒有大錯,但是,其實在「需求開發」上,還有進步的空間。當客戶開始使用軟體後,才陸續發現整個系統要能順暢運作,其實還缺乏若干機制或組成,這時,難免發出需求變更的請求,要求開發團隊協助修改、調整,或擴充。

許多客戶並不是不願意為他們沒有將需求表達完整付出代價(例如時間、或金錢),畢竟他們還是需要這些改變才能得到一個真正可用的軟體,但是,對開發團隊而言,專案後期的需求變更時常都是大麻煩,因為,需要改變的東西可能會影響到之前的設計、甚至是架構,到了後期才要改變這些東西需要付出頗大的代價。在客戶堅持不改不行的情況下,究竟需要再花多少時間才能完成專案,尚在未定之天。這要收的尾巴,同樣也不短。
這兩種情況都可以說是開發範圍無法收斂。一旦開發範圍遲遲無法收歛,開發團隊就要面對一個不確定性的目標,而只要目標不確定,究竟需要再投入多少時間和人力就無法評估,那麼專案究竟要何時結束,自然也難以估計。

積極因應需求本身多變的天性,避免雙方錯誤的認知與期待

細數許多難以收尾的專案,在需求面上搞不定,佔很大的比重。當然,對軟體開發而言,需求本身就是很難全盤掌握,許多開發者都承認在很多領域中,需求的天性就是多變。但面對這麼多變的東西,開發團隊的態度更應該是如臨大敵般的來面對,而不是抱持著,反正終究有可能改變,現在隨便一點也無所謂的想法。

當你用謹慎的態度來看待需求時,在和客戶討論需求時,你便會更積極的從各種角度,盡可能的和客戶進行溝通,以確認所收集的需求,的確和客戶所表達出來的相符。例如,有些人在和客戶討論軟體應有的功能時,會設計簡單的操作介面,或許沒有任何的程式碼,但是透過操作介面,可以更真實地讓客戶感受到未來所開發的軟體,究竟可能呈現出何等的面貌

因為你知道,只要在這個階段,多付出一些時間和力氣,避掉一個在需求上的誤解,日後就能避免在專案結束前夕,因此而耽誤更多的時間。

當你是個有經驗的需求分析者,你會知道客戶其實究竟需要的是什麼,未來他在建置系統或使用軟體時,其實還會面臨到那些真實的問題,但這些問題,都是客戶在需求分析時所沒有考慮到的,而你便可提出你的建議及觀點,進而和客戶得到更完善的討論結果。

消極、被動的規畫考量,以及溝通不足,可能會造成日後無法結案

同樣的,你不能因為客戶少提出了一些需求,而這些是你明明知道他終究會需求的,但你竟暗自竊喜,以為不讓客戶明白就可以縮小要開發的範圍,所以也就不告訴客戶其實他少設想了那些。但其實,「出來跑的遲早要還」

即便客戶在這個階段沒有查覺自己真實的需求,到了開發即將結束的那個時期,客戶終究是會積極和客戶溝通,盡可能基於自身的經驗、對系統運作的了解,對未來開發的預測,協助客戶規畫出一個真正可用的軟體。

需求分析通常都是軟體專案開發流程的先期階段,在這個階段謹慎、重視需求,而不要以輕忽的態度去面對,通常都對專案的收尾能夠起到作用。相反的,如果對需求的確認馬虎以對,那麼,通常最後的產物就是難以收尾的一個專案。

有些敏捷開發的方法論,便認真看待需求天生具有變動的本質,而在開發方法論中納入了許多考量和機制。

在這些方法論中,將需求視為十分容易變動,並不意謂著它們看輕需求對專案的重要性。相反的,這些方法論可以說是將整個核心精神,圍繞在需求容易變動的主軸上去建構。它們要解決的問題裡面,有些當然也就是許多專案開發到後期,因為需求難以收歛,因而很難收尾的情況

發表迴響