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