很多需求分析的工作是從需求調研開始的，我們就從這里說起吧。需求調研是需求分析最重要的一環，也最集中地體現了需求分析的特點——既是一份體力活兒，更是一份技術活兒。它既要求我們具有一種理解能力、設計能力，更要求我們具有一種與人交往、溝通的能力。
在一個陽光明媚的下午，項目經理帶領著項目組成員，參加了客戶組織的見面會，一個新的軟件研發項目就這樣開始了。雙方在一種友好的氣氛中進行，相互寒暄，介紹與會人員，拉拉家常。逐漸地，會議開始進入了正題。初次接觸客戶，對于項目團隊意義重大。對方對你印象的好壞，今后如何與你交往，都在這個階段被確定下來。然而，在客戶至上的今天，與客戶保持適當的謙卑是有必要的，但過于的謙卑卻常常給項目日后的進程帶來風險。為什么這么說呢？過于的謙卑，處處都是諾諾諾，客戶說什么就是什么，就會使客戶變得非常強勢。這樣的結果就是，客戶提出了許多變態的、不太現實的、不合理的需求，而我們呢卻是一味地服從，客戶說什么就是什么。最后我們做得很累，結果卻不能讓客戶滿意。
正確的做法是，我們對客戶提出的需求進行深入理解以后，運用我們專業知識，提出比客戶的原始需求更加合理、可操作的解決方案，讓客戶感覺你說的正是他們想要的。如果能夠這樣，客戶不僅能夠欣然接收你提出的方案，而且會感覺你非常專業，你在客戶心目中的形象也會無形中提高，使你有更多的機會提出有利于開發的可行方案，降低開發的風險。這毫無疑問會形成一個良性循環，但要做到這一點并不容易，毫無疑問，在與客戶接觸初期的表現起到了極其關鍵的作用。
人與人交往，往往在接觸的初期就決定了相互的行為方式，與客戶交往也是一樣。起初的唯唯諾諾，客戶說啥就是啥，必然造成客戶不再關注你的意見，對你發號施令就可以了。相反，起初展現出一位技術專家的姿態，能大方而得體地提出自己的意見，會使客戶重視你的意見，甚至主動征求你的意見。這一方面要求我們對自己要有足夠的自信，另一方面也要有循循善誘的表達能力。如果我們做到了這些，就會客戶心目中形成一種威信，使項目向著一種良性的方向前進。
同時，這樣的會議又是一個項目啟動會議。客戶方領導要在會議上傳達給與會代表一個清晰的信號，那就是與會代表今后要積極配合我們完成今后的工作。這時候，我們要弄清，客戶方有哪些角色，誰是這些角色的需求提出者與決策者。這是什么意思呢？在軟件項目中，特別是管理型軟件項目中，客戶都代表的是一個群體，而不是個人。他們代表的可能是一個單位、一個集團，甚至是一系列組織機構。在這樣一個群體中，他們按照職能被劃分成了不同的角色。拿一個單位來說，橫向可能劃分成不同的部門，財務部、銷售部、采購部、生產部······不同的部門，由于業務的不同，對軟件的需求自然是不同的，因此我們在進行需求調研的時候，什么部門的需求就應當跟什么部門談。同時，縱向又可以劃分為多個層次，如高層領導、中層領導與基層人員，理解這些方面格外重要：
1. 高層領導高層領導關心的是宏觀的目標，因此軟件研發目標、宏觀統計報表、決策支持功能，都應當與高層領導談。他們關系的都是宏觀的問題，因此不要與他們談那些細枝末節；
2. 中層領導中層領導關心的是具體的效益，即軟件給各個部門信息化管理方面帶來的效益，因此，中層領導是各項業務流程、功能模塊的需求決策者。他們關心功能的定義、業務流轉的銜接、查詢報表的設計，但不太關心一些具體的操作，以及一些具體業務流程的細節；
3. 基層人員基層人員是每一項業務流程的操作者，也是軟件今后真正的使用者。他們是真正了解你所要開發的軟件的業務需求的領域專家，是你進行需求調研的重點對象。但是，基層人員往往受到自身視野的局限，可能只清楚自己工作涉及的十分狹小的一個范圍，因此我們需要努力尋找那些業務涉及面廣，經驗豐富，又有一定大局觀的真正的專家。另外，他們就是軟件今后真正的使用者，讓他們參加，會讓他們成為今后軟件推行的忠實支持者，對其他操作人員的指導者，益處多多。而他們關心的則是每項操作的細節。
劃分清楚角色，弄清楚每個角色的需求提出者與決策者，就是為了在今后的需求調研中找對正確的人，使今后的調研工作事半功倍。另外，如果客戶方是一個集團、一個多組織機構的政府機關、事業單位，需求的多元化問題必須引起我們的足夠重視。什么是多元化問題呢？比如同樣一個業務操作，在同一級別的A單位是這樣操作的，而在B單位卻是那樣操作的。需求的多元化往往會給今后的軟件開發帶來巨大挑戰。因此，我們要在需求調研階段降低軟件的多元化需求。要解決這樣的問題，首先應當從高層領導著手，提出規范化管理的口號。同時，在進行需求調研時，盡可能地召集各個單位的代表在一起開會討論。同時，應當有高層領導，或者指定一個負責人，在出現分歧的時候最終拍板決策。這些都需要在項目啟動的時候事先規劃好。
最后，與客戶方領導制訂出軟件目標，是相當重要但常常被我們忽視的一個步驟。軟件信息化管理不是包治百病的神藥。很多項目的失敗都歸因與項目目標不明確造成的項目范圍的失控。因此，這時討論項目目標，既重要又適時。
也許在此之前我們已經做足了功課，對業務需求進行了一番詳細的整理，有了一大堆疑問急需解答。但是，在這時，不是解答具體問題的地方，這是我們常常會犯的一個毛病。在這樣一個會議上，我們應當詢問客戶方領導對這個項目的期望，渴望達到的項目預期，而我們應當描述的，是對達到這些預期的整體解決方案，凡此等等。
俗話說：萬事開頭難。如果你在項目開始的時候總感覺千頭萬緒不知如何著手，在這里我給大家的三點建議：1）樹立良好的職業威信；2）進行詳細角色分析，將與會各方代表對號入座；3）從宏觀上制訂目標與方案。隨后的工作，就是與各方代碼建立聯系，逐一拜訪他們，將需求調研工作一步一步進行下去。
我們應當怎樣做需求分析我們應當怎樣做需求調研：初識我們應當怎樣做需求調研：拜訪我們應當怎樣做需求調研：研討會我們應當怎樣做需求調研：需求研討我們應當怎樣做需求調研：迭代我們應當怎樣做需求調研：需求捕獲（上）我們應當怎樣做需求調研：需求捕獲（下）我們應當怎樣做需求分析：功能角色分析與用例圖我們應當怎樣做需求分析：業務流程分析（上）我們應當怎樣做需求分析：業務流程分析（下）我們應當怎樣做需求分析：用例說明我們應當怎樣做需求分析：查詢報表分析我們應當怎樣做需求分析：子用例與擴展用例我們應當怎樣做需求分析：行動圖和狀態圖我們應當怎樣做需求分析：業務領域分析我們應當怎樣做需求分析：原文分析法我們應當怎樣做需求分析：領域驅動設計我們應當怎樣做需求分析：非功能需求我們應當怎樣做需求確認：需求列表我們應當怎樣做需求確認：一個需求列表的實例我們應當怎樣做需求確認：快速原型法我們應當怎樣做需求確認：需求規格說明書我們應當怎樣做需求確認：評審與簽字確認會（續）
本站僅提供存儲服務，所有內容均由用戶發布，如發現有害或侵權內容，請
點擊舉報。
