在幾年的專案工作中，積累了一點和使用者溝通的經驗。
如果你做的專案業務是你熟悉的，那還好，如果是你不熟悉的，一定要花點精力學習一下這個行業業務的背景資料。畢竟，客戶是不可能給你系統地介紹業務的。只有你通曉了行業業務，才能和使用者交流，並正確而有效地引導客戶，做好需求分析，你不能指望客戶能明確地說出需求。當然，這也是系統分析人員的職責所在。
在開始做需求的時候，你最後花一點時間搞清楚你接觸的客戶是不是做實際業務的客戶，如果你面對的客戶不是將來的系統的實際使用者。你就有點麻煩了。可能他是客戶公司派過來的it部的人，他會提一大堆東西，而這些東西可能根本不是實際業務需要的功能，而他一般還會興致勃勃地給你一些技術實現的建議。這個時候你就要小心了，如果你聽了他的話，你可能在最後才發現，你花了大量精力解決的問題，其實並不是客戶真正需要的。而你真正需要關注的，卻做得遠遠不夠。
弗洛伊德說過，每個人都有三個層次，自我，本我，和超我。軟體需求也有三個層次，業務需求（business requirements），使用者需求（user requirements），功能需求（funtional requirements）和非功能需求。業務需求反映了客戶或組織結構對軟體系統，產品的高層次的目標要求，它們在專案檢視和系統範圍文件中說明。使用者需求描述了使用者使用系統必須要完成的工作或任務，這在用例圖中說明。功能需求定義了開發人員必須實現的軟體功能，使使用者能通過使用軟體，完成他們的工作，從而也就實現了使用者需求。除了系統能滿足使用者的功能之外，使用者對系統還有很多期望，比如，系統的易操作性好不好，執行效率高不高，反應速度快不快，可靠性如何等等，這些就是非功能需求。你必須區分出這三個層次的需求。這些工作都需要你根據你的業務背景或你的學習來完成。
對於企業系統來講，你需要面對不同層次，不同部門的客戶。要廣泛聽取意見。不同組織機構層次，不同業務部門，甚至不同計算機使用水平的客戶對系統的要求都會有不同。比如，總經理級別的客戶可能只是對巨集觀報表感興趣，業務細節操作他們一般不會發表什麼意見。部門經理則關注日常工作報表，系統功能的實現以及可能的擴充套件策略。普通業務操作人員則關心操作方式，介面風格，易用性等等。因此，把客戶分成不同的群組就變得非常有價值，這樣將會使需求分析的工作變得簡單。因為你可以把從不同群組的維度來分析需求，對於特定的需求問題，你則需要關注特定的客戶群來合作溝通。
需求獲取過程中的逆向溝通
一 需求的分類 需求分析是構建軟體系統的乙個重要過程。一般，把需求型別分成三個型別 1 業務需求 business requirement 反映了組織機構或客戶對系統 產品高層次的目的要求，它們在專案檢視與範圍文件中予以說明。2 使用者需求 user requirement 文件描述了使用者使用產品...
軟體專案開發過程中的需求分析心得
目錄參考 需求分析是軟體計畫階段的重要活動，也是軟體生存週期中的乙個重要環節。該階段是分析系統在功能上需要 實現什麼 而不是考慮如何去 實現 需求分析的目標是把使用者對待開發軟體提出的 要求 或 需要 進行分析與整理，確認後形成描述完整 清晰與規範的文件，確定軟體需要實現哪些功能，完成哪些工作。1 ...
ERP實施過程中的溝通管理研究
關於溝通管理，內容很多，也聽了大師級老師的培訓，自己略微總結一下，並結合 erp專案實施的具體特點來談談如何與客戶做溝通。這裡先講講溝通的基本概念，後期在深入體會 erp實施過程中如何與客戶進行溝通，希望更多的朋友參與討論。一 為什麼需要溝通？溝通的目的是什麼？一般來關於溝通管理，內容很多，也聽了大...