【文章內(nèi)容簡介】 分包的人就分包項目承擔連帶責任。 本案例中， A公司將子項工程分包給 B， B又將其分包給 C，顯然違背了招投標法的這一條款。根據(jù)條款中的內(nèi)容， “中標人應當就分包項目向招標人負責，接受分包的人就分包項目承擔連帶責任。 ”A公司顯然要承擔責任，同時 B 公司也承擔連帶責任。 作為項目經(jīng)理，不僅僅要做好項目的進度、質(zhì)量、成本的控制管理，而且要注意避免陷入法律陷阱中，因此，對《合同法》、《招投標法》都要有一定的了解。 【問題 3】 軟件配置管理是貫穿軟件開發(fā)過程始終的一項工作。對于一個軟件項目來說，軟件配置管理規(guī)范至少包括以下的內(nèi)容： (1)配置項及其命名規(guī)則。 (2)配置庫文件目錄結(jié)構。 (3)角色和權限定義。 (4)配置項變更流程。 (5)配置項發(fā)布。 (6)基線定義和基線變更。 項目中的基線有兩個方面：一是作為里程碑的基線 。另一個是模塊的階段性成果基線 (對工作產(chǎn)品而言 )，一般來說都要避免變更基線。對這兩種不同的基線，其影響的范圍不同，確立和變更方式也不一樣。 項目的基線變更控制委員會由客戶代表、產(chǎn)品經(jīng)理、項目經(jīng)理和技術經(jīng)理組成，對發(fā)布的里程碑類基線的變更必須由變更控制委員會確認并由 QA進行變更記錄，所有被變更影響的配置項都需要重新同步后再次發(fā)布 。而對于僅僅作為工作狀態(tài)保留的基線，一般只需要建立基線的小組確認更改并在 QA進行記錄即可。 【問題 4】 作為項目經(jīng)理，可以考慮首先從項目管理的 9 大知識點出發(fā)簡單闡述對本項目的一般性理解。此外，從本案例中，你可以發(fā)現(xiàn)項目中的合同與招投標管理、配置與變更管理方面均發(fā)生了問題。因此，可從本項目管理較弱的部分進行重點的 闡述，如對法律法規(guī)的理解 (招投標管理 )，項目進度管理、項目變更的控制。配置管理，以及進度計劃的變更將導致質(zhì)量和成本的變化，此外，還可從進度、質(zhì)量、成本三要素之間關系進行闡述。因為，基線的變更往往會帶來成本、進度方面的變更。 參考答案 【問題 1】 (6 分 ) 小丁在接到任務后開始項目計劃的編制工作，編制的計劃應包括： (l)項目總計劃 (包括范圍計劃、工作范圍定義、活動定義、資源需求、資源計劃、活動排序、費用估算、進度計劃以及費用計劃 )。 (2)項目輔助計劃 (質(zhì)量計劃、溝通計劃、人力資源計劃、風險計劃、采購計劃等 )。 【問題 2】 (6 分 ) 根據(jù)《中華人民共和國招投標法》第 48 條：中標人應當按照合同約定履行義務，完成中標項目。中標人不得向他人轉(zhuǎn)讓中標項目，也不得將中標項目肢解后分別向他人轉(zhuǎn)讓。 中標人按照合同約定或者經(jīng)招標人同意，可以將中標項目的部分非主體、非關鍵性工作分包給他人完成。接受分包的人應當具備相應的資格條件，并不得再次分包。 中標人應當就分包項目向招標人負責，接受分包的人就分包項目承擔連帶責任。 本案例中， A公司將子項工程分包給 B， B又將其分包給 C，顯然違背了招投標法的這一條款。根據(jù)條款中的內(nèi)容： “中標人應當就分包項目向招標人負責，接受分包的人就分包項目承擔連帶責任。 ”A公司顯然要承擔責任，同時 B 公司也負連帶責任。 【問題 3】 (6 分 ) 本題中，在項目執(zhí)行過程中，項目發(fā)生的變更，程序員老張擅自修改了已進入基線的程序，作為項目經(jīng)理的小丁不應該默許他的操作，且修改后的東西沒有經(jīng)過評審。 項目中缺乏變更控制的體系，需要建立變更控制流程，確保項目中所做的變更保持一致，并將產(chǎn)品的狀態(tài)、對其所做的變更，以及這些變更對成本和時間表的影響通知 給有關的項目干系人，以便于資源的協(xié)調(diào)。同時，項目團隊所有成員要清楚變更程序的步驟和要求。 提出以下建議： (1)建立配置管理體系。 (2)建立變更請求流程。 (3)組建變更控制委員會。 【問題 4】 (7 分 ) (1)從項目管理 9 大知識點出發(fā)簡單闡述本項目。 (2)從本項目管理較弱的部分進行重點的闡述，如對法律法規(guī)的理解 (招投標管理 )、項目進度管理、項目變更的控制。配置管理及進度計劃的變更將導致質(zhì)量和成本的變化，描述進度、質(zhì)量、成本三要素之間的關系。 案例二： 【說明】 老高承接了一個信息系統(tǒng)項目管理工作，在進行了需求分析和設計后，項目人員分頭進行開發(fā)工作，其間客戶提出一些變更要求也由各部門人員分別解決，各部門人員在進行自測的時候均報告正常，因此，老高決定直接在客戶現(xiàn)場進行集成，各部分人員分別提交了各自工作的最終版本進行集成，但是發(fā)現(xiàn)問題很多，針對系統(tǒng)各部分所表現(xiàn)出來的問題，開發(fā)人員又分別進行了修改，但是問題并未有明顯減少，而且項目工作和產(chǎn)品版本越來越混亂。 【問題 1】 分析出現(xiàn)這種情況的原因 【問題 2】 說明配置管理的主要工作并作簡要解釋 【問題 3】 說明針對目前情 況可采取哪些補救措施 【問題 1】 1。老高在分配給項目人員分工進行開發(fā)工作之前，沒有定義明確的各開發(fā)小組的接口?；蛘哂卸x統(tǒng)一接口，后來需求變更，沒有做統(tǒng)一管理。 2。項目溝通不暢，在客戶需求變更后，沒有通知相關干系人。以至于分頭工作的項目組不了解其他組是否了解變更，如果導致接口變更，就應該從項目的整體管控上解決此事。 3。沒有嚴格的變更管理程序。不是所有的客戶需求變更都可以實施的，應該從各小組抽出人員組成變更委員會，確認是否可以進行變更。 4。缺乏對整體版本的管理。沒有設定項目基線，每一個階段達成什么 樣的系統(tǒng)目標，由于缺乏整體的版本管理，導致后來的需求變更越來越多，不能形成一個統(tǒng)一的版本。 5。測試環(huán)節(jié)缺乏集成測試。各小組雖然進行了單元測試，沒有問題。應該留出時間給集成測試，不至于到客戶現(xiàn)場暴露太多的問題。 【問題 2】 配置管理主要工作有： 1。制定配置管理計劃。 2。標示配置項 3。對配置項進行版本控制。 4。對配置項的變更管理 5。定期進行配置審計 6。對配置狀態(tài)報告 【問題 3】 補救措施： 針對不前混亂的情況，老高要能把握項目的全局。理清需求設計完成之后所有的變更需求，成立項目組委會，以項目能及時 交付為目的，對變更的項目需求進行分類，那些需求對系統(tǒng)整合有影響，那些需求的缺少并暫時不影響系統(tǒng)的使用，生成一個可以滿足用戶的基本需求的版本，在以后的版本發(fā)布中，對新需求再加以補充。 另外，要加強配置管理環(huán)節(jié)。對進入基線的版本要嚴格控制，需求變更應該有詳細的變更流程，有變更委員會確認之后方可執(zhí)行。 在交付客戶驗收之前，應該進行集成測試，確保各模塊的銜接沒有問題之后再提交客戶驗收。 案例三： 閱讀以下關于信息系統(tǒng)項目管理過程中項目啟動與項目經(jīng)理角色方面問題的敘述，回答問題1 至問題 3，將解答填入答題紙的對應欄內(nèi)。 案例場景 A公司是一家經(jīng)營紙產(chǎn)品的企業(yè)，近幾年業(yè)務得到了成倍的發(fā)展，原來采用手工處理業(yè)務的方式已經(jīng)越來越顯得力不從心，因此，經(jīng)過公司董事會研究決定，在公司推行一套管理軟件，用管理軟件替代原有的手工作業(yè)的方式，同時，請公司副總經(jīng)理負責此項目的啟動。 副總經(jīng)理在接到任務后，即開始了項目的啟動工作。項目經(jīng)過前期的一些工作后，副總經(jīng)理任命小丁為該項目的項目經(jīng)理，小丁組建了項目團隊，并根據(jù)項目前期的情況，開始進行項目的計劃，表 12 所示為初步項目進度計劃表。 表 12 項目進度計劃表 任 務 名 稱 工 作 量 開 始 時 間 結(jié) 束 時 間 項目范圍規(guī)劃 5 2020 年 1 月 1 日 2020 年 1 月 6 日 分析軟件需求 20 2020 年 1 月 6 日 2020 年 1 月 26 日 設計 21 2020 年 1 月 26 日 2020 年 2 月 13 日 開發(fā) 30 2020 年 2 月 16 日 2020 年 3 月 16 日 測試 66 2020 年 2 月 16 日 2020 年 4 月 22 日 培訓 63 2020 年 2 月 16 日 2020 年 4 月 19 日 文檔 43 2020 年 2 月 16 日 2020 年 3 月 29 日 典型試驗 97 2020 年 1 月 26 日 2020 年 5 月 3 日 部署 7 2020 年 5 月 3 日 2020 年 5 月 10 日 實施工作總結(jié) 3 2020 年 5 月 10 日 2020 年 5 月 13 日 項目進行了一半，由于公司業(yè)務發(fā)展的需要，公司副總經(jīng)理要求小丁提前完工，作為項目經(jīng)理，小丁對項目進行了調(diào)整，保證了項目的提前完工。 【問題 1】（ 7 分） 請用 400 字以內(nèi)的文字描述你作為項目前期的負責人，在接到任務后將如何啟動 項目？ 【問題 2】（ 9 分） 作為項目經(jīng)理，你的項目進度控制中的重點是什么？請描述你在項目進度控制中的甘特圖及雙代號網(wǎng)絡圖，并比較甘特圖與網(wǎng)絡圖的區(qū)別。 【問題 3】（ 9 分） 假 設公司總經(jīng)理要求提前完工，作為項目經(jīng)理將如何處理？請用 400字以內(nèi)的文字描述你應該如何處理？ 案例分析 這是一道綜合性試題，涉及到項目的啟動、進度控制等問題。 【問題 1】 項目的啟動包括了以下幾個主要活動。 1）識別項目的需求 從投資方角度而言，識別需求是項目啟動過程和整個項目生命周期的最初活動，在這個過程中，為項目的目標確定，以及可行性分析和項目立項提供直接、有效的依據(jù)，為需求建議書的撰寫提供基礎。 一旦確定了相關問題和需求，并證實了項目將得到益處，投資方就可以開始準備需求建議書。 從承建方 的角度而言，識別需求就是得到客戶的需求建議書，或得到客戶初步需求意向后，項目團隊從技術實現(xiàn)、應用和項目實施角度識別客戶實際存在的問題、基本意圖和真實想法，從而達到與客戶有效的溝通，準確分析需求和問題，為制訂可行、正確的技術及實施解決方案提供依據(jù)。 承建方可以提交一份清晰的需求分析說明書，請客戶予以確定，形成需求共識。 2）解決方案的確定 解決方案類似于向投資方（客戶）提交的項目建議書。承建方在研究、分析投資方客戶的需求建議書后，結(jié)合當前情況與客戶交流，分析、制訂實施解決方案。解決方案通常包含如下三個部分。 （ 1）技術方案部分。該部分應使投資方認識到，承建方理解需求或問題，并且能夠提供風險最低且受益最大的解決方案。 （ 2）管理部分。該部分應使投資方相信，承建方有能力做好項目所提出的工作，組織好項目的實施。 （ 3）項目費用部分。該部分應使投資方相信，承建方項目建議書所提出的項目費用是符合實際的。根據(jù)客戶需求不同，對項目成本費用表述有所不同，部分項目要求提供總價或明細。 3）對項目進行可行性分析 可行性分析的目的就是給決策者提供判斷項目是否可行和投資決策的依據(jù)。 4）項目立項 經(jīng)過項目可行性分析后，投資方確立具體的 可投資項目或承建方確立可承接的項目的過程。 5）項目章程的確定 項目立項完成后，項目章程的制訂和發(fā)布將是項目啟動的一個結(jié)束標志。項目章程是企業(yè)內(nèi)部正式確認項目存在的企業(yè)文件。 本題中，項目前期的負責人實際是公司副總經(jīng)理，在項目章程中確定項目經(jīng)理的 人選。 【問題 2】 1）甘特圖法 甘特圖也叫橫道圖或條形圖，主要應用于項目計劃和項目進度的安排。它把工程項目中的各項作業(yè)，在標有日期的圖表上用橫線表示出其起止的時間。 甘特圖把計劃和進度安排兩種職能結(jié)合在一起，縱向列出項目活動，橫向列出事件跨度。項目活動 在左側(cè)列出，時間在圖表頂部列出，圖中的橫道線顯示了每項活動的開始時間和結(jié)束時間，橫道線的長度等于活動的工期，甘特圖頂部的時間段決定著項目計劃的詳略程度。 由于甘特圖把項目計劃和項目進度安排兩種職能組合在一起，因此在繪制甘特圖時，必須清楚各項活動之間的關系，即哪些活動必須在其他活動開始之前完成，哪些活動可以同時進行。 甘特圖直觀、簡單、容易制作，便于理解，一般適用于比較簡單的小型項目，可用于 WBS的任何層次、進度控制、資源優(yōu)化、編制資源和費用計劃。但是，不能系統(tǒng)地表達一個項目所包含的各項工作之間的復雜關系，難 以進行定量的計算和分析，以及計劃的優(yōu)化等。 2）網(wǎng)絡計劃技術 網(wǎng)絡計劃技術的原理是從需要管理的任務總進度出發(fā)，以任務中各項作業(yè)所需要的工時為時間因素，繪制出網(wǎng)絡圖，明確而直接地反映出該項任務的全貌，各項作業(yè)的進度安排、先后順序和相互關系。 在選擇計劃方法編制項目進度計劃時應考慮以下因素。 （ 1）項目的規(guī)模和復雜程度。 （ 2）對項目細節(jié)的掌握程度。 案例三： 閱讀以下關于在信息系統(tǒng)項目管理過程中項目整體管理方面問題的敘述，回答問題 1 至問題3，將解答填入答題紙的對應欄內(nèi)。 案例場景 XX 集團下屬飛達信息技術有限 公司新接到一個有關電子政務公文流轉(zhuǎn)系統(tǒng)的軟件項目，王工作為公司派出的項目經(jīng)理，帶領項目組開始進行項目的研發(fā)工作。 王工以前是一名老技術人員，從事 Java 開發(fā)多年，是個細心而又技術扎實的老工程師。在項目的初期，王工制訂了非常詳細的項目計劃，項目組人員的工作都被排得滿滿的，為加快項目的進度，王工制訂項目計劃后即分發(fā)到項目組成員手中開始實施。然而，隨著項目的進展，由于項目需求不斷變更，項目組人員也有所更換，項目組已經(jīng)沒有再按照計劃來進行工作，大家都是在當天早上才安排