閱讀以下關于信息系統(tǒng)項目管理過程中項目范圍管理方面問題的敘述，回答問題1至問題3.

   信管信息技術有限公司(CNITPM )剛剛和M簽訂了一份新的合同，合同的主要內(nèi)容是處理公司以前為M公司開發(fā)的信息系統(tǒng)的升級工作。升級后的系統(tǒng)可以滿足M公司新的業(yè)務流程和范圍。由于是一個現(xiàn)有系統(tǒng)的升級，項目經(jīng)理張工特意請來了原系統(tǒng)的需求調(diào)研人員李工擔任該項目的需求調(diào)研負責人。在李工的幫助下，很快地完成了需求開發(fā)的工作并進入設計與編碼。由于M公司的業(yè)務非常繁忙，M公司的業(yè)務代表沒有足夠的時間投入到項目中，確認需求的工作一拖再拖。張工認為，雙方已經(jīng)建立了密切的合作關系，李工也參加了原系統(tǒng)的需求開發(fā)，對業(yè)務的系統(tǒng)比較熟悉，因此定義的需求是清晰的。故張工并沒有催促業(yè)務代表在需求說明書中簽字。

    進入編碼階段后，李工因故移民加拿大，需要離開項目組。張工考慮到系統(tǒng)需求已經(jīng)定義，項目已經(jīng)進入編碼期，李工的離職雖然會對項目造成一定的影響，但影響較小，因此很快辦理好了李工的離職手續(xù)。

    在系統(tǒng)交付的時候，M公司的業(yè)務代表認為已經(jīng)提出的需求很多沒有實現(xiàn)，實現(xiàn)的需求也有很多不能滿足業(yè)務的要求，必須全部實現(xiàn)這些需求后才能驗收。此時李工已經(jīng)不在項目組，沒有人能夠清晰地解釋需求說明書。最終系統(tǒng)需求發(fā)生重大變更，項目延期超過50%, M的業(yè)務代表也因為系統(tǒng)的延期表示了強烈的不滿。

 【問題1】(8分)

