- 相關(guān)推薦
項目需求變更管理
項目總結工作包括項目中事先識別的風(fēng)險和沒(méi)有預料到而發(fā)生的變更等風(fēng)險的應對措施的分析和總結，也包括項目中發(fā)生的變更和項目中發(fā)生問(wèn)題的分析統計的總結。下面yjbys小編為大家準備了關(guān)于項目需求變更管理的文章，歡迎閱讀。
1. 需求變更的原因分析
(1)范圍沒(méi)有圈定就開(kāi)始細化
細化工作是由需求分析人員完成的，一般是根據用戶(hù)提出的描述性的、總結性的短短幾句話(huà)去細化的，提取其中的一個(gè)個(gè)功能，并給出描述(正常執行時(shí)的描述和意外發(fā)生時(shí)的描述)。當細化到一定程度后并開(kāi)始系統設計時(shí)，范圍會(huì )發(fā)生變化，那細節用例的描述可能就有很多要改動(dòng)。如原來(lái)是手工添人的數據，要改成根據信息系統計算出來(lái)，而原來(lái)的一個(gè)屬性的描述要變成描述一個(gè)實(shí)體等。
(2)沒(méi)有指定需求的基線(xiàn)
需求的基線(xiàn)是指是否容許需求變更的分界線(xiàn)。隨著(zhù)項目的進(jìn)展，需求的基線(xiàn)也在變化。是否容許變更的依據是合同以及對成本的影響，比如軟件整體結構已經(jīng)設計出來(lái)是不容許改變需求范圍的，因為整體結構會(huì )對整個(gè)項目的進(jìn)度和成本有初步預算。隨著(zhù)項目的進(jìn)展，基線(xiàn)將越定越高(容許的變更將越少)，其過(guò)程如下：變更請求、比較基線(xiàn)、變更實(shí)現。
(3)沒(méi)有良好的軟件結構適應變化
組件式的軟件結構就是提供了快速適應需求變化的體系結構，數據層封裝了數據訪(fǎng)間邏輯，業(yè)務(wù)層封裝了業(yè)務(wù)邏輯，表示層展現用戶(hù)表示邏輯。但適應變化必須遵循一些松禍合原則，各層之間還是存在一些聯(lián)系的，設計要力求減少會(huì )對接口入口參數產(chǎn)生變化。如果業(yè)務(wù)邏輯封裝好了，則表示層界面上的一些排列或減少信息的要求是很容易適應的。如果接口定義得合理，那么即使業(yè)務(wù)流程有變化，也能夠快速適應變化。因此，在成本影響的容許范圍內可以降低需求的基線(xiàn)，提高客戶(hù)的滿(mǎn)意度。
2. 如何控制需求變更
按照現代項目管理的概念，一個(gè)項目的生命周期分為啟動(dòng)、實(shí)施、收尾三個(gè)過(guò)程。需求變更的控制不應該只是項目實(shí)施過(guò)程考慮的事情，而是要分布在整個(gè)項目生命周期的全過(guò)程。為了將項目變更的影響降低到最小，就需要采用綜合變更控制方法。綜合變更控制主要內容有找出影響項目變更的因素、判斷項目變更范圍是否已經(jīng)發(fā)生等。
進(jìn)行綜合變更控制的主要依據是項目計劃、變更請求和提供了項目執行狀況信息的績(jì)效報告。為保證項目變更的規范和有效實(shí)施，通常項目實(shí)施組織會(huì )有一些方案。
(1)項目啟動(dòng)階段的變更預防
對于任何項目，變更都無(wú)可避免，也無(wú)從逃避，只能積極應對，這個(gè)應對應該是從項目啟動(dòng)的需求分析階段就開(kāi)始了。對一個(gè)需求分析做得很好的項目來(lái)說(shuō)，基準文件定義的范圍越詳細清晰，用戶(hù)跟項目經(jīng)理扯皮的幌子就越少。如果需求沒(méi)做好，基準文件里的范圍含糊不清，被客戶(hù)抓住空子，往往要付出許多無(wú)謂的犧牲。如果需求做得好，文檔清晰且又有客戶(hù)簽字，那么后期客戶(hù)提出的變更就超出了合同范圍，需要另外收費。這個(gè)時(shí)候千萬(wàn)不能手軟，這并非要刻意賺取客戶(hù)的錢(qián)財，而是不能讓客戶(hù)養成經(jīng)常變更的習慣，否則后患無(wú)窮。相對于需求來(lái)說(shuō)，什么WBS、風(fēng)險管理、計劃進(jìn)度都是次要的，只要需求做好了就會(huì )一帆風(fēng)順。
(2)項目實(shí)施階段的需求變更
成功項目和失敗項目的區別就在于項目的整個(gè)過(guò)程是否是可控的。項目經(jīng)理應該樹(shù)立一個(gè)理念——“需求變更是必然的、可控的、有益的”。項目實(shí)施階段的變更控制需要做的是分析變更請求，評估變更可能帶來(lái)的風(fēng)險和修改基準文件�？刂菩枨鬂u變需要注意以下幾點(diǎn)：
需求一定要與投入有聯(lián)系，如果需求變更的成本由開(kāi)發(fā)方來(lái)承擔，則項目需求的變更就成為必然了。所以，在項目的開(kāi)始，無(wú)論是開(kāi)發(fā)方還是出資方都要明確這一條：需求變，軟件開(kāi)發(fā)的投人也要變。
需求的變更要經(jīng)過(guò)出資者的認可，這樣才會(huì )對需求的變更有成本的概念，能夠慎重地對待需求的變更。
小的需求變更也要經(jīng)過(guò)正規的需求管理流程，否則會(huì )積少成多。在實(shí)踐中，人們往往不愿意為小的需求變更去執行正規的需求管理過(guò)程，認為降低了開(kāi)發(fā)效率，浪費了時(shí)間。但正是由于這種觀(guān)念才使需求逐漸變?yōu)椴豢煽�，最終導致項目的失敗。
精確的需求與范圍定義并不會(huì )阻止需求的變更。并非對需求定義得越細，就越能避免需求的漸變，這是兩個(gè)層面的問(wèn)題。太細的需求定義對需求漸變沒(méi)有任何效果。因為需求的變化是永恒的，并非需求寫(xiě)細了，它就不會(huì )變化了。
注意溝通的技巧。實(shí)際情況是用戶(hù)、開(kāi)發(fā)者都認識到了上面的幾點(diǎn)間題，但是由于需求的變更可能來(lái)自客戶(hù)方，也可能來(lái)自開(kāi)發(fā)方，因此，作為需求管理者，項目經(jīng)理需要采用各種溝通技巧來(lái)使項目的各方各得其所。
(3)項目收尾階段的總結
能力的提高往往不是從成功的經(jīng)驗中來(lái)，而是從失敗的教訓中來(lái)。許多項目經(jīng)理不注重經(jīng)驗教訓總結和積累，即使在項目運作過(guò)程中碰得頭破血流，也只是抱怨運氣、環(huán)境和團隊配合不好，很少系統地分析總結，或者不知道如何分析總結，以至于同樣的問(wèn)題反復出現。
【項目需求變更管理】相關(guān)文章：
項目管理能力需求01-11
ERP項目需求管理的六個(gè)技巧10-01
營(yíng)銷(xiāo)管理需求06-22
營(yíng)銷(xiāo)管理要滿(mǎn)足五種需求10-16
項目管理流程管理07-18
配置管理和變更管理方法06-03
項目經(jīng)理與項目管理06-17