項目變更管理：決戰項目成敗

　變更控制的目的并不是控制變更的發(fā)生，而是對變更進(jìn)行管理，確保變更有序進(jìn)行。對于軟件開(kāi)發(fā)項目來(lái)說(shuō)，發(fā)生變更的環(huán)節比較多，因此變更控制顯得格外重要。
　　IT項目中引起變更的因素有兩個(gè)：一是來(lái)自外部的變更要求，如客戶(hù)要求修改工作范圍和需求等;二是開(kāi)發(fā)過(guò)程內部的變更要求，如為解決測試中發(fā)現的一些錯誤而修改源碼甚至設計。比較而言，最難處理的是來(lái)自外部的需求變更，因為IT項目需求變更的概率大，引發(fā)的工作量也大(特別是到項目的后期)。
　　變更控制不能僅在過(guò)程中靠流程控制，有效的方法是在事前明確定義。事前控制的一種方法是在項目開(kāi)始前明確定義，否則“變化”也無(wú)從談起。工作范圍(以前章節談過(guò)); 另一種方法是評審，特別是對需求進(jìn)行評審，這往往是項目成敗的關(guān)鍵。需求評審的目的不僅是“確認”，更重要的是找出不正確的地方并進(jìn)行修改，使其盡量接近 “真實(shí)”需求。另外，需求通過(guò)正式評審后應作為重要基線(xiàn)，從此之后即開(kāi)始對需求變更進(jìn)行控制。
　　雖然可以事前定義好變更控制流程，但在各種壓力下真正“控制”起來(lái)其實(shí)非常困難。下面給大家分析一個(gè)變更失控的項目案例：王先生剛出任項目經(jīng)理，并承接了一個(gè)中型軟件項目。上任時(shí)公司高層再三叮嚀他一定要尊重客戶(hù)，充分滿(mǎn)足客戶(hù)需求。項目開(kāi)始比較順利，但進(jìn)入到后期，客戶(hù)頻繁的需求變更帶來(lái)很多額外工作。王先生動(dòng)員大家加班，保持了項目的正常進(jìn)度，客戶(hù)相當滿(mǎn)意。
　　但需求變更卻越來(lái)越多。為了節省時(shí)間，客戶(hù)的業(yè)務(wù)人員不再向王先生申請變更，而是直接找程序員商量。程序員疲于應付，往往直接改程序而不做任何記錄，很多相關(guān)文檔也忘記修改。很快王先生就發(fā)現：需求、設計和代碼無(wú)法保持一致，甚至沒(méi)有人能說(shuō)清楚現在系統“到底改成什么樣了”。版本管理也出現了混亂，很多人違反配置管理規定，直接在測試環(huán)境中修改和編譯程序。但在進(jìn)度壓力下，他也只能佯裝不知此事。但因頻繁出現“改好的錯誤又重新出現”的問(wèn)題，客戶(hù)已經(jīng)明確表示“失去了耐心”。
　　而這還只是噩夢(mèng)的開(kāi)始。一個(gè)程序員未經(jīng)許可擅自修改了核心模塊，造成系統運行異常緩慢，大量應用程序超時(shí)退出。雖然最終花費了整整3天的時(shí)間解決了這個(gè)問(wèn)題，但客戶(hù)卻投訴了，表示“無(wú)法容忍這種低下的項目管理水平”。更糟糕的是，因為擔心系統中還隱含著(zhù)其他類(lèi)似的錯誤，客戶(hù)高層對項目的質(zhì)量也疑慮重重。
　　隨后發(fā)生的事情讓王先生更加為難：客戶(hù)的兩個(gè)負責人對界面風(fēng)格的看法不一致，并為此發(fā)生了激烈爭執。王先生知道如果發(fā)表意見(jiàn)可能會(huì )得罪其中一方，于是保持了沉默。最終客戶(hù)決定調整所有界面，王先生只好立刻動(dòng)員大家抓緊時(shí)間修改�？珊髞�(lái)當聽(tīng)說(shuō)因修改界面而造成了項目一周的延誤后，客戶(hù)方原來(lái)發(fā)生爭執的兩人這次卻非常一致，同時(shí)氣憤地質(zhì)問(wèn)王先生：“為什么你不早點(diǎn)告訴我們要延期!早知這樣才不會(huì )讓你改呢!”王先生委屈極了，疑惑自己到底錯在哪里了。
　　從上面的案例中可以看到各種變更失控的現象和造成的后果，王先生主要犯了幾個(gè)錯誤：
　　(1) 沒(méi)有明確的授權。
　　事先應該明確客戶(hù)方有權提出變更申請的人員和實(shí)施方有權受理變更的人員，并要控制雙方人數。這樣做才可以對變更有整體的控制。絕不能進(jìn)行“私下交易”，而沒(méi)有人能完整地知道到底改了些什么。另外，授權雙方接口人的好處是可以屏蔽客戶(hù)內部的矛盾，如果只有一個(gè)接口人，內部尚未達成一致時(shí)變更是無(wú)法提出來(lái)的。從實(shí)際經(jīng)驗看，授權可以顯著(zhù)減少變更，特別是那些因內部看法不同而導致的反復變更。
　　(2) 對變更沒(méi)有進(jìn)行必要的審核。
　　并不是所有的變更都要修改，也不是所有變更都要立刻修改，審核的目的就是為了決定是否需要修改和什么時(shí)候修改。比如案例中提到的界面風(fēng)格問(wèn)題，就可以先不修改，或者規劃一下修改的時(shí)間待到以后進(jìn)行優(yōu)化。另外，對于核心模塊的修改要嚴格審核把關(guān)，否則會(huì )引起全局問(wèn)題，案例中提到的“擅自修改核心模塊”造成的事故就是因為沒(méi)有審核而造成的。
　　(3) 對變更的影響沒(méi)有評估。
　　變更都是有代價(jià)的，應該評估一下變更的代價(jià)和對項目的影響，要讓客戶(hù)了解變更的后果，并與客戶(hù)一起做判斷。案例中客戶(hù)最后的質(zhì)問(wèn)正是因為沒(méi)有事前告訴客戶(hù)變更的影響造成的。如果客戶(hù)不知道你為變更付出的代價(jià)，對你的辛苦便難以體會(huì )。案例中客戶(hù)剛開(kāi)始對王先生加班處理變更相當滿(mǎn)意，但只是對工作態(tài)度滿(mǎn)意，后期當變更引發(fā)一系列問(wèn)題時(shí)客戶(hù)并沒(méi)有感謝王先生的苦勞。
　　(4) 應該讓客戶(hù)確認是否接受變更的代價(jià)。
在評估代價(jià)并且與客戶(hù)討論的過(guò)程中，可以請客戶(hù)一起做判斷：“我可以修改，但您能接受后果嗎?”。案例中如果王先生評估了修改界面的工作量并請客戶(hù)確認，則有三種可能：客戶(hù)預先接受延期這一后果，也就不會(huì )再質(zhì)問(wèn)王先生了;如果客戶(hù)認為代價(jià)太大，則王先生就不必修改了;如果認為可以縮短延期時(shí)間，則王先生至少爭取到了與客戶(hù)協(xié)商的機會(huì )，讓客戶(hù)知道為此項目組需要付出加班的代價(jià)，吃個(gè)“明虧”。
　　上述步驟完成后，要等客戶(hù)確認變更再組織實(shí)施變更的相關(guān)工作。變更要按配置管理(讀者可以查閱相關(guān)的資料)的規定執行，確保所有交付物的一致性和完整性。同時(shí)，對所有的變更要跟蹤和驗證，確保都按要求完成了。
　　最后，要特別提醒的是：要在項目開(kāi)始就對項目組和客戶(hù)進(jìn)行宣傳和培訓，讓所有成員都理解變更控制的重要意義;在項目過(guò)程中要對變更控制的執行情況進(jìn)行審計，發(fā)現違反規定的事件要嚴肅處理，否則過(guò)程很快就會(huì )失效。
　　綜上所述，變更控制的目的是管理變化。變更控制對項目成敗有重要影響，事前要明確定義，事中要嚴格執行。實(shí)施變更之前有四個(gè)重要控制點(diǎn)：授權、審核、評估和確認;在實(shí)施過(guò)程要進(jìn)行跟蹤和驗證，確保變更被正確執行。（資料來(lái)源：項目管理者聯(lián)盟）