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

標籤：

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

1、 有的IT主管抱怨業務部門提出的需求，IT人員看不懂甚至根本不能稱之為需求，您覺得為什麼會出現這種情況？

聚冠因尚楊春波：

這是比較常見的現象，“語言不通”是造成這種情況的主要原因之一。在公司資訊化程度不高的情況下，業務人員的系統使用經驗較少，他們提出的需求往往用的是“業務語言”，比如說，“我需要在錄入這兩項資料之後，分攤成本能在這個視窗直接蹦出來……”。而我們IT人員熟悉的是“系統語言”，比如“能以這個欄位為關鍵字，按照結算時間順序排列，出個報表”。

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

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

聚冠因尚楊春波：

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

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

IT人員還應做好“翻譯師”。將業務需求整理並轉化為“業務需求說明書”，並將整理好的檔案與業務部門進行充分的溝通，來確認是否準確、完整地表述出業務部門的需求。

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

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

聚冠因尚楊春波：

我們發現，業務人員在提需求的時候，經常是從個人的實際業務需要出發，非常關注與自己日常工作相關的內容。如果需求調研過程只找個別業務人員來問問，必然會出現需求不完整的情況。

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

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

聚冠因尚楊春波：

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

“以誠待人”是良好溝通的基礎。不管業務人員的職位高還是低、對資訊化懂還是不懂，我們都要真誠、虛心地進行溝通。

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

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

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

1、在需求分析階段，您覺得擷取IT“需求”的途徑有哪些？

聚冠因尚楊春波：

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

首先說“拿來主義”。現在是“知識爆炸”的時代，在互連網上很容易找到可供參考的需求檔案。即使沒有同行業的資料，找到同業務領域的應該說不難。比如要找“重型卡車預算報價系統需求”，雖然找“汽車行業”的需求檔案有點困難，但在網上找到“預算報價系統需求”還是比較輕鬆的。IT人員通過閱讀和理解“拿來主義”的檔案，找到功能需求的相似之處，會協助我們更好地擷取實際業務的IT需求。

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

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

有些IT人員會說，沒必要搞這麼複雜吧。說這話的人一般都喜歡“直接調研式”，反正按照業務部門要求的做就是了，他要吃燒餅咱就烙燒餅，沒必要推薦什麼“披薩”。完全按照業務部門定製需求的方式造成的直接後果是，IT人員辛辛苦苦做出的系統被要求無休止的改來改去。

2、有時候業務部門往往會提出一些無法滿足的“過分”的需求，您覺得IT主管該怎麼對這些需求進行取捨？

聚冠因尚楊春波：

業務部門可能會提出一些“過分”的需求，如果系統恰好是IT部門主導開發的，這種情況就更常見了。

“過分”這肯定是對於IT部門來說的，從業務角度，任何“過分”的需求肯定有合理的地方。對IT部門而言，“過分”的需求要麼是系統實現的難度很大，要麼是對裝置的效能要求較高。

IT主管應對“過分”的需求進行評估，可以從四個方面考慮：

首先是需求的重要性，結合實際業務，判斷該需求是否為核心需求；其次是需求的難度，從整體實現難度上進行等級劃分；第三是實現需求的成本，比如說需要多少個開發人月和測試人月、需要多少經費來提高裝置效能；最後是有無替代的解決方案，比如說業務部門要求業務系統中的人員資訊要與HR系統裡的人員資訊即時同步，要即時難度很大，是否可以考慮三天同步一次、或者一天同步一次。

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

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

聚冠因尚楊春波：

曾經遇到過。如果是核心需求，那就考慮立即調整計劃，將其增加進來。如果是非核心需求，可以考慮說服業務部門放在下一階段實現。

出現這種情況，我認為有兩種原因，首先是需求分析工作不充分，其次是缺乏對需求的分類分級。

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

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

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