論如何進行有效的需求管理

1、 論如何進行有效的需求管理 通過高級項目經(jīng)理5天課程的培訓(xùn)，個人感覺對于原先的工作實踐有了一個很好的指導(dǎo)，從原先的實踐上升了一個層次，對于實踐有了一個很好的理論指導(dǎo)。我想很多人可能會與我同感，一個項目做了很久，感覺總是做不完，就像一個“無底洞”。你想加人盡快完成這個項目，而用戶總是有新的需求要項目開發(fā)方來做，就像用戶是一個不知廉恥的要求者，而開發(fā)方是在苦苦接收的接受者。實際上，這里涉及到一個需求管理的概念。項目中哪些該做，哪些不該做，做到什么程度，都是由需求管理來決定的。那么，到底什么是需求管理，從這幾天的學(xué)習(xí)中，我從理論上對此問題做了一個分析，表達一些自已的想法。影響項目的最后成功的因素是多

2、方面的，包括項目管理的九大知識領(lǐng)域(包括項目的整體管理、范圍管理、時間管理、費用管理、質(zhì)量管理、溝通管理、成本管理、人力資源管理、采購管理)。然而，要這九大知識領(lǐng)域?qū)椖砍晒Ξa(chǎn)生的影響的輕重程度上進行比較的話，我個人認(rèn)為其中項目范圍管理中的需求管理是最為重要的。本文主要講述范圍管理中的需求管理部分。需求管理是軟件項目中一項十分重要的工作，據(jù)調(diào)查顯示在眾多失敗的軟件項目中，由于需求原因?qū)е碌募s占了很大的一部分，本人從事的工作經(jīng)歷中有好2次就是因為需求不明確，導(dǎo)致最終的系統(tǒng)不可控，項目陷入困境。因此，需求工作將對軟件項目能否最終實現(xiàn)產(chǎn)生至關(guān)重要的影響。雖然如此，在項目開發(fā)工作中，很多人對需求的認(rèn)識

3、還遠遠不夠，從本人參與或接觸到的一些項目來看，小到幾萬元，大到上千萬元的軟件項目的需求都或多多少的存在問題。有的是開發(fā)者本身不重視原因,有的是技術(shù)原因、有的是人員組織原因、有的是溝通原因、有的是機制原因，以上種種原因都表明做好軟件需求開發(fā)是一項系統(tǒng)工作，而不是簡單的技術(shù)工作，只有系統(tǒng)的了解和掌握需求的基本概念、方法、手段、評估標(biāo)準(zhǔn)、風(fēng)險等相關(guān)知識，并在實踐中加以應(yīng)用，才能真正做好需求的開發(fā)和管理工作。在軟件項目的開發(fā)過程中，需求變更貫穿了軟件項目的整個生命周期，從軟件的項目立項，研發(fā)，維護，用戶的經(jīng)驗在增加，對使用軟件的感受有變化，以及整個行業(yè)的新動態(tài)，都為軟件帶來不斷完善功能，優(yōu)化性能，提高

4、用戶友好性的要求。在軟件項目管理過程中，項目經(jīng)理經(jīng)常面對用戶的需求變更。如果不能有效處理這些需求變更，項目計劃會一再調(diào)整，軟件交付日期一再拖延，項目研發(fā)人員的士氣將越來越低落，將直接導(dǎo)致項目成本增加、質(zhì)量下降及項目交付日期推后。這決定了項目組必須擁有需求管理策略。下面主要針對需求開發(fā)及需求管理兩個方面對需求進行分析。1. 需求開發(fā)，從目前我們的實際工作情況來看按順序主要分成如下幾個部分: 請教行業(yè)專家行業(yè)客戶對信息化的需求越來越細化，對專業(yè)性以及行業(yè)能力的全面性要求越來越高，惟有深入行業(yè)，洞察其需求，研發(fā)出更適合客戶需求的產(chǎn)品，才能成功。因此有必要先請這方面的行業(yè)專家對于客戶的業(yè)務(wù)需求進行從流

5、程上的梳理。為什么請行業(yè)專家，而不是直接請客戶進行交談，得到其實需求，個人認(rèn)為主要是因為目前各政府部門、企事業(yè)單位對于信息化與業(yè)需求的整合這一塊缺少經(jīng)驗，大部分情況還不能完全整理出完善、清晰的系統(tǒng)需求來。只有通過行業(yè)專家對其實業(yè)務(wù)流程進行梳理，一方面更容易與客戶產(chǎn)生共鳴，另一方面也可以大大減少因為知識方面的差異導(dǎo)致錯識需求的產(chǎn)生。 和客戶交談你要面對“正確”的客戶區(qū)分不同層次的客戶需求,要面對不同層級，不同部門的客戶，把客戶分類,區(qū)分需求的優(yōu)先級別.如果你做的項目業(yè)務(wù)是你熟悉的，那還好，如果是你不熟悉的，一定要花點精力學(xué)習(xí)一下這個行業(yè)業(yè)務(wù)的背景資料,這也是我上面談到的先請行業(yè)專家的原因。畢竟，

