[轉載]給IT人員支招：如何跟業務部門談需求分析？

一提跟業務人員作「需求分析」，許多IT人員馬上就頭大了，要麼不在同一個「頻道」講話，要麼「變來變去，定不下來」。如何跟業務部門談需求分析呢，咱們帶着這個問題，與聚冠因尚的諮詢顧問楊春波展開了討論。

一、 有的IT主管抱怨業務部門提出的需求，IT人員看不懂甚至根本不能稱之爲需求，您以爲爲何會出現這種狀況？

聚冠因尚楊春波：

這是比較常見的現象，「語言不通」是形成這種狀況的主要緣由之一。在企業信息化程度不高的狀況下，業務人員的系統使用經驗較少，他們提出的需求每每用的是「業務語言」，好比說，「我須要在錄入這兩項數據以後，分攤成本能在這個窗口直接蹦出來……」。而咱們IT人員熟悉的是「系統語言」，好比「能以這個字段爲關鍵字，按照結算時間順序排列，出個報表」。

從「業務語言」到「系統語言」，須要一個「翻譯」的過程。若是IT人員在公司時間不長、或者是對業務不熟的話，難度確實是不小的。咱們的IT主管們也別上火、少抱怨，應該注意培養IT人員的業務知識、鼓勵IT人員常常與業務部門多交流。早就據說財務人員要「走出帳房」了，咱們的IT人員也應該不時地「遠離電腦」。

二、 業務人員與IT人員在需求分析階段的分工是什麼樣的？

聚冠因尚楊春波：

在需求分析階段，IT人員切忌只作「聆聽者」，還要兼作「翻譯師」和「培訓師」。

「聆聽」業務人員的需求是第一步，但IT人員要儘可能避免「你只管說，我只管作」的局面。「系統反正是按業務部門提得需求作出來的，好很差用別怪我」 ，這種想法看似很安全，實際上是找麻煩，等到系統被改來改去的時候，才發現雙方都浪費了時間。

IT人員還應作好「翻譯師」。將業務需求整理並轉化爲「業務需求說明書」，並將整理好的文件與業務部門進行充分的溝通，來確認是否準確、完整地表述出業務部門的需求。

IT人員還應作好「培訓師」。在企業信息化程度不高的狀況下，培訓工做尤其重要。IT人員應建議業務骨幹參加有關信息化內訓或外訓課程，讓他們多聽「IT理念」、多瞭解「信息化案例」，促使雙方有更多的「共同語言」。

三、 您以爲該怎麼確保需求分析階段得出的項目需求，能充分反映業務部門的需求？

聚冠因尚楊春波：

咱們發現，業務人員在提需求的時候，常常是從我的的實際業務須要出發，很是關注與本身平常工做相關的內容。若是需求調研過程只找個別業務人員來問問，必然會出現需求不完整的狀況。

在需求分析階段，應該「多方位」、「多層次」地選擇需求調研對象，不只要找不一樣的業務管理人員瞭解業務管理需求，也要找多個業務執行人員瞭解操做需求。這樣的需求調研方式，纔有可能獲得一個相對完整的業務需求。

四、 在需求分析階段IT部門與業務部門的溝通上，您有哪些經驗？

聚冠因尚楊春波：

我對IT人員與業務部門的溝通方面的建議是，「以誠待人、學會傾聽、活潑一點」。

「以誠待人」是良好溝通的基礎。無論業務人員的職位高仍是低、對信息化懂仍是不懂，咱們都要真誠、虛心地進行溝通。

「學會傾聽」不是說讓咱們擺出一幅「專心聽講、認真記筆記」的姿態，更重要的是要「會聽」，要明白業務人員某句話背後實際是想說什麼想要什麼，這要求IT人員具有必定的業務經驗和領悟能力。

「活潑一點」是對那些日常較爲嚴肅的IT人員的建議。與業務人員特別是營銷人員交流時，溝通方式不妨活潑一點，更能拉近彼此距離、更能碰撞出火花。

在上一節中，咱們就需求分析過程當中IT部門與業務部門的分工、溝通等方面，與聚冠因尚的諮詢顧問楊春波進行了交流。接下來咱們繼續就如下三個問題，與專家探討「如何跟業務部門談需求」。

