IT項(xiàng)目管理的需求管理如何做到更好
我們知道現(xiàn)代項(xiàng)目管理的六要素是：時(shí)間、成本、質(zhì)量、組織、范圍、客戶滿意度，實(shí)際上，要滿足這六個(gè)要素，計(jì)劃一個(gè)良好的需求分析是實(shí)現(xiàn)這六因素的前提，如果我們?cè)陧?xiàng)目生命周期的某些階段出了問題，而我們可能還不知道，這將影響整個(gè)項(xiàng)目周期，無論該計(jì)劃如何詳盡，如果需求有誤和需求分析不到位，項(xiàng)目的控制將沒有任何價(jià)值，IT軟件項(xiàng)目中百分之四十至百分之六十的問題都是在需求分析階段埋下的“禍根”(Leffingwell 1997)，從某種意義來講，項(xiàng)目的成功基于項(xiàng)目的需求管理的成功。
1 需求的定義及特點(diǎn) 項(xiàng)目管理者聯(lián)盟文章
根據(jù)IEEE項(xiàng)目工程標(biāo)準(zhǔn)詞匯表(1997)年中對(duì)需求的描述如下：業(yè)主解決問題或達(dá)到目的所需的條件或權(quán)能，和系統(tǒng)或系統(tǒng)部件要滿足合同、標(biāo)準(zhǔn)、規(guī)范或其他正式規(guī)定文檔所需具有的條件或權(quán)能。在PMBOK中，項(xiàng)目需求就是在“項(xiàng)目范圍”約定的。
需求最顯著的特點(diǎn)是“隨著項(xiàng)目而改變、隨著項(xiàng)目而漸進(jìn)明晰”，項(xiàng)目管理的特點(diǎn)是隨著進(jìn)展而漸進(jìn)明細(xì)化，可以看出需求管理和項(xiàng)目管理一樣，這就意味著需求在項(xiàng)目的整個(gè)生命周期都可能存在的，這樣項(xiàng)目管理的過程，也必不可少需求的管理。
2 如何獲取需求
獲得需求的方式可以有多種多樣：電話詢問、現(xiàn)場(chǎng)考察、聆聽用戶講解、閱讀用戶編制的相關(guān)文件(如招標(biāo)書)，其實(shí)這些方法都是GET方式，我們可以通過以下兩類技術(shù)手段來達(dá)到：GET(獲取)和PUSH(引導(dǎo)、反饋、激發(fā))相互結(jié)合的方式來得到我們真正的需求，而這兩個(gè)過程都是必須交互進(jìn)行的，一般我們可以篩選一名非常有經(jīng)驗(yàn)(包括談判技巧、深厚的業(yè)務(wù)和技術(shù)背景、人緣很好、勤奮努力)的人士擔(dān)任需求工程師，長(zhǎng)期在客戶那里工作，他的工作主要是界定項(xiàng)目的范圍和需求變更管理，通過我們編制的各類模板文檔來實(shí)現(xiàn)需求變更的控制;
一般來講IT集成需求包含三個(gè)不同的層次-業(yè)務(wù)需求、用戶需求和功能需求-也包括非功能需求:業(yè)務(wù)需求提供給客戶和產(chǎn)品開發(fā)商的新系統(tǒng)的最初利益,反映了組織機(jī)構(gòu)或客戶對(duì)系統(tǒng)、產(chǎn)品高層次的目標(biāo)要求，它們?cè)陧?xiàng)目視圖與范圍文檔中予以說明;用戶需求文檔描述了用戶使用產(chǎn)品必須要完成的任務(wù)，這在使用實(shí)例文檔或方案腳本說明中予以說明;功能需求定義了開發(fā)人員必須實(shí)現(xiàn)的軟件功能，使得用戶能完成他們的任務(wù)，從而滿足了業(yè)務(wù)需求，必須具備一定的業(yè)務(wù)背景和技術(shù)背景，能從三個(gè)不同的層次發(fā)掘客戶的需求。
根據(jù)我們?cè)谀呈芯W(wǎng)上審批項(xiàng)目中的經(jīng)驗(yàn)，我們采用如下方法，其中每項(xiàng)工作都記錄文檔備案：如查閱了大量資料和病歷資料格式、各類應(yīng)急防御措施、統(tǒng)計(jì)分析報(bào)表、系統(tǒng)規(guī)劃書、舊系統(tǒng)業(yè)務(wù)狀況、歷史資料、還訪談了操作員的應(yīng)用感受、多次技術(shù)交流、專題討論等多種形式的交互式討論和分析。這樣無論是業(yè)務(wù)、功能、用戶詳盡的期望我們都了解的比較透徹。
3 需求管理
獲取了需求接著要作的的工作就是對(duì)需求分析、消化和評(píng)審、基線制定、需求說明書制定，這里我們主要集中在需求分析和需求說明書兩方面來。
3.1需求分析
1)建立需求關(guān)聯(lián)圖：需求關(guān)聯(lián)圖是用于定義系統(tǒng)與系統(tǒng)外部實(shí)體間的界限和接口的簡(jiǎn)單模型，同時(shí)它也明確了通過接口的信息流和物質(zhì)流，通過關(guān)聯(lián)圖，對(duì)用戶需求的約定和確認(rèn)以及CCB的評(píng)審都是非常關(guān)鍵的。
2)創(chuàng)建開發(fā)原型：創(chuàng)建用戶接口原型可以在如下應(yīng)用如下情況：如果開發(fā)人員或用戶不能確定需求時(shí)，開發(fā)一個(gè)用戶接口原型，這樣使得許多概念和可能發(fā)生的事更為直觀明了。用戶通過評(píng)價(jià)原型將使項(xiàng)目參與者能更好地相互理解所要解決的問題。通過開發(fā)原形，業(yè)主和集成商都可以相互了解業(yè)務(wù)，發(fā)掘潛在的信息，避免用戶需求的不必要變更。
3)分析可行性：分析需求可行性在允許的成本、性能要求下，分析每項(xiàng)需求實(shí)施的可行性，明確與每項(xiàng)需求實(shí)現(xiàn)相聯(lián)系的風(fēng)險(xiǎn)，包括與其它需求的沖突，對(duì)外界因素的依賴和技術(shù)障礙，這個(gè)主要用于內(nèi)部評(píng)審和制定技術(shù)線路提供依據(jù)，如在什么情況下采用.NET技術(shù),什么情況下采用J2EE技術(shù),我們?cè)?003年電子政務(wù)網(wǎng)上審批系統(tǒng)中充分對(duì)需求(業(yè)務(wù)、技術(shù)、用戶操作人員需求、現(xiàn)有系統(tǒng)需求等)做整體提取分析來確定技術(shù)線路的選型。
4)確定需求優(yōu)先級(jí)：確定需求的優(yōu)先級(jí)別應(yīng)用分析方法來確定使用實(shí)例、產(chǎn)品特性或單項(xiàng)需求實(shí)現(xiàn)的優(yōu)先級(jí)別。以優(yōu)先級(jí)為基礎(chǔ)確定產(chǎn)品版本將包括哪些特性或哪類需求。當(dāng)允許需求變更時(shí)，在特定的版本中加入每一項(xiàng)變更，并在那個(gè)版本計(jì)劃中作出需要的變更。
5)為需求建立模型：為需求建立模型需求的圖形分析模型是軟件需求規(guī)格說明極好的補(bǔ)充說明。它們能提供不同的信息與關(guān)系以有助于找到不正確的、不一致的、遺漏的和冗余的需求。這樣的模型包括數(shù)據(jù)流圖、實(shí)體關(guān)系圖、狀態(tài)變換圖、對(duì)話框圖、對(duì)象類及交互作用圖。
6)編寫數(shù)據(jù)字典：在需求階段，很難使團(tuán)隊(duì)的思路一致，建立一個(gè)合適的機(jī)制是完全必要的，這就是數(shù)據(jù)字典，數(shù)據(jù)字典是對(duì)系統(tǒng)用到的所有數(shù)據(jù)項(xiàng)和結(jié)構(gòu)的定義，以確保開發(fā)人員使用統(tǒng)一的數(shù)據(jù)定義。在需求階段，數(shù)據(jù)字典至少應(yīng)定義客戶數(shù)據(jù)項(xiàng)以確保客戶與開發(fā)小組是使用一致的定義和術(shù)語。分析和設(shè)計(jì)工具通常包括數(shù)據(jù)字典組件。
3.2建立需求與產(chǎn)品質(zhì)量的關(guān)系模型
需求是項(xiàng)目正確實(shí)施的一個(gè)前提,如果沒有抓住用戶的需求,那么很可能是漏洞百出，最終產(chǎn)品將不是一個(gè)真正的可交付物。我們知道，質(zhì)量是一個(gè)客戶滿意度的一個(gè)主要因素，質(zhì)量在項(xiàng)目中又有許多影響因素，這里我們著重從需求的角度出發(fā)來討論需求與質(zhì)量的關(guān)系，那么如何來從需求的角度出發(fā)建立與質(zhì)量的控制呢?
我們來建立一個(gè)思路如下：客戶所有的期望 需求產(chǎn)生 轉(zhuǎn)換矩陣 產(chǎn)品開發(fā) 可交付物 客戶滿意。在這里轉(zhuǎn)換矩陣就非常關(guān)鍵了，如何來實(shí)現(xiàn)需求與質(zhì)量的關(guān)聯(lián)呢，可以通過質(zhì)量功能調(diào)配(QFD)來實(shí)現(xiàn)，通過QFD可以把需求(用戶期望)、產(chǎn)品特性關(guān)聯(lián)起來，這里要用到一個(gè)工具：質(zhì)量屋(House of Quality)，我現(xiàn)在用一個(gè)案例來說明這個(gè)工具，在做某市網(wǎng)上審批項(xiàng)目中，我們從客戶哪里收集和整理了許多需求：審批項(xiàng)目、報(bào)表要求、認(rèn)證方式、工作流要求、數(shù)據(jù)范圍及格式、操作界面、醫(yī)藥管理規(guī)范等等;我們通過建立質(zhì)量屋完成了需求與如何去實(shí)現(xiàn)，如下圖所示：
在QFD技術(shù)中以三種形式來定性地描述工程特征之間的相關(guān)影響關(guān)系，即正相關(guān)(向相同方向變化)、不相關(guān)和負(fù)相關(guān)(向相反方向變化)。對(duì)相關(guān)程度還可以進(jìn)一步地細(xì)分為強(qiáng)相關(guān)、一般相關(guān)和弱相關(guān)幾種關(guān)系，并給以標(biāo)度值來表達(dá)相關(guān)程度，這樣我們可以定義一些需求的強(qiáng)弱程度：如不確定需求、一般確定需求、強(qiáng)烈確定需求等，在這個(gè)HOQ中，還要用到其他技術(shù)工具，如：要素加權(quán)法等，這樣做的好處是主次分明，可以把需求分析和管理做到隨時(shí)間的推進(jìn)客戶的變更變限于固定的框架里，符合如下曲線，而不至于走向極端。
3.3需求說明書編寫經(jīng)驗(yàn)談
目前需求說明書有固定的格式和要求,可以從專門介紹需求說明書的相關(guān)書籍中獲得,在本論文中,我著重闡述需求說明書的經(jīng)驗(yàn)，編寫優(yōu)秀的是沒有公式化的方法的，這需要大量的經(jīng)驗(yàn)，要從你在過去的文檔中發(fā)現(xiàn)的問題學(xué)習(xí)。
1) 采用IT項(xiàng)目需求規(guī)格說明模版,要注意的是很多人拿來需求說明書模板就套用,這就有很大的風(fēng)險(xiǎn),例如:會(huì)出現(xiàn)需求不全、需求范圍界定不到位、需求分類不明確等因素，我們應(yīng)該把需求規(guī)格說明書拿來后先羅列許多要點(diǎn)：約定、法律法規(guī)、需求分類、技術(shù)限制、采用的技術(shù)和工具等等全面考慮，與項(xiàng)目干系人特別是用戶進(jìn)行溝通，然后討論，可以采用頭腦風(fēng)暴法和德爾菲方法來討論，確定說明書大綱，而不能照本著書。
2) 附加文檔的管理，值得注意的是需求說明書并非一成不變的，我們可以通過附加文檔來跟蹤用戶的新的需求和需求變更，這樣必須建立一個(gè)配套的文檔集合，隨時(shí)跟蹤需求，保證開發(fā)團(tuán)體步進(jìn)統(tǒng)一，一般這些文件是要考慮的：《需求(或功能)變更申請(qǐng)書》、《需求(或功能)變更規(guī)格書》、《需求清單一覽表》等。這樣做的好處是對(duì)需求時(shí)實(shí)監(jiān)控，保證項(xiàng)目的安排，同時(shí)讓用戶知道變更是一件很嚴(yán)肅的事情，可以防止個(gè)別人提出無法界定的需求(因?yàn)楝F(xiàn)實(shí)IT項(xiàng)目中，很多問題是其他系統(tǒng)的遺留而又超出本項(xiàng)目技術(shù)線路可以彌補(bǔ)的問題等)。項(xiàng)目管理論壇
3) 編寫需求說明書的時(shí)候，可能還會(huì)遇到一些解決不了的需求，我們也一定用專門的章節(jié)要羅列出來，防止漏項(xiàng)，同時(shí)也利于我們?cè)谧鰧?shí)施計(jì)劃的時(shí)候來采取那種措施，采購其他設(shè)備、投入相關(guān)人力或其他辦法。
4) 需求必須要客戶確認(rèn)，許多項(xiàng)目，可能開發(fā)商為了保護(hù)自己的“利益”很多事情都沒有得到客戶的確認(rèn)，其實(shí)在需求階段，我們的需求是要跟客戶確認(rèn)的，比如數(shù)據(jù)字典、界面選型、技術(shù)線路、功能模塊等，這樣做的好處是防止需求把握不得當(dāng)，缺少了用戶必要的功能，另一個(gè)就是防止了開發(fā)商需求鍍金，提供了不必要的功能。
4 總結(jié)
經(jīng)過以上各個(gè)方面來討論需求管理在整個(gè)項(xiàng)目生命期所起到的作用，結(jié)合自身的經(jīng)驗(yàn)，和一個(gè)案例《某市網(wǎng)上審批系統(tǒng)》綜合分析了需求管理的辦法和用到的工具，根據(jù)自身經(jīng)驗(yàn)提出編寫需求說明書要注意的地方。
原文鏈接：http://www.mypm.net/articles/show_article_content.asp?articleID=13033&pageNO=1
【編輯推薦】
