軟件開發(fā)實(shí)施過程中如何管理業(yè)務(wù)需求
企業(yè)的常規(guī)做法是比較典型的交鑰匙工程，業(yè)務(wù)部門提需求，軟件開發(fā)部門就去張羅方案論證并組織實(shí)施，業(yè)務(wù)部門最后驗(yàn)收評價和使用，IT部門負(fù)責(zé)系統(tǒng)維護(hù)和更 新。這樣做的結(jié)果往往是系統(tǒng)不好用，不適用，或者跟不上業(yè)務(wù)的發(fā)展，業(yè)務(wù)部門不愿意用，最終成為擺設(shè)，浪費(fèi)了投資，而帶來的唯一好處可能是給企業(yè)相關(guān)人員 上了一堂生動現(xiàn)實(shí)的用戶培訓(xùn)課，花錢買了經(jīng)驗(yàn)教訓(xùn)。
一般地，在IT項(xiàng)目上線前后，都會做需求調(diào)研，并要求業(yè)務(wù)相關(guān)方簽字進(jìn)行需求確認(rèn)。而在后續(xù)的項(xiàng)目推進(jìn)過程中，一般都會凍結(jié)業(yè)務(wù)需求不做變更響應(yīng)。這樣會 造成系統(tǒng)上線后與業(yè)務(wù)需求匹配存在偏差，需求實(shí)現(xiàn)程度又直接關(guān)系到項(xiàng)目效果，業(yè)務(wù)用戶要求更改，這又增加系統(tǒng)正式上線時間，影響項(xiàng)目如期驗(yàn)收，IT部門將 被詬病。如果項(xiàng)目比較復(fù)雜，IT部門害怕出錯，前期需求調(diào)研時間都比較長，應(yīng)用推出的周期相應(yīng)增加，業(yè)務(wù)部門等待時間過長，滿意度也會降低。
因此，為了推進(jìn)企業(yè)IT建設(shè)，適應(yīng)業(yè)務(wù)管理需要，必須讓業(yè)務(wù)部門深度參與IT建設(shè)，充分激活業(yè)務(wù)人員的主觀能動性。如果企業(yè)以前沒有采用這種模式，可以選 擇一兩個業(yè)務(wù)部門，試點(diǎn)推行一些節(jié)省人力、改善效率的系統(tǒng)，業(yè)務(wù)部門很快感受到技術(shù)的好處，就會帶動其他部門逐漸形成主動提出各種需求的習(xí)慣。
在軟件開發(fā)系統(tǒng)建設(shè)和完善過程中，企業(yè)都需要積極地管理業(yè)務(wù)用戶的需求，并根據(jù)情形對系統(tǒng)進(jìn)行優(yōu)化完善。為此，IT部門具有IT項(xiàng)目建設(shè)管理、系統(tǒng)維護(hù)職能，需要在系統(tǒng)全生命周期中對業(yè)務(wù)需求進(jìn)行有效地管理，便顯得尤為重要。
一是嘗試逐步建立需求量化管理模式，可以從使用角度對需求管理、IT實(shí)現(xiàn)程度、業(yè)務(wù)期望值等方面進(jìn)行量化，考量項(xiàng)目是否滿足業(yè)務(wù)的期望。以需求管理為例， 在開始建立IT系統(tǒng)時，可同步建立用戶的使用日志，讓管理層、業(yè)務(wù)層的每一個使用者都可隨時了解企業(yè)整體系統(tǒng)的使用情況，哪些系統(tǒng)使用的頻率更高，哪些功 能用的多，哪些功能用的少等。通過這樣不斷的積累，在企業(yè)內(nèi)部形成這樣一種新觀念：一個系統(tǒng)用得好不好，首先源于業(yè)務(wù)部門的需求提得好不好，業(yè)務(wù)部門應(yīng)該 對這些需求負(fù)責(zé)。如果業(yè)務(wù)部門提出一項(xiàng)需求，但實(shí)際上并不使用這些功能，說明當(dāng)初的需求提得并不好。
隨著來自業(yè)務(wù)的需求越來越多，可以進(jìn)一步引入看板管理，將需求進(jìn)行分級分類。需求分為功能需求、界面需求、使用需求等，主要的、重要的需求會被寫到看板 上，讓所有人都可以看到哪些需求正在排隊(duì)，哪些需求正在解決中，哪些需求已經(jīng)解決完畢，盡量做到公開、透明，能夠獲得相關(guān)部門和人員的理解、支持與配合。
二是IT部門要幫助業(yè)務(wù)部門更好地提出需求。通過建立良好的溝通模式，IT部門和業(yè)務(wù)部門共同研究業(yè)務(wù)變化、需求變更，并深入探討需求的合理性。IT部門 在接到一項(xiàng)需求后，并不馬上就投入需求實(shí)現(xiàn)的工作中，而是先對需求進(jìn)行初始化，探究需求背后的動機(jī)，了解業(yè)務(wù)部門的真正想法、管理者的想法、技術(shù)人員的想 法，各方達(dá)成一致。在確定需求的內(nèi)容合理之后，才會開始進(jìn)行規(guī)劃和執(zhí)行階段。
對于IT部門和乙方而言，平時最頭疼的并非項(xiàng)目型需求，而是來自用戶平時的零散需求，或者根本說不清需求，只有一個大概的需求框架。先說前者，零散需求往 往來自對現(xiàn)有某一項(xiàng)功能的改進(jìn)，或者臨時需要對一部分?jǐn)?shù)據(jù)進(jìn)行處理等。面對這些零散需求，一般企業(yè)的IT部門會采取拖延戰(zhàn)術(shù)，盡可能不做響應(yīng)，其實(shí)更好的 做法則是擁抱需求，擁抱變更。一個好的系統(tǒng)是設(shè)計(jì)出來的，一個好的系統(tǒng)也是用出來的。一個系統(tǒng)在用戶的使用中，必然因?yàn)橛脩舻牧?xí)慣和業(yè)務(wù)變化，產(chǎn)生各種需 求，而IT部門通過小修小補(bǔ)的多次改變，才能逐漸讓系統(tǒng)變得友好易用。反之，如果一個系統(tǒng)不做任何變更，用戶逐漸便不愿意使用，系統(tǒng)也就荒廢了。
至于后者，在業(yè)務(wù)需求不清晰的情況下，可以暫緩執(zhí)行需求，應(yīng)和業(yè)務(wù)部門繼續(xù)研究完善。當(dāng)然，如果有能力，可以先搭建一些原型系統(tǒng)，引導(dǎo)業(yè)務(wù)部門思考，不斷參與系統(tǒng)試用，進(jìn)一步明確、完善需求。
三是要加強(qiáng)IT部門自身的團(tuán)隊(duì)建設(shè)。在項(xiàng)目建設(shè)過程中，IT團(tuán)隊(duì)最好能夠相對固定，并且要隨著業(yè)務(wù)發(fā)展進(jìn)行轉(zhuǎn)型。企業(yè)IT部門在進(jìn)行項(xiàng)目管理時，在乙方人 員進(jìn)場后，不能只當(dāng)“包工頭”監(jiān)督乙方的工作進(jìn)度，還要領(lǐng)會業(yè)務(wù)的IT需求和實(shí)施方案，進(jìn)行需求的匹配分析。否則系統(tǒng)一旦上線，IT團(tuán)隊(duì)還是不知道內(nèi)部的 設(shè)計(jì)細(xì)節(jié)�；诖耍琁T團(tuán)隊(duì)需要具備更高的技術(shù)技能，包括把控需求、設(shè)計(jì)主要的技術(shù)路徑，從長遠(yuǎn)來看更有利于IT團(tuán)隊(duì)能力和價值的塑造。
根據(jù)個人經(jīng)驗(yàn)，IT系統(tǒng)建設(shè)都是不斷的折衷，IT部門、業(yè)務(wù)部門和承建方三方相互妥協(xié)。系統(tǒng)越復(fù)雜越是這樣，企業(yè)要抓大放小，實(shí)現(xiàn)主要的功能需求、使用需 求和界面需求，一些未盡需求只要不影響大局也可以留待后續(xù)升級更新中去實(shí)現(xiàn)。從這點(diǎn)來看，IT系統(tǒng)項(xiàng)目建設(shè)和新房裝修其實(shí)差不多，業(yè)主方的能力強(qiáng)、考慮問 題全面，留的遺憾就會少一些，或者無關(guān)痛癢，總體上來說就算是比較成功的了。
