第2章項目范圍管理案例
    項目的范圍管理影響到信息系統項目的成功。在實踐中，“需求蔓延”是信息系統失敗最常見的原因之一，信息系統項目往往在項目啟動、計劃、執行、甚至收尾時不斷加入新功能，無論是客戶的要求還是項目實現人員對新技術的試驗，都可能導致信息系統項目范圍的失控，從而使得信息系統項目無論在時間、資源和質量上都受到嚴重影響。
2．1案例一：范圍定義
    閱讀以下關于信息系統項目管理過程中范圍管理方面問題的敘述，回答問題1至問題3。
2.1.1案例場景
    中培信息技術有限公司(Z公司原本是一家專注于企業信息化的公司，在電子政務如火如茶的時候，開始進軍電子政務行業。在電子政務的市場中，接到的第一個項目是開發一套工商審批系統。由于電子政務保密要求，該系統涉及到兩個互不聯通的子網：政務內網和政務外網。政務內網中儲存著全部信息，其中包括部分機密信息；政務外網可以對公眾開放，開放的信息必須得到授權。系統要求在這兩個子網中的合法用戶都可以訪問到被授權的信息，訪問的信息必須是一致可靠，政務內網的信息可以發布到政務外網，政務外網的信息在經過審批后可以進入政務內網系統。
    老王是該項目的項目經理，在捕獲到這個需求后認為電子政務建設與企業信息化有很大的不同，有其自身的特殊性，若照搬企業信息化原有的經驗和方案必定會遭到慘敗。因此采用了嚴格瀑布模型，并專門招聘了熟悉網絡互通互聯的技術人員設計了解決方案，在經過嚴格評審后實施。在項目交付時，雖然系統完全滿足了保密性的要求，但用戶對系統用戶界面提出了較大的異議，認為不符合政務信息系統的風格，操作也不夠便捷，要求徹底更換。由于最初設計的缺陷，系統表現層和邏輯層緊密耦合，導致70％的代碼重寫，而第二版的用戶界面仍不能滿足最終用戶的要求，最終又重寫的部分代碼才通過驗收。由于系統的反復變更，項目組成員產生了強烈的挫折感，士氣低落，項目工期也超出原計劃的100％。
    【問題1】(10分)
    請不超過300字，對老王的行為進行點評？
    【問題2】(9分)
    請從項目范圍管理的角度找出該項目實施過程中的主要管理問題？不超過200字回答。
    【問題3】(6分)
    請結合你本人實際項目經驗，指出應如何避免類似問題？不超過200字回答。
2.1.2案例分析
    這是一個失敗的項目，老王在項目管理中既有閃光點，也有失敗的地方。但項目管理中的任何差錯都會影響項目的結果，而范圍管理的失誤對項目的影響更為明顯。模糊的項目范圍定義、錯誤的工作分解、缺失的范圍確認和無力的范圍控制都將嚴重影響項目的結果。
    老王對項目范圍有一定的把握。在范圍定義中，老王發現了不同行業間具有不同的特點，電子政務行業對系統運行環境有著特殊的要求。根據國家對電子政務的要求，政務內網與政務外網是該行業一致的標準，這與企業信息化是完全不同的。老王捕獲到該需求，并對這個需求進行了清晰的定義，根據瀑布模型的要求，對設計和實現都進行了嚴格的控制，因此在系統交付時完全滿足了用戶對保密性的要求。在這一點上，老王是成功的。如果在范圍定義時忽略了行業標準，項目肯定會招致更大的失敗。
    但用戶界面的風格和操作的便捷性也屬于系統范圍的一部分。與系統運行環境一樣，我們通常稱這類需求為隱性需求。這類需求往往不是由用戶直接提出，而且受行業特點決定的范圍所約束。對于電子政務來說，系統保持一致的風格非常重要。作為政府對公眾開放的窗口而言，并不需要很強的個性化，但一致的界面風格可以體現出政務的嚴肅性。考慮到全體民眾層次差異較大，大多數訪問系統的用戶一般都沒有接受過系統使用的培訓，操作的便捷性也是政務系統必須實現的功能之一。很明顯，對于這些系統的隱性需求老王沒有充分考慮，從而導致一而再，再而三的變更。
    對于軟件項目，所有的需求都必須經過清晰的定義，這些需求都是項目范圍的一部分。老王僅僅注意了其中的一部分，而忽略了用戶界面，最終導致項目的失敗。
    對于電子政務信息系統，尤其是面向公眾開放的信息系統，范圍定義更加困難。這些系統的最終用戶幾乎不會參加需求開發的工作，他們的需求都是間接的，通過政府部門的負責人傳遞到項目組。但最終用戶的意見對項目的結果會有巨大的影響，這是就對范圍管理提出了更高的要求。
    除了在范圍定義方面的問題外，老王在范圍確認和范圍控制方面也存在不小的失誤。當系統第一次更改時，就應該意識到系統界面風格和操作便捷性的重要性。這時應該清晰地定義系統的界面風格和操作風格，并設法進行確認。如果采取了恰當的措施，第二次的變更是完全可以避免的。
    在剛剛進入一個陌生領域的時候，其中充滿了各種各樣的風險。隱性的行規和行業特點都是項目范圍的風險。面對這些風險，即使再細致的調研也無法完全避免，也不能完整定義系統的范圍。因此可以考慮采取原型法等方式來提前暴露風險，減少風險帶來的損失。因此在案例中，老王也沒有進行充分的風險管理，采用嚴格的瀑布模型增加了風險發生后帶來的損失。
    對于這個案例，缺乏良好的設計也是很明顯的缺陷。用戶界面中耦合了大量的業務邏輯，這必然增加變更的代價，從而導致大部分代碼重寫。若在項目初期意識到界面變更的風險，隨之采用良好的設計，將表現層和業務邏輯徹底分開，系統變更的代價也會小得多。
    綜上所述，項目經理老王在整個案例中，針對范圍管理做了一些工作，但不全面，在風險管理和質量管理上也都存在缺陷。
    有了上面的分析，這道題就很容易作答。項目的閃光點在于對系統運行環境進行了清晰的定義，并最終滿足了用戶的要求；但不充分的范圍定義和范圍  確認招致了項目的失敗，而采用了抗風險能力較弱的瀑布模型和低質量的設計又雪上加霜，最終導致項目延期100%.
    因此第一題答案的要點就很明確了：
    (1)老王注意到了系統運行環境的特殊性，在良好設計和實現的情況下滿足了用戶的要求。
    (2)老王忽略了系統用戶的潛在要求，在用戶界面和操作的風格上范圍定義不清晰，造成系統交付的重大變更。
    (3)老王在第一次問題發生后仍沒有對范圍進行有效的管理，造成了系統第二次的變更。
    (4)老王沒有對用戶界面是否能夠滿足要求的風險進行有效的管理，而是采用了對風險適應性較差的瀑布模型組織開發。
    (5)老王沒有對設計質量進行有效的控制，造成表現層中耦合了業務邏輯，增加了修改的代價。
    對于第二題，是在第一題的基礎上考察對范圍管理的理解，因此可以忽略在其他領域的問題。在范圍管理中主要包括如下內容：
    (1)范圍管理計劃。
    (2)范圍定義。
    (3)工作分解。
    (4)范圍確認。
    (5)范圍控制。
    在本案例中，沒有專門設計到范圍管理計劃和工作分解的內容。從表面上看，范圍定義存在明顯的缺陷。但案例中提到系統又發生了第二次變更，由此可見，老王在范圍確認和范圍控制上也存在不足。若在問題第一次出現時就進行有效的范圍確認和范圍控制，則完全可以避免第二次的變更。因此，第二題的答案要點如下：
    (1)老王沒有挖掘到系統的全部隱性需求，缺乏精確的范圍定義。
    (2)在發生第一次變更時，老王仍沒有有效的范圍管理，從而造成系統的二次變更。
    (3)重復的系統變更說明老王對系統范圍控制不足，導致一而再再而三的反復。
    在完成第二題后，第三題就是水到渠成了，第三題的要點見參考答案，此處不再贅述。
    項目管理是一個系統工程，沒有哪種單一的手段可以有效地改善項目，反之管理中的任何疏忽都可能招致嚴重的后果，造成項目的失敗。而軟件項目的復雜性又決定了項目中的工作環環相扣，問題也總是相互關聯的。在發現問題后，也需要采取多種手段才能徹底解決問題。這對信息系統的項目經理來說是重大的挑戰。
2.1.3參考答案
    【問題1】(10分)
    (1)老王注意到了系統運行環境的特殊性，在良好設計和實現的情況下滿足了用戶的要求。(2分)
    (2)老王忽略了系統用戶的潛在要求，在用戶界面和操作的風格上范圍定義不清晰，造成系統交付時的重大變更。(2分)
    (3)老王在第一次問題發生后仍沒有對范圍進行有效的管理，造成了系統第二次的變更。(2分)
    (4)老王沒有對用戶界面是否能夠滿足要求的風險進行有效的管理，而是采用了對風險適應性較差的瀑布模型組織開發。(2分)
    (5)老王沒有對設計質量進行有效的控制，造成表現層中耦合了業務邏輯，增加了修改的代價。(2分)
    【問題2】(9分)
    (1)老王沒有挖掘到系統的全部隱性需求，缺乏精確的范圍定義。(3分)
    (2)在發生第一次變更時，老王仍沒有有效的范圍管理，從而造成系統的二次變更。(3分)
    (3)重復的系統變更說明老王對系統范圍控制不足，導致一而再再而三的反復。(3分)
    【問題3】(6分)
    有效的范圍管理包括了從范圍定義到范圍控制等多方面的工作，每一項工作都是重要的。對于本案例，要結合行業特點進行需求分析，挖掘系統潛在的需求，同時通過原型等方法來輔助需求的定義，避免范圍定義不清晰的問題。
    在發生需求變更時需要進行有效的需求控制，盡量在滿足用戶需求的前提下縮小需求范圍，堅決避免需求的再次變更。