【正文】 時間熟悉項目情況，因此即使增派兩人也很難在四個月內(nèi)完成。如果強行要求項目組成員通過加班等方式追逐4個月完成的目標(biāo)，肯定會降低項目的質(zhì)量，造成用戶不滿意。因此，張工提出將整個項目分為兩部分實現(xiàn)，第一部分使用三個半月的時間，第二部分使用三個月的時間，分別制定出兩部分的驗收標(biāo)準(zhǔn)，這樣不增派開發(fā)人員也可以完成。高層經(jīng)理認為該方案可以滿足 公司的運作要求，用戶也同意按照這種方案進行實施。六個月以后，項目在沒有增加人員的前提下順利地完成，雖然比最初計劃延長了半個月的工期，但既達到了公司的要求，客戶對最終交付的系統(tǒng)也非常滿意，項目組的成員也沒有感受到很大的壓力。 【問題1】(10分) 請不超過500字，指出張工是如何保證項目成功的？ 【問題2】(15分) 請不超過500字，試結(jié)合案例指出項目范圍管理的工作要點？ 這是一個成功的項目管理案例，項’目經(jīng)理張工有效的運用范圍管理，在不同的項目干系人中達成一致，使項目的結(jié)果同時滿足了高層經(jīng)理、客戶和項目組成員的要求。 作為一個項目管理者，必須熟練掌握和應(yīng)用項目管理九大領(lǐng)域涵蓋的知識與技能，對于進行信息系統(tǒng)開發(fā)項目而言，范圍管理是其中最重要的技能之一。 軟件項目的范圍主要是由系統(tǒng)需求構(gòu)成的，而系統(tǒng)需求既是難以把握的，也是容易調(diào)整和控制的。軟件系統(tǒng)的需求來源于用戶需求，在軟件項目目標(biāo)是滿足用戶需求的情況下，對于相同的用戶價值可以定義出不同的系統(tǒng)需求。舉一個簡單的例子，用戶的需求是“解決口渴的問題”，那么最簡單的系統(tǒng)需求可以是遞上一杯水，復(fù)雜一些的可能是遞上一杯熱水，更復(fù)雜的是遞上一杯經(jīng)過多層過濾的純凈水，當(dāng)然也可以是打一桶虎跑泉的水，然后沏上一杯龍井茶。 用戶當(dāng)然希望用買礦泉水的錢換一杯正宗的龍井茶，但這樣的項目范圍肯定會導(dǎo)致項目失敗。聰明的軟件項目經(jīng)理總是從范圍管理開始，先界定系統(tǒng)的邊界，然后再在明確的范圍內(nèi)進行時間、成本、風(fēng)險等的管理。 在項目中，時間、成本和范圍構(gòu)成了一個穩(wěn)固的三角形，如圖21所示。 對于該三角形來說，任何一邊都不可能孤立地改變。換句話說，我們不可能固定其中兩邊而試圖縮短第三邊。其實這也是很容易理解的問題，如果項目需要做的東西已經(jīng)確定(項目范圍固定)，項目的人員也已經(jīng)確定(項目成本固定)，那么項目需要的時間就也是固定的。同理，已經(jīng)固定的項目投入和項目時間也只能做出固定的工作。對于這個三角形而言，非但不可能孤立地改變某一邊的長短，就是三邊的變化比例不一致也不可能。不成比例的變化與孤立的改變某一邊是一樣的，都將破壞三角形的結(jié)構(gòu)，違反項目的客觀規(guī)律，最終招致失敗。因此有效的范圍管理更像一門藝術(shù)，可以幫助項目經(jīng)理在已經(jīng)確定的時間和成本下完成項目目標(biāo)。 在本案例中，高層經(jīng)理S就提出了試圖打破這個三角形的要求。他要求，項目組可以增加部分資源，但要提前兩個月完成。初一看，并沒有在不增加投入的情況下要求項目提前完成，似乎合情合理，比起既要馬兒跑又不讓馬兒吃草的要求好得多，但細一想，增加的資源和提前的時間還是不成比例。項目經(jīng)理張工深知此中奧妙，因此在聽到高層經(jīng)理的要求后，馬上意識到這是一個不可能完成的任務(wù)。 那么該如何解決這個矛盾呢？還是要從這個三角形入手。既然時間和資源的變化已經(jīng)打破了項目規(guī)律，那么不妨根據(jù)新的時間和資源來重新劃定合理的項目范圍，保證項目的正常運作。于是，張工將這個項目拆分為兩部分，重新定義這兩部分的項目范圍，使每一部分的范圍都可以與已經(jīng)確定的資源和時間匹配起來，讓項目的運作又重新滿足了項目的客觀規(guī)律，最終取得了成功。 在案例中，還有一些細節(jié)需要考生注意。張工最初估算整個項目需要花費60人月的總工作量，但如果考慮到拆分為兩個階段后會增加設(shè)計的復(fù)雜度，增加了額外的驗收過程等因素，超出原計劃半個月是正常的。計劃在6個月內(nèi)完成。在把項目拆分后，實際是用了6個半月的時間，也就是花費了65人月完成了項目。對于上面介紹的時間、成本和范圍的關(guān)系而言，僅是在理想情況下成立，即項目成員始終能以固定的成本完成固定的工作。而在實際情況下，項目的工期、復(fù)雜度等因素都會對項目造成影響。在案例中，雖然看似兩部分工作的總和等于沒有拆分前的項目，但這僅對于最終目標(biāo)而言，拆分后的項目增加了若干中間成果，項目的范圍實際上還是擴大了。 因為軟件項目的范圍直接與需求相關(guān)，所以，很多人誤認為控制項目范圍就是控制需求，而控制的方法就是減少需求的內(nèi)容。這種理解是完全錯誤的。 范圍控制體現(xiàn)在軟件開發(fā)的各個階段，很多范圍控制并非是針對客戶的要求而進行的。例如，本案例中，范圍控制就是針對高層經(jīng)理的要求進行的。再比如，在設(shè)計中，我們既可以設(shè)計剛剛夠用甚至略有欠缺，通過犧牲系統(tǒng)的擴展性、維護性等方面來簡化設(shè)計，也可以對系統(tǒng)進行充分良好的設(shè)計，甚至可能是過度設(shè)計。采取哪一種設(shè)計策略也是軟件項目范圍管理的一部分。項目經(jīng)理可以根據(jù)目前的項目的目標(biāo)與環(huán)境出發(fā)，綜合考慮質(zhì)量和成本的約束，制定明確的項目范圍，保證項目的成功。根據(jù)筆者的經(jīng)驗，即時需求已經(jīng)確定，通過有效的范圍管理仍能給項目帶來很大的收益，可以在不犧牲軟件質(zhì)量的前提下通過范圍管理來降低項目成本，縮短項目工期。 上面主要針對張工在范圍控制方面進行了分析，實際在整個案例中，張工還進行了其他的范圍管理工作。 首先，在項目剛剛開始，張工就對項目范圍進行了定義，進而劃分了WBS并對項目進行了估算和計劃。在S提出需要縮短工期的要求后，張工首先進行了項目范圍的控制，縮小了第一步需要完成的項目范圍。緊接著張工又對兩階段需要完成的項目范圍進行了重新定義，制定了驗收標(biāo)準(zhǔn)。最后，張工對重新定義的范圍進行了確認，與客戶和高層經(jīng)理達成一致。 對于項目而言，僅僅管理范圍仍不能保證項目的成功。在這個案例中，張工也運用了其他的管理手段。其中包括，張工對項目進行了估算，這屬于項目時間管理的范疇；張工協(xié)調(diào)了多個項目干系人之間的矛盾，這屬于溝通管理的范疇。 有了上面的分析，這道考題的答案也就很清晰了。 【問題1】(10分) (1)張工首先對最初的項目范圍進行了清晰的定義，并根據(jù)定義對工作進行了分解，制定了WBS。 (2)張工對項目進行了估算，且估算結(jié)果真實可信，對項目工作量有量化的把握。(2分) (3)在出現(xiàn)新的項目目標(biāo)后，張工對項目進行了范圍控制，縮小了第一階段實現(xiàn)的范圍。(2分) (4)張工對重新定義的項目范圍進行了確認，與高層經(jīng)理和客戶達成一致。(2分) (5)張工對項目進行了溝通管理，協(xié)調(diào)了多個項目干系人之間的矛盾。(2分) 【問題2】(15分) 項目范圍管理的要點： (1)范圍管理計劃。(2分) (2)范圍定義。(2分) (3)工作分解。(2分) (4)范圍確認。(2分) (5)范圍控制。(2分) 在本案例中，張工首先進行了范圍定義和工作分解，得到了清晰的項目范圍；在出現(xiàn)新的項目目標(biāo)后，張工進行了范圍控制，重新定義了兩個階段的項目范圍；最后，張工將重新定義的范圍與項目干系人進行了確認。(5分)　案例三：范圍確認 閱讀以下關(guān)于信息系統(tǒng)項目管理過程中項目范圍管理方面問題的敘述，回答問題1至問題3. 希賽信息技術(shù)有限公司(CSAI )剛剛和M簽訂了一份新的合同，合同的主要內(nèi)容是處理公司以前為M公司開發(fā)的信息系統(tǒng)的升級工作。升級后的系統(tǒng)可以滿足M公司新的業(yè)務(wù)流程和范圍。由于是一個現(xiàn)有系統(tǒng)的升級，項目經(jīng)理張工特意請來了原系統(tǒng)的需求調(diào)研人員李工擔(dān)任該項目的需求調(diào)研負責(zé)人。在李工的幫助下，很快地完成了需求開發(fā)的工作并進入設(shè)計與編碼。由于M公司的業(yè)務(wù)非常繁忙，M公司的業(yè)務(wù)代表沒有足夠的時間投入到項目中，確認需求的工作一拖再拖。張工認為，雙方已經(jīng)建立了密切的合作關(guān)系，李工也參加了原系統(tǒng)的需求開發(fā)，對業(yè)務(wù)的系統(tǒng)比較熟悉，因此定義的需求是清晰的。故張工并沒有催促業(yè)務(wù)代表在需求說明書中簽字。 進入編碼階段后，李工因故移民加拿大，需要離開項目組。張工考慮到系統(tǒng)需求已經(jīng)定義，項目已經(jīng)進入編碼期，李工的離職雖然會對項目造成一定的影響，但影響較小，因此很快辦理好了李工的離職手續(xù)。 在系統(tǒng)交付的時候，M公司的業(yè)務(wù)代表認為已經(jīng)提出的需求很多沒有實現(xiàn)，實現(xiàn)的需求也有很多不能滿足業(yè)務(wù)的要求，必須全部實現(xiàn)這些需求后才能驗收。此時李工已經(jīng)不在項目組，沒有人能夠清晰地解釋需求說明書。最終系統(tǒng)需求發(fā)生重大變更，項目延期超過50%, M的業(yè)務(wù)代表也因為系統(tǒng)的延期表示了強烈的不滿。 【問題1】(8分)請以400字對張工在項目管理工作中的行為進行點評。 【問題2】(9分) 請從項目范圍管理的角度找出該項目實施過程中的問題，以500字內(nèi)回答。 【問題3】(8分) 請結(jié)合你本人項目經(jīng)驗，談?wù)剳?yīng)如何避免類似的問題，以500字內(nèi)回答?！“咐治? 這是一個失敗的軟件項目，與很多失敗的軟件項目一樣，在系統(tǒng)需求上栽了跟頭。開發(fā)與定義軟件系統(tǒng)的需求在整個軟件開發(fā)過程中是最重要的一環(huán)，這是每個從事信息系統(tǒng)建設(shè)的項目經(jīng)理都清楚的事情，但往往又因為一時的疏忽而造成需求的重大缺陷，最終導(dǎo)致項目的失敗。案例中的項目經(jīng)理張工就是既重視需求又沒有控制好需求的一個例子。 在案例中，張工接手了一個系統(tǒng)升級的軟件項目。對于這樣的項目，首先需要熟悉原有的系統(tǒng)，然后才能談升級的問題。因此張工專門找到了原系統(tǒng)的需求調(diào)研人員李工來解決新系統(tǒng)的需求問題。這無疑是一個很好的辦法，可以快速準(zhǔn)確地把握新系統(tǒng)的需求。從這一點上來說，張工是成功的，找到了合適的資源進行需求的開發(fā)與定義。李工也沒有讓張工失望，很快就整理出了新系統(tǒng)的需求，并進入了設(shè)計和編碼階段，除了客戶太忙沒有時間確認需求外，一切盡在張工的掌握之中。這是一個陽光燦爛的開端，如果一切順利的話，項目的成功也就是早晚的事情。就如同大多數(shù)經(jīng)典的悲劇故事一樣，故事的序幕是美好的。 晴朗的天空飄來一塊烏云，李工要移民加拿大。不過僅僅是一片烏云而已，并沒有下起雨來。開發(fā)出的需求都已經(jīng)過設(shè)計，一些編碼工作也已經(jīng)開始，李工的工作已近圓滿完成，畢竟，一些細枝末節(jié)的問題還可以同客戶直接溝通。 經(jīng)過項目組努力，項目終于完成開發(fā)，準(zhǔn)備發(fā)布了。這時，烏云開始下雨，問題爆發(fā)了?？蛻舨徽J可項目組的工作，認為很多需求沒有實現(xiàn)，實現(xiàn)的功能也與需求不符。 誰是這個項目組的罪人呢？李工？還是張工？換一個思路考慮一下，如果李工沒有離開項目組，結(jié)果又會是什么樣呢？客戶會因為李工還在項目組就認可這個系統(tǒng)嗎？很顯然，不會。至多可以在雙發(fā)的協(xié)商下少一些變更，項目延期不是50%,而是30％而已。如果非要區(qū)分50％和30％的區(qū)別，也不過是五十步笑百步而已。 從項目管理的角度來說，項目范圍直接決定了工作量和工作目標(biāo)，所以項目經(jīng)理必須管理項目的范圍。在范圍管理中，范圍定義、范圍確認和范圍控制又是最核心的三項活動，缺一不可。范圍定義是基礎(chǔ)的活動，不進行范圍定義就不能進行范圍確認和范圍控制。范圍確認則是基線化已定義的范圍，是范圍控制的依據(jù)。范圍控制的作用在于減少變更，保持項目范圍的穩(wěn)定性。在案例中，由于張工沒有進行范圍確認，最后的范圍控制也就變成了無本之木，控制過程肯定變成了討價還價，失去本身的意義。 在軟件系統(tǒng)的開發(fā)中，系統(tǒng)需求就是項目的范圍。從軟件誕生至今的幾十年中，人們探索出了很多獲取系統(tǒng)需求的方法，但是熟悉軟件開發(fā)的人都知道，無論哪種方法都不可能定義出完美無誤的需求，需求中的缺陷必然存在，無法完全避免。因此需求確認或者說是范圍確認就顯得更為重要。 有人可能會說，很難說服客戶在需求上簽字，很難讓客戶為需求的缺陷負責(zé)。以現(xiàn)在軟件行業(yè)的情況，這種說法是不無道理的。讓客戶在需求上簽字很困難，但并不等于就不需要進行范圍確認，而且范圍確認的方法也不僅僅只有需求簽字這一種方法。召集客戶的業(yè)務(wù)代表對需求進行評審、詳細記錄最原始的調(diào)研材料，讓客戶確認調(diào)研報告、采用迭代開發(fā)逐步確認系統(tǒng)需求，都是可以采用的方法。這些方法雖然沒有直接確認需求分析報告，但至少可以讓現(xiàn)有需求在項目組和客戶之間達成一致，提供范圍控制的基準(zhǔn)，一樣可以達到范圍確認的目的。 再回到這個案例，項目經(jīng)理張工樂觀認為李工開發(fā)的需求沒有什么問題，也誤認為雙方已經(jīng)有良好的合作，在不緊逼要求客戶代表簽字顯得不近人情，于是就抱著僥幸信息進入了開發(fā)。然而最終的結(jié)果是，項目延期嚴(yán)重，業(yè)務(wù)代表反而更不滿意，張工也要承擔(dān)項目延期造成的成本增加的責(zé)任。 有了上面的分析，后面問題的答案就不難得出。首先看第一個問題，對張工的行為進行點評。前面已經(jīng)提到，張工注意到了需求的問題，專門找到了原系統(tǒng)需求負責(zé)人李工進行需求開發(fā)，這是對項目有利的一面。但由于缺少需求評審和確認的過程，造成需求中的缺陷沒有被及時發(fā)現(xiàn)，系統(tǒng)需求沒有與客戶確認，造成缺少需求控制的基準(zhǔn)，最終導(dǎo)致需求的重大變更。 對于第二題，聯(lián)系范圍管理的知識，我們不難發(fā)現(xiàn)張工在范圍確認和范圍控制中都有重大的缺陷，在范圍定義中也由于缺乏評審造成需求的質(zhì)量問題。 在完成第二題后，第三題就水到渠成了，第三題的要點見參考答案，此處不再贅述。 【問題1】(8分) (1)張工為了更明確地把握系統(tǒng)需求，聘請了原系統(tǒng)的需求調(diào)研人員李工，提高了需求定義的效率和質(zhì)量。(2分) (2)張工沒有對李工開發(fā)的系統(tǒng)需求進行評審和復(fù)查，從而使得需求的缺陷沒有被及時發(fā)現(xiàn)。 (3)張工沒有要求用戶對已經(jīng)定義的需求進行確認，從而導(dǎo)致需求理解的偏差。(2分) (4)張工對需求的不能進行缺乏有效控制，最終造成項目延期50%.(2分) 【問題2】(9分) 該項目實施過程中的主要問題包括： (1)在范圍定義中，張工沒有對李工定義的需求進行評審，造成需求中的質(zhì)量缺陷沒有被及時發(fā)現(xiàn)。(3分) (2)在范圍確認中，張工沒有主動地要求用戶對需求進行確認。(3分) (3)在范圍控制中，張工無法進行有效的范圍控制，最終造成了重大的需求變更。(3分) 【問題3