大部分軟體開發從業人員常述說「很難把握客戶的需求」。這句話基本上不應該從乙個專業人員口中說出來，你聽過乙個裝修工人告訴你不能把握他客戶的裝修需求嗎？但這卻是事實。如何能夠「把握客戶的需求」便成為軟體工程中急需解決的問題。很多專家發表很多理論，應該如何才能夠把握客戶的需求，需要採用那些手段，那些方法等等。。。。但我可以把過去三十多年科技企業軟體開發的經驗告訴大家，我們基本不用去「把握」客戶的「需求」。
軟體開發的冤枉路帶來目前it 專案管理的另一段冤枉路，我們是否還需要繼續朝這條冤枉路走下去，還是找尋我們軟體工程的正確路線？希望各從業人員自己判斷，並適當的做出結論。
國內對需求的解釋
從72 年開始從事軟體開發，到79 年開始成為開發小組主管，到84 年正式成為專案經理，一直到今天已經積累了三十多年的開發及二十多年的管理經驗，最近這兩年在國內從事教育及諮詢的工作，發覺國內軟體從業人員所談的「需求」和我過去在國外執行軟體開發時所談的「需求」有很大的差異。我們在國外建設系統的時候，『需求』是技術人員建立的，不是從客戶口中把握的。但國內的軟體從業人員所談的「需求」是在「調研」過程中由客戶提出的。坦白說，客戶基本不理解本身的需求，又如何能夠告訴我們所期待的「需求」呢？又如何會認同從業人員收集到的「需求」及確認所謂「需求說明書」呢？試想想，當我們要研製一件產品的時候，我們會問消費者他們對產品的需求嗎？也許我們會諮詢他們的意見，但生產商會綜合消費者的意見，本身對市場的理解，和最終客戶群的採購「目的」來制定產品功能需求，最後成為產品的規格。才投入生產，推廣到市場中。這個道理很簡單，但我國的軟體工業卻認為軟體工程與產品開發不是一樣的，不能用同一直方法處理，一直在走冤枉路。
從專案開始進行「調研」（另乙個軟體工業的重大誤區），對客戶的基層人員進行訪談，希望能夠在調研期間讓客戶說出本身的需求，好能把握客戶的需求，好能編寫所謂調研報告或需求說明書，所謂調研是進行調查，繼而進行研究，這是兩個工作，但我們常把它變成乙個工作來進行。國內對「gather requirements」 （收集需求）的理解是從客戶的訪談、調查、研究過程中發掘客戶的需求，由於客戶對需求不明確，技術人員未能把握需求，所以一開始調研下去便是半天。
國外對需求的詮譯
國外軟體行業基本沒有乙個所謂「調研」的概念。我們在專案的起始階段只有「factfinding」（或ff，即「找尋事實」）。顧名思義，ff 的目的是理解客戶如何執行工作，技術人員對客戶進行訪談，目的並不是把握客戶的需求，目的是理解客戶目前如何執行本身的工作。訪談報告只包括目前工作如何在部門中實施，是現狀的描述。所以往往能夠得到客戶的認同及確認。
在訪談結果後開始對現狀進行分析，考慮整個工作流程是否合理，如何才能夠達到專案的目標，從如何達到專案的目標來決定專案的需求。
國內外的差異
我們必須認識到一點， 軟體開發的目的是為企業提公升生產率（ productivity improvement），提公升工作效率（efficiency improvement）及建立商業效益（business benefits），而不是為了滿足某一些需求。如果專案的目的是為了滿足某一些需求來解決一些運營上的問題，那麼這些便是系統維護專案，不是系統開發專案。這些專案的需求通常比較明確，客戶清楚的知道需要增加那些功能，可以直接告訴技術人員有關功能的需求。在現有系統中附加該功能，便能夠完成專案，這方面的需求絕對可以得到各階層人員的認同。
軟體開發是為了提供一套完整工具（軟體加硬體）來完成乙個部門或一家企業的「運營目標」，如何可以利用科技來使企業的運營更理想，是軟體開發的主要原因。所以當我們完成分析後，明確的理解需要那些功能才能夠讓企業或部門能夠更有效地達到目標，這些功能才是系統的真正需求。我們所說的「gather requirements」基本上是包括fact findings 和分析（analysis）兩個階段的結果，不是國內所執行的「調研」乙個工作希望直接帶出來的結果。
整體解決方案
當完成分析後，有了全面的功能需求，接下來便需要讓客戶認識到他們的最終目的需要那些功能和如何可以利用科技（軟體及硬體）的結合來完成，這便是我們所說的解決方案。這時候還沒有對系統進行設計，只是讓客戶認識他們所希望的目標需要那些系統功能來完成。我們的目的是讓客戶認同只要我們的系統可以提供這些功能，便能夠達到他們的最終目的。這便是確認需求的目的。同時在確認這些需求的時候，把專案的範圍牢牢的建立起來。
客戶的確認
到這裡，相信大家都知道為什麼我們在國外可以讓客戶確認需求而國內的技術人員卻未能讓客戶確認需求了？很多同業往往感覺困惑，為什麼訪談結果可以讓被訪者接受，但每當要求對方主管確認的時候又被打回頭票呢？在回顧國內把握需求的方法，希望從訪談的使用者口中提供系統的功能需求，這是把我們的專業工作交給客戶來執行，他們又如何能夠完成我們本身做不到的工作呢？縱然訪談的客戶可以很明確的認識到本身工作上的需求，同時可以確認你遞交的調研報告或需求說明書，但這只屬於他本人工作崗位及工作層次上的需求，而部門主管及企業領導的需求是比較全面，肯定與有關工作人員所提出的需求有所不同，這份調研報告又如何能夠讓使用者主管或客戶確認呢！
未能把握整個解決方案的目標，未能分析整體工作的過程來建立目標的功能，出來的需求只能解決區域性的問題，未能做到「解決方案」的目標。其實我們只需要確認業主的專案投資最終目標，從分析的結果來建立所需的功能，便能夠有效地讓客戶認同這些主要功能，認同專案地需求。
開發的另一誤區
我常看到一些開發人員把過去一些案例讓客戶**，希望客戶從中可以理解本身的需求，然後在建設的過程中慢慢把需求建立起來，但這種方法往往讓我們無法把握專案的真正範圍，讓範圍不斷蔓延，導致專案不斷延誤，未能有效的完成交付。每乙個客戶有本身的思想，有本身獨特的需求，有企業本身的特色，**別人的案例只讓客戶增加本身對結果的期盼，不能完全解決專案的最終目的。尤其是近年來的專案多是概念性的專案。所謂概念性專案是從商業概念所產生的專案，例如「乙個客戶管理系統」來對客戶進行管理和提供客戶的服務，建立客戶滿意度等類似的專案，又
或者是客戶需要建立乙個「市場管理系統」來對企業產品銷售進行有效的分析及開拓市場方向等專案。這些專案便是我們現在所說的「資訊化」專案的建設。技術人員絕對不能夠把握這些概念性專案的需求，也成為目前國內資訊化過程的延誤和資訊化結果的最大障礙。九零年代中期，國際企業開始進行資訊化，在無數慘痛教訓後理解到技術人員本身的極限，對商業運營的最終目標並不認識，所以特意在軟體行開發專案中建立乙個新崗位，商業分析師（business analyst），商業分析師可以是資深的系統分析師，但必須曾經在工作的過程中對某乙個行業的運營相當理解，這包括在某個行業中曾經負責開發多種不同的專案，對企業的運營需求和運營方向全面理解。也可能是乙個部門的業務經理，經過培訓後理解如何進行分析，如何建立商業模式等方法。才負責專案初期的資訊收集，分析及設計工作。目的是因為技術人員對企業的業務並不認識，很難把握客戶的真正需求，改由商業分析師來理解客戶建立系統的最終目的，從目的中建立商業模式（business model），再從商業模式中建立主要的工作模組（process modules），從工作模組中建立運營流程（business procedures），再從運營流程中建立專案需求，這時候才轉交技術人員建立專案功能規格。
我國要改善軟體工程的困境，必須理解本身的問題，才能夠提公升我國軟體工業的發展潛力。高校的老師及導師必須理解我國軟體工業過去所走的冤枉路，才能夠培育更優秀的技術人員和軟體工程管理人員。軟體服務商的領導必須認識本身企業的缺點，盲目去進行各種認證只能治標，不能全面解決企業本身的服務缺憾，需要建立本身的體系及制度，建立企業的開發文化，更需要全力提公升管理人員，對軟體工程的開發進行有效管理。而各應用單位的領導更需要認識本身必須投入專案的開發過程，才能夠有效的讓專案投資帶來回報。
聚焦OA選型陷阱，讓你不走冤枉路
目前國內oa市場日益成熟，近幾年隨著企業對oa產品的需求增加，催生了很多新品牌。不可否認新品牌的誕生推動oa技術上的革新，新品牌的溶入讓整個軟體行業也呈現一片欣欣向榮的面貌。然而，對於企業來說，選擇的越多，就越難選擇。如果一頭扎入oa海洋，您會覺得這也需要那也很好，而選型的結果往往偏離實際或者無法實...
家裝少走冤枉路，揭秘領跑機濱特爾軟水機各項引數
在日常生活中,是否遇見過這些現象?衛浴裡的鏡面 檯面等位置到處是水垢和白色粉末狀的堆gkxsybyqv積物質 熱水器等涉水家電裝置管路堵塞 洗完的衣服僵硬 易褪色 這些大多都是由於生活用水的硬度過高而導致的。而水質過硬,大概率是因為水中鈣 鎂離子含量程式設計客棧較高。軟水機則可以通過離子交換樹脂去除...
當前中國工業軟體市場的發展現狀
當前中國工業軟體市場的發展現狀 鄭炳權 發表於 2012年07月11日 來自 預設分類 工業軟體最早出現在上世紀80年代初，80年代的工業軟體是基於 dos系統 開發的，當時的主要產品是onspec paragon和ifix等 進入90年代，主要是基於windows系統的，如intouch king...