2. 需求管理

　　首先要針對需求做出分析，隨后應(yīng)用于產(chǎn)品并提出方案。需求分析的模型正是產(chǎn)品的原型樣本，優(yōu)秀的需求管理提高了這樣的可能性：它使最終產(chǎn)品更接近于解決需求，提高了用戶對產(chǎn)品的滿意度，從而使產(chǎn)品成為真正優(yōu)質(zhì)合格的產(chǎn)品。從這層意義上說，需求管理是產(chǎn)品質(zhì)量的基礎(chǔ)。

　　需求管理的目的是在客戶與開發(fā)方之間建立對需求的共同理解，維護(hù)需求與其它工作成果的一致性，并控制需求的變更。

　　需求確認(rèn)是指開發(fā)方和客戶共同對需求文檔進(jìn)行評審，雙方對需求達(dá)成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。

　　需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護(hù)“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進(jìn)行開發(fā)。

　　需求變更控制是指依據(jù)“變更申請-審批-更改-重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項目發(fā)生混亂。

　　根據(jù)上面描述的具體方法及步驟，由于需求分析的參與人員、業(yè)務(wù)模式、投資、時間等客觀因素的影響和需求本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛在的風(fēng)險,應(yīng)引起項目相關(guān)干系人的注意。這些風(fēng)險主要表現(xiàn)如下：

　　1)用戶不能正確表達(dá)自身的需求。在實際開發(fā)過程中，常常碰到用戶對自己真正的需求并不是十分明確的情況，他們認(rèn)為計算機是萬能的，只要簡單的說說自己想干什么就是把需求說明白了，而對業(yè)務(wù)的規(guī)則、工作流程卻不愿多談，也講不清楚。這種情況往往會增加需求分析工作難度，分析人員需要花費更多的時間和精力與用戶交流，幫助他們梳理思路，搞清用戶的真實需求。從另一方面來看，他們對于計算機的理解肯定不是很到位，而我們?nèi)绾我龑?dǎo)，正確梳理出正確的需求就需要先從工作業(yè)務(wù)流程出發(fā)，而不是先從計算機方面來考慮問題。

　　2)業(yè)務(wù)人員配合力度不夠。有的用戶日常工作繁忙，他們不愿意付出更多的時間和精力向分析人員講解業(yè)務(wù)，這樣會加大分析人員的工作難度和工作量，也可能導(dǎo)致因業(yè)務(wù)需求不足而使系統(tǒng)無法使用。針對此類問題我們一般的做法是在項目開始階段先確定好一個與客戶溝通過的需求調(diào)研計劃，當(dāng)然這樣還是經(jīng)常會有變動，但相對來講從責(zé)任上來講，客戶也會有一定的壓力，因為如果不配合可能會導(dǎo)致系統(tǒng)進(jìn)度的延誤，其實這也不是客戶希望看到的。

　　3)用戶需求的不斷變更。由于需求識別不全、業(yè)務(wù)發(fā)生變化、需求本身錯誤、需求不清楚等原因，需求在項目的整個生命周期都可能發(fā)生變化，因此，我們要認(rèn)識到，軟件開發(fā)的過程實際上是同變化做斗爭的過程，需求變化是每個開發(fā)人員、項目管理人員都會遇到的問題，也是最頭痛的問題，一旦發(fā)生了需求變化，就不得不修改設(shè)計、重寫代碼、修改測試用例、調(diào)整項目計劃等等，需求的變化就像是萬惡之源，為項目的正常的進(jìn)展帶來不盡的麻煩。針對這類需求變更的問題，個人認(rèn)為是影響進(jìn)度的最大的敵人，目前我們的做法是每次根據(jù)客戶的需求整理出一個書面的文件，由客戶簽字確認(rèn)。當(dāng)然這里還有一個很重要的問題就是不是每個需求都是必須做的，我們要學(xué)習(xí)如何拒絕客戶。

