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

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

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

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

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

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

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

這時候，可能發生兩種情況。第一種是，客戶發現做出來的東西和他們預期的有所落差，甚至落差很大，所以客戶開始要求要修改開發團隊所做出來的產物，以便和他們的需求相符。

而第二種情況是，雖然開發團隊做出來的東西，的確就是當初開發團隊將他們的需求白紙黑字所記錄下來，也請他們親筆畫押確認過的東西，但是，客戶當初的設想的確是有所不足之處，必須要再做一些調整、甚至是補強、擴充，才有可能真的滿足客戶的需要，甚至使團隊所開發出來的軟體能真正的派上用場。

不少人都有碰過第一種情況。會發生這種情況，大多的問題出在需求了解的環節之上。和客戶訪談、討論需求的需求分析人員，沒有準確的了解、分析出客戶的需求，以致於造成後續的系統分析、設計、開發全部因此出了偏差，在開發的過程中又沒有讓客戶分段審查、確認的矯正措施，導致一直到了開發末期，才讓客戶發現這驚而不喜的結果。當然，因為做的東西不對，客戶端勢必發出可觀的變更請求，開發團隊持續為了這些變更請求，疲於奔命。收尾？當然很困難，因為這尾巴究竟有多長，還很難說。
第二種情況大多數人也不陌生。雖然問題並不出在對需求的認知錯誤，卻出在沒有誘導、協助客戶表達出正確的需求。開發團隊沒有大錯，但是，其實在「需求開發」上，還有進步的空間。當客戶開始使用軟體後，才陸續發現整個系統要能順暢運作，其實還缺乏若干機制或組成，這時，難免發出需求變更的請求，要求開發團隊協助修改、調整，或擴充。

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

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

當你用謹慎的態度來看待需求時，在和客戶討論需求時，你便會更積極的從各種角度，盡可能的和客戶進行溝通，以確認所收集的需求，的確和客戶所表達出來的相符。例如，有些人在和客戶討論軟體應有的功能時，會設計簡單的操作介面，或許沒有任何的程式碼，但是透過操作介面，可以更真實地讓客戶感受到未來所開發的軟體，究竟可能呈現出何等的面貌。
因為你知道，只要在這個階段，多付出一些時間和力氣，避掉一個在需求上的誤解，日後就能避免在專案結束前夕，因此而耽誤更多的時間。

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

消極、被動的規畫考量，以及溝通不足，可能會造成日後無法結案
同樣的，你不能因為客戶少提出了一些需求，而這些是你明明知道他終究會需求的，但你竟暗自竊喜，以為不讓客戶明白就可以縮小要開發的範圍，所以也就不告訴客戶其實他少設想了那些。但其實，「出來跑的遲早要還」。

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

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

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

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