經(jīng)過(guò)一個(gè)漫長(zhǎng)的需求開(kāi)發(fā)、設(shè)計(jì)、編碼和測(cè)試階段后才能夠與客戶(hù)見(jiàn)面，而客戶(hù)在這個(gè)時(shí)間段上進(jìn)入了“盲區(qū)”，直到開(kāi)發(fā)團(tuán)隊(duì)“隆重推出”開(kāi)發(fā)成果。而恰恰這個(gè)時(shí)候是項(xiàng)目風(fēng)險(xiǎn)最大的時(shí)候，由于在過(guò)程中缺乏交流機(jī)會(huì)，客戶(hù)往往會(huì)發(fā)現(xiàn)這個(gè)產(chǎn)品與他們想象的很不一樣，因此很有可能導(dǎo)致項(xiàng)目拖延或者失敗。
小版本發(fā)布則不同，它將系統(tǒng)的實(shí)現(xiàn)分解為多個(gè)連續(xù)的版本，每一個(gè)都實(shí)現(xiàn)一部分的系統(tǒng)功能。當(dāng)每個(gè)小版本結(jié)束后，都會(huì)邀請(qǐng)客戶(hù)評(píng)估這一版本實(shí)現(xiàn)的狀況，并且根據(jù)用戶(hù)反饋制定和調(diào)整下一個(gè)小版本的目標(biāo)。這樣做的好處是顯而易見(jiàn)的：客戶(hù)越早看到產(chǎn)品，就能越早發(fā)現(xiàn)與開(kāi)發(fā)團(tuán)隊(duì)間就用戶(hù)需求方面的理解差異， 盡早調(diào)整需求，從而避免了在項(xiàng)目后期調(diào)整需求帶來(lái)的巨額代價(jià)。另一個(gè)潛在的好處是，這一部分產(chǎn)品功能經(jīng)過(guò)驗(yàn)收后就有可能投入使用，從而盡早為用戶(hù)提供價(jià)值。 當(dāng)然，小版本發(fā)布會(huì)不可避免地面臨較多的需求變更請(qǐng)求，因此需要仔細(xì)的管理需求變更。
以需求實(shí)現(xiàn)為單位規(guī)劃項(xiàng)目實(shí)施
小版本發(fā)布需要為每個(gè)版本制定實(shí)施目標(biāo)，確定在本次版本中需要實(shí)現(xiàn)的功能以及計(jì)劃修改的以前版本的缺陷。而用戶(hù)需求是功能的表達(dá)方式，因此使用用戶(hù)需求作為小版本是順理成章的。當(dāng)然根據(jù)粒度不同，也可以使用軟件需求做為小版本發(fā)布的內(nèi)容。
在定下版本計(jì)劃的目標(biāo)后，就需要規(guī)劃實(shí)施。不過(guò)由于用戶(hù)需求描述的是客戶(hù)的業(yè)務(wù)和對(duì)系統(tǒng)的期望，因此直接采用用戶(hù)需求作為開(kāi)發(fā)任務(wù)安排的起點(diǎn)并不合適。從用戶(hù)需求導(dǎo)出的軟件需求則是以開(kāi)發(fā)團(tuán)隊(duì)能夠理解的語(yǔ)言和結(jié)構(gòu)描述的，很適合作為安排需求實(shí)現(xiàn)的基礎(chǔ)。需求追蹤矩陣可以幫助我們找到版本目標(biāo)中的那些用戶(hù)需求相關(guān)的軟件需求，項(xiàng)目經(jīng)理則為找到的這些軟件需求的實(shí)現(xiàn)制定開(kāi)發(fā)任務(wù)，從而形成開(kāi)發(fā)任務(wù)集的主線，再輔以集成測(cè)試和缺陷追蹤，就形成了完整的開(kāi)發(fā)計(jì)劃。這樣的分解方式自然而且清晰，易于上手。
項(xiàng)目的進(jìn)度監(jiān)控
前文說(shuō)到用戶(hù)需求是客戶(hù)與開(kāi)發(fā)團(tuán)隊(duì)間的契約，因此用戶(hù)需求自然成為客戶(hù)參與項(xiàng)目時(shí)候關(guān)心的重點(diǎn)。但是，在實(shí)際項(xiàng)目過(guò)程中，當(dāng)客戶(hù)真正參與項(xiàng)目、試圖了解項(xiàng)目進(jìn)展?fàn)顩r時(shí)，卻發(fā)現(xiàn)除了用戶(hù)文檔外，再也找不到這些需求的影子，取而代之的是一堆花花綠綠的項(xiàng)目任務(wù)進(jìn)展報(bào)告、甘特圖、統(tǒng)計(jì)報(bào)告等。這些報(bào)表也許準(zhǔn)確地反映了現(xiàn)在項(xiàng)目中任務(wù)的分布和實(shí)現(xiàn)狀況，但是與用戶(hù)關(guān)心的需求實(shí)現(xiàn)狀態(tài)沒(méi)有什么直接聯(lián)系，因而與缺少了共同的語(yǔ)言。
這個(gè)問(wèn)題來(lái)源于傳統(tǒng)項(xiàng)目管理過(guò)程中以任務(wù)為中心的理念和實(shí)踐。在這種理念下，項(xiàng)目被認(rèn)為是一個(gè)任務(wù)的集合，主要的工作就是任務(wù)的分解（WBS： Work Breakdown Structure）、分派、實(shí)現(xiàn)和審核。在一個(gè)項(xiàng)目組內(nèi)部，這的確是工作的主要內(nèi)容。但是，現(xiàn)代的軟件開(kāi)發(fā)過(guò)程都強(qiáng)調(diào)用戶(hù)的參與，項(xiàng)目進(jìn)展僅僅以任務(wù)為視角展現(xiàn)就不是很合適了。對(duì)于客戶(hù)而言，他們所熟悉的問(wèn)題描述，即用戶(hù)需求，已經(jīng)被分解成幾十甚至上百個(gè)大大小小的任務(wù)，再難看出它們之間的聯(lián)系，客戶(hù)自然會(huì)感到迷茫，更別說(shuō)從中看出需求實(shí)現(xiàn)的狀態(tài)了。
而RDPM中提供的是需求實(shí)現(xiàn)狀態(tài)圖，需求變化趨勢(shì)，需求數(shù)量完成率，需求規(guī)模完成率，工時(shí)消耗率等指標(biāo)。這些指標(biāo)對(duì)于客戶(hù)來(lái)說(shuō)更有意義。
需求的變更
“需求變更”是業(yè)界公認(rèn)的項(xiàng)目管理重大挑戰(zhàn)，尤其是項(xiàng)目后期產(chǎn)生的需求變更，對(duì)項(xiàng)目的影響是非常大的。但是，需求開(kāi)發(fā)不可能做到完美無(wú)瑕，而且隨著客戶(hù)對(duì)項(xiàng)目和系統(tǒng)的了解，很有可能提出新的需求或者對(duì)原有的需
求作出修正。因此，需求的變化是不可避免的。
對(duì)于如何應(yīng)對(duì)需求變更，主要的思路有兩條：首先是從源頭做起，提高需求質(zhì)量，減少變更的可能性，這個(gè)在前文已經(jīng)提過(guò)，不再贅述；另一