錯誤的需求分析對任何CIO來講都是一場噩夢。在需求分析階段看似微不足道的疏忽，都有可能成為項目失敗的罪魁禍?zhǔn)?。無論CIO的項目管理經(jīng)驗多么豐富，基于錯誤需求分析的IT項目，其結(jié)果只能以失敗而告終。但是，即便如此，IT項目前期的需求分析仍然沒有引起CIO們的普遍重視。他們往往更多地關(guān)注項目的時間、成本、質(zhì)量、組織、范圍和客戶滿意度，卻沒有意識到，需求分析是所有項目成功要素發(fā)揮作用的前提，如果需求分析有誤或者不到位，任何IT項目管理技巧和對IT項目的任何控制，都是沒有價值的。
與此同時，對于缺乏經(jīng)驗的CIO來講，需求分析恰恰又是整個項目中最容易讓人焦頭爛額的階段——業(yè)務(wù)部門提出的需求往往文不對題并且不斷變化，甚至在項目接近尾聲的時候，業(yè)務(wù)部門仍然在不斷地提出新需求。挖掘業(yè)務(wù)部門的項目需求時，CIO往往感覺力不從心，業(yè)務(wù)部門對項目需求的反復(fù)無常，又讓CIO措手不及。那么CIO該如何確保項目需求分析的正確與充分，面對業(yè)務(wù)部門反復(fù)無常的項目需求又該如何應(yīng)對呢?為此，記者NSIGHT近日請到了武漢健民集團信息中心主任柳駿、浙江吉利控股集團信息系統(tǒng)部副經(jīng)理章正柱、AMT咨詢深圳公司總經(jīng)理楊春波，圍繞“需求分析”相關(guān)話題展開了討論。
記者：我們經(jīng)常會聽到一些CIO抱怨說，對業(yè)務(wù)部門提出的需求IT人員看不懂，甚至根本不能稱之為“需求”，為什么會出現(xiàn)這種情況?
章正柱：我就遇到過這種情況。業(yè)務(wù)部門對IT不太了解，他們有時候會把IT想象得過于神化，覺得系統(tǒng)上了之后就會無所不能，往往提出一些脫離實際的需求。
我印象比較深的是我們集團的“一車一檔”系統(tǒng)，這是做ERP的時候業(yè)務(wù)部門提出的需求，他們希望在ERP中實現(xiàn)這樣的功能。一車一檔系統(tǒng)管理的內(nèi)容比較多，從汽車生產(chǎn)的訂單接收，到生產(chǎn)的組織，再到最后的銷售結(jié)果反饋等環(huán)節(jié)都有涉及。對于業(yè)務(wù)部門提出的這個需求本身，我覺得是合理的，但是如果要做“一車一檔”系統(tǒng)，必須要有采購系統(tǒng)、生產(chǎn)系統(tǒng)、物流系統(tǒng)和銷售系統(tǒng)做支撐，在沒有銷售系統(tǒng)的情況下，單純依靠ERP去實現(xiàn)“一車一檔”系統(tǒng)就顯得不切實際了。
柳駿：對于任何IT項目的需求分析，如果主要依靠業(yè)務(wù)部門去提是絕對不行的，因為他們對系統(tǒng)功能的認(rèn)知非常有限，很難在項目前期提出有效的需求。實際上，很多項目在需求分析階段，業(yè)務(wù)部門壓根就提不出什么具體的需求，倒是在系統(tǒng)上線之后，他們的需求才能慢慢地涌現(xiàn)，最后甚至鋪天蓋地地呈現(xiàn)。我在很早以前就遇到過這種情況，前期做需求分析的時候，業(yè)務(wù)部門會說：“我們沒什么需求，你們IT部門根據(jù)自己的想法去做，做出來我們能用就行了。”結(jié)果系統(tǒng)做出來了以后，業(yè)務(wù)部門的需求才真正爆發(fā)出來，搞得項目組焦頭爛額。楊春波：前面兩位IT主管都提到了業(yè)務(wù)人員對IT的不了解，我覺得還有一個很重要的原因，就是“語言不通”。在企業(yè)信息化程度不高的情況下，業(yè)務(wù)人員的系統(tǒng)使用經(jīng)驗較少，他們提出的需求往往用的是業(yè)務(wù)語言，比如說：“我需要的是在錄入這兩項數(shù)據(jù)之后，分?jǐn)偝杀灸茉谶@個窗口直接蹦出來??”而我們IT人員熟悉的是系統(tǒng)語言，比如：“能以這個字段為關(guān)鍵字，按照結(jié)算時間順序排列，顯示出一個報表。”
從業(yè)務(wù)語言到系統(tǒng)語言需要一個翻譯的過程。如果IT人員到公司時間不長或者是對業(yè)務(wù)不熟的話，難度確實是不小。不過CIO們別上火、別抱怨，他們應(yīng)該注意多培養(yǎng)IT人員的業(yè)務(wù)知識，鼓勵I(lǐng)T人員經(jīng)常與業(yè)務(wù)部門多交流。很早就有人提出，財務(wù)人員要“走出賬房”，我覺得IT人員也應(yīng)該時不常地“遠(yuǎn)離電腦”。
記者:柳駿剛剛提到了在需求分析階段僅僅依靠業(yè)務(wù)部門提需求是不夠的，那么你們認(rèn)為獲取IT需求的途徑應(yīng)該有哪些?
柳駿：需求分析不能完全依賴業(yè)務(wù)部門，在這個階段，IT人員不僅要充分介入進(jìn)去，還要鉆到業(yè)務(wù)中，與業(yè)務(wù)部門綁在一起，和業(yè)務(wù)人員成為朋友，盡量成為業(yè)務(wù)方面的專家。
具體來講，IT人員可以先通過訪談的方式，了解業(yè)務(wù)流程的大概狀況，然后再深入到業(yè)務(wù)部門，跟著業(yè)務(wù)人員，把業(yè)務(wù)流程整個走一遍，以充分熟悉業(yè)務(wù)流程的每一個環(huán)節(jié)。我覺得需求分析有點類似于機械行業(yè)的工藝卡片，工藝卡片是以工序為單位，詳細(xì)地說明整個工藝過程的一種工藝文件，用來指導(dǎo)工人生產(chǎn)，幫助車間管理人員和技術(shù)人員掌握整個零件加工的過程。做需求分析也要像編制工藝卡片一樣，細(xì)化到業(yè)務(wù)流程中的每一個動作，這是非常有必要的。因為只有對業(yè)務(wù)流程的每一個細(xì)節(jié)都足夠了解了，才有可能在此基礎(chǔ)上進(jìn)行流程優(yōu)化、重組，盡可能多地挖掘出業(yè)務(wù)部門對系統(tǒng)的潛在需求，進(jìn)而形成項目需求分析報告。
除了分析業(yè)務(wù)部門的工作流之外，還要收集他們?nèi)粘９ぷ髦杏玫降母鞣N單據(jù)、報表和表單等，也就是通常所說的票據(jù)流。實際上，票據(jù)流是業(yè)務(wù)部門工作流的載體，通過這些載體，不僅可以對工作流有更加深入的理解，還可以分析出業(yè)務(wù)部門對信息的需求是什么。
楊春波：我覺得至少有三個途徑，一個是拿來主義，一個是直接調(diào)研，再一個是混合式。
首先說拿來主義。現(xiàn)在是“知識爆炸”的時代，在互聯(lián)網(wǎng)上很容易找到可供參考的需求文件。即使沒有同行業(yè)的資料，找到同業(yè)務(wù)領(lǐng)域的應(yīng)該說也不難。比如要找“重型卡車預(yù)算報價系統(tǒng)需求”，雖然找“汽車行業(yè)”的需求文件有點困難，但在網(wǎng)上找到“預(yù)算報價系統(tǒng)需求”還是比較容易的。IT人員通過閱讀和理解“拿來主義”的文件，找到功能需求的相似之處，會幫助他們更好地獲取實際業(yè)務(wù)的IT需求。
再說直接調(diào)研，就是直接找到業(yè)務(wù)部門人員進(jìn)行需求調(diào)研，這也是最常用的一種方式。比較有意思的是混合式，也就是將拿來主義和直接調(diào)研結(jié)合起來的一種方式。首先讓業(yè)務(wù)門直接提需求，再提供“拿來”的需求文檔給他們做參考，來達(dá)到進(jìn)一步啟發(fā)需求的目的。有些IT人員可能會說：“沒必要搞這么復(fù)雜吧。”說這話的人一般都喜歡直接調(diào)研式，反正按照業(yè)務(wù)部門要求的做就是了，他要“吃燒餅”咱就“烙燒餅”，沒必要推薦什么“比薩”。完全按照業(yè)務(wù)部門定制需求的方式容易造成的直接結(jié)果是，IT人員辛辛苦苦做出的系統(tǒng)無休止地被要求改來改去。
章正柱：我們的做法主要是通過培訓(xùn)，這是獲得需求的一種很好的途徑。比如上CRM項目之前我們會先對相關(guān)業(yè)務(wù)部門做培訓(xùn)，通過項目概念的導(dǎo)入，業(yè)務(wù)部門就清楚CRM到底是做什么，這樣他們才能夠把真正的需求提出來。否則，如果連這個系統(tǒng)是做什么的都不知道，讓他們提需求最多也只能泛泛而談。與此同時，我們還會進(jìn)行一些訪談，與業(yè)務(wù)部門，特別是和領(lǐng)導(dǎo)面談，詢問他們對項目相關(guān)領(lǐng)域的需求和想法。
目前我們主要是通過培訓(xùn)和訪談這兩種方法，實際結(jié)果顯示也是比較有效的。當(dāng)然，還有其他一些手段，比如問卷調(diào)查，但是效果要差很多。
記者:看來獲得需求的途徑并不是惟一的。業(yè)務(wù)人員與IT人員在需求分析階段的分工是什么樣的呢?
楊春波：我認(rèn)為，在需求分析階段，IT人員切忌只做聆聽者，還要兼做翻譯師和培訓(xùn)師。聆聽業(yè)務(wù)人員的需求是第一步，但I(xiàn)T人員要盡量避免“你只管說，我只管做”的局面?！跋到y(tǒng)反正是按業(yè)各部門提得需求做出來的，好不好用別怪我。”這種想法看似很安全，其實是在給自己找麻煩，等到系統(tǒng)被改來改去的時候，才發(fā)現(xiàn)雙方都浪費了時間。IT人員還應(yīng)做好翻譯師。將業(yè)務(wù)需求整理并轉(zhuǎn)化為業(yè)務(wù)需求說明書，并將整理好的文件與業(yè)務(wù)部門進(jìn)行充分地溝通，來確認(rèn)是否準(zhǔn)確、完整地表述出了業(yè)務(wù)部門的需求。
此外，IT人員還應(yīng)做好培訓(xùn)師。在企業(yè)信息化程度不高的情況下，培訓(xùn)工作尤為重要。IT人員應(yīng)建議業(yè)務(wù)骨干參加有關(guān)信息化內(nèi)訓(xùn)或外訓(xùn)課程，讓他們多聽IT理念，多了解信息化案例，促使雙方有更多的共同語言。章正柱：IT人員的主要工作是概念的導(dǎo)入和系統(tǒng)功能的介紹。要讓業(yè)務(wù)人員明白，我們要做什么樣的系統(tǒng)，能解決什么樣的問題，這個系統(tǒng)有哪些具體的功能。業(yè)務(wù)部門的職責(zé)主要是對現(xiàn)有業(yè)務(wù)現(xiàn)狀的描述，他們要告訴IT人員現(xiàn)在是怎么管理的，未來希望怎么管理。
柳駿：目前來看，我們需求分析階段的工作大部分都是IT人員完成的，因為業(yè)務(wù)人員對IT需求不是很明白，在項目的需求分析階段，業(yè)務(wù)部門很難提出具體量化的、可以直接被IT人員提取的需求。他們提出的需求往往需要IT人員進(jìn)行編譯或者翻譯，把他們的業(yè)務(wù)語言轉(zhuǎn)化成IT語言。因此在這個過程中，業(yè)務(wù)人員承擔(dān)的工作很少。
記者:你們覺得該怎么確保需求分析階段得出的項目需求，能充分反映業(yè)務(wù)部門的實際需求?
楊春波：我發(fā)現(xiàn)業(yè)務(wù)人員在提需求的時候經(jīng)常是從個人的實際業(yè)務(wù)需要出發(fā)的，非常關(guān)注與自己日常工作相關(guān)的內(nèi)容。如果需求調(diào)研過程只找個別業(yè)務(wù)人員來問，必然會出現(xiàn)需求不完整的問題。
在需求分析階段，應(yīng)該多方位、多層次地選擇需求調(diào)研對象，不僅要找不同的業(yè)務(wù)管理人員了解業(yè)務(wù)管理需求，也要找多個業(yè)務(wù)執(zhí)行人員了解操作需求。這樣的需求調(diào)研方式才有可能得到一個相對完整的業(yè)務(wù)需求。
柳駿：我剛剛談到的獲取需求的方法有三步，第一步是訪談，第二步是IT人員跟著業(yè)務(wù)人員走流程，第三步是搜集業(yè)務(wù)人員工作中的票據(jù)流。但是，這三步之后拿出來的只是一些需求的簡單羅列，還不能稱之為真正意義上的需求。還有一個環(huán)節(jié)，就是對羅列的這些離散的信息和數(shù)據(jù)加以提煉，整理出系統(tǒng)的、規(guī)范性的需求。
記者:柳駿提到“要對離散的信息和數(shù)據(jù)加以提煉”，提煉的過程也就是對需求進(jìn)行取舍的過程，各位對取舍的標(biāo)準(zhǔn)有哪些建議?
柳駿：這主要看系統(tǒng)設(shè)計過程中關(guān)注的點在哪兒。一般來講，我們關(guān)注的點主要是業(yè)務(wù)控制和管理控制的節(jié)點，同時也應(yīng)該是系統(tǒng)的控制節(jié)點，所以重點應(yīng)該滿足這些控制節(jié)點。同時在取舍過程中，要盡可能地征求業(yè)務(wù)部門的意見。雖然業(yè)務(wù)部門在需求提出階段，很難提出像樣的需求，但是在這些需求的取舍上，業(yè)務(wù)部門很有發(fā)言權(quán)，他們也可以提供很多有價值的意見。剛剛談到的需求分析階段，這個環(huán)節(jié)是業(yè)務(wù)部門參與最多的地方，即關(guān)鍵控制節(jié)點和管理節(jié)點的確認(rèn)，以及離散需求的取舍。
章正柱：以我的經(jīng)驗，首先是看項目的范圍，不能把所有的需求都“朝一棵樹上靠”，如果是項目范圍之外的需求，我們肯定會舍棄。項目范圍之內(nèi)的，我們會從業(yè)務(wù)部門的需求緊迫程度、實現(xiàn)難度以及IT基礎(chǔ)設(shè)施和資源等各方面綜合考慮，在與業(yè)務(wù)部門充分溝通之后，去掉一些邊緣性的、非核心的需求。
楊春波：需求的取舍，在大部分情況下更多是針對業(yè)務(wù)部門提出的。因為業(yè)務(wù)部門可能會提出一些“過分”的需求，如果系統(tǒng)恰好是IT部門主導(dǎo)開發(fā)的，這種情況就更常見了。
“過分”肯定是對于IT部門來說的，從業(yè)務(wù)角度看，任何過分的需求肯定有合理的地方。對IT部門而言，這種“過分”的需求要么是系統(tǒng)實現(xiàn)的難度很大，要么是對設(shè)備的性能要求過高。
CIO應(yīng)對“過分”的需求進(jìn)行評估，可以從四個方面進(jìn)行考慮：首先是需求的重要性，結(jié)合實際業(yè)務(wù)，判斷該需求是否為核心需求;其次是需求的難度，從整體實現(xiàn)難度上進(jìn)行等級劃分;第三是實現(xiàn)需求的成本，比如說需要多少個開發(fā)人月和測試人月，需要多少經(jīng)費來提高設(shè)備性能;最后是有無替代的解決方案，比如說業(yè)務(wù)部門要求業(yè)務(wù)系統(tǒng)中的人員信息要與HR系統(tǒng)里的人員信息實時同步，但是如果實現(xiàn)難度很大，是否可以考慮3天同步一次或者一天同步一次。
此外，CIO還要將評估結(jié)果與業(yè)務(wù)部門進(jìn)行溝通，甚至可以和業(yè)務(wù)部門負(fù)責(zé)人一起探討從高層獲取資源的可能性。這樣IT部門和業(yè)務(wù)部門一道來解決問題，就不會因為直接對業(yè)務(wù)部門說“不”而產(chǎn)生一些節(jié)外生枝的結(jié)果。
記者:需求分析階段結(jié)束之后，甚至項目進(jìn)行過程中，業(yè)務(wù)部門往往還會增加新的需求，這無疑會打亂原有的項目部署，這時候該怎樣處理?
楊春波：出現(xiàn)這種情況，我認(rèn)為有兩種原因，首先是需求分析工作不充分，其次是缺乏對需求的分類、分級。需求工作不充分主要體現(xiàn)在兩點：一個是有明顯的遺漏，一個是缺乏預(yù)判。解決需求的遺漏問題，只能靠多層次、多方面的調(diào)研訪談，資料搜集以及溝通交流來完成。解決需求預(yù)判是對IT人員的需求分析能力提出的更高要求。在需求分析的過程中，不但要面向現(xiàn)有業(yè)務(wù)流程，還要對一定階段內(nèi)可能的業(yè)務(wù)變化做充分地預(yù)判和探討。例如，CIO要跟高層和業(yè)務(wù)部門討論一下短期內(nèi)是否有組織架構(gòu)方面的變動，業(yè)務(wù)模式或業(yè)務(wù)流程是否會發(fā)生變化等等。
需求的分類、分級是需求分析工作中很重要的環(huán)節(jié)，要把所有需求在一期項目中完成是不現(xiàn)實的。所以我們要對需求按業(yè)務(wù)領(lǐng)域進(jìn)行分類，從重要性及實施難度上進(jìn)行分級，經(jīng)過與業(yè)務(wù)部門的討論，對實施過程的階段進(jìn)行明確，第一階段可以實現(xiàn)哪些需求，第二階段可以實現(xiàn)哪些需求，這樣整個項目才能達(dá)到“明確規(guī)劃、逐步推進(jìn)、快速見效”，才能讓業(yè)務(wù)部門滿意，讓IT部門輕松。
在項目進(jìn)行過程中，由于業(yè)務(wù)部門提出的新需求而打亂原有項目的部署，這種情況在做IT項目時是很普遍的。如果是核心需求，IT部門就應(yīng)該考慮立即調(diào)整計劃，將其增加進(jìn)來;如果是非核心需求，就可以考慮說服業(yè)務(wù)部門，把這個新需求放在下一階段實現(xiàn)。
章正柱：需要明確的是，這種情況是不可避免的，幾乎每一個IT項目主管都有可能碰到。因為隨著業(yè)務(wù)部門參與項目的不斷深入，他們對系統(tǒng)的理解也會有一個逐步提升的過程，可能剛開始提出一個過高的、理想化的需求，或者提出了一個過低的需求，隨著對項目理解的不斷加深，可能會對需求不斷進(jìn)行調(diào)整。
通常我們把項目實施分為項目準(zhǔn)備、業(yè)務(wù)藍(lán)圖設(shè)計、系統(tǒng)實現(xiàn)、上線準(zhǔn)備、運行支持這么幾個階段。其中業(yè)務(wù)藍(lán)圖設(shè)計就是需求分析和設(shè)計階段，在這個階段，要把對項目的最終需求以流程圖的形式繪制出來，讓相關(guān)業(yè)務(wù)部門負(fù)責(zé)人簽字確認(rèn)。
這個階段結(jié)束之后，如果業(yè)務(wù)部門再提出新需求，需要走項目變更流程。通過變更流程，對新需求進(jìn)行分析，這時候取舍的標(biāo)準(zhǔn)和之前有所不同，并不是業(yè)務(wù)人員提出了一個更好的需求，我們就一定會進(jìn)行調(diào)整，這要看實現(xiàn)成本。如果實現(xiàn)成本比較大，涉及到原有工作調(diào)整比較多，就會按照原定流程進(jìn)行。
柳駿：針對這種情況，比較有效的防范措施就是在需求分析完成之后，一定要讓相關(guān)業(yè)務(wù)部門簽字確認(rèn)。和做項目管理一樣，必須每一個步驟都要有確認(rèn)的過程，每一個階段設(shè)置對應(yīng)的里程碑，防止業(yè)務(wù)部門最后盲目提出變更。因為軟件架構(gòu)一旦成型，往往“牽一發(fā)而動全身”，業(yè)務(wù)部門不理解，他們往往認(rèn)為“就是細(xì)微的改動嗎，很簡單”，實際上不是這樣的。針對業(yè)務(wù)部門臨時提出的需求，我的處理辦法是，在需求分析結(jié)束之后，即使業(yè)務(wù)部門提出新的需求，我們也不會進(jìn)行任何相應(yīng)的變更，而是會把這些需求記錄下來，到了某一個時間點，比如半年以后，把這些需求歸納起來，對系統(tǒng)進(jìn)行統(tǒng)一的升級，或者發(fā)布新版本。否則，一個項目往往涉及到多個部門的多個崗位，今天改一下，明天改一下，到最后整個項目就亂了。
需求分析階段一定要把握住主脈，不要被業(yè)務(wù)部門牽著鼻子跑。在做IT項目的時候，既要依靠業(yè)務(wù)部門，把他們的業(yè)務(wù)需求充分展示出來;也不能被業(yè)務(wù)原有的流程束縛，不能完全在他們現(xiàn)有需求上進(jìn)行量身定制，一定要有所提升。否則，項目將很難成功。
