2.3 案例三：范圍確認
    閱讀以下關于信息系統項目管理過程中項目范圍管理方面問題的敘述，回答問題1至問題3。
2.3.1案例場景
    中培信息技術有限公司(Z公司 )剛剛和M簽訂了一份新的合同，合同的主要內容是處理公司以前為M公司開發的信息系統的升級工作。升級后的系統可以滿足M公司新的業務流程和范圍。由于是一個現有系統的升級，項目經理老王特意請來了原系統的需求調研人員劉工擔任該項目的需求調研負責人。在劉工的幫助下，很快地完成了需求開發的工作并進入設計與編碼。由于M公司的業務非常繁忙，M公司的業務代表沒有足夠的時間投入到項目中，確認需求的工作一拖再拖。老王認為，雙方已經建立了密切的合作關系，劉工也參加了原系統的需求開發，對業務的系統比較熟悉，因此定義的需求是清晰的。故老王并沒有催促業務代表在需求說明書中簽字。
    進入編碼階段后，劉工因故移民加拿大，需要離開項目組。老王考慮到系統需求已經定義，項目已經進入編碼期，劉工的離職雖然會對項目造成一定的影響，但影響較小，因此很快辦理好了劉工的離職手續。
    在系統交付的時候，M公司的業務代表認為已經提出的需求很多沒有實現，實現的需求也有很多不能滿足業務的要求，必須全部實現這些需求后才能驗收。此時劉工已經不在項目組，沒有人能夠清晰地解釋需求說明書。最終系統需求發生重大變更，項目延期超過50%, M的業務代表也因為系統的延期表示了強烈的不滿。
 【問題1】(8分)
請以400字對老王在項目管理工作中的行為進行點評。
 【問題2】(9分)
    請從項目范圍管理的角度找出該項目實施過程中的問題，以500字內回答。
 【問題3】(8分)
    請結合你本人項目經驗，談談應如何避免類似的問題，以500字內回答。
