閱讀筆記——怎樣做需求分析
當客戶提出業務變更的時候，我們一定不能被客戶牽著走，客戶說啥就是啥。我們要從業務角度深入的去分析，他為什麽提出變更，提得合不合理，我有沒有更合理的方案滿足這個需求。當我們提出更加合理的方案時，客戶是樂於接受的，變更也變得可控了。
這件事留給我的深刻教訓是，不能客戶怎麽說軟件就怎麽做。客戶提出的原始需求往往是不考慮技術實現，基於非計算機管理的操作模式提出來的。他們提出的很多需求常常比較理想而不切實際，畢竟人家是非技術的。但我們作為技術人員，需求分析必須實事求是的、基於技術可以實現的角度去考慮。所以我們必須要基於技術實現去引導客戶的需求。我們做需求就應當首先理解現有的管理模式，然後站在信息化管理的角度去審視他們的管理模式是否合理，最後一步一步地去引導他們按照更加合理的方式去操作與管理。
一個軟件項目的需求調研首先必須要進行角色分析，然後對不同的角色分別進行調研。需求調研的初期需要召開項目動員大會，這是十分必要的。但真正要完成需求分析，應該是一個一個的小會，1-3個業務專家，只討論某個領域的業務需求，並且很多問題都不是能一蹴而就完成的，我們必須與專家建立聯系，反復溝通後完成。需求分析必須遵從的是一定的科學方法，而不是盲目的大上快上。
需求分析不是一蹴而就的，它應當貫穿整個開發周期，不斷的分析確認的過程。如果我們提早將開發成果給客戶看，提早解決問題，後面的情況就將不再發生。這就是敏捷開發倡導的需求反饋。敏捷開發認為，需求分析階段不可能解決所有的需求問題，因此在設計、開發、測試，直到最終交付客戶，這整個過程都應當不停地用開發的成果與客戶交流，及時獲得反饋。只有這樣才能及時糾正需求理解的偏差，保證項目的成功。
怎麽樣做需求調研？
初識
對客戶提出的需求進行深入理解以後，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利於開發的可行方案，降低開發的風險。這毫無疑問會形成一個良性循環，但要做到這一點並不容易，毫無疑問，在與客戶接觸初期的表現起到了極其關鍵的作用。在進行需求調研的時候，什麽部門的需求就應當跟什麽部門談。同時，縱向又可以劃分為多個層次，如高層領導、中層領導與基層人員。
- 高層領導
高層領導關心的是宏觀的目標，因此軟件研發目標、宏觀統計報表、決策支持功能，都應當與高層領導談。他們關系的都是宏觀的問題，因此不要與他們談那些細枝末節。 - 中層領導
中層領導關心的是具體的效益，即軟件給各個部門信息化管理方面帶來的效益，因此，中層領導是各項業務流程、功能模塊的需求決策者。他們關心功能的定義、業務流轉的銜接、查詢報表的設計，但不太關心一些具體的操作，以及一些具體業務流程的細節。
- 基層人員
他們是真正了解你所要開發的軟件的業務需求的領域專家，是你進行需求調研的重點對象。但是，基層人員往往受到自身視野的局限，可能只清楚自己工作涉及的十分狹小的一個範圍，因此我們需要努力尋找那些業務涉及面廣，經驗豐富，又有一定大局觀的真正的專家。
劃分清楚角色，弄清楚每個角色的需求提出者與決策者，就是為了在今後的需求調研中找對正確的人，使今後的調研工作事半功倍。
拜訪
應當清晰地向客戶表達這樣一個意思，要完成這樣的目標，不是某一方的努力，而是雙方共同努力的結果。這也是客戶方召開這樣一個項目啟動會議的重要意義。最後一個成果，也是最重要的成果，就是與各種角色、各個類型的客戶建立了聯系。下面，我們將一個一個去拜訪他們，展開我們的需求調研。
分析一個客戶人群的關系，就是在分析這個人群中，誰有意願支持我們，而誰卻在自覺不自覺地阻礙我們。那些通過這個項目可以提高政績，提高自身價值的人，都是我們可以爭取的盟友。他們是我們最可以依賴的人，我們一定要與他們站在一起，榮辱與共，建立戰略合作夥伴關系。
研討會
業務研討會是重要的，但同時又是靈活的，沒有一個定式，甚至有時都不能稱之為會議。項目經理需要根據實際情況，合理地與客戶組織研討會。但不論怎樣組織，必須註意兩點：有效抑制個性化差異、分模塊組織專項研討會。
需求研討
在進行需求研討的時候，首先跟客戶探討的不是軟件功能，而是客戶現有的業務知識，用專業的話叫“業務領域分析”。客戶現有的業務流程是什麽樣的，都有些什麽操作？客戶在業務中都有些什麽事物，什麽專用名詞，都是怎樣定義的，相互之間的關系是什麽？客戶在每一項操作中的目的是什麽，為什麽要這樣做，他們制作的手工報表都說明了什麽問題？後面我會更加詳細地描述怎麽進行業務領域分析。需求分析不是一種簡單的你說我記的收集活動，而是在大量業務分析與技術可行性分析基礎上的分析活動。只有建立在這種分析基礎上的軟件研發，才能保證需求的正確與變更的可控。
思維導圖：
閱讀筆記——怎樣做需求分析