專案管理過程之變更控制 (轉)

ger8發表於2007-08-09
1.3 專案的變更控制
變更控制的目的並不是控制變更的發生,而是對變更進行管理,確保變更有序進行。對於軟體開發專案來說,發生變更的環節比較多,因此變更控制顯得格外重要。

IT專案中引起變更的因素有兩個:一是來自外部的變更要求,如客戶要求修改工作範圍和需求等;二是開發過程內部的變更要求,如為解決測試中發現的一些錯誤而修改原始碼甚至設計。比較而言,最難處理的是來自外部的需求變更,因為IT專案需求變更的機率大,引發的工作量也大(特別是到專案的後期)。

變更控制不能僅在過程中靠流程控制,有效的方法是在事前明確定義。事前控制的一種方法是在專案開始前明確定義,否則“變化”也無從談起。工作範圍(以前章節談過);另一種方法是評審,特別是對需求進行評審,這往往是專案成敗的關鍵。需求評審的目的不僅是“確認”,更重要的是找出不正確的地方並進行修改,使其儘量接近“真實”需求。另外,需求透過正式評審後應作為重要基線,從此之後即開始對需求變更進行控制。

雖然可以事前定義好變更控制流程,但在各種壓力下真正“控制”起來其實非常困難。下面給大家分析一個變更失控的專案案例:

王先生剛出任專案經理,並承接了一箇中型軟體專案。上任時公司高層再三叮嚀他一定要尊重客戶,充分滿足客戶需求。專案開始比較順利,但進入到後期,客戶頻繁的需求變更帶來很多額外工作。王先生動員大家加班,保持了專案的正常進度,客戶相當滿意。

但需求變更卻越來越多。為了節省時間,客戶的業務人員不再向王先生申請變更,而是直接找程式設計師商量。程式設計師疲於應付,往往直接改程式而不做任何記錄,很多相關文件也忘記修改。很快王先生就發現:需求、設計和程式碼無法保持一致,甚至沒有人能說清楚現在系統“到底改成什麼樣了”。版本管理也出現了混亂,很多人違反配置管理規定,直接在測試環境中修改和編譯程式。但在進度壓力下,他也只能佯裝不知此事。但因頻繁出現“改好的錯誤又重新出現”的問題,客戶已經明確表示“失去了耐心”。

而這還只是噩夢的開始。一個程式設計師未經許可擅自修改了核心模組,造成系統執行異常緩慢,大量應用程式超時退出。雖然最終花費了整整3天的時間解決了這個問題,但客戶卻投訴了,表示“無法容忍這種低下的專案管理水平”。更糟糕的是,因為擔心繫統中還隱含著其他類似的錯誤,客戶高層對專案的質量也疑慮重重。

隨後發生的事情讓王先生更加為難:客戶的兩個負責人對介面風格的看法不一致,併為此發生了激烈爭執。王先生知道如果發表意見可能會得罪其中一方,於是保持了沉默。最終客戶決定調整所有介面, 王先生只好立刻動員大家抓緊時間修改。可後來當聽說因修改介面而造成了專案一週的延誤後,客戶方原來發生爭執的兩人這次卻非常一致,同時氣憤地質問王先生:“為什麼你不早點告訴我們要延期!早知這樣才不會讓你改呢!”王先生委屈極了,疑惑自己到底錯在哪裡了。

從上面的案例中可以看到各種變更失控的現象和造成的後果,王先生主要犯了幾個錯誤:

1) 沒有明確的授權。事先應該明確客戶方有權提出變更申請的人員和實施方有權受理變更的人員,並要控制雙方人數。這樣做才可以對變更有整體的控制。絕不能進行“私下交易”,而沒有人能完整地知道到底改了些什麼。另外,授權雙方介面人的好處是可以遮蔽客戶內部的矛盾,如果只有一個介面人,內部尚未達成一致時變更是無法提出來的。從實際經驗看,授權可以顯著減少變更,特別是那些因內部看法不同而導致的反覆變更。

2) 對變更沒有進行必要的稽核。並不是所有的變更都要修改,也不是所有變更都要立刻修改,稽核的目的就是為了決定是否需要修改和什麼時候修改。比如案例中提到的介面風格問題,就可以先不修改,或者規劃一下修改的時間待到以後進行最佳化。另外,對於核心模組的修改要嚴格稽核把關,否則會引起全域性問題,案例中提到的“擅自修改核心模組”造成的事故就是因為沒有稽核而造成的。

3) 對變更的影響沒有評估。變更都是有代價的,應該評估一下變更的代價和對專案的影響,要讓客戶瞭解變更的後果,並與客戶一起做判斷。案例中客戶最後的質問正是因為沒有事前告訴客戶變更的影響造成的。如果客戶不知道你為變更付出的代價,對你的辛苦便難以體會。案例中客戶剛開始對王先生加班處理變更相當滿意,但只是對工作態度滿意,後期當變更引發一系列問題時客戶並沒有感謝王先生的苦勞。

4) 應該讓客戶確認是否接受變更的代價。在評估代價並且與客戶討論的過程中,可以請客戶一起做判斷:“我可以修改,但您能接受後果嗎?”。案例中如果王先生評估了修改介面的工作量並請客戶確認,則有三種可能:客戶預先接受延期這一後果,也就不會再質問王先生了;如果客戶認為代價太大,則王先生就不必修改了;如果認為可以縮短延期時間,則王先生至少爭取到了與客戶協商的機會,讓客戶知道為此專案組需要付出加班的代價,吃個“明虧”。

上述步驟完成後,要等客戶確認變更再組織實施變更的相關工作。變更要按配置管理(讀者可以查閱相關的資料)的規定執行,確保所有交付物的一致性和完整性。同時,對所有的變更要跟蹤和驗證,確保都按要求完成了。

最後,要特別提醒的是:要在專案開始就對專案組和客戶進行宣傳和培訓,讓所有成員都理解變更控制的重要意義;在專案過程中要對變更控制的執行情況進行審計,發現違反規定的事件要嚴肅處理,否則過程很快就會失效。

綜上所述,變更控制的目的是管理變化。變更控制對專案成敗有重要影響,事前要明確定義,事中要嚴格執行。實施變更之前有四個重要控制點:授權、稽核、評估和確認;在實施過程要進行跟蹤和驗證,確保變更被正確執行。
[@more@]

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-937826/,如需轉載,請註明出處,否則將追究法律責任。

相關文章