6、客戶是不可能給你系統(tǒng)地介紹業(yè)務(wù)的。只有你通曉了行業(yè)業(yè)務(wù)，才能和用戶交流，并正確而有效地引導(dǎo)客戶，做好需求分析，你不能指望客戶能明確地說出需求。當(dāng)然，這也是系統(tǒng)分析人員的職責(zé)所在。在開始做需求的時候，你最后花一點時間搞清楚你接觸的客戶是不是做實際業(yè)務(wù)的客戶，如果你面對的客戶不是將來的系統(tǒng)的實際使用者。你就有點麻煩了?？赡芩强蛻艄九蛇^來的it部的人，他會提一大堆東西，而這些東西可能根本不是實際業(yè)務(wù)需要的功能，而他一般還會興致勃勃地給你一些技術(shù)實現(xiàn)的建議。這個時候你就要小心了，如果你聽了他的話，你可能在最后才發(fā)現(xiàn)，你花了大量精力解決的問題，其實并不是客戶真正需要的。而你真正需要關(guān)注的，卻做得遠遠

7、不夠。 參考其他類似軟件和系統(tǒng)在經(jīng)過與客戶的溝通，并形成初步的需求之后,不要急成正式的需求，請先參考一下以前的一些系統(tǒng)，去理解一下了解到的需求與原先系統(tǒng)的差異，并去發(fā)現(xiàn)是否有些需求會產(chǎn)生錯識需求。 業(yè)務(wù)建模為需求建立模型，需求的圖形分析模型是軟件需求規(guī)格說明極好的補充說明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實體關(guān)系圖、狀態(tài)變換圖、對話框圖、對象類及交互作用圖。 需求整理并形成需求規(guī)格說明書需求規(guī)格說明書的模板我想每家公司都是不一樣的，也沒有必要都一樣，但我認(rèn)為每個需求規(guī)格說明書至少應(yīng)包括軟件需求一旦通過了評審,就應(yīng)該基線化,納

8、入配置管理庫.而在配置管理庫中的文檔或代碼不能再輕易進行修改.當(dāng)有需求要進行變更的時候,就必須提出申請,寫需求變更計劃,審核通過,才有權(quán)限進行需求變更.然后配置管理員一定要做好需求的跟蹤.,凡是跟變更需求有牽連的開發(fā)人員和測試人員都要同步的通知到和及時讓他們做好相應(yīng)部分的各類文檔的修改。 需求變更管理需求的變更管理我個人認(rèn)為是最容易出問題，一般項目做不完也主要是由此產(chǎn)生。需求變更的出現(xiàn)主要是因為在項目的需求確定階段，用戶往往不能確切地定義自己需要什么。用戶常常以為自己清楚，但實際上他們提出的需求只是依據(jù)當(dāng)前的工作所需，而采用的新設(shè)備、新技術(shù)通常會改變他們的工作方式;或者要開發(fā)的系統(tǒng)對用戶來說也

9、是個未知數(shù)，他們以前沒有過相關(guān)的使用經(jīng)驗。隨著開發(fā)工作的不斷進展，系統(tǒng)開始展現(xiàn)功能的雛形，用戶對系統(tǒng)的了解也逐步深入。于是，他們可能會想到各種新的功能和特色，或?qū)σ郧疤岢龅囊筮M行改動。他們了解得越多，新的要求也就越多，需求變更因此不可避免地一次又一次出現(xiàn)。如何有效的管理需求變更，下面是我公司目前的做法。公司采用test director作為需求管理工具，需求人員每次與客戶溝通后形成需求調(diào)查表，統(tǒng)一錄入test director,并進行綜合及整理后形成需求規(guī)格說明書， 之后由研發(fā)部、產(chǎn)品部、及銷售代表(如果有客戶參加就更好了)進行需求評審，建立需求基線。制訂簡單、有效的變更控制流程，并形成文檔

10、。在建立了需求基線后提出的所有變更都必須遵循變更控制流程進行控制，同時每一筆重要的需求變更都需要客戶簽字確認(rèn)才認(rèn)為需求變更生效。需求變更后，受影響的軟件計劃、產(chǎn)品、活動都要進行相應(yīng)的變更，以保持和更新的需求一致。因為test director提供了需求變更記錄，可以幫助我們形成良好的文檔，便于進行管理。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ā)方之

