歷盡千辛萬(wàn)苦，終于簽署合同，IT供應(yīng)商拿到了用戶(hù)提供的幾頁(yè)“需求書(shū)”；然后就憑借自己的理解立即投入開(kāi)發(fā)，等生米熬成粥才發(fā)現(xiàn)滿(mǎn)足不了用戶(hù)需求，接下來(lái)就是艱難、反復(fù)地修改，最后開(kāi)發(fā)人員厭倦了，用戶(hù)也厭倦了，當(dāng)然項(xiàng)目款也遙遙無(wú)期。這樣的案例可謂比比皆是！
比起不成功的項(xiàng)目，一個(gè)成功的項(xiàng)目在開(kāi)發(fā)者和客戶(hù)之間往往采取了更多交流方式；IT供應(yīng)商不僅與終端用戶(hù)或潛在用戶(hù)群交流，而且對(duì)用戶(hù)感性、樸素的認(rèn)識(shí)進(jìn)行抽象，提取出潛在邏輯關(guān)系，準(zhǔn)確把握客戶(hù)的真正需求，然后才進(jìn)行軟件開(kāi)發(fā)。作為項(xiàng)目開(kāi)發(fā)者和最終用戶(hù)之間的“橋梁”，CIO如何推進(jìn)開(kāi)發(fā)人員和終端用戶(hù)的“對(duì)接”？如何從用戶(hù)籠統(tǒng)、感性的描述中抽象出潛在邏輯關(guān)系？
撥開(kāi)需求“迷霧”
業(yè)務(wù)部門(mén)的主管甚至CIO經(jīng)常試圖代替終端用戶(hù)說(shuō)話(huà)，但通常又無(wú)法準(zhǔn)確說(shuō)明“用戶(hù)需求”。用戶(hù)需求來(lái)自產(chǎn)品的真正使用者，必須讓實(shí)際用戶(hù)參與到收集需求的過(guò)程中；否則，產(chǎn)品很可能會(huì)因缺乏足夠的信息而遺留不少隱患。
需求分析是軟件開(kāi)發(fā)和項(xiàng)目管理的基礎(chǔ)，但業(yè)務(wù)部門(mén)經(jīng)常三言五語(yǔ)就把開(kāi)發(fā)人員“打發(fā)”了，業(yè)務(wù)人員籠統(tǒng)、感性的描述對(duì)開(kāi)發(fā)人員來(lái)說(shuō)就像“霧里看花”，一些開(kāi)發(fā)人員只好按照自己的理解去寫(xiě)CODE。要撥開(kāi)需求分析的“迷霧”，就要先了解需求分析的“程序”。
需求分析包括業(yè)務(wù)需求、用戶(hù)需求、功能需求、非功能性需求和需求分析報(bào)告等。業(yè)務(wù)需求反映了組織機(jī)構(gòu)或客戶(hù)對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，通常在項(xiàng)目定 義與范圍文檔中予以說(shuō)明；用戶(hù)需求描述了用戶(hù)使用產(chǎn)品必須要完成的任務(wù)，應(yīng)在使用實(shí)例或方案腳本中予以說(shuō)明；功能需求定義了開(kāi)發(fā)人員必須實(shí)現(xiàn)的軟件功能， 使用戶(hù)利用系統(tǒng)能夠完成他們的任務(wù)，從而滿(mǎn)足業(yè)務(wù)需求；非功能性的需求描述了系統(tǒng)展現(xiàn)給用戶(hù)的行為和執(zhí)行的操作等，它包括產(chǎn)品必須遵從的標(biāo)準(zhǔn)、規(guī)范和約 束，操作界面的具體細(xì)節(jié)和構(gòu)造上的限制等；需求分析報(bào)告所說(shuō)明的功能需求充分描述了軟件系統(tǒng)所應(yīng)具有的外部行為，在開(kāi)發(fā)、測(cè)試、質(zhì)量保證、項(xiàng)目管理以及相 關(guān)項(xiàng)目功能中起著重要作用。
業(yè)務(wù)部門(mén)的主管通常闡明“業(yè)務(wù)需求”，即產(chǎn)品的高層次概念和主要業(yè)務(wù)內(nèi)容，為后繼工作建立指導(dǎo)性框架；但“業(yè)務(wù)需求”并不能為開(kāi)發(fā)人員提供開(kāi)發(fā)所需的許多細(xì)節(jié)說(shuō)明?！坝脩?hù)需求”必須找系統(tǒng)的最終使用者，他們最清楚要使用該產(chǎn)品完成什么任務(wù)和一些非功能性的特性需求，如程序的易用性、健壯性和可靠性等，而這些特性將會(huì)使用戶(hù)很好地接受具有該特點(diǎn)的軟件產(chǎn)品。業(yè)務(wù)部門(mén)的主管甚至CIO經(jīng)常試圖代替終端用戶(hù)說(shuō)話(huà)，但通常又無(wú)法準(zhǔn)確說(shuō)明“用戶(hù)需求”。用戶(hù)需求來(lái)自產(chǎn)品的真正使用者，必須讓實(shí)際用戶(hù)參與到收集需求的過(guò)程中；否則，產(chǎn)品很可能會(huì)因缺乏足夠的信息而遺留不少隱患。
在實(shí)際需求分析過(guò)程中，由于業(yè)務(wù)部門(mén)工作很忙，經(jīng)常沒(méi)有時(shí)間或者覺(jué)得沒(méi)有必要與IT人員討論需求分析，有時(shí)甚至希望IT人員無(wú)須討論和編寫(xiě)需求說(shuō)明就能說(shuō)出用戶(hù)的需求。除非遇到的需求極為簡(jiǎn)單；否則千萬(wàn)不能這樣做。
優(yōu)秀的軟件產(chǎn)品建立在優(yōu)秀的需求分析基礎(chǔ)上，而優(yōu)秀的需求分析又源于客戶(hù)與開(kāi)發(fā)人員之間有效的交流和合作。只有雙方參與者都明白自己需要什么、成功的合作需要什么時(shí)，才能建立起一種良好的合作關(guān)系。
十項(xiàng)基本法則
如果CIO嘗試著問(wèn)一些愚蠢問(wèn)題，例如：“以我的理解，你們收到訂單后，會(huì)……”。業(yè)務(wù)人員立刻就會(huì)指出你的錯(cuò)誤，并開(kāi)始滔滔不絕談?wù)摌I(yè)務(wù)，這一招就叫“拋磚引玉”。
開(kāi)發(fā)人員與業(yè)務(wù)部門(mén)的交流需要好的方法。下面建議10條法則，開(kāi)發(fā)人員和業(yè)務(wù)部門(mén)可以通過(guò)評(píng)審以下內(nèi)容并達(dá)成共識(shí)；如果遇到分歧，可通過(guò)協(xié)商達(dá)成對(duì)各自義務(wù)的相互了解，以便減少日后
項(xiàng)目經(jīng)理勝任力免費(fèi)測(cè)評(píng)PMQ上線(xiàn)啦！快來(lái)測(cè)測(cè)你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
