?、苷莆崭鞣N溝通技巧

　　需求分析的過(guò)程實(shí)際上是個(gè)溝通的過(guò)程，CIO要想方設(shè)法吸引業(yè)務(wù)人員說(shuō)出其需求。有時(shí)候，嘗試著問(wèn)一些“愚蠢”的問(wèn)題也有助于用戶打開話匣子。如果CIO直接要求業(yè)務(wù)人員寫出業(yè)務(wù)是如何實(shí)現(xiàn)的，十有八九無(wú)法完成;但如果嘗試著問(wèn)一些實(shí)際的問(wèn)題，例如：“以我的理解，你們收到訂單后，會(huì)。。。”。業(yè)務(wù)人員立刻就會(huì)指出你的錯(cuò)誤，并滔滔不絕的開始談?wù)摌I(yè)務(wù)，這一招就叫“拋磚引玉”。

　?、輰?duì)業(yè)務(wù)需求進(jìn)行邏輯分析

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

　　⑥以通俗的語(yǔ)言編寫軟件需求報(bào)告

　　IT人員應(yīng)將從業(yè)務(wù)人員那里獲得的所有信息進(jìn)行整理，以區(qū)分業(yè)務(wù)需求及規(guī)范、功能需求、質(zhì)量目標(biāo)、解決方法等，然后編寫軟件需求報(bào)告。“需求分析報(bào)告”是IT人員和業(yè)務(wù)人員之間針對(duì)要開發(fā)的產(chǎn)品內(nèi)容達(dá)成的協(xié)議。報(bào)告應(yīng)以一種業(yè)務(wù)人員認(rèn)為易于翻閱和理解的方式組織編寫;報(bào)告中可以大量使用圖表，但必須向業(yè)務(wù)人員解釋清楚每個(gè)圖表的作用、符號(hào)的意義和需求開發(fā)工作的結(jié)果，以及怎樣檢查圖表有無(wú)錯(cuò)誤及不一致等。

　?、呙枋霎a(chǎn)品的使用特性

　　業(yè)務(wù)人員可以要求IT人員在實(shí)現(xiàn)功能需求的同時(shí)還注意軟件的易用性，因?yàn)橐子眯曰蛸|(zhì)量屬性能使客戶更準(zhǔn)確、高效地完成任務(wù)。例如業(yè)務(wù)人員有時(shí)要求產(chǎn)品要“界面友好”或“健壯”、“高效率”，但對(duì)IT人員來(lái)講，太主觀了并無(wú)實(shí)用價(jià)值。IT人員可以通過(guò)詢問(wèn)和調(diào)查了解客戶所要的“友好、健壯、高效“所包含的具體特性，具體分析哪些特性對(duì)哪些特性有負(fù)面影響，在性能代價(jià)和所提出解決方案的預(yù)期利益之間做出權(quán)衡，以確保做出合理的取舍。

　　⑧業(yè)務(wù)人員和IT人員互相尊重

　　如果業(yè)務(wù)人員與IT人員不能相互尊重，那關(guān)于需求的討論將會(huì)遇到障礙。參與需求分析的業(yè)務(wù)人員有權(quán)要求IT人員尊重他們并珍惜他們?yōu)轫?xiàng)目成功所付出的時(shí)間;但業(yè)務(wù)人員也要尊重IT人員的需求可行性及成本評(píng)估。所有軟件功能都是有成本的，業(yè)務(wù)人員所希望的某些產(chǎn)品特性可能在技術(shù)上行不通，或者實(shí)現(xiàn)它要付出極高的代價(jià)，而某些需求試圖達(dá)到在操作環(huán)境中不可能達(dá)到的性能，或試圖得到一些根本得不到的數(shù)據(jù)。IT人員會(huì)拒絕或?qū)崿F(xiàn)不了業(yè)務(wù)人員的一些要求，業(yè)務(wù)人員也應(yīng)該尊重IT人員的意見。

　?、嵊行枨笞兏⒓绰?lián)系

　　不斷的需求變更，會(huì)給在預(yù)定計(jì)劃內(nèi)完成的產(chǎn)品質(zhì)量帶來(lái)嚴(yán)重的不利影響，但需求變更又是不可避免的。在開發(fā)周期內(nèi)變更越在晚期出現(xiàn)，其影響越大;變更不僅 會(huì)導(dǎo)致代價(jià)極高的返工，而且工期將可能被延誤，特別是在主體架構(gòu)已完成后又需要增加新特性時(shí)。所以，一旦客戶發(fā)現(xiàn)需 要變更需求時(shí)，請(qǐng)立即通知IT人員。

　?、庑枨蟠_認(rèn)僅僅是以后討論的“基線”

