【文章內容簡介】 預期效果：項目經理通過銷售經理、信息科長直接與醫(yī)院院領導面對面溝通，結合相關背景，有效掌握了醫(yī)院對本項目的要求和期望，同時也了解除院長外其他領導的關注點。識別干系人：通過信息科長和銷售經理了解各部門的真實想法和期望，在實現(xiàn)項目整體目標前提下對項目規(guī)劃方案進行調整。召開項目現(xiàn)場啟動會：在項目經理和信息科長的精心準備下，啟動會很成功。既讓全院上下明白了此項目對醫(yī)院的重要性，同時也看到了系統(tǒng)將來對自己工作的影響和改進，了解了X軟公司在醫(yī)療行業(yè)的發(fā)展，了解了項目建設的階段、推進方案，以及下一步涉及到自己的具體工作。項目初步規(guī)劃：通過對網絡布線工程進度、干系人要求與期望、公司當前資源狀況、老系統(tǒng)使用狀況等情況分析，對原有實施方案及時做出調整并得到醫(yī)院認可。良好的前期策劃保證了項目按計劃推進。 輸出成果物過程活動過程輸出產物是否必要項目啟動項目立項項目任務書是環(huán)境管理環(huán)境確認Checklist(開發(fā)、測試、培訓、實施、硬件、辦公等環(huán)境)是環(huán)境管理項目進駐現(xiàn)場條件評估報告是環(huán)境管理客戶現(xiàn)場情況調查表是項目策劃項目組織結構圖是項目管理制度是項目干系人管理表是項目初步計劃（范圍、目標、溝通、里程碑、）是風險管理風險/問題管理表是配置管理配置管理計劃是質量保證質量保證計劃是管理評審評審記錄是啟動會內部啟動會報告是外部啟動會報告是會議記錄及決議是 參與角色及職責角色職責客戶方領導小組組長批準項目啟動計劃，確定參加項目啟動會的時間、講稿。公司領導小組組長批準項目啟動計劃，確定參加項目啟動會的時間、講稿。銷售經理配合項目經理在啟動階段與項目相關干系人溝通，搜集項目信息，編制項目初步規(guī)劃，策劃項目啟動會。項目經理負責編制項目初步規(guī)劃，策劃項目啟動會。項目軟件經理協(xié)助項目經理完成項目軟件部分內容的需求分析、開發(fā)實現(xiàn)、交付實施、售后服務等實施方案。第三方項目經理配合項目經理編制項目初步規(guī)劃，負責完成第三方承建工作的實施方案。客戶方項目經理接口人協(xié)助項目經理編制項目初步規(guī)劃，與項目經理一起策劃項目啟動會。PMO管理員編制項目任務書，發(fā)布項目經理任命。 需求（現(xiàn)場）調研 過程概述需求調研的主要目的是定義項目的范圍，詳細描述項目最終的可交付成果。了解客戶相關業(yè)務背景，收集相關資料，與客戶干系人互動，理解干系人的想法和期望，并對最終項目成果的內容和特征達成一致，并用文字、圖表、符號等語言進行詳細描述。需求調研是工作分解的前提，是項目預算的基礎，是項目進度計劃的重要根據(jù)。主要任務有以下幾項：1）編制需求調研計劃，確定需求調研內容、形式、方法以及進度計劃和需求變更管理等。2）需求調查，為實現(xiàn)項目目標而定義并記錄干系人需求的過程。3）需求分析，對項目目標和產品功能進行詳細描述，形成項目驗收標準文件，即《需求分析報告》。4）需求評審，組織項目干系人對《需求分析報告》進行評審，以使甲乙雙方對項目目標和產品功能描述達成清晰、一致的理解，評審完成雙方簽字確認，形成項目范圍基準。5）需求變更管理，需求的變更需要得到項目領導小組的審批，需求變更是正常的，但不能范圍漫延，不能超出合同約定范圍。 工作任務 編制需求調研計劃 編制需求調研計劃的目的是讓需求分析具有計劃性，確保在有限的時間和資源條件下，準確理解用戶需求，完成需求分析的任務。項目經理根據(jù)招標文件、投標文件及合同文件等，與客戶方接口人一起組織討論需求調研計劃，包括確定需求調查內容、形式、方法，分解需求調研任務，確定所需資源，分配工作任務，編制需求調研時間進度計劃。 需求調查需求調查的目的是了解業(yè)務背景和干系人的期望、需要，收集意見和業(yè)務相關的原始表單、信息，以備加工、分析和呈現(xiàn)。根據(jù)項目目標和業(yè)務系統(tǒng)特點，設計《需求調查表》，收集最初步的客戶需求描述和業(yè)務相關的原始表單。對回收的《需求調查表》進行整理、分析，在必要時進一步與用戶溝通，以文字或圖形的形式大致描述雙方對特定需求的一致理解，并簽字確認，形成需求跟蹤矩陣。 需求分析需求分析的目的是為實現(xiàn)項目目標，整合干系人想法和意見、業(yè)務相關資料等，對項目可交付成果和驗收標準進行詳細描述。需求分析最重要的工作是界定項目哪些是需要做的工作內容，哪些是不需要做的，就交付成果的驗收標準與用戶達成一致。在理解需求調查信息的基礎上，用文字、圖表、符號等語言，以項目需求功能點的形式，逐項對功能點進行描述，包括產品功能的內容和特征、驗收標準、制約因素、假設約束條件、除外責任等。描述越通俗易懂，越便于用戶理解，越能與用戶達成一致。需求分析時最好還包括驗證功能點實現(xiàn)的測試用例。需求分析是一個迭代的過程，需要不斷與用戶確認和調整。需求分析報告越詳細，項目驗收中風險的消極影響越低。需求分析過程輸出是《需求規(guī)格說明書》。 需求評審需求評審的目的是讓《需求規(guī)格說明書》得到客戶干系人的確認。需求評審可以是正式或非正式的會議，可以是一次，也可以是多次，《需求規(guī)格說明書》可能會根據(jù)一次或多次的評審意見不斷完善，直到雙方達成一致。簽署《需求評審記錄》。 需求變更管理需求變更管理的目的是管理變更，不是控制不變更，只要是在項目約定范圍內，變更是合理的。需求變更需要得到項目領導小組或變更控制委員會的批準。需求是干系人管理思想的體現(xiàn)，凡是人想的都可能存在一定不足或缺陷。軟件系統(tǒng)的最終目標是協(xié)助管理者貫徹管理思想，管理思想可能存在不斷提高和完善的過程，軟件系統(tǒng)也會隨著這種變化而變化，因此變化是合理的。允許需求變更不是意味著放縱需求變更，變更不能是隨意性的，需要得到領導層的批準。需求變更率過高，說明有可能前期需求分析工作做得不太好，相關制約因素、假設約束條件、風險沒考慮周全。 控制要點 如何有效開展需求調研？為了有效開展需求調研，需要注意以下幾個方面：需求調研工作涉及到眾多的項目干系人，需要編制詳細的計劃。在什么時間與哪些部門的業(yè)務負責人進行交流？需要收集一些什么樣的材料？最重要的是我們的需求調研計劃需要描述出本次需求調研的目標和交付物，其中哪些文檔是需要雙方評審并簽字確認的？需求調研中最重要的干系人是客戶方的管理層或領導層。項目的范圍是由管理層或領導層最初想法而逐步細化的。因此調研應從管理層或領導層開始，了解、掌握了項目需求的演變過程，更有助于項目團隊識別更多的項目約束、限制條件、以及項目的風險，同時也有助于在隨后的執(zhí)行層調研中把握項目總體的目標、總體的需求框架。需求調研有多種方式，演示、訪談、書面問卷、會議等。有時候我們?yōu)榱藞D省事，需求調研時演示一下系統(tǒng)、發(fā)一些書面問卷就完了，或者通過一些會議進行調查收集。這些方法并不是不好，而是不夠。需求調研需要花時間與項目干系人充分交流，只有在雙方經過多次溝通、交流，才會形成達成一致的需求調研成果。訪談是必不可少的，與干系人互動方能了解干系人真實的想法和期望，這種訪談最好是一對一的，并且是多次的，對項目干系人的需求進行口頭或書面描述，然后不斷確認。需求調研時注意收集原始表單和資料，需求分析的結果就是在原始信息的基礎上進行創(chuàng)新、改進。有時候我們想要知道用戶這個需求的目的是為了實現(xiàn)什么？最直接的方式就是看用戶原來的操作模式以及原始的表單和資料，通過這些信息我們能分析、判斷用戶的真正目的，或許還能找到更好的方式去實現(xiàn)。需求調研時注意對用戶進行正確引導，采用行業(yè)中最優(yōu)的解決方案，避免墨守陳規(guī)。現(xiàn)場需求調研是一項非常有挑戰(zhàn)性的工作，客戶經常受原有系統(tǒng)的影響而抗拒接受新系統(tǒng)，因為他們已經熟悉老系統(tǒng)的管理模式和操作習慣。如果處理不好這種關系，很容易導致系統(tǒng)的需求無法控制，客戶很容易糾結于新、老系統(tǒng)之間的差別上，在新、老系統(tǒng)兩種模式反復，這種反復多發(fā)生在系統(tǒng)上線后。事實上每一個系統(tǒng)的設計都有其優(yōu)缺點，有一定的可取之處，多數(shù)情況下，要想將兩個系統(tǒng)的優(yōu)點整合到一起，往往是比較困難的，因為系統(tǒng)的核心設計思想不一樣。為了避免系統(tǒng)上線后需求反復帶來的返工工作量，在項目前期需求調研時，要利用歷史項目經驗、行業(yè)發(fā)展趨勢等有利條件，盡量引導用戶盡早確定采用最優(yōu)的解決方案。需求調研周期不能過長，避免需求漫延?？蛻粜枨笫枪芾硭枷?、管理模式的表達，管理思想、目標、模式有一定的周期性。時間過長，管理制度和政策有可能存在變化，那之前的需求調研成果又得變更，變更會帶來更多的連鎖反應，很容易導致項目進度不斷的延期。為什么很多項目需求永遠都做不完，多數(shù)原因是因為客戶的需求已經脫離了原來確認的需求了原來的需求基準成了一紙空文，缺少需求基準的項目，需求有很大的漫延風險。 如何正確理解控制需求？在項目中，我們經常提到一個詞語“控制需求”，我們需要正確理解控制需求的含義?？刂菩枨蟛皇菫榱丝刂贫刂?，不是控制項目的需求不變，項目需求永遠存在變更的可能，控制需求的真正目的是管理好需求、管理好需求變更。如何管理好需求？我們通常用《需求規(guī)格說明書》和《需求跟蹤矩陣》來進行管理。需求調研完成后，必須進行需求評審和簽字確認，《需求規(guī)格說明書》是項目的最終驗收標準，招標文件、投標文件、合同文件的約定可能是粗略的，《需求規(guī)格說明書》是非常詳細的，是雙方對項目結果的一致理解?！缎枨蟾櫨仃嚒肥垢上等饲逦亓私飧黜椥枨髲奶岢鲩_始到結果呈現(xiàn)的各個過程和狀態(tài)。如何管理好需求變更？需求管理中最重要的是管理變更，而不是控制需求不變更。凡是人的想法都會存不足，都會有缺陷，需求變更是允許的，但需求變更需要規(guī)范流程，需要得到變更控制委員會或類似的機構評審、審批。如果需求變更增加了項目目標實現(xiàn)的風險，需要同時提出相應的解決方案和應對措施；如果需求變更導致了項目范圍漫延，則需要增加項目預算。需求變更有助于提高干系人滿意度，并取得他們的信任和支持，有助項目目標實現(xiàn)。需求變更一定要得到項目領導小組或變更控制委員會的批準。管理需求變更的目的是保持項目范圍不會漫延、擴大，超過了合同約定的范圍，當項目范圍漫延時，需要酌情增加項目預算投入。 場景分析：昆明醫(yī)學院第一附屬醫(yī)院門診系統(tǒng)需求調研【場景描述】2006年8月該項目正式啟動，在召開項目現(xiàn)場啟動會后，項目組開始著手進行需求調研工作，計劃2個月完成全部調研分析工作，11月進行需求評審和簽字確認。在經過兩周的準備后，項目組向各科室下發(fā)需求調查表，根據(jù)收回來的調查表逐科室召開會議，一邊演示系統(tǒng)一邊提需求，大家各抒己見。雖然這種模式了解了各業(yè)務科室大多數(shù)人的想法，但這樣的會議效率非常低，普通操作員不會關注整個系統(tǒng)的建設目標和方案，而是著眼于操作細節(jié)，而操作細節(jié)往往又會陷入老系統(tǒng)的操作習慣。需求調研進展緩慢，在所有科室調研完成時，已經是11月底。而當項目組將調研結果匯報給院領導時，院領導否決了科室需求，要求嚴格遵照招標文件設計，對原有流程需要進行優(yōu)化調整，操作細節(jié)可參照原有系統(tǒng)，這導致項目組需求調研工作非常被動，需求評審再次延期，直到春節(jié)前才基本完成需求規(guī)格說明書的編寫，客戶同時要求春節(jié)后先出一個原型系統(tǒng)，然后再進行需求評審。春節(jié)假期之后，藥劑科對原合同約定中的外購系統(tǒng)美康合理用藥提出了異議，說其審方機制不滿足國家規(guī)范，要求更換為上海大通的合理用藥。這一變更的處理持續(xù)了約3個月，直到2007年5月份才完全談妥。由于合同約定的藥品管理系統(tǒng)只有門診部分，藥庫和住院部分將采用老系統(tǒng)，需要與新門診藥房進行接口。藥劑科長逐漸看到了新系統(tǒng)的優(yōu)越性，提出將藥庫系統(tǒng)換成新系統(tǒng)，由老住院藥房系統(tǒng)與新藥庫系統(tǒng)做接口。為了爭取后續(xù)的藥庫和住院系統(tǒng)，項目經理同意了這個需求。這樣做的好處是藥庫和門診藥房管理比較清晰，同時將來換藥庫系統(tǒng)時省去了很多工作量；但壞處是在這個合同增加了項目范圍，增加了工作量，對項目進度影響比較大。更為致命的是原分管副院長調走，導致需求評審再次推遲2個月，這兩個月中需求和原型不斷在變化，最終在2007年7月完成需求評審，該項目的需求調研持續(xù)了約10個月。【場景分析】需求調研模式：應該先找管理層溝通，而不是直接找科室談需求。軟件需求是自上而下的具體實現(xiàn)，脫離管理目標、思想的需求都是沒有幫助的。在跟各業(yè)務科室溝通時，應先跟科室領導談醫(yī)院整體目標和方案，而不是直接面對普通操作人員。要將管理層的目標和需求逐層分解、講明白，然后緊扣目標展開業(yè)務調研。這樣能引導用戶不至于脫離管理層的期望和要求，也就不會發(fā)生領導否決科室需求的情況。需求引導：需求調研中未能正確引導客戶，過多陷入老系統(tǒng)的操作習慣，導致需求調研過多糾纏在一些細節(jié)方面，而對院領導關注的流程優(yōu)化反而關注得不夠。這樣做的結果是得不到管理層的支持的。需求調研周期過長：周期過長，管理目標有可能發(fā)生變化，本項目中的合理用藥就一個很好的例子。投標中用戶對美康產品并沒有異議，藥劑科長春節(jié)后一次外出參觀改變了原有想法，提出了更換產品的需求。同時，周期過長導致院內人事關系發(fā)生了變化，主管此項目的領導都發(fā)生了變化，即項目需求的確認結果可想而知了。 項目“鍍金”：合同中沒有藥庫系統(tǒng)是一種嚴重的鍍金行為，通常也叫“釣魚工程”，從項目管理角度這是不允許的。即便要做，必須得到公司管理層的批準，要增加成本預算。本項目另一大不足便是藥庫的“鍍金”。 輸出成果物過程活動過程輸出產物是否必要需求管理需求策劃需求調研計劃是需求調查需求調查表是需求跟蹤矩陣是需求分析需求規(guī)格說明書是需求評審需求評審記錄是需求變更管理需求變更管理單是 參與角色及職責角色職責客戶方領導小組組長批準或否決需求規(guī)格說明書，批準或否決需求變更。公司領導小組組長批準或否決需求規(guī)格說明書，批準或否決需求變更。項目經理負責編制需求調研計劃，審核需求規(guī)格說明書和需求變更管理單，組織需求評審，提交項目領導小組審批。項目軟件經理協(xié)助項目經理完成需求調研計劃，并組織干系人完成需求調查、訪談、原始資料收集、需求分析。編制需求跟蹤矩陣、需求規(guī)格說明書?？蛻舴巾椖拷浝?