房地產(chǎn)項(xiàng)目管理軟件
當(dāng)前位置：工程項(xiàng)目OA系統(tǒng) > 房地產(chǎn)OA系統(tǒng) > 相關(guān)系統(tǒng) > 房地產(chǎn)項(xiàng)目管理軟件
如何應(yīng)對IT項(xiàng)目的需求變更？
IT人員，特別是作項(xiàng)目管理的，難免會(huì)提出一個(gè)問題：客戶為什么總是反反復(fù)復(fù)。有感于自己的多年電信行業(yè)項(xiàng)目管理實(shí)踐，也談?wù)劰こ绦皂?xiàng)目的變更需求管理。
我從2001年開始，一直從事電信行業(yè)項(xiàng)目管理。在自己的軟件項(xiàng)目管理職業(yè)過程中，幾乎天天面對用戶的需求變更，切身感受到，如果不能有效處理這些需求變更，項(xiàng)目計(jì)劃會(huì)一再調(diào)整，軟件交付日期一再拖延，用戶的耐性漸漸消逝，研發(fā)人員的士氣也越來越低落，最后所有的人都在等待一個(gè)結(jié)果：項(xiàng)目最好馬上結(jié)束。
在討論問題解決之前，我們先了解一下目前在電信行業(yè)的需求變更。大家一向認(rèn)為需求變更對開發(fā)商或集成商來說是個(gè)非常負(fù)面的因素，對項(xiàng)目來說是個(gè)巨大的風(fēng)險(xiǎn)｡但現(xiàn)在很多一級系統(tǒng)集成商，比如神州數(shù)碼思特奇，提出歡迎變更，歡迎風(fēng)險(xiǎn)的說法。問題在于我們有了很好的好應(yīng)對變更的方法論，能夠有效的應(yīng)對變更，在風(fēng)險(xiǎn)中尋找機(jī)遇。
我們的秘訣就在于對需求變更的主動(dòng)管理。具體說來：
1：在項(xiàng)目合同中，成立變更控制委員會(huì)CCB），并規(guī)定嚴(yán)格的變更控制流程。一般而言，在合同階段，我們客戶是很樂意接受這種規(guī)范的管理方式的。
2：取得了合同階段的主動(dòng)后，在實(shí)施階段的嚴(yán)格執(zhí)行也很關(guān)鍵。不能因?yàn)閲?yán)格執(zhí)行變更流程，就影響和客戶的關(guān)系，這方面就要依靠項(xiàng)目經(jīng)理和技術(shù)經(jīng)理的的管理和溝通藝術(shù)的。我們的目的不是讓用戶不提出變更，而是讓用戶不輕易，隨便的提出變更。
3：對于用戶提出的變更，可以看實(shí)際情況處理，站在客戶立場上為客戶考慮，有些需求，是可以引導(dǎo)客戶在后期的項(xiàng)目中實(shí)現(xiàn)，這樣也可以為公司帶來好的項(xiàng)目機(jī)會(huì)。
在不斷的學(xué)習(xí)和實(shí)踐中，我總結(jié)了兩點(diǎn)比較有效的方法，在軟件研發(fā)階段能夠較好地解決這方面的問題。
需求分析階段通過原型明確用戶需求
在軟件項(xiàng)目的需求分析階段，有大量需求信息需要收集、篩選、加工，這是需求管理的開始?？蛻艉脱邪l(fā)兩方面的人員對需求的理解呈現(xiàn)“大體上共識多，細(xì)節(jié)上差異多”的特點(diǎn)。即使通過反復(fù)溝通，最終在時(shí)間表限制之內(nèi)也能拿出一份“用戶需求說明書”，但是以實(shí)踐經(jīng)驗(yàn)，用戶需求的描述永遠(yuǎn)是“不夠清晰”、“不夠明確”的。這主要是因?yàn)樵谶@個(gè)階段，所謂的產(chǎn)品都在大家的大腦中構(gòu)思，在此階段，原型開發(fā)是一個(gè)較好的輔助手段，它將存在于大家頭腦中的虛境實(shí)實(shí)在在地表達(dá)出來，一個(gè)界面，幾個(gè)控件，外觀形式固定了，功能描述明確了，這就是研發(fā)部門對用戶的需求理解。此時(shí)與用戶再次溝通，用戶基本上可以說出來：“這是我想要的”，或者“不，這不是我想要的，我要的是……”。一般情況下，原型之后的需求溝通就實(shí)際得多，雙方的理解迅速向一個(gè)折衷方案靠攏，一個(gè)可以指導(dǎo)研發(fā)過程的需求說明書正式誕生了。
采用嚴(yán)格的需求變更管理流程
一旦需求分析階段結(jié)束，此后如果用戶要求有新的需求加入交付的軟件系統(tǒng)中，需要走需求變更管理流程。這個(gè)流程必須在軟件項(xiàng)目成立之初與用戶約定好，一般的軟件企業(yè)內(nèi)部有需求變更的管理流程，可以向用戶解釋這種管理的必要性，直至與用戶就此問題達(dá)成共識為止。不必?fù)?dān)心用戶不會(huì)接受，有過多次成功研發(fā)軟件項(xiàng)目經(jīng)驗(yàn)的需求變更管理流程，有著它不容置疑的合理性，這正是軟件企業(yè)的經(jīng)驗(yàn)和價(jià)值所在，用戶最終會(huì)理解和同意的。
需求變更管理流程各家企業(yè)有各家的做法，在我們項(xiàng)目組，通過變更管理流程軟件來實(shí)現(xiàn)需求變更。步驟如下：
1：提出變更申請
（1）：客戶提出需求變更，提交給客戶方責(zé)任人；
（2）：客戶方責(zé)任人審核需求變更，認(rèn)為屬于變更范圍，允許變更，則轉(zhuǎn)給我們責(zé)任人；如果不允許變更，則轉(zhuǎn)給需求變更提出人，要求完成內(nèi)容或取消需求變更；
2：變更評估
（1）：我方責(zé)任人接收到需求后，初步了解需求，之后和客戶進(jìn)行溝通，詳細(xì)化需求情況；
（2）：初步估算變更產(chǎn)生的工作時(shí)間和費(fèi)用情況；
3：變更決策
CBD對需求變更作出決策。由于其中設(shè)計(jì)到工作時(shí)間和費(fèi)用，需要相關(guān)人員，包括客戶參與作出決策。
4：接收變更
雙方達(dá)成變更的決定；
5：實(shí)施變更
針對達(dá)成的變更，實(shí)施變更；
6：驗(yàn)證
在變更完成后，回顧變更的成果；
在此提醒大家，切忌對用戶提出的需求拍胸脯，在此之前可以捫心自問：“如果拍了胸脯，以后不能按時(shí)完成，我能不能負(fù)擔(dān)全部責(zé)任？”這樣冷靜一下就不會(huì)胡亂應(yīng)承了。有一個(gè)比較好的方式減少這樣的麻煩，就是在需求分析階段之后，與用戶不要親密接觸，而是按照軟件項(xiàng)目的周期，或者雙方在初期的約定，定時(shí)通報(bào)軟件研發(fā)的進(jìn)展。如果軟件研發(fā)采用迭代式開發(fā)，就可以在每一期交付產(chǎn)品發(fā)布時(shí)做這個(gè)事情，征詢到的用戶需求將納入以后某期的軟件版本中。
我從2001年開始，一直從事電信行業(yè)項(xiàng)目管理。在自己的軟件項(xiàng)目管理職業(yè)過程中，幾乎天天面對用戶的需求變更，切身感受到，如果不能有效處理這些需求變更，項(xiàng)目計(jì)劃會(huì)一再調(diào)整，軟件交付日期一再拖延，用戶的耐性漸漸消逝，研發(fā)人員的士氣也越來越低落，最后所有的人都在等待一個(gè)結(jié)果：項(xiàng)目最好馬上結(jié)束。
在討論問題解決之前，我們先了解一下目前在電信行業(yè)的需求變更。大家一向認(rèn)為需求變更對開發(fā)商或集成商來說是個(gè)非常負(fù)面的因素，對項(xiàng)目來說是個(gè)巨大的風(fēng)險(xiǎn)｡但現(xiàn)在很多一級系統(tǒng)集成商，比如神州數(shù)碼思特奇，提出歡迎變更，歡迎風(fēng)險(xiǎn)的說法。問題在于我們有了很好的好應(yīng)對變更的方法論，能夠有效的應(yīng)對變更，在風(fēng)險(xiǎn)中尋找機(jī)遇。
我們的秘訣就在于對需求變更的主動(dòng)管理。具體說來：
1：在項(xiàng)目合同中，成立變更控制委員會(huì)CCB），并規(guī)定嚴(yán)格的變更控制流程。一般而言，在合同階段，我們客戶是很樂意接受這種規(guī)范的管理方式的。
2：取得了合同階段的主動(dòng)后，在實(shí)施階段的嚴(yán)格執(zhí)行也很關(guān)鍵。不能因?yàn)閲?yán)格執(zhí)行變更流程，就影響和客戶的關(guān)系，這方面就要依靠項(xiàng)目經(jīng)理和技術(shù)經(jīng)理的的管理和溝通藝術(shù)的。我們的目的不是讓用戶不提出變更，而是讓用戶不輕易，隨便的提出變更。
3：對于用戶提出的變更，可以看實(shí)際情況處理，站在客戶立場上為客戶考慮，有些需求，是可以引導(dǎo)客戶在后期的項(xiàng)目中實(shí)現(xiàn)，這樣也可以為公司帶來好的項(xiàng)目機(jī)會(huì)。
在不斷的學(xué)習(xí)和實(shí)踐中，我總結(jié)了兩點(diǎn)比較有效的方法，在軟件研發(fā)階段能夠較好地解決這方面的問題。
需求分析階段通過原型明確用戶需求
在軟件項(xiàng)目的需求分析階段，有大量需求信息需要收集、篩選、加工，這是需求管理的開始?？蛻艉脱邪l(fā)兩方面的人員對需求的理解呈現(xiàn)“大體上共識多，細(xì)節(jié)上差異多”的特點(diǎn)。即使通過反復(fù)溝通，最終在時(shí)間表限制之內(nèi)也能拿出一份“用戶需求說明書”，但是以實(shí)踐經(jīng)驗(yàn)，用戶需求的描述永遠(yuǎn)是“不夠清晰”、“不夠明確”的。這主要是因?yàn)樵谶@個(gè)階段，所謂的產(chǎn)品都在大家的大腦中構(gòu)思，在此階段，原型開發(fā)是一個(gè)較好的輔助手段，它將存在于大家頭腦中的虛境實(shí)實(shí)在在地表達(dá)出來，一個(gè)界面，幾個(gè)控件，外觀形式固定了，功能描述明確了，這就是研發(fā)部門對用戶的需求理解。此時(shí)與用戶再次溝通，用戶基本上可以說出來：“這是我想要的”，或者“不，這不是我想要的，我要的是……”。一般情況下，原型之后的需求溝通就實(shí)際得多，雙方的理解迅速向一個(gè)折衷方案靠攏，一個(gè)可以指導(dǎo)研發(fā)過程的需求說明書正式誕生了。
采用嚴(yán)格的需求變更管理流程
一旦需求分析階段結(jié)束，此后如果用戶要求有新的需求加入交付的軟件系統(tǒng)中，需要走需求變更管理流程。這個(gè)流程必須在軟件項(xiàng)目成立之初與用戶約定好，一般的軟件企業(yè)內(nèi)部有需求變更的管理流程，可以向用戶解釋這種管理的必要性，直至與用戶就此問題達(dá)成共識為止。不必?fù)?dān)心用戶不會(huì)接受，有過多次成功研發(fā)軟件項(xiàng)目經(jīng)驗(yàn)的需求變更管理流程，有著它不容置疑的合理性，這正是軟件企業(yè)的經(jīng)驗(yàn)和價(jià)值所在，用戶最終會(huì)理解和同意的。
需求變更管理流程各家企業(yè)有各家的做法，在我們項(xiàng)目組，通過變更管理流程軟件來實(shí)現(xiàn)需求變更。步驟如下：
1：提出變更申請
（1）：客戶提出需求變更，提交給客戶方責(zé)任人；
（2）：客戶方責(zé)任人審核需求變更，認(rèn)為屬于變更范圍，允許變更，則轉(zhuǎn)給我們責(zé)任人；如果不允許變更，則轉(zhuǎn)給需求變更提出人，要求完成內(nèi)容或取消需求變更；
2：變更評估
（1）：我方責(zé)任人接收到需求后，初步了解需求，之后和客戶進(jìn)行溝通，詳細(xì)化需求情況；
（2）：初步估算變更產(chǎn)生的工作時(shí)間和費(fèi)用情況；
3：變更決策
CBD對需求變更作出決策。由于其中設(shè)計(jì)到工作時(shí)間和費(fèi)用，需要相關(guān)人員，包括客戶參與作出決策。
4：接收變更
雙方達(dá)成變更的決定；
5：實(shí)施變更
針對達(dá)成的變更，實(shí)施變更；
6：驗(yàn)證
在變更完成后，回顧變更的成果；
在此提醒大家，切忌對用戶提出的需求拍胸脯，在此之前可以捫心自問：“如果拍了胸脯，以后不能按時(shí)完成，我能不能負(fù)擔(dān)全部責(zé)任？”這樣冷靜一下就不會(huì)胡亂應(yīng)承了。有一個(gè)比較好的方式減少這樣的麻煩，就是在需求分析階段之后，與用戶不要親密接觸，而是按照軟件項(xiàng)目的周期，或者雙方在初期的約定，定時(shí)通報(bào)軟件研發(fā)的進(jìn)展。如果軟件研發(fā)采用迭代式開發(fā)，就可以在每一期交付產(chǎn)品發(fā)布時(shí)做這個(gè)事情，征詢到的用戶需求將納入以后某期的軟件版本中。