2.3.2 案例分析
    這是一個失敗的軟件項目，與很多失敗的軟件項目一樣，在系統需求上栽了跟頭。開發與定義軟件系統的需求在整個軟件開發過程中是最重要的一環，這是每個從事信息系統建設的項目經理都清楚的事情，但往往又因為一時的疏忽而造成需求的重大缺陷，最終導致項目的失敗。案例中的項目經理老王就是既重視需求又沒有控制好需求的一個例子。·
    在案例中，老王接手了一個系統升級的軟件項目。對于這樣的項目，首先需要熟悉原有的系統，然后才能談升級的問題。因此老王專門找到了原系統的需求調研人員劉工來解決新系統的需求問題。這無疑是一個很好的辦法，可以快速準確地把握新系統的需求。從這一點上來說，老王是成功的，找到了合適的資源進行需求的開發與定義。劉工也沒有讓老王失望，很快就整理出了新系統的需求，并進入了設計和編碼階段，除了客戶太忙沒有時間確認需求外，一切盡在老王的掌握之中。這是一個陽光燦爛的開端，如果一切順利的話，項目的成功也就是早晚的事情。就如同大多數經典的悲劇故事一樣，故事的序幕是美好的。
    晴朗的天空飄來一塊烏云，劉工要移民加拿大。不過僅僅是一片烏云而已，并沒有下起雨來。開發出的需求都已經過設計，一些編碼工作也已經開始，劉工的工作已近圓滿完成，畢竟，一些細枝末節的問題還可以同客戶直接溝通。
    經過項目組努力，項目終于完成開發，準備發布了。這時，烏云開始下雨，問題爆發了。客戶不認可項目組的工作，認為很多需求沒有實現，實現的功能也與需求不符。
    誰是這個項目組的罪人呢？劉工？還是老王？換一個思路考慮一下，如果劉工沒有離開項目組，結果又會是什么樣呢？客戶會因為劉工還在項目組就認可這個系統嗎？很顯然，不會。至多可以在雙發的協商下少一些變更，項目延期不是50%,而是30％而已。如果非要區分50％和30％的區別，也不過是五十步笑百步而已。
    從項目管理的角度來說，項目范圍直接決定了工作量和工作目標，所以項目經理必須管理項目的范圍。在范圍管理中，范圍定義、范圍確認和范圍控制又是最核心的三項活動，缺一不可。范圍定義是基礎的活動，不進行范圍定義就不能進行范圍確認和范圍控制。范圍確認則是基線化已定義的范圍，是范圍控制的依據。范圍控制的作用在于減少變更，保持項目范圍的穩定性。在案例中，由于老王沒有進行范圍確認，最后的范圍控制也就變成了無本之木，控制過程肯定變成了討價還價，失去本身的意義。
    在軟件系統的開發中，系統需求就是項目的范圍。從軟件誕生至今的幾十年中，人們探索出了很多獲取系統需求的方法，但是熟悉軟件開發的人都知道，無論哪種方法都不可能定義出完美無誤的需求，需求中的缺陷必然存在，無法完全避免。因此需求確認或者說是范圍確認就顯得更為重要。
    有人可能會說，很難說服客戶在需求上簽字，很難讓客戶為需求的缺陷負責。以現在軟件行業的情況，這種說法是不無道理的。讓客戶在需求上簽字很困難，但并不等于就不需要進行范圍確認，而且范圍確認的方法也不僅僅只有需求簽字這一種方法。召集客戶的業務代表對需求進行評審、詳細記錄最原始的調研材料，讓客戶確認調研報告、采用迭代開發逐步確認系統需求，都是可以采用的方法。這些方法雖然沒有直接確認需求分析報告，但至少可以讓現有需求在項目組和客戶之間達成一致，提供范圍控制的基準，一樣可以達到范圍確認的目的。
    再回到這個案例，項目經理老王樂觀認為劉工開發的需求沒有什么問題，也誤認為雙方已經有良好的合作，在不緊逼要求客戶代表簽字顯得不近人情，于是就抱著僥幸信息進入了開發。然而最終的結果是，項目延期嚴重，業務代表反而更不滿意，老王也要承擔項目延期造成的成本增加的責任。
    有了上面的分析，后面問題的答案就不難得出。首先看第一個問題，對老王的行為進行點評。前面已經提到，老王注意到了需求的問題，專門找到了原系統需求負責人劉工進行需求開發，這是對項目有利的一面。但由于缺少需求評審和確認的過程，造成需求中的缺陷沒有被及時發現，系統需求沒有與客戶確認，造成缺少需求控制的基準，最終導致需求的重大變更。
     對于第二題，聯系范圍管理的知識，我們不難發現老王在范圍確認和范圍控制中都有重大的缺陷，在范圍定義中也由于缺乏評審造成需求的質量問題。
    在完成第二題后，第三題就水到渠成了，第三題的要點見參考答案，此處不再贅述。
2.3.3參考答案
    【問題1】(8分)
    (1)老王為了更明確地把握系統需求，聘請了原系統的需求調研人員劉工，提高了需求定義的效率和質量。(2分)
    (2)老王沒有對劉工開發的系統需求進行評審和復查，從而使得需求的缺陷沒有被及時發現。
    (3)老王沒有要求用戶對已經定義的需求進行確認，從而導致需求理解的偏差。(2分)
    (4)老王對需求的不能進行缺乏有效控制，最終造成項目延期50%.(2分)
    【問題2】(9分)
    該項目實施過程中的主要問題包括：
    (1)在范圍定義中，老王沒有對劉工定義的需求進行評審，造成需求中的質量缺陷沒有被及時發現。(3分)
    (2)在范圍確認中，老王沒有主動地要求用戶對需求進行確認。(3分)
    (3)在范圍控制中，老王無法進行有效的范圍控制，最終造成了重大的需求變更。(3分)
    【問題3】(8分)
    對于本案例，項目經理需要對需求定義的結果進行質量控制，采取評審等方式減少需求中的問題。對已經定義的需求需要與用戶進行確認，保證雙方理解的一致。在發生需求變更時，也應該采取靈活的手段，在滿足用戶需求的前提下，盡量減少需求變更的范圍。