撥開需求“迷霧”
業(yè)務(wù)部門的主管甚至CIO經(jīng)常試圖代替終端用戶說話，但通常又無法準確說明“用戶需求”。用戶需求來自產(chǎn)品的真正使用者，必須讓實際用戶參與到收集需求的過程中；否則，產(chǎn)品很可能會因缺乏足夠的信息而遺留不少隱患。
需求分析是軟件開發(fā)和項目管理的基礎(chǔ)，但業(yè)務(wù)部門經(jīng)常三言五語就把開發(fā)人員“打發(fā)”了，業(yè)務(wù)人員籠統(tǒng)、感性的描述對開發(fā)人員來說就像“霧里看花”，一些開發(fā)人員只好按照自己的理解去寫CODE.要撥開需求分析的“迷霧”，就要先了解需求分析的“程序”。
需求分析包括業(yè)務(wù)需求、用戶需求、功能需求、非功能性需求和需求分析報告等。業(yè)務(wù)需求反映了組織機構(gòu)或客戶對系統(tǒng)、產(chǎn)品高層次的目標要求，通常在項目定義與范圍文檔中予以說明；用戶需求描述了用戶使用產(chǎn)品必須要完成的任務(wù)，應(yīng)在使用實例或方案腳本中予以說明；功能需求定義了開發(fā)人員必須實現(xiàn)的軟件功能，使用戶利用系統(tǒng)能夠完成他們的任務(wù)，從而滿足業(yè)務(wù)需求；非功能性的需求描述了系統(tǒng)展現(xiàn)給用戶的行為和執(zhí)行的操作等，它包括產(chǎn)品必須遵從的標準、規(guī)范和約束，操作界面的具體細節(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ā)所需的許多細節(jié)說明。“用戶需求”必須找系統(tǒng)的最終使用者，他們最清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性的特性需求，如程序的易用性、健壯性和可靠性等，而這些特性將會使用戶很好地接受具有該特點的軟件產(chǎn)品。業(yè)務(wù)部門的主管甚至CIO經(jīng)常試圖代替終端用戶說話，但通常又無法準確說明“用戶需求”。用戶需求來自產(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)容并達成共識；如果遇到分歧，可通過協(xié)商達成對各自義務(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ù)流程。
②表達要符合業(yè)務(wù)部門語言習(xí)慣
需求討論集中于業(yè)務(wù)需求和任務(wù)，必然使用各種業(yè)務(wù)術(shù)語。如果開發(fā)人員是IT廠商，CIO應(yīng)將有關(guān)業(yè)務(wù)術(shù)語教給開發(fā)人員，同時還要把IT人員常用的一些術(shù)語“翻譯”給業(yè)務(wù)人員，做到交流暢通無阻。
③了解業(yè)務(wù)部門的業(yè)務(wù)及目標
只有充分了解業(yè)務(wù)部門的具體業(yè)務(wù)，才能開發(fā)出滿足其需求的軟件。為充分了解業(yè)務(wù)人員的具體需求，CIO要和開發(fā)人員一起到業(yè)務(wù)部門去觀察他們的實際工作流程，甚至與業(yè)務(wù)部門一起工作一段時間。如果是舊系統(tǒng)切換到新系統(tǒng)，CIO還要親自用一下目前的舊系統(tǒng)，明白目前系統(tǒng)是怎樣工作的，了解其流程情況以及可供改進之處等。
④掌握各種溝通技巧
需求分析的過程實際上是個溝通的過程，CIO要想方設(shè)法吸引業(yè)務(wù)人員說出其需求。有時候，嘗試著問一些“愚蠢”的問題也有助于用戶打開話匣子。如果CIO直接要求業(yè)務(wù)人員寫出業(yè)務(wù)是如何實現(xiàn)的，十有八九無法完成；但如果嘗試著問一些實際的問題，例如：“以我的理解，你們收到訂單后，會……”。業(yè)務(wù)人員立刻就會指出你的錯誤，并滔滔不絕的開始談?wù)摌I(yè)務(wù)，這一招就叫“拋磚引玉”。
⑤對業(yè)務(wù)需求進行邏輯分析
業(yè)務(wù)人員對需求的表達通常是籠統(tǒng)、感性、瑣碎的，CIO要盡量理解業(yè)務(wù)人員用于表述他們需求的思維過程，充分研究用戶執(zhí)行任務(wù)時決策的過程，并抽象出潛在邏輯關(guān)系，把一些“常識”性東西用邏輯來實現(xiàn)。
例如，當(dāng)IT人員與護士交流醫(yī)囑處理過程時，護士會告訴IT人員，護理級別有特級護理、一級護理、二級護理、三級護理以等；飲食又分流食、半流食、禁食等種類。如果僅僅把護士的要求用計算機語言表達出來，就可能出現(xiàn)同一個病人既是一級護理又是二級護理，既吃流食又吃半流食的可笑情況；這些矛盾的避免原來是靠護士的大腦來判斷的常識性問題，而用計算機來判斷“常識”是最難的，也是最容易忽視的。經(jīng)過反復(fù)探索，協(xié)和醫(yī)院信息中心主任李包羅抽象出了一個互斥組的概念。特級、一級、二級、三級護理組成一個互斥組，當(dāng)護士選擇特級護理的時候，自然排斥了一級、二級和三級護理。李包羅說：“在與醫(yī)生、護士溝通的過程中，IT人員不是要成為臨床專家或者護理專家，而是要用IT知識去梳理醫(yī)生護士的要求，變成一種計算機可以實現(xiàn)的概念，超越了手工的功能才會受到業(yè)務(wù)部門的歡迎。”
⑥以通俗的語言編寫軟件需求報告
IT人員應(yīng)將從業(yè)務(wù)人員那里獲得的所有信息進行整理，以區(qū)分業(yè)務(wù)需求及規(guī)范、功能需求、質(zhì)量目標、解決方法等，然后編寫軟件需求報告?！靶枨蠓治鰣蟾妗笔荌T人員和業(yè)務(wù)人員之間針對要開發(fā)的產(chǎn)品內(nèi)容達成的協(xié)議。報告應(yīng)以一種業(yè)務(wù)人員認為易于翻閱和理解的方式組織編寫；報告中可以大量使用圖表，但必須向業(yè)務(wù)人員解釋清楚每個圖表的作用、符號的意義和需求開發(fā)工作的結(jié)果，以及怎樣檢查圖表有無錯誤及不一致等。
⑦描述產(chǎn)品的使用特性
業(yè)務(wù)人員可以要求IT人員在實現(xiàn)功能需求的同時還注意軟件的易用性，因為易用性或質(zhì)量屬性能使客戶更準確、高效地完成任務(wù)。例如業(yè)務(wù)人員有時要求產(chǎn)品要“界面友好”或“健壯”、“高效率”，但對IT人員來講，太主觀了并無實用價值。IT人員可以通過詢問和調(diào)查了解客戶所要的“友好、健壯、高效”所包含的具體特性，具體分析哪些特性對哪些特性有負面影響，在性能代價和所提出解決方案的預(yù)期利益之間做出權(quán)衡，以確保做出合理的取舍。
⑧業(yè)務(wù)人員和IT人員互相尊重
如果業(yè)務(wù)人員與IT人員不能相互尊重，那關(guān)于需求的討論將會遇到障礙。參與需求分析的業(yè)務(wù)人員有權(quán)要求IT人員尊重他們并珍惜他們?yōu)轫椖砍晒λ冻龅臅r間；但業(yè)務(wù)人員也要尊重IT人員的需求可行性及成本評估。所有軟件功能都是有成本的，業(yè)務(wù)人員所希望的某些產(chǎn)品特性可能在技術(shù)上行不通，或者實現(xiàn)它要付出極高的代價，而某些需求試圖達到在操作環(huán)境中不可能達到的性能，或試圖得到一些根本得不到的數(shù)據(jù)。IT人員會拒絕或?qū)崿F(xiàn)不了業(yè)務(wù)人員的一些要求，業(yè)務(wù)人員也應(yīng)該尊重IT人員的意見。
⑨有需求變更要立即聯(lián)系
不斷的需求變更，會給在預(yù)定計劃內(nèi)完成的產(chǎn)品質(zhì)量帶來嚴重的不利影響，但需求變更又是不可避免的。在開發(fā)周期內(nèi)變更越在晚期出現(xiàn)，其影響越大；變更不僅會導(dǎo)致代價極高的返工，而且工期將可能被延誤，特別是在主體架構(gòu)已完成后又需要增加新特性時。所以，一旦客戶發(fā)現(xiàn)需要變更需求時，請立即通知IT人員。
⑩需求確認僅僅是以后討論的“基線”。
在“需求分析報告”上簽字，通常被認為是業(yè)務(wù)部門同意需求分析報告的標志性行為，然而在實際操作中，業(yè)務(wù)人員往往把“簽字”看作毫無意義的事情。有時這個領(lǐng)導(dǎo)同意了，那個領(lǐng)導(dǎo)卻不同意；即使每個相關(guān)人員都簽了字，也照樣“翻供”，通常的理由是：“他們要我在需求文檔的最后一行簽名，于是我就簽了，否則他們不開始編碼！”同樣的問題也發(fā)生在僅把“簽字確認”看作是完成任務(wù)的IT人員身上，一旦有需求變更出現(xiàn)，便指著“需求分析報告”說：“您已經(jīng)在需求分析報告上簽字了，所以這都是按照您的要求開發(fā)的?！?這兩種態(tài)度都是不對的，因為業(yè)務(wù)人員不可能在項目早期就能說清楚所有業(yè)務(wù)需求，變更需求是必然現(xiàn)象。在“需求分析報告”上簽字確認，僅僅是需求分析過程結(jié)束的標志，它意味著“需求分析報告”是以后討論的基線，進一步的變更可在此基線上通過項目定義的變更過程來進行。
撥開需求分析的迷霧，將給初步的需求開發(fā)工作畫上雙方都明確的句號，將有助于形成一個持續(xù)良好的客戶與開發(fā)人員的關(guān)系，為項目成功奠定堅實的基礎(chǔ)。
