歷盡千辛萬苦，終于簽署合同，IT供應(yīng)商拿到了用戶提供的幾頁“需求書”;然后就憑借自己的理解立即投入開發(fā)，等生米熬成粥才發(fā)現(xiàn)滿足不了用戶需求，接下來就是艱難、反復(fù)地修改，最后開發(fā)人員厭倦了，用戶也厭倦了，當(dāng)然項目款也遙遙無期。這樣的案例可謂比比皆是!

　　比起不成功的項目，一個成功的項目在開發(fā)者和客戶之間往往采取了更多交流方式;IT供應(yīng)商不僅與終端用戶或潛在用戶群交流，而且對用戶感性、樸素的認(rèn)識進(jìn)行抽象，提取出潛在邏輯關(guān)系，準(zhǔn)確把握客戶的真正需求，然后才進(jìn)行軟件開發(fā)。作為項目開發(fā)者和最終用戶之間的“橋梁”，CIO如何推進(jìn)開發(fā)人員和終端用戶的“對接”?如何從用戶籠統(tǒng)、感性的描述中抽象出潛在邏輯關(guān)系?

　　撥開需求“迷霧”

　　業(yè)務(wù)部門的主管甚至CIO經(jīng)常試圖代替終端用戶說話，但通常又無法準(zhǔn)確說明“用戶需求”。用戶需求來自產(chǎn)品的真正使用者，必須讓實際用戶參與到收集需求的過程中;否則，產(chǎn)品很可能會因缺乏足夠的信息而遺留不少隱患。

　　需求分析是軟件開發(fā)和項目管理的基礎(chǔ)，但業(yè)務(wù)部門經(jīng)常三言五語就把開發(fā)人員“打發(fā)”了，業(yè)務(wù)人員籠統(tǒng)、感性的描述對開發(fā)人員來說就像“霧里看花”，一些開發(fā)人員只好按照自己的理解去寫CODE。要撥開需求分析的“迷霧”，就要先了解需求分析的“程序”。

　　需求分析包括業(yè)務(wù)需求、用戶需求、功能需求、非功能性需求和需求分析報告等。業(yè)務(wù)需求反映了組織機(jī)構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常在項目定 義與范圍文檔中予以說明;用戶需求描述了用戶使用產(chǎn)品必須要完成的任務(wù)，應(yīng)在使用實例或方案腳本中予以說明;功能需求定義了開發(fā)人員必須實現(xiàn)的軟件功能， 使用戶利用系統(tǒng)能夠完成他們的任務(wù)，從而滿足業(yè)務(wù)需求;非功能性的需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和約 束，操作界面的具體細(xì)節(jié)和構(gòu)造上的限制等;需求分析報告所說明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為，在開發(fā)、測試、質(zhì)量保證、項目管理以及相 關(guān)項目功能中起著重要作用。

　　業(yè)務(wù)部門的主管通常闡明“業(yè)務(wù)需求”，即產(chǎn)品的高層次概念和主要業(yè)務(wù)內(nèi)容，為后繼工作建立指導(dǎo)性框架;但“業(yè)務(wù)需求”并不能為開發(fā)人員提供開發(fā)所需的許多細(xì)節(jié)說明。“用戶需求”必須找系統(tǒng)的最終使用者，他們最清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性的特性需求，如程序的易用性、健壯性和可靠性等，而這些特性將會使用戶很好地接受具有該特點的軟件產(chǎn)品。業(yè)務(wù)部門的主管甚至CIO經(jīng)常試圖代替終端用戶說話，但通常又無法準(zhǔn)確說明“用戶需求”。用戶需求來自產(chǎn)品的真正使用者，必須讓實際用戶參與到收集需求的過程中;否則，產(chǎn)品很可能會因缺乏足夠的信息而遺留不少隱患。

　　在實際需求分析過程中，由于業(yè)務(wù)部門工作很忙，經(jīng)常沒有時間或者覺得沒有必要與IT人員討論需求分析，有時甚至希望IT人員無須討論和編寫需求說明就能說出用戶的需求。除非遇到的需求極為簡單;否則千萬不能這樣做。

　　優(yōu)秀的軟件產(chǎn)品建立在優(yōu)秀的需求分析基礎(chǔ)上，而優(yōu)秀的需求分析又源于客戶與開發(fā)人員之間有效的交流和合作。只有雙方參與者都明白自己需要什么、成功的合作需要什么時，才能建立起一種良好的合作關(guān)系。