　　4)需求的完整程度。需求如何做到?jīng)]有遺漏?這是一個大問題，大的系統(tǒng)要想窮舉需求幾乎是不可能的，即使小的系統(tǒng)，新的需求也總會不時地冒出來。一個系統(tǒng)很難確定明確的范圍并把所有需求一次性提出來，這會導(dǎo)致開發(fā)人員在項目進(jìn)展中去不斷完善需求，先建立系統(tǒng)結(jié)構(gòu)再完成需求說明，造成返工的可能性很大，會給開發(fā)人員帶來挫折感，降低他們完成項目的信心。

　　5)需求的細(xì)化程度。需求到底描述到多細(xì)，才算可以結(jié)束了?雖然國家標(biāo)準(zhǔn)有需求說明的編寫規(guī)范，但具體到某一個需求上，很難給出一個具體的指標(biāo)，可謂仁者見仁，智者見智，并沒有定論。需求越細(xì)，周期越長，可能的變化越多，對設(shè)計的限制越嚴(yán)格，對需求的共性提取要求也越高，相反，需求越粗，開發(fā)人員在技術(shù)設(shè)計時不清楚的地方就越多，影響技術(shù)設(shè)計。

　　6)需求描述的多義性。需求描述的多義性一方面是指不同讀者對需求說明產(chǎn)生了不同的理解;另一方面是指同一讀者能用不同的方式來解釋某個需求說明。多義性會使用戶和開發(fā)人員等項目參與者產(chǎn)生不同的期望，也會使開發(fā)、測試人員為不同的理解而浪費時間，帶來不可避免的后果便是返工重做。

　　7)忽略了用戶的特點分析。分析人員往往容易忽略了系統(tǒng)用戶的特點，系統(tǒng)是由不同的人使用其不同的特性，使用頻繁程度有所差異，使用者受教育程度和經(jīng)驗水平不盡相同。如果忽略這些的話，將會導(dǎo)致有的用戶對產(chǎn)品感到失望。

　　8)需求開發(fā)的時間保障。為了確保需求的正確性和完整性，項目負(fù)責(zé)人往往堅持要在需求階段花費較多的時間，但用戶和開發(fā)部門的領(lǐng)導(dǎo)卻會因為項目遲遲看不到實際成果而焦慮，他們往往會強迫項目盡快往前推進(jìn)，需求開發(fā)人員也會被需求的復(fù)雜和善變折騰的筋疲力盡，他們也希望盡快結(jié)束需求階段。

　　在實際的工作中，我列了一些需要關(guān)注的問題，以避免一些不必要的麻煩。

　　1)抓住決策者最迫切和最關(guān)心的問題，引起重視。用戶方?jīng)Q策者對項目的關(guān)心重視程度是項目能否順利開展的關(guān)鍵，決策者的真實意圖也是用戶方的最終需求，因此，在開發(fā)過程中要利用一切機會了解決策者關(guān)心的問題，同時也要讓他們了解項目的情況。在諸如談判、專題匯報、協(xié)調(diào)會議、領(lǐng)導(dǎo)視察、階段性成果演示等過程中用簡短明確的語言或文字抓住領(lǐng)導(dǎo)最關(guān)心的問題，引導(dǎo)他們了解和重視項目的開發(fā)，當(dāng)決策者認(rèn)識到項目的重要性時，需求分析工作在人力、物力、時間上就有了保障。

　　2)建立組織保障，明確的責(zé)任分工。項目開發(fā)一般都會成立相應(yīng)的項目組或工程組，目前，常見的組織形式是：產(chǎn)品管理組、質(zhì)量與測試組、程序開發(fā)組、用戶代表組和后勤保障組，各組的主要分工是：產(chǎn)品管理組負(fù)責(zé)確定和設(shè)置項目目標(biāo)，根據(jù)需求的優(yōu)先級確定功能規(guī)范，向相關(guān)人員通報項目進(jìn)展。程序管理組負(fù)責(zé)系統(tǒng)分析，根據(jù)軟件開發(fā)標(biāo)準(zhǔn)協(xié)調(diào)日常開發(fā)工作確保及時交付開發(fā)任務(wù)，控制項目進(jìn)度。程序開發(fā)組負(fù)責(zé)按照功能規(guī)范要求交付軟件系統(tǒng)。質(zhì)量與測試組負(fù)責(zé)保證系統(tǒng)符合功能規(guī)范的要求，測試工作與開發(fā)工作是獨立并行的。用戶代表組負(fù)責(zé)代表用戶方提出需求，負(fù)責(zé)軟件的用戶方測試。后勤保障組負(fù)責(zé)確保項目順利進(jìn)行的后勤保障工作。