一、在需求分析階段，您以爲獲取IT「需求」的途徑有哪些？

聚冠因尚楊春波：

至少有三個途徑。一個是「拿來主義」，一個是「直接調研」，一個是「混合式」。

首先說「拿來主義」。如今是「知識爆炸」的時代，在互聯網上很容易找到可供參考的需求文件。即便沒有同行業的資料，找到同業務領域的應該說不難。好比要找「重型卡車預算報價系統需求」，雖然找「汽車行業」的需求文件有點困難，但在網上找到「預算報價系統需求」仍是比較輕鬆的。IT人員經過閱讀和理解「拿來主義」的文件，找到功能需求的類似之處，會幫助咱們更好地獲取實際業務的IT需求。

再說「直接調研」。直接找到業務部門人員進行需求調研，這也是最經常使用的一種方式。

比較有意思的是「混合式」，也就是將「拿來主義」和「直接調研」結合起來的一種方式，首先讓業務部門直接提需求，再提供「拿來」的需求文檔給他們作參考，來達到進一步啓發需求的目的。

有些IT人員會說，不必搞這麼複雜吧。說這話的人通常都喜歡「直接調研式」，反正按照業務部門要求的作就是了，他要吃燒餅咱就烙燒餅，不必推薦什麼「披薩」。徹底按照業務部門定製需求的方式形成的直接後果是，IT人員辛辛苦苦作出的系統被要求無休止的改來改去。

二、有時候業務部門每每會提出一些沒法知足的「過度」的需求，您以爲IT主管該怎麼對這些需求進行取捨？

聚冠因尚楊春波：

業務部門可能會提出一些「過度」的需求，若是系統剛好是IT部門主導開發的，這種狀況就更常見了。

「過度」這確定是對於IT部門來講的，從業務角度，任何「過度」的需求確定有合理的地方。對IT部門而言，「過度」的需求要麼是系統實現的難度很大，要麼是對設備的性能要求較高。

IT主管應對「過度」的需求進行評估，能夠從四個方面考慮：

首先是需求的重要性，結合實際業務，判斷該需求是否爲核心需求；其次是需求的難度，從總體實現難度上進行等級劃分；第三是實現需求的成本，好比說須要多少個開發人月和測試人月、須要多少經費來提升設備性能；最後是有無替代的解決方案，好比說業務部門要求業務系統中的人員信息要與HR系統裏的人員信息實時同步，要實時難度很大，是否能夠考慮三天同步一次、或者一天同步一次。

IT主管要將評估結果與業務部門進行溝通，甚至能夠和業務部門負責人一塊兒探討從高層獲取資源的可能性。這樣，IT部門就是和業務部門一道來解決問題，而不會由於直接對業務部門說「不」，產生一些節外生枝的結果。

三、在需求分析階段結束以後，甚至項目進行過程當中，業務部門每每還會增長新的需求，這無疑會打亂原有的項目部署，您遇到過這種狀況嗎？該如何處理？如何避免這種狀況的出現？

聚冠因尚楊春波：

曾經遇到過。若是是核心需求，那就考慮當即調整計劃，將其增長進來。若是是非核心需求，能夠考慮說服業務部門放在下一階段實現。

出現這種狀況，我認爲有兩種緣由，首先是需求分析工做不充分，其次是缺少對需求的分類分級。

需求工做不充分體如今兩點，一個是有明顯遺漏、一個是缺少預判。解決需求遺漏問題，只能靠多層次多方面的調研訪談、資料蒐集、溝通交流來完成。解決需求預判是對IT人員的需求分析能力提出的更高要求。在需求分析的過程當中，不但要面向現有業務流程，還要對必定階段內可能的業務變化作充分的預判和探討。舉例來講，IT主管要跟高層和業務部門討論一下短時間內是否有組織架構方面的變更、業務模式或業務流程是否會發生變化等等。

需求的分類分級是需求分析工做中很重要的環節，要把全部需求在一期項目中完成是不現實的。咱們對需求按業務領域進行了分類，從重要性及實施難度上進行了分級，經與業務部門的討論，對實施過程的階段進行明確，第一階段實現哪些需求、第二階段實現哪些需求，這樣整個項目才能達到「明確規劃、逐步推動，快速見效」，才能讓業務部門滿意、讓IT部門輕鬆。