2025年下半年信息系統(tǒng)項目管理師考試《案例分析》練習題及答案一、案例描述某市衛(wèi)健委委托XX科技公司開發(fā)“智慧醫(yī)療平臺升級項目”，旨在整合區(qū)域內(nèi)12家二級以上醫(yī)院的HIS系統(tǒng)，實現(xiàn)電子病歷互通、檢查結果共享、遠程會診三大核心功能。項目合同約定工期12個月（2024年10月2025年9月），預算1200萬元，采用總價加激勵費用合同（PIPF），要求系統(tǒng)吞吐量不低于5000次/秒，遠程會診延遲≤300ms。XX科技公司任命李華為項目經(jīng)理，團隊包括需求分析師3人、架構師2人、開發(fā)工程師15人（前端6人、后端9人）、測試工程師5人、實施顧問2人。項目關鍵里程碑：2025年1月：完成需求確認（原計劃12月）2025年4月：完成系統(tǒng)設計（原計劃3月）2025年7月：完成開發(fā)（原計劃6月）2025年9月：上線試運行（原計劃8月）截至2025年8月中旬，項目實際進展如下：1.需求階段：市衛(wèi)健委在2025年1月首次確認需求后，3月提出新增“疫苗接種記錄查詢”“家庭醫(yī)生簽約”功能，4月要求調整電子病歷數(shù)據(jù)字段格式（涉及23項字段），5月要求與醫(yī)保系統(tǒng)對接（原合同未包含）。需求變更單累計17份，其中12份未經(jīng)過正式審批。2.設計階段：架構師團隊采用RESTfulAPI設計接口，但某三甲醫(yī)院HIS系統(tǒng)僅支持SOAP協(xié)議，需額外開發(fā)適配器；數(shù)據(jù)標準未與各醫(yī)院提前對齊，導致檢查結果共享模塊需重新定義數(shù)據(jù)字典。3.開發(fā)階段：前端團隊因接口文檔更新不及時（后端團隊未同步），導致3次返工；后端團隊為趕進度簡化了部分數(shù)據(jù)校驗邏輯，測試階段發(fā)現(xiàn)12項數(shù)據(jù)不一致問題。4.測試階段：系統(tǒng)吞吐量僅達到3800次/秒，遠程會診延遲最高達800ms；用戶側測試（UAT）中，10家醫(yī)院反饋操作界面不符合醫(yī)護人員使用習慣，需調整交互設計。5.資源管理：2名核心后端開發(fā)工程師（負責數(shù)據(jù)交換模塊）分別于5月、7月離職，交接周期均超過2周，新人需1個月才能獨立編碼；團隊成員因頻繁加班出現(xiàn)情緒抵觸，3名測試工程師提出調崗申請。當前項目狀態(tài)：進度滯后2.5個月，實際成本已支出980萬元（原計劃8月中旬支出750萬元），CPI=0.82，SPI=0.75；客戶滿意度調查評分為62分（滿分100），主要投訴點為“需求響應慢”“系統(tǒng)不穩(wěn)定”“溝通不透明”。二、問題1.結合案例，指出項目當前存在的主要問題（8分）。2.分析導致項目進度滯后和成本超支的根本原因（10分）。3.針對需求變更管理問題，說明應采取的具體改進措施（10分）。4.若需在剩余時間內(nèi)將SPI提升至0.95以上，可采取哪些進度壓縮策略？并說明各自適用場景（7分）。三、答案問題1：項目當前存在的主要問題（1）需求變更管理混亂：變更未按流程審批（12份變更單未審批），缺乏變更影響評估，導致需求基線頻繁變動（17份變更單）。（2）設計階段缺陷：接口協(xié)議與醫(yī)院現(xiàn)有系統(tǒng)不兼容（RESTful與SOAP沖突），數(shù)據(jù)標準未提前對齊（需重新定義數(shù)據(jù)字典）。（3）團隊協(xié)作低效：前后端接口文檔更新不同步（導致3次返工），開發(fā)階段簡化校驗邏輯（引發(fā)12項數(shù)據(jù)問題）。（4）質量控制不足：性能指標未達標（吞吐量3800次/秒、延遲800ms），UAT階段用戶體驗問題集中（10家醫(yī)院反饋界面問題）。（5）資源管理失控：核心人員流失（2名后端開發(fā)離職）、交接周期長（超2周），團隊士氣低落（測試工程師調崗）。（6）溝通管理失效：客戶滿意度低（62分），需求響應慢、系統(tǒng)問題反饋不及時（投訴點集中）。問題2：進度滯后和成本超支的根本原因（1）需求管理計劃缺失：未在項目啟動階段制定明確的需求變更流程（如CCB審批、變更影響分析），導致需求蔓延（17份變更單）直接沖擊進度基線。（2）風險識別與應對不足：未提前識別“醫(yī)院系統(tǒng)接口不兼容”“核心人員流失”等風險（如未制定關鍵崗位備份計劃、未與醫(yī)院提前確認技術標準），風險發(fā)生時缺乏快速響應措施（交接周期長）。（3）過程控制不嚴格：設計階段未進行多方案技術驗證（如未測試SOAP協(xié)議兼容性），開發(fā)階段未執(zhí)行代碼評審（簡化校驗邏輯未被發(fā)現(xiàn)），導致后期返工（前端3次返工、數(shù)據(jù)問題12項）。（4）資源分配不合理：核心崗位依賴個人能力（后端開發(fā)僅2名核心人員），未建立知識共享機制（交接周期長）；團隊負荷過高（頻繁加班）導致效率下降、人員流失。（5）溝通機制失效：與客戶的需求確認不充分（首次需求確認延遲1個月），變更影響未及時同步（客戶隨意提出變更）；團隊內(nèi)部信息傳遞不暢（接口文檔不同步）。問題3：需求變更管理的改進措施（1）建立正式變更控制流程：成立變更控制委員會（CCB），成員包括客戶代表、項目經(jīng)理、架構師、測試負責人，明確CCB審批權限（如5萬元以下變更由項目經(jīng)理審批，超5萬元需CCB決策）。所有變更需提交《變更申請單》，包含變更內(nèi)容、影響分析（進度、成本、質量）、優(yōu)先級評估（如“疫苗接種查詢”為高優(yōu)先級，“界面配色調整”為低優(yōu)先級）。（2）加強需求基線管理：使用配置管理工具（如SVN、GitLab）對需求文檔進行版本控制，明確需求基線（如2025年1月確認的V1.0基線），后續(xù)變更需基于基線進行差異分析。建立需求跟蹤矩陣（RTM），將每個需求與設計文檔、測試用例、開發(fā)任務關聯(lián)，確保變更可追溯（如“家庭醫(yī)生簽約”功能需關聯(lián)至3個開發(fā)任務、5個測試用例）。（3）強化變更影響評估：對每個變更進行“三維評估”：進度影響（如新增功能需延長2周）、成本影響（需增加開發(fā)人天×單價）、質量影響（如接口擴展可能降低系統(tǒng)穩(wěn)定性）。與客戶協(xié)商變更優(yōu)先級，對非關鍵變更（如“醫(yī)保對接”）建議推遲至二期項目，對關鍵變更（如“疫苗接種查詢”）重新調整項目基線（更新進度計劃、成本預算）。（4）定期溝通與確認：每周召開變更狀態(tài)會議，向客戶匯報已審批變更的實施進度（如“字段格式調整”已完成80%）、未審批變更的評估結果（如“醫(yī)保對接”需額外預算200萬）。每月發(fā)布《需求變更報告》，包含變更數(shù)量、類型分布（功能類占60%、界面類占30%）、對項目目標的影響（如進度延遲2個月），確?？蛻羧虆⑴c決策。問題4：進度壓縮策略及適用場景（1）趕工（Crashing）：具體措施：增加資源投入（如臨時招聘2名有醫(yī)療系統(tǒng)經(jīng)驗的后端開發(fā)）、延長工作時間（經(jīng)團隊協(xié)商后安排周末加班，但需支付加班費）。適用場景：關鍵路徑上的任務（如“數(shù)據(jù)交換模塊開發(fā)”），且資源投入與進度縮短呈正相關（如增加1人可縮短1周）。（2）快速跟進（FastTracking）：具體措施：將串行任務改為并行（如原計劃“接口適配”完成后再進行“性能優(yōu)化”，現(xiàn)同步開展）、提前啟動測試準備（如在開發(fā)完成50%時開始編寫測試用例）。適用場景：任務之間存在軟邏輯關系（非強制性依賴），且并行實施的風險可控（如測試用例編寫不影響開發(fā)進度）。（3）縮小范圍（ScopeReduction）：具體措施：與客戶協(xié)商，將非核心功能（如“家庭醫(yī)生簽約”的“歷史簽約記錄導出”子功能）推遲至上線后迭代開發(fā)。適用場景：客戶對項目核心目標（電子病歷互通、遠程會診）優(yōu)先級高于次要功能，且縮小范圍不影響驗收標準。（4）資源優(yōu)化（ResourceLeveling）：具體措施：從非關鍵路徑調派資源至關鍵路徑（如將1名前端工程師臨時支援后端接口開發(fā)）、優(yōu)化任務分配（如讓經(jīng)驗