需求是HIS項目最大的“焦油坑”。十多年前我讀了一本好書：《走出軟件作坊》，阿朱著，至今還在受益。“焦油坑”，在人類史前時代，沒有別的場景比巨獸在“焦油坑”中垂死掙扎的場面更令人震撼。造物者見證著恐龍、猛犸象、劍齒虎在焦油中掙扎，它們掙扎得越猛烈，焦油糾纏得越緊，沒有任何猛獸足夠強壯或具有足夠的技巧去掙脫束縛，到最后它們都沉到了坑底。紅軍在過草地時，不小心陷入泥沼，若旁邊沒有戰友，或沒有足夠長且結實的工具協助，最終都慢慢陷入澤地失去生命。人類區別于動物的一點是使用工具和知識傳承。

需求分級管理，是一名合格項目經理最重要的任務之一。需求分級有二個層面：一是需求管理層面；二是需求緊急重要程度判定層面。

HIS實施期間，需求滿天飛，若沒有規范的收集、跟蹤、處理流程，信息科與HIS公司都將陷入需求的“焦油坑”。需求產生有一定規律可循，一般有以下幾個階段。

1.進場階段的懷舊性需求。

此階段因為對新HIS系統還不太了解，需求不多，矛盾還未出現，主要想把舊HIS系統一些好的功能移植過來。再爛的舊HIS，總有幾處可借鑒的好功能，特別是一些實用的小工具，一線人員使用習慣了，這些懷舊性需求，會最早被提出來讓新HIS公司修改。還有一些是流程上的習慣，各類外部系統接口等，都是新HIS進場要全盤接收的需求。

2.培訓階段的易用性需求。

如果培訓之前，能夠改出一版懷舊性需求，再換成自己醫院的數據環境，那么培訓的效果一定比拿其他醫院的備份環境，要好很多很多。但經常時間不允許，能保證流程不出錯就算不錯了。培訓階段主要還是讓一線操作人員熟練掌新HIS的流程、功能特點和注意事項，操作人員總會代入到舊HIS的場景來對新HIS提出一些易用性的要求，甚至會要求改成與舊HIS界面一模一樣。這需要培訓老師有極強的說服能力，不然就會被扯入需求的泥潭。同時，信息科也要發揮行政管理的作用，合理的需求還是要收集采納，不合理要進行制止，不要陷入是非對錯之爭，保留意見，先學習新HIS的功能，然后考試，不合格全院通報。此階段開始了解新HIS系統，需求不會太多，仍有懷舊情結，會產生一定沖突，但還在控制范圍之內。

3.上線階段的各類爆發性需求。

此階段是需求和矛盾最集中的時期，嚴重到可以導致上線失敗。因為在正式醫療環境中運行，以前隱藏的BUG、未測試到的波及范圍、接口不穩定不完善、數據報錯、高峰期阻塞、更新一個功能點引發更多的錯誤等等。一天上百個需求都算正常，此階段不能按常規來填申請表走流程審批修改。特別是出錯性需求，要立即馬上進行修改，所以一天發布N個版本都是正常的。首先要保證診療流程能走得下去，醫囑不要出錯，費用不能出錯，每天晚上一定要集中開會，花時間進行需求清理和歸類，根據輕重緩急統籌安排修改順序，可以用最簡便的EXCEL表格進行記錄。

4.運維階段的優化性需求。

此階段是解決HIS系統從“能用”到“好用”的需求，持續的過程一直到被下一個新HIS換掉。驗收前會有幾波需求集中收集整改，驗收后需求會逐步減少，此階段都需要按照需求申請單的格式和流程執行。

理解需求產生的各階段規律，對我們管理需求有很大幫助，這是一名HIS熟手或項目經理應具備的職業素養。