　　在“需求分析報(bào)告”上簽字，通常被認(rèn)為是業(yè)務(wù)部門同意需求分析報(bào)告的標(biāo)志性行為，然而在實(shí)際操作中，業(yè)務(wù)人員往往把“簽字”看作毫無(wú)意義的事情。有時(shí)這個(gè)領(lǐng)導(dǎo)同意了，那個(gè)領(lǐng)導(dǎo)卻不同意;即使每個(gè)相關(guān)人員都簽了字，也照樣“翻供”，通常的理由是：“他們要我在需求文檔的最后一行簽名，于是我就簽了，否則他們不開始編碼!”同樣的問(wèn)題也發(fā)生在僅把“簽字確認(rèn)”看作是完成任務(wù)的IT人員身上，一旦有需求變更出現(xiàn)，便指著“需求分析報(bào)告”說(shuō)：“您已經(jīng)在需求分析報(bào)告上簽字了，所以這都是按照您的要求開發(fā)的。”-這兩種態(tài)度都是不對(duì)的，因?yàn)闃I(yè)務(wù)人員不可能在項(xiàng)目早期就能說(shuō)清楚所有業(yè)務(wù)需求，變更需求是必然現(xiàn)象。在“需求分析報(bào)告”上簽字確認(rèn)，僅僅是需求分析過(guò)程結(jié)束的標(biāo)志，它意味著“需求分析報(bào)告”是以后討論的基線，進(jìn)一步的變更可在此基線上通過(guò)項(xiàng)目定義的變更過(guò)程來(lái)進(jìn)行。

　　撥開需求分析的迷霧，將給初步的需求開發(fā)工作畫上雙方都明確的句號(hào)，將有助于形成一個(gè)持續(xù)良好的客戶與開發(fā)人員的關(guān)系，為項(xiàng)目成功奠定堅(jiān)實(shí)的基礎(chǔ)。

　　需求分析的風(fēng)險(xiǎn)

　　客戶有時(shí)會(huì)提一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能;若要實(shí)現(xiàn)這些功能可能要耗費(fèi)大量時(shí)間和成本，造成項(xiàng)目延期，此時(shí)CIO要權(quán)衡業(yè)務(wù)需求和項(xiàng)目資源之間的關(guān)系，及時(shí)決定必須完成哪些需求，舍棄哪些需求。

　　不重視需求分析的項(xiàng)目組將“自食其果”，但重視了并不一定能寫出完美的需求分析報(bào)告，因?yàn)樾枨蠓治鲋羞€有很多陷阱，稍微不慎CIO就可能掉進(jìn)業(yè)務(wù)需求的“陷阱”。需求分析中常見的陷阱有以下幾種：

　　首先是無(wú)足夠用戶參與。業(yè)務(wù)部門經(jīng)常不明白為什么收集需求和確保需求質(zhì)量需要費(fèi)那么多功夫。由于業(yè)務(wù)部門工作很忙，有時(shí)IT人員很難與業(yè)務(wù)人員坐在一起交流業(yè)務(wù)需求;即使費(fèi)了九牛二虎之力坐在一起，業(yè)務(wù)人員也講不明白自己的真正需求。為確保需求分析的質(zhì)量，CIO一方面要讓IT人員與盡量多的業(yè)務(wù)人員交流;另一方面，應(yīng)讓具有代表性的用戶在項(xiàng)目早期就直接參與到開發(fā)隊(duì)伍中來(lái)，一同經(jīng)歷整個(gè)開發(fā)過(guò)程。

　　其次是業(yè)務(wù)需求無(wú)休無(wú)止。業(yè)務(wù)部門在開發(fā)中若不斷補(bǔ)充需求，項(xiàng)目就可 能越變?cè)酱笠灾掠诔^(guò)計(jì)劃及預(yù)算范圍。計(jì)劃并不總是與項(xiàng)目需求規(guī)模與復(fù)雜性、風(fēng)險(xiǎn)及需求變更實(shí)際情況相一致，使得問(wèn)題更難解決。要想把需求變更范圍控制到 最小，必須一開始就對(duì)項(xiàng)目視圖、范圍、目標(biāo)、約束限制和成功標(biāo)準(zhǔn)給予明確說(shuō)明，并將此說(shuō)明作為評(píng)價(jià)需求變更和新特性的參照框架。另一方面，CIO要確定一個(gè)提需求分析的最后時(shí)間，不能放任業(yè)務(wù)人員無(wú)休止的提需求分析。

　　再次是用戶需求模棱兩可。模棱兩可是需求規(guī)格說(shuō)明中最可怕的問(wèn)題。模棱兩可的需求會(huì)使開發(fā)人員為錯(cuò)誤問(wèn)題而浪費(fèi)時(shí)間，并使測(cè)試者無(wú)所適從。一位系統(tǒng)測(cè)試人員說(shuō)，他所在的測(cè)試組經(jīng)常對(duì)需求理解有誤，以致不得不重寫許多測(cè)試用例并重做許多測(cè)試。

　　最后是不必要的“畫蛇添足”。“畫蛇添足”是指開發(fā)人員力圖增加一些用戶“欣賞”，但需求分析說(shuō)明中并未涉及的新功能。有時(shí)IT人員花了非常大的力氣，但用戶并不認(rèn)為這些功能很有用;IT人員應(yīng)努力使功能簡(jiǎn)單易用，但不要未經(jīng)業(yè)務(wù)人員同意，就自作主張。同樣，客戶有時(shí)也會(huì)提一些看上去很“酷”，但缺乏實(shí)用價(jià)值的功能;若要實(shí)現(xiàn)這些功能可能要耗費(fèi)大量時(shí)間和成本，造成項(xiàng)目延期，此時(shí)CIO要權(quán)衡業(yè)務(wù)需求和項(xiàng)目資源之間的關(guān)系，及時(shí)決定必須完成哪些需求，舍棄哪些需求。任何項(xiàng)目都不可能十全十美，也不可能滿足用戶的所有需求，畢竟項(xiàng)目的成本有限;CIO要弄清這些功能的“來(lái)龍去脈”，使得需求分析過(guò)程始終注重那些能使用戶完成主要任務(wù)的核心功能。