請以400字對張工在項目管理工作中的行為進行點評。

    【問題2】(9分)

    請從項目范圍管理的角度找出該項目實施過程中的問題，以500字內(nèi)回答。

    【問題3】(8分)

    請結合你本人項目經(jīng)驗，談談應如何避免類似的問題，以500字內(nèi)回答。

    這是一個失敗的軟件項目，與很多失敗的軟件項目一樣，在系統(tǒng)需求上栽了跟頭。開發(fā)與定義軟件系統(tǒng)的需求在整個軟件開發(fā)過程中是最重要的一環(huán)，這是每個從事信息系統(tǒng)建設的項目經(jīng)理都清楚的事情，但往往又因為一時的疏忽而造成需求的重大缺陷，最終導致項目的失敗。案例中的項目經(jīng)理張工就是既重視需求又沒有控制好需求的一個例子。·

    在案例中，張工接手了一個系統(tǒng)升級的軟件項目。對于這樣的項目，首先需要熟悉原有的系統(tǒng)，然后才能談升級的問題。因此張工專門找到了原系統(tǒng)的需求調(diào)研人員李工來解決新系統(tǒng)的需求問題。這無疑是一個很好的辦法，可以快速準確地把握新系統(tǒng)的需求。從這一點上來說，張工是成功的，找到了合適的資源進行需求的開發(fā)與定義。李工也沒有讓張工失望，很快就整理出了新系統(tǒng)的需求，并進入了設計和編碼階段，除了客戶太忙沒有時間確認需求外，一切盡在張工的掌握之中。這是一個陽光燦爛的開端，如果一切順利的話，項目的成功也就是早晚的事情。就如同大多數(shù)經(jīng)典的悲劇故事一樣，故事的序幕是美好的。

    晴朗的天空飄來一塊烏云，李工要移民加拿大。不過僅僅是一片烏云而已，并沒有下起雨來。開發(fā)出的需求都已經(jīng)過設計，一些編碼工作也已經(jīng)開始，李工的工作已近圓滿完成，畢竟，一些細枝末節(jié)的問題還可以同客戶直接溝通。

    經(jīng)過項目組努力，項目終于完成開發(fā)，準備發(fā)布了。這時，烏云開始下雨，問題爆發(fā)了。客戶不認可項目組的工作，認為很多需求沒有實現(xiàn)，實現(xiàn)的功能也與需求不符。

    誰是這個項目組的罪人呢？李工？還是張工？換一個思路考慮一下，如果李工沒有離開項目組，結果又會是什么樣呢？客戶會因為李工還在項目組就認可這個系統(tǒng)嗎？很顯然，不會。至多可以在雙發(fā)的協(xié)商下少一些變更，項目延期不是50%,而是30％而已。如果非要區(qū)分50％和30％的區(qū)別，也不過是五十步笑百步而已。

    從項目管理的角度來說，項目范圍直接決定了工作量和工作目標，所以項目經(jīng)理必須管理項目的范圍。在范圍管理中，范圍定義、范圍確認和范圍控制又是最核心的三項活動，缺一不可。范圍定義是基礎的活動，不進行范圍定義就不能進行范圍確認和范圍控制。范圍確認則是基線化已定義的范圍，是范圍控制的依據(jù)。范圍控制的作用在于減少變更，保持項目范圍的穩(wěn)定性。在案例中，由于張工沒有進行范圍確認，最后的范圍控制也就變成了無本之木，控制過程肯定變成了討價還價，失去本身的意義。

    在軟件系統(tǒng)的開發(fā)中，系統(tǒng)需求就是項目的范圍。從軟件誕生至今的幾十年中，人們探索出了很多獲取系統(tǒng)需求的方法，但是熟悉軟件開發(fā)的人都知道，無論哪種方法都不可能定義出完美無誤的需求，需求中的缺陷必然存在，無法完全避免。因此需求確認或者說是范圍確認就顯得更為重要。

    有人可能會說，很難說服客戶在需求上簽字，很難讓客戶為需求的缺陷負責。以現(xiàn)在軟件行業(yè)的情況，這種說法是不無道理的。讓客戶在需求上簽字很困難，但并不等于就不需要進行范圍確認，而且范圍確認的方法也不僅僅只有需求簽字這一種方法。召集客戶的業(yè)務代表對需求進行評審、詳細記錄最原始的調(diào)研材料，讓客戶確認調(diào)研報告、采用迭代開發(fā)逐步確認系統(tǒng)需求，都是可以采用的方法。這些方法雖然沒有直接確認需求分析報告，但至少可以讓現(xiàn)有需求在項目組和客戶之間達成一致，提供范圍控制的基準，一樣可以達到范圍確認的目的。

    再回到這個案例，項目經(jīng)理張工樂觀認為李工開發(fā)的需求沒有什么問題，也誤認為雙方已經(jīng)有良好的合作，在不緊逼要求客戶代表簽字顯得不近人情，于是就抱著僥幸信息進入了開發(fā)。然而最終的結果是，項目延期嚴重，業(yè)務代表反而更不滿意，張工也要承擔項目延期造成的成本增加的責任。

    有了上面的分析，后面問題的答案就不難得出。首先看第一個問題，對張工的行為進行點評。前面已經(jīng)提到，張工注意到了需求的問題，專門找到了原系統(tǒng)需求負責人李工進行需求開發(fā)，這是對項目有利的一面。但由于缺少需求評審和確認的過程，造成需求中的缺陷沒有被及時發(fā)現(xiàn)，系統(tǒng)需求沒有與客戶確認，造成缺少需求控制的基準，最終導致需求的重大變更。

     對于第二題，聯(lián)系范圍管理的知識，我們不難發(fā)現(xiàn)張工在范圍確認和范圍控制中都有重大的缺陷，在范圍定義中也由于缺乏評審造成需求的質(zhì)量問題。

    在完成第二題后，第三題就水到渠成了，第三題的要點見參考答案，此處不再贅述。

    【問題1】(8分)

    (1)張工為了更明確地把握系統(tǒng)需求，聘請了原系統(tǒng)的需求調(diào)研人員李工，提高了需求定義的效率和質(zhì)量。(2分)

    (2)張工沒有對李工開發(fā)的系統(tǒng)需求進行評審和復查，從而使得需求的缺陷沒有被及時發(fā)現(xiàn)。

    (3)張工沒有要求用戶對已經(jīng)定義的需求進行確認，從而導致需求理解的偏差。(2分)

    (4)張工對需求的不能進行缺乏有效控制，最終造成項目延期50%.(2分)

    【問題2】(9分)

    該項目實施過程中的主要問題包括：

    (1)在范圍定義中，張工沒有對李工定義的需求進行評審，造成需求中的質(zhì)量缺陷沒有被及時發(fā)現(xiàn)。(3分)

    (2)在范圍確認中，張工沒有主動地要求用戶對需求進行確認。(3分)

    (3)在范圍控制中，張工無法進行有效的范圍控制，最終造成了重大的需

求變更。(3分)

    【問題3】(8分)

    對于本案例，項目經(jīng)理需要對需求定義的結果進行質(zhì)量控制，采取評審等方式減少需求中的問題。對已經(jīng)定義的需求需要與用戶進行確認，保證雙方理解的一致。在發(fā)生需求變更時，也應該采取靈活的手段，在滿足用戶需求的前提下，盡量減少需求變更的范圍。