【文章內(nèi)容簡介】 了用戶保密性的要求；工作的缺點：采用“瀑布模式”的項目生命周期，沒有進(jìn)行論證，武斷；用戶需求調(diào)研的不全面，忽視了系統(tǒng)頁面的需求；并且，進(jìn)行第二版修正時，沒有針對頁面的需求修改進(jìn)行確認(rèn)。設(shè)計方案沒有進(jìn)行驗證；表現(xiàn)層內(nèi)耦合的業(yè)務(wù)邏輯，增加了修改的代價；團(tuán)隊管理措施不力，成員產(chǎn)生挫折感；【問題 2】請從項目范圍管理的角度找出該項目實施過程中的主要管理問題。 沒有建立規(guī)范的項目范圍管理流程和制度。 范圍定義和需求分析時，工作不細(xì)致，忽視了 B/S 架構(gòu)下的頁面需求 需求范圍變更中，沒有對頁面變更進(jìn)行“確認(rèn)”，就修改代碼【問題 3】答題的思路和提綱，請將下列答題點細(xì)化 針對甲方的需求，制定實用的項目范圍管理計劃； 做好范圍定義工作（詳細(xì)列出方法） 做好需求分析工作（方法、過程、工作步驟） 重視范圍確認(rèn)（方法） 嚴(yán)格范圍變更（變更流程） 建立完善的項目范圍管理制度和規(guī)范的范圍管理流程案例二（需求評審 教程 p514 ）《系統(tǒng)集成項目管理工程師》教程 p514 第 23 章案例分析 答： 軟件需求的定義軟件需求是軟件開發(fā)的最重要的一個輸入，需求風(fēng)險也常常是軟件開發(fā)過程中最大的一個風(fēng)險，降低需求風(fēng)險的一個重要手段就是需求評審，但是需求評審是所有的評審活動中最難的一個，也是最容易被忽視的一個評審。上述案例的問題小結(jié)2 以上的現(xiàn)象可以在很多項目中都可以看到。概括起來，在需求評審中常見的問題是：17◇ 需求報告很長，短時間內(nèi)評審者根本就不能把需求報告讀懂，想清楚；◇ 沒有作好前期準(zhǔn)備工作，需求評審的效率很低；◇ 需求評審的節(jié)奏無法控制；◇ 找不到合格的評審員，與會的評審員無法提出深入的問題；……上述案例的原因分析3 問題所在：l 評審缺乏有效依據(jù)和規(guī)范，不能保證評審的覆蓋率和有效性。l 產(chǎn)品經(jīng)理沒有把握好會議主題，評審變成了頭腦風(fēng)暴。l 目標(biāo)性需求沒有溝通好，后面的需求變成空中樓閣。l 缺乏評審的可操作依據(jù)，遺漏評審內(nèi)容。l 沒有作好前期準(zhǔn)備工作，導(dǎo)致評審時間長，效率低。l 沒有選擇合適的評審人員，無法獲得有價值的反饋。l 參加人員過多，容易陷入細(xì)枝末節(jié)的討論，會議演變成一場人人自由的混戰(zhàn)。針對以上問題，提出一些建議4 那么究竟如何做好需求評審呢？建議一：分層次評審我們知道用戶的需求是可以分層次的，一般而言可以分成如下的層次：216。 目標(biāo)性需求：定義了整個系統(tǒng)需要達(dá)到的目標(biāo)；216。 功能性需求：定義了整個系統(tǒng)必須完成的任務(wù)；216。 操作性需求：定義了完成每個任務(wù)的具體的人機(jī)交互；目標(biāo)性需求是企業(yè)的高層管理人員所關(guān)注的，功能性需求是企業(yè)的中層管理人員所關(guān)注的，操作性需求是企業(yè)的具體操作人員所關(guān)注的。對不同層次的需求，其描述形式是有區(qū)別的，參與評審的人員也是不同的。如果讓具體的操作人員去評審目標(biāo)性需求，可能會很容易地導(dǎo)致“撿了芝麻，丟了西瓜”的現(xiàn)象，如果讓高層的管理人員也去評審那些操作性需求，無疑是一種資源的浪費(fèi)或者就會出現(xiàn)案例三的情形。建議二：正式評審與非正式評審結(jié)合正式評審是指通過開評審會的形式，組織多個專家，將需求涉及到的人員集合在一起，并定義好參與評審人員的角色和職責(zé)，對需求進(jìn)行正規(guī)的會議評審。而非正式的評審并沒有這種嚴(yán)格的組織形式，一般也不需要將人員集合在一起評審，而是通過電子郵件、文件匯簽甚至是網(wǎng)絡(luò)聊天等多種形式對需求進(jìn)行評審。 2 種形式各有利弊，但往往非正式的評審比正式的評審效率更高，更容易發(fā)現(xiàn)問題。因此在評審時，應(yīng)該更靈活地利用這 2 種方式。建議三：分階段評審應(yīng)該在需求形成的過程中進(jìn)行分階段的評審，而不是在需求最終形成后再進(jìn)行評審。分階段評審可以將原本需要進(jìn)行的大規(guī)模評審拆分成各個小規(guī)模的評審，降低了需求返工的風(fēng)險，提高了評審的質(zhì)量。比如可以在形成目標(biāo)性需求后進(jìn)行一次評審，在形成系統(tǒng)的初次概要需求后進(jìn)行一次評審，當(dāng)對概要需求細(xì)分成幾個部分，對每個部分進(jìn)行各個評審，最終再對整體的需求進(jìn)行評審。建議四：精心挑選評審員18需求評審可能涉及的人員包括：需方的高層管理人員、中層管理人員、具體操作人員、 IT 主管、采購主管；供方的市場人員、需求分析人員、設(shè)計人員、測試人員、質(zhì)量保證人員、實施人員、項目經(jīng)理以及第三方的領(lǐng)域?qū)＜业鹊取Ｔ谶@些人員中由于大家所處的立場不同，對同一個問題的看法是不相同的，有些觀點是和系統(tǒng)的目標(biāo)有關(guān)系的，有些是關(guān)系不大的，不同的觀點可能形成互補(bǔ)的關(guān)系。為了保證評審的質(zhì)量和效率，需要精心挑選評審員。首先要保證使不同類型的人員的都要參與進(jìn)來，否則很可能會漏掉了很重要的需求。其次在不同類型的人員中要選擇那些真正和系統(tǒng)相關(guān)的，對系統(tǒng)有足夠了解的人員參與進(jìn)來，否則很可能使評審的效率降低或者最終不切實際的修改了系統(tǒng)的范圍。建議五：對評審員進(jìn)行培訓(xùn)在很多情況下，評審員是領(lǐng)域?qū)＜叶皇沁M(jìn)行評審活動的專家，他們沒有掌握進(jìn)行評審的方法、技巧、過程等，因此需要對評審員進(jìn)行，同樣對于主持評審的管理者也需要進(jìn)行培訓(xùn)，以便于參與評審的人員能夠緊緊圍繞評審的目標(biāo)來進(jìn)行，能夠控制評審活動的節(jié)奏，提高評審效率，避免發(fā)生案例一和案例二中出現(xiàn)的現(xiàn)象。對評審員的培訓(xùn)也可以區(qū)分為簡單培訓(xùn)與詳細(xì)培訓(xùn) 2 種。簡單培訓(xùn)可能需要十幾分鐘或者幾十分鐘，需要將在評審過程中的需要把握的基本原則，需要注意的常見問題說清楚。詳細(xì)培訓(xùn)則可能要需要對評審的方法、技巧、過程進(jìn)行正式的培訓(xùn)，需要花費(fèi)較長的時間，是一個獨立的活動。需要注意的是被評審人員也要被培訓(xùn)。建議六：充分利用需求評審檢查單需求檢查單是很好的評審工具，需求檢查單可以分成 2 類：需求形式的檢查單和需求內(nèi)容的檢查單。需求形式的檢查可以由 QA 人員負(fù)責(zé)，主要是針對需求文擋的格式是否符合質(zhì)量標(biāo)準(zhǔn)來提出的，需求內(nèi)容的檢查是由評審員負(fù)責(zé)的，主要是檢查需求內(nèi)容是否達(dá)到了系統(tǒng)目標(biāo)、是否有遺漏、是否有錯誤等等，這是需求評審的重點。檢查單可以幫助評審員系統(tǒng)全面地發(fā)現(xiàn)需求中的問題，檢查單也是隨著工程財富的積累逐漸豐富和優(yōu)化的。建議七：建立標(biāo)準(zhǔn)的評審流程對正規(guī)的需求評審會需要建立正規(guī)的需求評審流程，按照流程中定義的活動進(jìn)行規(guī)范的評審過程。比如在評審流程定義中可能規(guī)定評審的進(jìn)入條件，評審需要提交的資料，每次評審會議的人員職責(zé)分配，評審的具體步驟，評審?fù)ㄟ^的條件等等。通過評審流程執(zhí)行可能會避免出現(xiàn)案例五之類的問題。建議八：做好評審后的跟蹤工作在需求評審后，需要根據(jù)評審人員提出的問題進(jìn)行評價，以確定哪些問題是必須糾正的，哪些可以不糾正，并給出充分的客觀的理由與證據(jù)。當(dāng)確定需要糾正的問題后，要形成書面的需求變更的申請，進(jìn)入需求變更的管理流程，并確保變更的執(zhí)行，在變更完成后，要進(jìn)行復(fù)審。切忌評審?fù)戤吅?，沒有對問題進(jìn)行跟蹤，而無法保證評審結(jié)果的落實，使前期的評審努力付之東流。建議九：充分準(zhǔn)備評審評審質(zhì)量的好壞很大程度上取決于在評審會議前的準(zhǔn)備活動。常出現(xiàn)的問題是，需求文檔在評審會議前并沒有提前下發(fā)給參與評審會議的人員，沒19有留出更多更充分的時間讓參與評審的人員閱讀需求文檔。更有甚者，沒有執(zhí)行需求評審的進(jìn)入條件，在評審文檔中存在大量的低級的錯誤或者沒有在評審前進(jìn)行溝通，文檔中存在方向性的錯誤，從而導(dǎo)致評審的效率很低，質(zhì)量很差。對評審的準(zhǔn)備工作，也應(yīng)當(dāng)定義一個檢查單，在評審之前對照檢查單落實每項準(zhǔn)備工作。案例三（范圍管理 2009 下 試題二）閱讀下列說明，針對項目的范圍管理，回答問題 1 至問題 3，將解答填入答題紙的對應(yīng)欄內(nèi)?！菊f明】C 公司是一家從事電子商務(wù)的外國公司，為了在中國開展業(yè)務(wù)，派出 S 主管和 W翻譯來中國尋找合適的系統(tǒng)集成商，試圖在中國建設(shè)一套業(yè)務(wù)系統(tǒng)。 S 主管精通軟件開發(fā)，但是不懂漢語，而 W 翻譯對計算機(jī)相關(guān)技術(shù)知之甚少。W 翻譯通過中國朋友介紹，找到了從事系統(tǒng)集成的 H 公司。 H 公司指派楊工為該業(yè)務(wù)系統(tǒng)建設(shè)項目經(jīng)理，與 C 公司進(jìn)行交流。經(jīng)過需求調(diào)研，楊工認(rèn)為， C 公司想要建設(shè)一個視頻聊天網(wǎng)站，并據(jù)此完成了系統(tǒng)方案。在 W 的翻譯下， S 審閱并認(rèn)可了 H公司的系統(tǒng)方案。經(jīng)過進(jìn)一步的談判， C 公司和 H 公司簽訂了合同，并把該系統(tǒng)方案作為合同附件，作為將來項目驗收的標(biāo)準(zhǔn)。合同簽訂后，楊工迅速組織人力投入系統(tǒng)開發(fā)。由于楊工系統(tǒng)集成經(jīng)驗豐富，開發(fā)過程進(jìn)展順利， 對項目如期完工很有把握。系統(tǒng)開發(fā)期間， S 主管和 W 翻譯忙于在全國各地開拓市場，與 H 公司沒有再進(jìn)行接觸。就在系統(tǒng)開發(fā)行將結(jié)束之際， S 主管和 W 翻譯來到 H 公司查看開發(fā)進(jìn)度。當(dāng)看到楊工演示的即將完工的業(yè)務(wù)系統(tǒng)時， S 主管卻表示，視頻聊天只是系統(tǒng)的一個基本功能，系統(tǒng)的核心功能則是通過視頻聊天實現(xiàn)網(wǎng)上交易的電子商務(wù)活動，要求 H 公司完善系統(tǒng)功能并如期交付。楊工拿出系統(tǒng)方案作為證據(jù)，據(jù)理力爭。W 翻譯承認(rèn)此前他的工作有誤，導(dǎo)致雙方對項目范圍的認(rèn)識產(chǎn)生了偏差，并說服S 主管將交付日期延后 2 個月。為了完成合同，楊工同意對系統(tǒng)功能進(jìn)行擴(kuò)充完善，并重新修訂了系統(tǒng)方案。但是，此后 C 公司又多次提出范圍變更要求。楊工發(fā)現(xiàn)，不斷修訂的系統(tǒng)方案已經(jīng)嚴(yán)重偏離了原始方案，系統(tǒng)如期交付已經(jīng)是不可能的任務(wù)了?！締栴} 1】（6 分）請結(jié)合案例簡要說明，詳細(xì)的項目范圍說明書應(yīng)包含哪些內(nèi)容，并指出 C 公司和H 公司對哪些方面的理解出現(xiàn)了重大偏差。【問題 2】（6 分）請指出 S主管的要求是否恰當(dāng)？為什么？并請結(jié)合本案例簡要分析導(dǎo)致 C公司多次提出范圍變更的可能原因。【問題 3】（3 分）作為項目管理者，楊工此時應(yīng)關(guān)注的范圍變更控制的要點有哪些？〔問題 1〕詳細(xì)的項目范圍說明書應(yīng)包含如下內(nèi)容：項目的目標(biāo)；產(chǎn)品（或服務(wù)）的范圍描述；項目的可交付物；項目邊界；20產(chǎn)品驗收標(biāo)準(zhǔn)；項目的約束條件；項目的假定。C 和 H 在如下幾個方面出現(xiàn)了嚴(yán)重偏差：項目的目標(biāo)： H 以為是實現(xiàn)視頻聊天網(wǎng)站，而 C 期望是通過視頻聊天實現(xiàn)網(wǎng)上交易的電子商務(wù)；項目的可交付物：同上；驗收標(biāo)準(zhǔn)： H 把未經(jīng)確認(rèn)的存在嚴(yán)重偏差的“系統(tǒng)方案”作為驗收標(biāo)準(zhǔn)?！矄栴} 2〕S 主管的要求是恰當(dāng)?shù)摹Ｒ驗殡p方在需求（項目范圍）理解上存在重大偏差，而 H 公司未把詳細(xì)的項目范圍說明書（需求分析說明書），提交給 C 公司（S 主管）確認(rèn)簽字?；颍篠 主管的要求是不恰當(dāng)?shù)?，因為雙方已簽訂了合同， H 公司按照合同進(jìn)行開發(fā)，并無不妥。導(dǎo)致 C 公司多次提出范圍變更的可能原因： W 翻譯對計算機(jī)相關(guān)技術(shù)知之甚少，未能準(zhǔn)確轉(zhuǎn)達(dá) S 主管的需求；楊工收集需求時，理解出現(xiàn)偏差，未能準(zhǔn)確把握需求；楊工編制的需求分析說明書，未進(jìn)行內(nèi)部評審；需求分析說明書（或項目范圍說明書）未與 C 公司達(dá)成一致，未提交給 S 主管確認(rèn)簽字；楊工在范圍控制上做得不好?！矄栴} 3〕 確定范圍變更是否已經(jīng)產(chǎn)生；對造成范圍變更的因素施加影響，以確保這些變更得到一致的認(rèn)可。當(dāng)范圍變更發(fā)生時，對實際的變更進(jìn)行管理。案例四（涉及范圍管理、進(jìn)度管理和變更管理 2010 下 試題一）試題一[說明]某信息系統(tǒng)集成公司（承建方）成功中標(biāo)當(dāng)?shù)卣巢块T（建設(shè)方）辦公場所的一信息系統(tǒng)軟件升級改造項目。項目自 2 月份初開始，工期 1 年。承建方項目經(jīng)理制訂了相應(yīng)的進(jìn)度計劃，將項目工期分為四個階段：需求分析階段計劃 8 月底結(jié)束；設(shè)計階段計劃 9 月底結(jié)束；編碼階段計劃 11 月底結(jié)束； 安裝、測試、調(diào)試和運(yùn)行階段計劃次年 2 月底結(jié)束。當(dāng)年 2 月底，建設(shè)方通知承建方， 6 月至 8 月這 3 個月期間因某種原因，無法配合項目實施。經(jīng)雙方溝通后達(dá)成一致，項目仍按原合同約定的工期執(zhí)行。由于該項目的按時完成對承建方非常重要，在雙方就合同達(dá)成一致后，承建方領(lǐng)導(dǎo)立刻對項目經(jīng)理做出指示：21（1）招聘新人，加快需求分析的進(jìn)度，趕在 6 月底之前完成需求分析；（2） 6 月至 8 月期間在本單位內(nèi)部完成系統(tǒng)設(shè)計工作。項目經(jīng)理雖有不同意見，但還是根據(jù)領(lǐng)導(dǎo)的指示立即修改了進(jìn)度管理計劃并招募了新人，要求項目組按新計劃執(zhí)行，但項目進(jìn)展緩慢。直到 7 月底項目組才剛剛完成需求分析和初步設(shè)計?！締栴} 1】（3 分）除案例中描寫的具體事項外，承建方項目經(jīng)理在進(jìn)度管理方面可以采取哪些措施？A、開發(fā)拋棄型原型 B、績效評估 C、偏差分析D、編寫項目進(jìn)度報告 E、確認(rèn)項目范圍 F、發(fā)布新版項目章程【問題 2】（6 分）基于你的經(jīng)驗，請指出承建方領(lǐng)導(dǎo)的指示中可能存在的風(fēng)險，并簡要敘述進(jìn)行變更的主要步驟。【問題 3】（6 分）針對項目現(xiàn)狀，請簡述項目經(jīng)理可以采用的進(jìn)度壓縮技術(shù)，并分析利弊。答案：【問題 1】 B C D【問題 2】（4） 盲目增加人力未必可以加快項目進(jìn)度，尤其是增加沒有經(jīng)驗的員工，反而可能會拖延進(jìn)度。（5） 項目的風(fēng)險是否能夠規(guī)避，需要按照風(fēng)險管理的方法進(jìn)行風(fēng)險識別、風(fēng)險分析和風(fēng)險監(jiān)控。進(jìn)行變更控制：（1） 根據(jù)領(lǐng)導(dǎo)指示的內(nèi)容，向變更控制委員會提出相關(guān)變更申請；（2） 推動變更控制委員會對變更進(jìn)行評估，分析變更造成的影響和風(fēng)險；（3） 根據(jù)變更決策推動變更的實施，包括更新進(jìn)度計劃、招聘新人和相關(guān)活動；（4） 執(zhí)行或推動變更的確認(rèn)，開展變更后的項目活動。【問題 3】進(jìn)度壓縮的技術(shù)有以下兩種：（1）趕進(jìn)度：對費(fèi)用和進(jìn)度進(jìn)行權(quán)衡，確定如何在盡量減少費(fèi)用的前提下縮短項目所需時間.利：有可能在盡量減少費(fèi)用的前提下縮短項目所需的時間；弊： 趕進(jìn)度并非總能產(chǎn)生可行的方案，有可能