醫學資訊化領域的軟體工程

軟體工程從來就不是一門精細的學問，在我看來，在沒有弄清楚人類思維的核心規律之前，任何力求精確的模型/度量/計算都是徒勞的。再加上一些管理者不斷地拿一些現成的過程和方法來進行換湯不換藥的概念翻新，比如一下一個6西格瑪，一下一個Lean，使得本來很多確實成效不錯的過程和方法淪落成為玩弄技術管理的工具，甚至企業管理的政治口號。最終，使得很多技術牛人對軟體工程這個領域嗤之以鼻。確實，沒有任何兩個軟體開發，可以用完全相同的方法學取得成功。然而，當一部分技術牛人的興趣，從機器的運行規律遷移到人腦以及人類組織的運行規律上面來的時候，他們才驚奇地發現原來它們是如此的相似：整個世界就是一部電腦，而我們每個人都是其中的一個計算單元。而軟體工程領域所有的這些不確定性，也從他們厭惡的對象轉化為一種激動人心的挑戰。

讓我們去偽存真，從一個實踐者的角度來體驗和找尋適合我們自己的工程方法。因為我們相信，同一件事情，你可以用很多種方法來做，但只有少數幾種方法能夠讓你獲得成功。

最近醫學資訊理論壇上的討論，又讓我得以重新審視一下一些工程方法在這個領域的應用。於是乾脆把自己的兩篇文章轉寄過來，一個是關於需求開發，一個是關於組態管理，留備後用。

在我看來，在軟體工程過程體系的這麼多繁文縟節背後，或者至少在實際操作層面，對最終項目的成功發布真正起到決定性作用的只有兩個：一個是需求管理，一個是組態管理（包括變更和發行管理在內）。它們分別是項目的一進一出，把好這兩道關，其他的東西，不管是分工，進度，風險控制等等，都可以順勢衍生出來。

--

對於需求人員來說，最忌諱兩種做法，一種是“傳聲筒”，一種是“捏造需求”。因此，要做好使用者和技術人員的橋樑，需求人員除了具備一定的溝通技巧之外，還需要：

1、深知溝通過程的基本原理，以及常見的溝通陷阱。
2、基本的需求分析（即對原始需求進行正確的提煉和整理）的技能。

關於第一點，玩過多人傳話之類遊戲的人應該都比較瞭解。而關於第二點，則需要具備一些工程知識和技能。

舉個例子，很多醫院流程裡面都有三查三對，有些還是三查七對。但有些新手設計的使用者介面，如果沒有注意這一點，經常會把一些重要訊息（比如病人姓名、性別、年齡）顯示得不夠顯眼。於是醫生提出，你這個字型能不能大一點，這個屬於一個原始的客戶需求。一般醫生忙起來也不會跟你說得很細，或者最多跟你說姓名、年齡要大一點（可能因為他是婦科醫生，一般來的都是婦女，也不用關心性別了）。於是，“傳聲筒”型的需求人員就會原樣告訴技術人員，讓他們把姓名、年齡搞大。哪天輪到另外一個科室要上這個系統了，又來了一個需求，叫做把性別搞大。然後開發人員又要改，測試和變更管理等相關人員又要就類似的問題再檢查和跟蹤一遍。或者，其中有一個人提出，乾脆把整個介面的字型都搞大點好了，省得每次都改。可能因為這個人在某些方面比較資深，或者比較能說會道比較有感染力，或者在職務上本身就有一定的影響力，而剛好這個醫院的老醫生比較多，一些人可能認為這些醫生本來電腦操作就不熟練，眼睛又不好使，所以也同意了把整個介面的字型搞大。甚至，還有人提出，乾脆把整個介面的字型做成可配置的，聽起來也不錯，卻沒想到這又增加了測試、實施和維護工作的複雜度。最後，系統一升級，醫生嚇了一跳，怎麼整個介面的字型都變大了。有些得過且過的醫生倒也不再提了，越改越不像樣，反正我要看的那些資訊，我湊近螢幕仔細找找就好了。這就是一個典型的“捏造需求”案例。

從這個例子可以看出，“傳聲筒”相對還好一些，最多會讓類似的需求反覆提反覆改（甚至還會出現一些前後矛盾的需求，比如改過來又改過去），成本增加一些，需求變更的收斂速率低一點而已；最可怕的是“捏造需求”，而且在小型項目裡面，大多是專案經理充當需求人員的角色，他一旦對需求判斷錯誤，對項目產生的後果將不堪設想。