　　3)建立良好的溝通環(huán)境和氛圍。分析人員與用戶溝通的程度關(guān)系到需求分析的質(zhì)量，因此建立一個良好的溝通氛圍、處理好分析人員與用戶之間的關(guān)系顯得尤其重要，一般情況，用戶作為投資方會有一些心理優(yōu)勢，希望他們的意見得到足夠的重視，分析人員應(yīng)該充分的認(rèn)識到這一點，做好心理準(zhǔn)備，盡量避免與他們發(fā)生爭執(zhí)，因為我們的目的是幫助用戶說出他們的最終需要。在溝通時分析人員應(yīng)注意以下幾個方面：1)態(tài)度上要尊重對方，但不謙恭。謙恭可能會讓用戶一時感到滿意，但對長期合作并沒有好處，尤其是在發(fā)生沖突的時候，用戶會習(xí)慣性地感到自己的優(yōu)勢，而忽略分析人員地意見。2)分析人員要努力適應(yīng)不同用戶的語言表達(dá)方式。每個人都有自己的表達(dá)方式，所以優(yōu)秀的分析人員應(yīng)該是一個優(yōu)秀的“傾聽者”，他們能很快的適應(yīng)用戶的語言風(fēng)格，理解他們的意思。3)善于表達(dá)自己，善于提問。分析人員在開口前應(yīng)該先讓對方充分表達(dá)他的意思，在領(lǐng)會了后，自己再說，盡量不要搶話。4)工作外的交流有助于增進(jìn)理解，加強溝通。

　　4)需求質(zhì)量控制要制度化需求的變化是軟件項目不可避免的事實，因此需求質(zhì)量控制是一項艱苦的工作，要保證該項工作的順利實施，就必須有制度保證，這個制度可以在項目質(zhì)量控制方案中制定，該方案主要是具體化、定量化的描述用戶要求，形成全面、一致、規(guī)范的軟件需求分析規(guī)格說明書，明確需求分析規(guī)格說明書的工作程序和要素，規(guī)范開發(fā)活動，為后續(xù)軟件設(shè)計、實現(xiàn)、測試、評審及驗收提供依據(jù)。在方案中要明確項目組各部門關(guān)于需求質(zhì)量控制的職責(zé)，制定需求分析的工作程序，包括編制需求分析工作計劃、編制《需求分析說明書》、《需求分析規(guī)格說明書》的評審和確認(rèn)、《需求分析規(guī)格說明書》修改控制、確定需求質(zhì)量控制的質(zhì)量記錄文檔規(guī)范等內(nèi)容。

　　本文論述圍繞于需求管理,需求管理是開發(fā)工作有效進(jìn)行的確證。很明顯需求管理是一種很高層次的系統(tǒng)行為，涉及整個開發(fā)過程和產(chǎn)品本身。需求管理首先要針對需求做出分析，隨后應(yīng)用于產(chǎn)品并提出方案。需求分析的模型正是產(chǎn)品的原型樣本，優(yōu)秀的需求管理提高了這樣的可能性：它使最終產(chǎn)品更接近于解決需求，提高了用戶對產(chǎn)品的滿意度，從而使產(chǎn)品成為真正優(yōu)質(zhì)合格的產(chǎn)品。從這層意義上說，需求管理是產(chǎn)品質(zhì)量的基礎(chǔ)。