“需求唯一接口人”，這是我在2012年《醫療衛生信息化項目管理實務》一書中提出來的理念，我們不但要有規范的需求單格式和流程，還要具體到由誰來管理需求。三甲醫院的員工2、3千人，每個人一口唾沫都可以把你淹死，何況咱們的HIS系統哪天不是一堆待處理的問題？“需求唯一接口人”并非只有一個人，原則上要求每個科室由一個人負責收集整理本科室的需求，然后匯總上報給主管部門指定的一個人來進行綜合研判，通過后再提交給信息科進行技術分析，細化需求，轉換成HIS公司能夠理解的語言，這時才是真正的信息化需求修改單，HIS公司項目經理再將需求提交給研發。真正執行時，主管部門的需求接口人，會過濾掉大部分無效的需求，將真正有用的需求，會與信息科和HIS公司的工程師，先商議出解決的方案后，才開始填寫需求申請單，復雜的需求會由信息科的工程師代為填寫。出錯性的需求，相對簡單，貼上出錯的原圖，再標出改進的意見，即是一張完美的需求申請單；涉及多部門的需求，可能會召開多次專題會來理清流程和功能點。

在需求管理這件事上，信息科不能來者不拒。如果實現難度特別大，又非緊急重要的需求，還會給系統造成性能或安全上的壓力，還不好拒絕時，信息科可以退后一步，將需求描述得很復雜，把相關科室拉得多多的，讓需求主管部門來組織會議，美其名曰集體討論決策，由他們先把流程、功能吵清楚后，再讓他們提供需求申請單，相關科室必須會簽意見，那么信息科就可以在旁邊看熱鬧，這樣的需求基本上就會緩好長一段時間，甚至不了了之。

我院HIS項目實施過程中，所有的需求必須經過我簽字后，才提交給HIS公司的項目經理，HIS項目經理也只認我的簽字或口頭交待，才會將需求單分配給研發人員。把握好這個關口，醫院再多再復雜的需求，都不會出現大的差錯。

臨床人員提出的每一個需求，他們認為都是最重要緊急的，恨不得上午提的下午就能搞好，今天提的明天就能實現，若二、三天還沒有動靜就會打電話來催你了，一周沒有動靜就投訴到領導那了，多幾次不回復，臨床就不愿意再提需求了。

解決這個問題其實很簡單，主要是溝通不到位。一是要告知按正規流程提需求，微信上的圖文語音一律不算；二是在接收確認需求時，請告知他一個開發大概完成的時間，若條件允許最好邀請他來參與測試，最后再告訴他軟件版本發布的時間。

需求很多時，讓他們挑出自認為最緊急重要的需求排個順序，先做二、三個，就像在飯館吃飯，先上兩個菜客人就不會老催了。

同一個功能模塊，可能有不同部門提出多個修改需求，最好統一在一次完成，做好綜合研判，減少重復修改。即便時間上有所耽誤，但總的時間和出錯機率會大大減少。

常規情況下，數據出錯性的需求最好插隊安排在下一個版本就修改好，邏輯性錯誤可以通過行政命令先人為避免，后繼盡快完善。獨立明確的需求，與其他模塊交互不多，可以優先安排。臨床特別關注的、影響使用體驗的需求，可以優先安排。

醫保和主管部門政策性需求，往往來得急、有明確的完成時間節點，是最強需求，其他需求都要暫時讓步。所以我們在安排其他需求時，要適當預留出一定時間，實在做不完時，要做好解釋工作。

我院HIS項目自2020年2月進場實施，截止到2021年9月底即國慶前。約2500個有效需求緊快趕慢，終于全部清空，我一直緊繃的弦終于放松下來，雖然后面一直有新的需求產生，但已非重要緊急或者我們已有余力很快完成。這種心理的放松是妙不可言的，每天都睡得比較踏實了。

緊快趕慢，綜合研判，時間預留，進度公告。目前我們沒有在院內部署一套需求修改進度查詢的系統，建議有條件的醫院可以開放這個功能，可以減少很多誤會，可以提升臨床人員的參與感和獲得感。

未完待續

作者簡介

郭揚帆，軟件工程碩士，高級工程師，南方醫科大學順德醫院信息科主任。廣東省首席信息官協會醫療分會副會長，廣東省衛生經濟學會信息分會副會長，廣東省醫療信息安全專業委員會副主委，順德醫學會醫學信息學分會主委等。主編著作二部《醫療衛生信息化項目管理實務》、《醫院網絡安全建設指引》，擔任多部著作編委。1997年從事醫院信息化工作，先后經歷過多次甲方、乙方角色換位，積累了豐富的項目管理經驗。