變更控制的目的并不是控制變更的發(fā)生,而是對變更進(jìn)行管理,確保變更有序進(jìn)行。對于軟件開發(fā)項(xiàng)目來說,發(fā)生變更的環(huán)節(jié)比較多,因此變更控制顯得格外重要。
項(xiàng)目中引起變更的因素有兩個:一是來自外部的變更要求,如客戶要求修改工作范圍和需求等;二是開發(fā)過程內(nèi)部的變更要求,如為解決測試中發(fā)現(xiàn)的一些錯誤而修改源碼甚至設(shè)計(jì)。比較而言,最難處理的是來自外部的需求變更,因?yàn)轫?xiàng)目需求變更的概率大,引發(fā)的工作量也大(特別是到項(xiàng)目的后期)。
變更控制不能僅在過程中靠流程控制,有效的方法是在事前明確定義。事前控制的一種方法是在項(xiàng)目開始前明確定義,否則“變化”也無從談起。工作范圍(以前章節(jié)談過);另一種方法是評審,特別是對需求進(jìn)行評審,這往往是項(xiàng)目成敗的關(guān)鍵。需求評審的
……(新文秘網(wǎng)http://jey722.cn省略520字,正式會員可完整閱讀)……
模塊,造成系統(tǒng)運(yùn)行異常緩慢,大量應(yīng)用程序超時退出。雖然最終花費(fèi)了整整天的時間解決了這個問題,但客戶卻投訴了,表示“無法容忍這種低下的項(xiàng)目管理水平”。更糟糕的是,因?yàn)閾?dān)心系統(tǒng)中還隱含著其他類似的錯誤,客戶高層對項(xiàng)目的質(zhì)量也疑慮重重。
隨后發(fā)生的事情讓王先生更加為難:客戶的兩個負(fù)責(zé)人對界面風(fēng)格的看法不一致,并為此發(fā)生了激烈爭執(zhí)。王先生知道如果發(fā)表意見可能會得罪其中一方,于是保持了_。最終客戶決定調(diào)整所有界面,王先生只好立刻
動員大家抓緊時間修改?珊髞懋(dāng)聽說因修改界面而造成了項(xiàng)目一周的延誤后,客戶方原來發(fā)生爭執(zhí)的兩人這次卻非常一致,同時氣憤地質(zhì)問王先生:“為什么你不早點(diǎn)告訴我們要延期!早知這樣才不會讓你改呢!”王先生委屈極了,疑惑自己到底錯在哪里了。
從上面的案例中可以看到各種變更失控的現(xiàn)象和造成的后果,王先生主要犯了幾個錯誤:
)沒有明確的授權(quán)。事先應(yīng)該明確客戶方有權(quán)提出變更申請的人員和實(shí)施方有權(quán)受理變更的人員,并要控制雙方人數(shù)。這樣做才可以對變更有整體的控制。絕不能進(jìn)行“私下交易”,而沒有人能完整地知道到底改了些什么。另外,授權(quán)雙方接口人的好處是可以屏蔽客戶內(nèi)部的矛盾,如果只有一個接口人,內(nèi)部尚未達(dá)成一致時變更是無法提出來的。從實(shí)際經(jīng)驗(yàn)看,授權(quán)可以顯著減少變更,特別是那些因內(nèi)部看法不同而導(dǎo)致的反復(fù)變更。
)對變更沒有進(jìn)行必要的審核。并不是所有的變更都要修改,也不是所有變更都要立刻修改,審核的目的就是為了決定是否需要修改和什么時候修改。比如案例中提到的界面風(fēng)格問題,就可以先不修改,或者規(guī)劃一下修改的時間待到以后進(jìn)行優(yōu)化。另外,對于核心模塊的修改要嚴(yán)格審核把關(guān),否則會引起全局問題,案例中提到的“擅自修改核心模塊”造成的事故就是因?yàn)闆]有審核而造成的。
。⿲ψ兏挠绊憶]有評估。變更都是有代價的,應(yīng)該評估一下變更的代價和對項(xiàng)目的影響,要讓客戶了解變更的后果,并與客戶一起做判斷。案例中客戶最后的質(zhì)問正是因?yàn)闆]有事前告訴客戶變更的影響造成的。如果客戶不知道你為變更付出的代價,對你的辛苦便難以體會。案例中客戶剛開始對王先生加班處理變更相當(dāng)滿意,但只是對工作態(tài)度滿意,后期當(dāng)變更引發(fā)一系列問題時客戶并沒有感謝王先生的苦勞。
。⿷(yīng)該讓客戶確認(rèn)是否接受變更的代價。在評估代價并且與客戶討論的過程中,可以請客戶一起做判斷“我可以修改,但您能接受后果嗎?”案例中如果王先生評估了修改界面的工作量并請客戶確認(rèn),則有三種可能:客戶預(yù)先接受延期這一后果,也就不會再質(zhì)問王先生了;如果客戶認(rèn)為代價太大,則王先生就不必修改了;如果認(rèn)為可以縮短延期時間,則王先生至少爭取到了與客戶協(xié)商的機(jī)會,讓客戶知道為此項(xiàng)目組需要付出加班的代價 ……(未完,全文共2295字,當(dāng)前僅顯示1458字,請閱讀下面提示信息。
收藏《項(xiàng)目管理過程之變更控制》)