軟件系統設計過程中，最重要的就是對用戶需求的把握，只有清楚了解用戶到底想要的是什么，才有可能開發出用戶滿意的系統，用戶需求如果沒有把握對，就像客戶找你建一座房子，你以為是A這樣子的，客戶實際想要的可能是B這樣子的，自然做不出用戶滿意的系統。
為了準確把握用戶的需求，根據不同的實際情況有不同的方法，比如訪談，調查問卷，實地觀察、查閱歷史資料，開會討論，原型確認等。
項目背景
我們公司是一家電子元器件貿易商，主要業務模式為將國外品牌的電子元器件通過項目協同設計的方式分銷給國內的制造企業及設計公司。兩年前，我們公司自主開發了一套內部使用的銷售過程管理系統（內部名稱為COP系統），我作為IT部程序組經理，擔任了這個項目的系統分析師角色，負責系統需求收集、分析及系統設計工作。
COP系統定位于公司內部客戶服務人員的協同作業平臺，主要用戶為銷售和技術人員。系統為銷售人員提供項目機會的創建、項目機會跟進、項目機會轉化功能。而對于技術人員，如何鼓勵他們更多更好地服務有價值項目，同時避免資源過度集中，以實現公司整體價值最大化正是本系統著重要解決的問題。在此之前，我們的銷售人員有在另外一套系統上（內部名稱為DIT系統）上管理機會，新開發的COP系統是需要取代DIT系統的。
我們采用過的方法
為了把握用戶的真實需求，開發出用戶真正滿意的系統，我們采用了如下幾個方法：
01用戶問卷調查
系統用戶是全公司所有銷售人員，人員眾多，且人員分布在全國各地，不便直接訪談。為了收集大家對舊系統的改良建議及對新系統的期望，我們設計了一套調查問卷，透過OA系統發布到每個人的待辦任務中。問卷回收后，我們將所有改善建議分類統計，將用戶反饋最多的問題，加入到了新系統的開發需求中，比如速度，是用戶普遍反饋的需要改善的問題。
02關鍵用戶訪談
對于核心的業務流程，比如提交原廠注冊時的具體要求，我們采用了關鍵用戶訪談的方式。我們首先透過高層領導出面，指定了幾個關鍵用戶，然后我們直接找關鍵用戶當面了解具體需求。
03高層領導匯報
我們有了初步想法后，找高層管理匯報了我們的系統設想，同時也了解到高層領導對系統的管理需求，比如在什么場景中需要審批，審批的層級都是由高層領導確定的。
04舊系統反向工程
對于舊系統，我們查看了歷史文檔及源代碼，了解到舊系統中對于機會階段的定義及機會屬性字段，這些都沿用到新系統中，以方便遷移歷史數據，及減少用戶的學習成本。
05開會討論
對于涉及到多個部門之間銜接的流程，我們采用召集各部門領導開會討論的方式來確認需求。比如DR流程（有些廠商為了避免各個代理商之間惡性競爭，針對每個最終客戶的業務機會要求做備案登記，專門用語為申請DR，一家代理已經做了DR，其他代理商就不能再做了）。
原先我們采用的是各銷售自己到原廠注冊的方式，為了提高效率我們將這個注冊工作集中到一個客服人員身上，對于如何提交資料，如何審批，如何反饋結果這個流程我們找銷售經理及客服經理最終確認了下來。
經驗教訓總結
有效的方法
上面我們采用的方法中，效果最好的是關鍵用戶訪談，從關鍵用戶身上，我們了解到系統的核心業務流程，及用戶最急迫希望改進的功能，比如機會要匯總到項目層管理。同時，在與用戶溝通的過程中，用戶也加強了對我們的理解與支持，后面正式上線前，都是關鍵用戶幫我們做的培訓，效果比我們IT部門自己培訓效果還要好。
無效的方法
高層領導匯報方式是需要改善的，第一次匯報時，我們是用PPT文字的方式，將我們打算開發怎樣的功能，我們需要改善的地方向領導做了匯報，領導給出了一些指示。在臨近上線前，我們再次給領導作了一次匯報，這一次我們系統已經開發完成，所以直接做了系統演示，領導看到系統界面后，提出需要增加一個客戶活躍度字段，這個字段需要我們根據該客戶活動內容自動計算。我們只好重新設計開發此功能，系統延后了一個月才上線。
對于給領導匯報，我們覺得可以做如下改善：
- 開發中期需要定期給領導匯報項目進展情況，對于開發時間比較長的項目不能只在開發前匯報一次，開發后匯報一次
- 給領導匯報系統，最好是有形象化，圖形化的界面，在系統開發出來前，最好是用系統原型，給領導一個直觀的，可交互的界面，有利于領導理解系統并提出需求。
