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