以前曾經看到過一個診所預約系統，由於前期需求不充分但客戶又急要一個技術方案，在制定一些具體技術規格的時候，專案經理為了能做出一些亮點，提出讓預約者直接看到被預約資源的使用方式，以便提高預約申請的通過率。如果是在辦公樓裡面，預訂會議室，這是個很好的辦法，但在醫學行業是完全行不通的，這違反了病人、護士/接待員和醫生的基本生產關係。幸運的是，在最終方案出台之前，經過多方努力，終於修正了這個想法。要不然，就算你好不容易把第一個版本的原型做出來了，拿給使用者提意見，使用者一看你就不懂醫學，別的也懶得跟你談了。

實際項目中的這些問題，用軟體工程的理論進行解釋，就是缺少對於業務需求的把握。

軟體工程裡面雖然各家表述不盡相同，但一般都會提到幾種需求：使用者需求、業務需求、系統需求（包括硬體需求和軟體需求）。這些需求，不管你是做項目還是做產品，都會用到。其中最關鍵的是業務需求，它的一個通俗說法，就是行業經驗。當然，能稱為業務需求的行業經驗一般都是抽象化、模型化並且可以分享的。因此，這樣的業務需求就成為了所有需求變更所圍繞的一個核心。從使用者要達到的最終營運目標的角度，業務需求就是審查每一項需求變更是否合理的一根準繩。

因此，基於業務需求來分析和評估原始的使用者需求，基於業務需求把原始需求提煉和整理成技術人員可以使用的系統需求，將會大大降低需求變更的頻率和控制的難度。當然，並不要求所有的需求人員都具備這樣的需求分析能力，但至少在需求小組裡面需要具備這樣工程知識和技能的人，才能產出高品質的需求，從而產出高品質的產品。

--

1、為什麼需要組態管理

在醫學資訊化項目中，也許會出現這樣的一些問題。有時，之前剛剛修改過的軟體缺陷，或者前不久已經實現了的客戶化需求，在最新版本裡竟然消失了。有時，面對好幾個科室甚至好幾家醫院同時提出的問題，需求人員和開發人員忙得不亦樂乎，但一些關鍵的問題卻石沉大海，客戶一直得不到回複。有時，發現一個共性的問題，需要大規模地升級系統，但由於各個科室安裝的工作站太多，每個科室可能還有一些特殊的使用者佈建或者客戶化補丁，到底哪些工作站適合升級，以及如何升級，才既能修複問題，又不影響系統穩定運行？有時，為了實現資訊整合以及更加順暢的工作流程，需要對某個已經上線啟動並執行系統進行修改，但是負責開發這個系統的程式員已經離職，負責維護這個系統的開發人員又找不到當時的代碼，或者在磁碟備份上好不容易找到了某個版本的代碼，卻無法編譯。所有這些問題，都跟組態管理有關。

很多人會覺得組態管理的工作很虛。在專案經理看來，組態管理無非是管好各種文檔，以及記錄一下將要發布的版本；在開發人員看來，組態管理無非是每天例行的簽入簽出，以及週期性整合和構建；在實施人員看來，組態管理無非是記錄和報告各種伺服器和工作站的硬體設定和軟體安裝情況，不厭其煩，又枯燥無味。

的確，組態管理並不能像編寫程式那樣給項目帶來直接的價值，但它最重要的意義之一在於讓包括編寫程式在內的各種原本不可見的工作任務可視化（用組態管理的術語，我們叫做配置項識別），這種可視化正是團隊溝通協作，以及項目品質、風險，進度和成本控制，甚至包括量化審計的基礎。正是組態管理所包含的這些看似簡單和重複的工作，卻為項目的順利運行提供了堅實的保障。

2、什麼是組態管理

組態管理的主要任務是對項目中不斷變化的各種工作產品進行記錄、控制和報告——這些工作產品可能包括需求和設計文檔、每一台伺服器和工作站、甚至細到每一個代碼檔案、以及記錄使用者操作喜好的個人化檔案——其目的是確保這些工作產品之間的關聯一致性和品質完整性。對於整個項目周期來說，組態管理是一個重要的支援性工作，它是項目走向精細管理的必經之路。

傳統意義上的組態管理，包括配置項識別、變更控制、組態狀態報告和配置審計幾大部分。在一些理論模型[ITIL]中，組態管理可能會跟變更管理、發行管理分開進行描述。但他們之間是密切相關的：變更的評估必須在組態管理相關的狀態監控活動，以及涉及多方協作的流程式控制制之內進行，而變更的實施一般也是通過發行管理活動來執行的。因此，這裡的討論範圍是包括了變更控制和發行管理在內的完整的組態管理。

當然，在具體的項目實踐中，不同的醫學資訊系統供應商，或者不同醫學機構中的IT服務部門，對組態管理工作內容的定義都略有不同。他們通常在傳統的組態管理基礎上，增加了組態管理工具的應用、維護、培訓和支援，軟體的整合、構建和版本發布，甚至包括製作軟體自動安裝包等工作內容。

