如何做一個有效需求分析員

在繁忙的工作之餘回想一下，你是如何從一個普通的開發人員變成一個需求分析員的？也許只是突然有一天，你的上司拍著你的肩膀，微笑著的對你說：“這個項目的需求就由你來做吧！”。欣喜之後，心裡不禁有些發虛，“我能夠成為一個有效需求分析員嗎？”。

有效需求分析員為什麼難以產生

不容置疑，需求分析的正確、完整直接影響著項目的成敗，而需求分析員是需求分析正確與否的直接責任人。可是我們所受的教育，所處的工作環境制約了我們，讓我們很難成為一個有效需求分析員。
大學裡，老師們講課完畢後，就會留給學生幾道習題，而這些習題幾乎是不用經過思考就可以知道它的要求是什麼，根本談不上需求分析，更加不需要考慮如何去進行有效需求分析。然而，同樣是這些學生，畢業後卻要面對錯綜複雜、頻繁變化的需求，需要像專家一樣發現需求、挖掘需求，但是這些沒有經過良好訓練的“士兵”僅僅靠天賦和勤奮就能打贏這場艱苦卓絕的“戰役”嗎？
大多數的需求分析人員都是從開發人員成長起來的。工作中，我們長時間一言不發，面對著冰冷的顯示器，手指在鍵盤上翻飛，嘴角帶著神秘的微笑，用一種奇怪的符號在寫著什麼。我們生活在一個數位世界中，我們當中可能很多人從來沒有和任何一個客戶接觸過。可是突然有一天，我們發現自己不得不面對一大群使用者，更加糟糕的是這些人竟然不懂什麼是C++，也沒有聽說過互連網。“天啦，我能和他們說什麼啊？”
現在存在著這樣一種謬論，認為優秀的程式員也會是有效需求分析員，但是我們所接受的教育，我們的工作並不能教會我們如何成為一個有效需求分析員。就像編碼，測試，專案管理一樣，需求分析也存在著大量的技巧。很難想象不經過艱苦的訓練就能夠很好的掌握一種程式設計語言，需求分析也是一樣。但是現實中，很多的程式員沒有經過任何的訓練就變成了一個需求分析員，變成了一個缺乏足夠技巧的需求分析員。
什麼是有效需求分析員？一個有效需求分析員需要在需求分析過程中在工作中和使用者建立真正的夥伴關係，能夠在錯綜複雜的現象中發現問題背後的問題（the problem behind the problem），在陌生的領域內能學得更快，而且還要用共同的語言和使用者進行交流在工作中和使用者建立真正的夥伴關係。

和使用者建立真正的夥伴關係

我們知道使用者的營運目標是什麼嗎？我們知道使用者三年甚至更久的發展方針是什麼嗎？我們知道我們的軟體能夠給使用者帶來哪些利益嗎？使用者把我們當作朋友嗎？
和使用者建立夥伴關係往往是寫在紙上，而不是放在心裡，更難落實在實際行動中。和使用者建立夥伴關係不是空泛的口號，而是要為使用者的經營結果負責。它不是隔靴搔癢式的善願，而是要求苦樂與共的團結、有用資訊的交流和協力謀求成果。我們作為一個需求分析員，捫心自問，在需求分析中真的把使用者的商業目標放在第一位了嗎？真的把使用者看成我們夥伴了嗎？不瞭解使用者的目標，不尊重使用者的利益，我們能夠分析出讓使用者驚喜的需求嗎？能夠開發出為使用者創造大量價值的軟體嗎？
怎麼才能和使用者建立真正的夥伴關係呢？首先，要轉變我們的態度。很多IT人都是自詡為“社會精英”、“高科技人才”，在和使用者，尤其是傳統行業的使用者交流的過程中，幾乎是習慣性的傲慢。如果需求分析員帶著這樣的態度去工作，使用者會是什麼感受？是我們給使用者服務，還是來教訓使用者？帶著居高臨下的態度，我們又怎麼能夠做到“像使用者一樣思考”？所以，我們必須要改變自己的態度，真心實意的把使用者當作上帝看待。要明白，是使用者的錢養活了我們。第二，培養人際關係。需求分析不是做交易，不是把收了錢就可以置諸腦後的一鎚子買賣。我們要真誠的面對客戶，用真心換取真心，儘力和使用者成為朋友。第三，我們要展開我們的商業想象力。大膽尋求滿足使用者需求的更佳途徑。象使用者一樣看待事物遠遠不夠，我們要爭取看得更清晰，也就是常說的“超越使用者”。

發現問題背後的問題

當一個軟體項目開始後，使用者的要求往往是開發完成某個功能（如人事管理，財務等）的軟體，用來解決目前存在的問題。但是軟體真正能夠給使用者創造的價值是什麼，這是每一個需求分析員必需思考的問題。
需求分析應該是一種系統思考，是一種需要“見樹又見林”工作。有效需求分析員要把企業看成一個系統，並且把它融入大社會這個大系統中，全面的觀察使用者的工作，而不是片段的、一幕一幕的個別事件。比如使用者需要開發一個人事管理軟體，表面上的需求可能是更方便的對員工進行管理，但是實質上的需求可能是通過人事管理軟體來解決工作紀律鬆散、考勤不嚴格、人員流動隨意等問題。同樣的，使用者需要開發一個財務軟體，除了更好的管理資金，其真正的目的可能是為瞭解決內部財務制度混亂的問題。如果需求分析只是停留在表面的問題，而不能夠發現使用者真正關心的問題，很難相信開發出來的軟體能夠讓使用者發自內心的滿意。
如果發現問題背後的問題呢？在大多數公司，除了存在一些正式的組織之外，還存在著各種非正式的組織，這就需要需求分析員在需求分析的過程中，除了要利用正式的渠道（會議、訪談等）外，還要善於利用非正式的渠道（午餐中的交談、私人會談等）來瞭解使用者的需求。我們會發現非正式的渠道往往是發現問題背後的問題的關鍵。
另外，我們還需要掌握一種有效分析方法——“深耕法”。下面是一個深耕法的例子：