　　十項基本法則

　　如果CIO嘗試著問一些愚蠢問題，例如：“以我的理解，你們收到訂單后，會……”。業(yè)務(wù)人員立刻就會指出你的錯誤，并開始滔滔不絕談?wù)摌I(yè)務(wù)，這一招就叫“拋磚引玉”。

　　開發(fā)人員與業(yè)務(wù)部門的交流需要好的方法。下面建議10條法則，開發(fā)人員和業(yè)務(wù)部門可以通過評審以下內(nèi)容并達(dá)成共識;如果遇到分歧，可通過協(xié)商達(dá)成對各自義務(wù)的相互了解，以便減少日后的摩擦。

　?、傧葘?dǎo)入管理思想，再梳理業(yè)務(wù)流程

　　“百聞不如一見，百見不如一嘗。”沒有親歷過信息化建設(shè)的人，對信息化的理解總是比較膚淺，甚至包括一些管理層成員。如上ERP系統(tǒng)時，如果一開始就讓業(yè)務(wù)部門談需求，業(yè)務(wù)人員談得通常是當(dāng)前工作中的困難或者希望實現(xiàn)的功能等;CIO必須從轉(zhuǎn)變觀念入手，先給業(yè)務(wù)部門導(dǎo)入信息系統(tǒng)所包含的管理思想，然后協(xié)助業(yè)務(wù)部門梳理業(yè)務(wù)流程。

　　需求的思維過程，充分研究用戶執(zhí)行任務(wù)時決策的過程，并抽象出潛在邏輯關(guān)系，把一些“常識”性東西用邏輯來實現(xiàn)。例如，當(dāng)IT人員與護(hù)士交流醫(yī)囑處理過程時，護(hù)士會告訴IT人 員，護(hù)理級別有特級護(hù)理、一級護(hù)理、二級護(hù)理、三級護(hù)理以等;飲食又分流食、半流食、禁食等種類。如果僅僅把護(hù)士的要求用計算機(jī)語言表達(dá)出來，就可能出現(xiàn) 同一個病人既是一級護(hù)理又是二級護(hù)理，既吃流食又吃半流食的可笑情況;這些矛盾的避免原來是靠護(hù)士的大腦來判斷的常識性問題，而用計算機(jī)來判斷“常識”是最難的，也是最容易忽視的。經(jīng)過反復(fù)探索，協(xié)和醫(yī)院信息中心主任李包羅抽象出了一個互斥組的概念。特級、一級、二級、三級護(hù)理組成一個互斥組，當(dāng)護(hù)士選擇特級護(hù)理的時候，自然排斥了一級、二級和三級護(hù)理。李包羅說：“在與醫(yī)生、護(hù)士溝通的過程中，IT人員不是要成為臨床專家或者護(hù)理專家，而是要用IT知識去梳理醫(yī)生護(hù)士的要求，變成一種計算機(jī)可以實現(xiàn)的概念，超越了手工的功能才會受到業(yè)務(wù)部門的歡迎。”

　?、诒磉_(dá)要符合業(yè)務(wù)部門語言習(xí)慣

　　需求討論集中于業(yè)務(wù)需求和任務(wù)，必然使用各種業(yè)務(wù)術(shù)語。如果開發(fā)人員是IT廠商，CIO應(yīng)將有關(guān)業(yè)務(wù)術(shù)語教給開發(fā)人員，同時還要把IT人員常用的一些術(shù)語“翻譯”給業(yè)務(wù)人員，做到交流暢通無阻。

　?、哿私鈽I(yè)務(wù)部門的業(yè)務(wù)及目標(biāo)

　　只有充分了解業(yè)務(wù)部門的具體業(yè)務(wù)，才能開發(fā)出滿足其需求的軟件。為充分了解業(yè)務(wù)人員的具體需求，CIO要和開發(fā)人員一起到業(yè)務(wù)部門去觀察他們的實際工作流程，甚至與業(yè)務(wù)部門一起工作一段時間。如果是舊系統(tǒng)切換到新系統(tǒng)，CIO還要親自用一下目前的舊系統(tǒng)，明白目前系統(tǒng)是怎樣工作的，了解其流程情況以及可供改進(jìn)之處等。