3、如何做組態管理

在一些人的印象中，實施組態管理，就意味著某些文檔必須按照指定的格式來寫，某些代碼必須在指定的時間和地點（目錄）上籤入簽出。原來開發人員發現代碼中的一些技術性的小問題，可能馬上就動手修改，現在卻要經過層層審批。原來需求人員聽到客戶的一個抱怨，可以直接把怨氣泄到技術人員頭上，責令他們趕緊修改，現在不僅要討論來討論去，還要在各種文檔上進行繁瑣的記錄，甚至還要郵件通知一些以前認為似乎沒有必要告知的那些人。難道組態管理真的就是這種繁瑣枯燥，既增加項目成本，又拖長客戶回應時間，還讓人覺得礙手礙腳的過程累贅嗎？

其實，資訊化項目比傳統的工程領域項目更加容易失敗的原因之一，就在於很多資訊化的工作產品的不可見度。比如，如果是某個機械零件長了或者短了幾個毫米，不管是工程師還是管理者都能肉眼直觀看到。但如果是在設計資料庫的時候遺漏了一個外鍵約束，或者是不小心使用了另外一個版本的編譯器，使得同一段代碼編譯出來的程式略有不同，有時可能難以覺察（除非是專業的測試工程師，利用精心設計的用例，經過相當長一段時間的測試）。為了化解這些風險並防範於未然，IT工程師和管理者們必須使用一些過程和方法來保證這些零組件在整合起來的時候能夠正常工作，並且滿足客戶需求。組態管理就是這些過程和方法中非常基礎又十分重要的一個。

因此，組態管理並不是空穴來風，只是我們由於每天都在使用它，所以漸漸淡忘了而已。比如我們經常使用的“版本”這個詞，就來自於組態管理，它是識別配置項變化的重要工具。又如我們常常談到的“需求變更”。其實任何變更都是發生在一個基準基礎上的變化，沒有基準，變更根本無從談起，而這個基準就是組態管理需要特別關注的“基準”。

當然，所有的組態管理方法得以實施的前提是高層的理解和支援。因此在資訊化項目中，主要負責溝通的專案經理，有責任讓你的領導，客戶，以及團隊的所有成員，理解相關的組態管理理念、策略、流程和工具，這是組態管理以及其他相關工作得以開展的必要前提。

4、誰來做組態管理

在很多理論模型[RUP]中，都有一個組態管理員或者組態管理工程師的角色。因此，很多人會習慣性的認為項目中組態管理的工作都應該由這個角色來完成。同時，組態管理的工作本身看起來確實沒有開發或者測試工作那樣有技術含量，所以這個角色常常由一些年輕的工程師擔當。另外，Team Dev一般總是聚在一起，比較好管理，實施團隊則是經常出差，在客戶現場安裝硬體和軟體，並進行必要的客戶化設定，所以組態管理就先在Team Dev裡面做起來，保證發布給實施團隊的版本沒問題就行了。以上這些錯誤的決策，常常會導致組態管理的失效，並最終讓項目陷入混亂。

筆者認為，在Team Dev中，組態管理工程師必須具備以下幾種素質。一、編程經驗，知道軟體是怎麼一步步開發出來的，這是不可迴避的基礎；二、對開發方法進行反思的習慣，以及系統思考能力，這是組態管理的基本素養；三、瞭解組態管理工具的使用和維護，並為項目提供支援，這點可以通過學習來實現。對於職責跨越Team Dev和實施團隊的組態管理，還需要瞭解實施團隊的工作方式。當然，對流程進行系統思考的能力，始終是為團隊制訂和最佳化組態管理策略，協助團隊提升工作效率、服務品質和客戶滿意度的核心能力。這些，都不是一個新人能夠輕易做到的，但如果讓一個資深工程師或者專案經理去兼職做這些工作，又會讓人覺得有點成本太高。但有時，特別在小型團隊中，這點成本是值得的。

其實，在眾多不成熟的小型團隊中實施組態管理的一個關鍵，在於向大家灌輸一個觀念：即組態管理不是組態管理員一個人的事，而是需要整個團隊共同參與。組態管理也不僅是一種管理方法和流程，更是一種工作習慣。這種習慣要求每個人工作的時候，都要考慮到不同成員之間工作產品的相關一致性和完整性，都要考慮到自己的工作是否會影響團隊最終交付的產品或者服務的整體品質。因此，養成這種習慣，無論對於一個團隊還是對於個人開發人員，都將受益匪淺。筆者認為，這也是把作坊式團隊打造成正規工程團隊的一個很好的切入點。