“把握客戶需求”是軟體開發的一段冤枉路

         客戶基本不理解本身的需求，又如何能夠告訴我們所期待的“需求”呢?又如何會認同技術人員收集到的“需求”及確認所謂“需求說明書”呢?

軟體開發的冤枉路

大部分軟體開發從業人員常訴說“很難把握客戶的需求”。筆者認為這句話不應該從一個專業人員口中說出來，你聽過一個裝修工人告訴你他不能把握客戶的裝修需求嗎?但這卻是事實。如何能夠“把握客戶的需求”便成為軟體工程中急需解決的問題。

很多專家發表很多關於“應該如何才能夠把握客戶的需求”，“需要採用哪些手段”等理論。但筆者以過去三十多年科技企業軟體開發的經驗告訴大家，基本不用去“把握”客戶的“需求”。

軟體開發的冤枉路，帶來目前IT專案管理的另一段冤枉路，我們是繼續朝這條冤枉路走下去，還是找尋軟體工程的正確路線?希望各從業人員自己判斷，並做出適當結論。

國內對需求的解釋

筆者從1972年開始從事軟體開發，1979年開始成為開發小組主管，1984年正式成為專案經理，到今天已經積累了三十多年的開發及二十多年的管理經驗。筆者最近這兩年在國內從事教育及諮詢的工作中，發覺國內軟體從業人員所談的“需求”和過去在國外執行軟體開發時所談的“需求”有很大的差異。

在國外建設系統的時候，“需求”是技術人員建立的，不是從客戶提出的。但國內的軟體從業人員所談的“需求”是在“調研”過程中由客戶提出的。坦白說，客戶基本不理解本身的需求，又如何能夠告訴我們所期待的“需求”呢?又如何會認同技術人員收集到的“需求”及確認所謂“需求說明書”呢?

試想想，當我們要研製一件產品的時候，我們會問消費者他們對產品的需求嗎?也許我們會諮詢他們的意見，但生產商會綜合消費者的意見，廠商本身對市場的理解，和最終客戶群的採購“目的”來制定產品功能需求，最後成為產品的規格，才投入生產，推廣到市場中。這個道理很簡單，但我國軟體從業人員卻認為軟體工程與產品開發是不一樣的，不能用同一方法處理，一直在走冤枉路。

我們的做法是，從項目開始進行“調研”(另一個軟體工業的重大誤區)，對客戶的基層人員進行訪談，希望能夠在調研期間讓客戶說出本身的需求，從而把握客戶的需求，編寫所謂調研報告或需求說明書。

其實，所謂調研是進行調查，繼而進行研究，這是兩個工作，但我們常把它變成一個工作來進行。國內對“gatherrequirements”(收集需求)的理解是從客戶的訪談、調查、研究過程中發掘客戶的需求，由於客戶對需求不明確，技術人員未能把握需求，所以一調研便花費很長時間。

國外對需求的詮譯

國外軟體行業基本沒有所謂“調研”的概念。我們在項目的起始階段只有“factfinding”(或FF，即“找尋事實”)。顧名思義，FF的目的是理解客戶如何執行工作，技術人員對客戶進行訪談，目的並不是把握客戶的需求，而是理解客戶目前如何執行自身的工作。訪談報告只包括目前工作如何在部門中實施，是現狀的描述，所以往往能夠得到客戶的認同及確認。

他們在訪談結束後，開始對現狀進行分析，考慮整個工作流程是否合理，如何才能夠達到項目的目標，從如何達到項目的目標來決定項目的需求。

國內外的差異

我們必須認識到一點，軟體開發的目的是為企業提升生產率(Productivityimprovement)，提升工作效率(efficiencyimprovement)及建立商業效益(businessbenefits)，而不是為了滿足某一些需求。

如果項目的目的是為了滿足某一些需求來解決一些運營上的問題，那麼這些便是系統維護項目，不是系統開發項目。而且這些項目的需求通常比較明確，客戶清楚地知道需要增加哪些功能，可以直接告訴技術人員有關功能的需求。在現有系統中附加該功能，便能夠完成項目。而且這方面的需求可以得到各階層人員的認同。

軟體開發是為了提供一套完整工具(軟體加硬體)來完成一個部門或一家企業的“運營目標”，如何可以利用科技來使企業的運營更理想，是軟體開發的主要原因。所以當我們完成分析後，明確地理解需要哪些功能才能夠讓企業或部門更有效地達到目標，這些功能才是系統的真正需求。我們所說的“收集需求(gatherrequirements)，”基本上是包括找尋事實(FactFindings)和分析(Analysis)兩個階段的結果，不是國內所執行的“調研”一個工作希望直接帶出來的結果。