任何從事IT行業(yè)的人員都清楚，軟件開(kāi)發(fā)項(xiàng)目失敗的其中一個(gè)主要原因是項(xiàng)目在啟動(dòng)的時(shí)候功能需求模糊，導(dǎo)致開(kāi)發(fā)過(guò)程的不斷修改，讓項(xiàng)目不斷延誤，功能不斷擴(kuò)張，資源越來(lái)越吃緊，最終影響交付的質(zhì)量和客戶(hù)的滿(mǎn)意度。希賽網(wǎng)軟件工程頻道有很多文章介紹如何去把握需求，很多業(yè)內(nèi)人士也常在網(wǎng)上分享他們把握客戶(hù)需求的方法，可惜效果并不太理想。因?yàn)槲覀兘^對(duì)不能夠把握基本上不存在的“客戶(hù)需求”。
作為一個(gè)軟件工程的專(zhuān)業(yè)人員，如何能夠從客戶(hù)所提供的模糊需求建立一個(gè)明確的范圍，然后從這個(gè)范圍中建立整個(gè)系統(tǒng)的功能需求，讓我們可以控制軟件開(kāi)發(fā)的過(guò)程，減少項(xiàng)目的范圍變動(dòng)，降低開(kāi)發(fā)過(guò)程中的修改需求，讓我們能夠按預(yù)算、按工期，提交符合質(zhì)量要求的交付物，達(dá)到客戶(hù)的預(yù)期目標(biāo)，我們便需要理解問(wèn)題的根源，打破過(guò)去的工作習(xí)慣，尋找一套可行的方法。
在項(xiàng)目管理知識(shí)體系(PMBOK)中我們學(xué)習(xí)范圍變動(dòng)管理，而不是需求變動(dòng)管理，范圍變動(dòng)才是需求變動(dòng)的主要原因。其實(shí)在這里PMBOK做了一個(gè)假設(shè)，就是有了明確的范圍便可以建立明確的功能需求，如果能夠控制范圍，便能夠控制功能需求。
功能需求變動(dòng)是導(dǎo)致軟件工程在開(kāi)發(fā)過(guò)程中進(jìn)行修改的主要原因，那是說(shuō)我們?cè)谲浖こ添?xiàng)目啟動(dòng)的時(shí)候沒(méi)有把握好項(xiàng)目的范圍，才會(huì)發(fā)生我們面對(duì)的問(wèn)題。所以，我們首先需要理解范圍與功能需求的關(guān)系，什么是范圍?什么原因?qū)е滦枨竽：?能夠明確理解兩者的異同，才能夠找出解決的方法，建立明確的項(xiàng)目范圍，轉(zhuǎn)換成功能需求。讓我們能夠從模糊的需求轉(zhuǎn)變成為明確的需求。
建立明確的項(xiàng)目范圍代替不明確的范圍，才能夠減少開(kāi)發(fā)過(guò)程中的修改。本人最近一直從過(guò)去30多年的科技項(xiàng)目開(kāi)發(fā)和管理經(jīng)驗(yàn)中，結(jié)合近年回國(guó)后對(duì)國(guó)內(nèi)IT企業(yè)運(yùn)營(yíng)模式的理解，我國(guó)技術(shù)人員的工作習(xí)慣，客戶(hù)的思維、心態(tài)和期盼，總結(jié)出一套建立明確項(xiàng)目范圍的方法，特在此與讀者分享，共同改善我國(guó)軟件企業(yè)的困境(請(qǐng)參考希賽顧問(wèn)黃紹良教授的《我國(guó)軟件企業(yè)的未來(lái)生存空間》一文)。
70年代的項(xiàng)目范圍與需求
項(xiàng)目范圍與項(xiàng)目需求是兩個(gè)完全不同的概念，但兩者卻不能單獨(dú)處理。讓我們回到上世紀(jì)70年代的時(shí)候，國(guó)外企業(yè)正進(jìn)行自動(dòng)化的過(guò)程。項(xiàng)目基本上是把人工作業(yè)流程轉(zhuǎn)變成計(jì)算機(jī)程序。那時(shí)候并沒(méi)有項(xiàng)目范圍這個(gè)名稱(chēng)，我們用Terms of Reference (ToR)來(lái)界定項(xiàng)目的邊界，采用文字描述的方法說(shuō)明這個(gè)項(xiàng)目要做什么。例如，要為希賽公司建立一個(gè)庫(kù)存管理系統(tǒng)，這個(gè)項(xiàng)目的ToR會(huì)說(shuō)明貨品從進(jìn)入倉(cāng)庫(kù)開(kāi)始，到貨品因應(yīng)生產(chǎn)或銷(xiāo)售申領(lǐng)要求離開(kāi)倉(cāng)庫(kù)為止，其中包括貨品存入量的統(tǒng)計(jì)，存放位置記錄，總庫(kù)存量統(tǒng)計(jì)、申領(lǐng)數(shù)目、檢貨、提取貨品、準(zhǔn)備出倉(cāng)，最后更新貨品存量統(tǒng)計(jì)等工作過(guò)程。這個(gè)項(xiàng)目的Term of Reference只說(shuō)明這個(gè)項(xiàng)目的范圍，包括一些需要執(zhí)行的工作和記錄等。
在項(xiàng)目實(shí)施過(guò)程中，系統(tǒng)分析員會(huì)對(duì)庫(kù)存管理全過(guò)程進(jìn)行調(diào)查或調(diào)研，采用訪談或觀察等方法，記錄上述范圍中的整個(gè)工序的過(guò)程，每一個(gè)數(shù)據(jù)的更新，參考記錄數(shù)據(jù)的報(bào)告格式和任何有關(guān)的工作單據(jù)。這些工序，數(shù)據(jù)更新時(shí)間和地點(diǎn)，報(bào)告打印等工作最后便成為系統(tǒng)的功能需求。這些需求能夠讓最終用戶(hù)明確開(kāi)發(fā)人員已經(jīng)把握了整個(gè)工作流程，明確每一個(gè)工作的內(nèi)容，保證完成的系統(tǒng)能夠提供庫(kù)存管理的功能。
這段時(shí)間軟件工程的焦點(diǎn)是在范圍確認(rèn)后的信息搜集(Facts Finding)和需求分析(Requirement Analysis)中。依據(jù)PMBOK的論述，我們?cè)?0世紀(jì)70年代，的確可以從范圍的建立帶出明確的功能需求，減少開(kāi)發(fā)過(guò)程中的修改，降低項(xiàng)目延誤的風(fēng)險(xiǎn)。這個(gè)模式在我國(guó)軟件產(chǎn)業(yè)發(fā)展初期采用，大概是20世紀(jì)