問題 原因  
今天早晨發生一起機床停工事故 　  
　 因為機床的密封圈漏油了  
密封圈為什麼會漏油？  　  
　 因為採購回來的密封圈品質不合格  
為什麼要採購品質不好的密封圈？  　  
　 因為價格低10％  
為什麼這麼小的價差還要採用品質不好的密封圈？  　  
　 因為採購人員的績效是按照採購成本來評定的。  
所以，問題的根本是要改變採購人員的績效評估標準！ 　  

  
通過一系列的“為什嗎？”，我們能夠很有效發現問題的背後的問題到底是什麼。
“使用者真正需要的是什嗎？”，每一個需求分析員在進行需求分析的過程中都應該不斷的問自己，要記住一個事實，“事情往往比它看起來複雜”。只有真正的融入到使用者當中，成為使用者團體中的一員，才能發現問題背後的問題，才能做出真正讓使用者滿意的產品來。

學得更快

不正確需求已經成為了導致軟體開發失敗的最大罪魁禍首，尤其是運用於非電腦行業的軟體。需求分析員往往不是主題專家，在十天半個月的需求分析中，我們很難完全理解一個擁有十幾年經驗的主題專家。這是一個很殘酷的現實，也是一個我們必須面對的事實。正是因為理解上的片面和偏差導致了很多軟體項目以悲慘的結局收場。
一個有效需求分析員應該是一個善於學習的人。只有學得更快才能讓一個需求分析員能夠在短暫的需求分析階段成為一個“行家裏手”，能夠像一個主題專家那樣思考、行動。但是學習能力也不是一朝一夕就能提高的，需求分析員要在日常的工作學習中不斷的加強，儘可能的用更快的速度來學習。只要堅持不懈，一定會大有收穫。
一個有效需求分析員也應該樂於學習的人。當他面對一個全新行業的時候，他能夠用超乎想象的熱情和速度去學習，去理解，去融入，而不是排斥、厭惡，甚至詛咒。很多IT人都有一種不好的想法，就是對傳統行業有一種近乎“天然”的排斥感，這種排斥感往往會導致需求分析員與使用者之間的隔閡和矛盾，其結果可想而知。

用共同的語言進行交流

當IBM AS400發布的時候，IBM專門在眾多的專家中找出一位既精通技術，又能夠把晦澀難懂的技術術語“翻譯”成易懂的口頭語言的專家，結果這位專家在發布會上用平實的語言說出了AS400的所有優點，在場的所有記者都能夠輕鬆的理解，從而使得發布會獲得了前所未有的成功。
作為一個需求分析員，對技術應該是有相當的瞭解的，但是我們不能奢望我們的使用者也能和我們一樣對IT技術有同樣精深的瞭解。使用者可能不知道什麼是“組件”，什麼是“物件導向”，甚至搞不清楚“10M頻寬網路和100M頻寬網路有什麼區別”。對於使用者而言，他們更加熟悉的是他們所在行業的術語和標準。於是奇怪的現象出現了，使用者和需求分析員用著互相不能理解的語言在交流，就好像是一個中國人和一個法國人各自用著自己的母語在交流，也許更多的是混亂，而不是共識。在這樣的情況下面，我們能夠奢望取得準確，全面的使用者需求嗎？
一個有效需求分析員應該怎麼解決這個問題呢？首先，應該努力的去熟悉使用者的行業，學慣用戶使用的術語，標準，以便能夠準確的理解使用者。這就需要我們大量的閱讀使用者所在行業的資料、文章，盡量多選取一些整體性介紹的文章，這樣可以在短時間內能夠對該行業有一個全面的認識，這樣我們就能夠較好的和使用者進行交流了。第二，應該盡量不使用IT行業的術語，而採用淺顯易懂的口頭語言來解釋IT行業中高深莫測的術語，以便使用者能夠很好的理解。我們可以向使用者這樣解釋10M頻寬網路和100M頻寬網路有什麼區別：“10M頻寬的網路就像是雙車道的柏油路，容易堵車，而100M頻寬的網路卻是二十車道的高速公路，堵車的可能性非常小”。這樣的解釋使用者就能夠很好的理解了。但是，用平實的語言解釋IT行業的術語並不是一件容易的事情。一方面它要求對該術語有透徹的理解，另一方面需要很好的表達能力。在平時的工作中，我們不妨試著把一些難懂的術語用平實的語言表達出來，甚至可以向一些不瞭解IT技術的人解釋一些艱深的概念。只要能夠堅持做下去，一定會有讓我們驚喜的進步。
需求之所以難以捕獲，是因為它們存在與使用者的頭腦中。有效需求分析員必須用自己智慧、行動和真誠去發現需求、挖掘需求。好的方法和習慣能夠讓我們的需求分析更加有效，也會讓我們成為一個有效需求分析員!

 
我幫人的原則：我不會說的很詳細，我會給你一個解題思路，你跟著思路走就會掌握解決問題的方法，方法比答案重要。