11、間建立對需求的共同理解，維護需求與其它工作成果的一致性，并控制需求的變更。需求確認(rèn)是指開發(fā)方和客戶共同對需求文檔進行評審，雙方對需求達成共識后作出書面承諾，使需求文檔具有商業(yè)合同效果。需求跟蹤是指通過比較需求文檔與后續(xù)工作成果之間的對應(yīng)關(guān)系，建立與維護“需求跟蹤矩陣”，確保產(chǎn)品依據(jù)需求文檔進行開發(fā)。需求變更控制是指依據(jù)“變更申請-審批-更改-重新確認(rèn)”的流程處理需求的變更，防止需求變更失去控制而導(dǎo)致項目發(fā)生混亂。根據(jù)上面描述的具體方法及步驟，由于需求分析的參與人員、業(yè)務(wù)模式、投資、時間等客觀因素的影響和需求本身具有主觀性和可描述性差的特點，因此，需求分析工作往往面臨著一些潛在的風(fēng)險,應(yīng)引起項目

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

13、力向分析人員講解業(yè)務(wù)，這樣會加大分析人員的工作難度和工作量，也可能導(dǎo)致因業(yè)務(wù)需求不足而使系統(tǒng)無法使用。針對此類問題我們一般的做法是在項目開始階段先確定好一個與客戶溝通過的需求調(diào)研計劃，當(dāng)然這樣還是經(jīng)常會有變動，但相對來講從責(zé)任上來講，客戶也會有一定的壓力，因為如果不配合可能會導(dǎo)致系統(tǒng)進度的延誤，其實這也不是客戶希望看到的。3)用戶需求的不斷變更。由于需求識別不全、業(yè)務(wù)發(fā)生變化、需求本身錯誤、需求不清楚等原因，需求在項目的整個生命周期都可能發(fā)生變化，因此，我們要認(rèn)識到，軟件開發(fā)的過程實際上是同變化做斗爭的過程，需求變化是每個開發(fā)人員、項目管理人員都會遇到的問題，也是最頭痛的問題，一旦發(fā)生了需求變

14、化，就不得不修改設(shè)計、重寫代碼、修改測試用例、調(diào)整項目計劃等等，需求的變化就像是萬惡之源，為項目的正常的進展帶來不盡的麻煩。針對這類需求變更的問題，個人認(rèn)為是影響進度的最大的敵人，目前我們的做法是每次根據(jù)客戶的需求整理出一個書面的文件，由客戶簽字確認(rèn)。當(dāng)然這里還有一個很重要的問題就是不是每個需求都是必須做的，我們要學(xué)習(xí)如何拒絕客戶。4)需求的完整程度。需求如何做到?jīng)]有遺漏?這是一個大問題，大的系統(tǒng)要想窮舉需求幾乎是不可能的，即使小的系統(tǒng)，新的需求也總會不時地冒出來。一個系統(tǒng)很難確定明確的范圍并把所有需求一次性提出來，這會導(dǎo)致開發(fā)人員在項目進展中去不斷完善需求，先建立系統(tǒng)結(jié)構(gòu)再完成需求說明，造成

15、返工的可能性很大，會給開發(fā)人員帶來挫折感，降低他們完成項目的信心。5)需求的細化程度。需求到底描述到多細，才算可以結(jié)束了?雖然國家標(biāo)準(zhǔn)有需求說明的編寫規(guī)范，但具體到某一個需求上，很難給出一個具體的指標(biāo)，可謂仁者見仁，智者見智，并沒有定論。需求越細，周期越長，可能的變化越多，對設(shè)計的限制越嚴(yán)格，對需求的共性提取要求也越高，相反，需求越粗，開發(fā)人員在技術(shù)設(shè)計時不清楚的地方就越多，影響技術(shù)設(shè)計。6)需求描述的多義性。需求描述的多義性一方面是指不同讀者對需求說明產(chǎn)生了不同的理解;另一方面是指同一讀者能用不同的方式來解釋某個需求說明。多義性會使用戶和開發(fā)人員等項目參與者產(chǎn)生不同的期望，也會使開發(fā)、測試人

16、員為不同的理解而浪費時間，帶來不可避免的后果便是返工重做。7)忽略了用戶的特點分析。分析人員往往容易忽略了系統(tǒng)用戶的特點，系統(tǒng)是由不同的人使用其不同的特性，使用頻繁程度有所差異，使用者受教育程度和經(jīng)驗水平不盡相同。如果忽略這些的話，將會導(dǎo)致有的用戶對產(chǎn)品感到失望。8)需求開發(fā)的時間保障。為了確保需求的正確性和完整性，項目負(fù)責(zé)人往往堅持要在需求階段花費較多的時間，但用戶和開發(fā)部門的領(lǐng)導(dǎo)卻會因為項目遲遲看不到實際成果而焦慮，他們往往會強迫項目盡快往前推進，需求開發(fā)人員也會被需求的復(fù)雜和善變折騰的筋疲力盡，他們也希望盡快結(jié)束需求階段。在實際的工作中，我列了一些需要關(guān)注的問題，以避免一些不必要的麻煩。

17、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ā)組、用戶代表組和后勤保障組，

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