2010年監(jiān)理工程師輔導(dǎo)資料：項(xiàng)目目標(biāo)和范圍

　　項(xiàng)目目標(biāo)和范圍

　　開始一個(gè)新項(xiàng)目或版本時(shí)候，首先是和用戶一起確認(rèn)需求，進(jìn)行項(xiàng)目的范圍規(guī)劃。項(xiàng)目是范圍，進(jìn)度，質(zhì)量和資源四要素的平衡，用戶對項(xiàng)目進(jìn)度要求和優(yōu)先級高的時(shí)候，我們往往要縮小項(xiàng)目范圍，對用戶需求進(jìn)行優(yōu)先級排序，排除優(yōu)先級低的需求。另外我們做項(xiàng)目范圍規(guī)劃的一個(gè)重要依據(jù)就是我們的歷史經(jīng)驗(yàn)數(shù)據(jù)，對項(xiàng)目特征的清楚認(rèn)識，項(xiàng)目范圍規(guī)劃初期需求你進(jìn)行一個(gè)較宏觀的估算，否則你很難判斷清楚或給用戶承諾在現(xiàn)有資源情況下，你3個(gè)月時(shí)間里面是否可以完成20個(gè)或更多用戶功能。

　　正規(guī)過程好像是先確認(rèn)項(xiàng)目范圍，然后根據(jù)WBS->進(jìn)度計(jì)劃確認(rèn)實(shí)際的項(xiàng)目周期，但實(shí)際情況往往很難如此，用戶往往對進(jìn)度的關(guān)注度大于對范圍的關(guān)注度，一個(gè)項(xiàng)目半年或一年都看不到具體的產(chǎn)品出來用戶肯定是無法接受的，所以我們的軟件項(xiàng)目一般也是按版本增量迭代進(jìn)行開發(fā)。

　　另外這里需要強(qiáng)調(diào)下項(xiàng)目目標(biāo)的確定，項(xiàng)目的目標(biāo)不能簡單理解為在某個(gè)時(shí)間點(diǎn)完成所有功能。項(xiàng)目另外一個(gè)重要目標(biāo)就是項(xiàng)目的質(zhì)量目標(biāo)，你完成的這個(gè)項(xiàng)目需要達(dá)到那個(gè)等級的質(zhì)量標(biāo)準(zhǔn)，交出的產(chǎn)品BUG泄漏率要控制在什么范圍內(nèi)等內(nèi)容。項(xiàng)目的質(zhì)量目標(biāo)不會影響到我們的范圍，但會影響到我們后續(xù)評審，測試等時(shí)間的安排，直接影響到項(xiàng)目的進(jìn)度。

　　PMBOK里已經(jīng)明確提到項(xiàng)目范圍定義的另一個(gè)重要目的就是項(xiàng)目的績效測量和驗(yàn)收準(zhǔn)則，你交付項(xiàng)目的時(shí)候用戶會根據(jù)用戶需求說明書內(nèi)容對項(xiàng)目進(jìn)行驗(yàn)收，所有我們項(xiàng)目的范圍的定義必須是明確，量化，可驗(yàn)證和可測試的，這樣才能夠避免后期無謂的糾紛。

　　另外在概述階段需要分析項(xiàng)目的假設(shè)和約束，假設(shè)和約束又分為技術(shù)方面和非技術(shù)方面，在這里我們分析的所有假設(shè)都可能成為項(xiàng)目的風(fēng)險(xiǎn)。