在上一節中，我們就需求分析過程中IT部門與業務部門的分工、溝通等方面，與聚冠因尚的諮詢顧問楊春波進行了交流。接下來我們繼續就以下三個問題，與專家探討“如何跟業務部門談需求”。
1、在需求分析階段，您覺得獲取IT“需求”的途徑有哪些？
聚冠因尚楊春波：
至少有三個途徑。一個是“拿來主義”，一個是“直接調研”，一個是“混合式”。
首先說“拿來主義”。現在是“知識爆炸”的時代，在互聯網上很容易找到可供參考的需求文件。即使沒有同行業的資料，找到同業務領域的應該說不難。比如要找“重型卡車預算報價系統需求”，雖然找“汽車行業”的需求文件有點困難，但在網上找到“預算報價系統需求”還是比較輕鬆的。IT人員通過閱讀和理解“拿來主義”的文件，找到功能需求的相似之處，會幫助我們更好地獲取實際業務的IT需求。
再說“直接調研”。直接找到業務部門人員進行需求調研，這也是最常用的一種方式。
比較有意思的是“混合式”，也就是將“拿來主義”和“直接調研”結合起來的一種方式，首先讓業務部門直接提需求，再提供“拿來”的需求文檔給他們做參考，來達到進一步啓發需求的目的。
有些IT人員會說，沒必要搞這麼複雜吧。說這話的人一般都喜歡“直接調研式”，反正按照業務部門要求的做就是了，他要吃燒餅咱就烙燒餅，沒必要推薦什麼“披薩”。完全按照業務部門定製需求的方式造成的直接後果是，IT人員辛辛苦苦做出的系統被要求無休止的改來改去。
2、有時候業務部門往往會提出一些無法滿足的“過分”的需求，您覺得IT主管該怎麼對這些需求進行取捨？
聚冠因尚楊春波：
業務部門可能會提出一些“過分”的需求，如果系統恰好是IT部門主導開發的，這種情況就更常見了。
“過分”這肯定是對於IT部門來說的，從業務角度，任何“過分”的需求肯定有合理的地方。對IT部門而言，“過分”的需求要麼是系統實現的難度很大，要麼是對設備的性能要求較高。
IT主管應對“過分”的需求進行評估，可以從四個方面考慮：
首先是需求的重要性，結合實際業務，判斷該需求是否爲核心需求；其次是需求的難度，從整體實現難度上進行等級劃分；第三是實現需求的成本，比如說需要多少個開發人月和測試人月、需要多少經費來提高設備性能；最後是有無替代的解決方案，比如說業務部門要求業務系統中的人員信息要與HR系統裏的人員信息實時同步，要實時難度很大，是否可以考慮三天同步一次、或者一天同步一次。
IT主管要將評估結果與業務部門進行溝通，甚至可以和業務部門負責人一起探討從高層獲取資源的可能性。這樣，IT部門就是和業務部門一道來解決問題，而不會因爲直接對業務部門說“不”，產生一些節外生枝的結果。
3、在需求分析階段結束之後，甚至項目進行過程中，業務部門往往還會增加新的需求，這無疑會打亂原有的項目部署，您遇到過這種情況嗎？該如何處理？如何避免這種情況的出現？
聚冠因尚楊春波：
曾經遇到過。如果是核心需求，那就考慮立即調整計劃，將其增加進來。如果是非核心需求，可以考慮說服業務部門放在下一階段實現。
出現這種情況，我認爲有兩種原因，首先是需求分析工作不充分，其次是缺乏對需求的分類分級。
需求工作不充分體現在兩點，一個是有明顯遺漏、一個是缺乏預判。解決需求遺漏問題，只能靠多層次多方面的調研訪談、資料蒐集、溝通交流來完成。解決需求預判是對IT人員的需求分析能力提出的更高要求。在需求分析的過程中，不但要面向現有業務流程，還要對一定階段內可能的業務變化做充分的預判和探討。舉例來說，IT主管要跟高層和業務部門討論一下短期內是否有組織架構方面的變動、業務模式或業務流程是否會發生變化等等。
需求的分類分級是需求分析工作中很重要的環節，要把所有需求在一期項目中完成是不現實的。我們對需求按業務領域進行了分類，從重要性及實施難度上進行了分級，經與業務部門的討論，對實施過程的階段進行明確，第一階段實現哪些需求、第二階段實現哪些需求，這樣整個項目才能達到“明確規劃、逐步推進，快速見效”，才能讓業務部門滿意、讓IT部門輕鬆。