編輯導語：隨著互聯網技術的普及和不斷發展，互聯網醫療也走進越來越多人的生活，本篇文章作者從產品經理的角度出發，詳細地講述了如何從單純的醫療業務去逆推未來的產品架構，干貨滿滿，一起來學習一下。

這次文章里將會講到如何從單純的業務去逆推未來的產品架構，再從單業務線延伸的方向可以是SaaS、PaaS、業務中臺等。

從互聯網醫療領域最簡單的預約掛號功能的設計開始，所有是復雜的功能合集都是由簡單的產品組成的。

掌握了核心的底層邏輯，未來大部分產品迭代將會有比較穩定的思路。

在之前這些工作也會做，是自然而然就能夠產出的，一直沒概念。

問了行業里的一些產品專家，他們說是這是產品架構師做的事，好吧，如何成為一名產品架構。

一、預約掛號功能的分析和設計

1. 常規的一般就醫流程

掛號是常規到院看病治療的一般流程，大部分常規門診都是這樣的。

在以往去醫院看病的流程，基本是從掛號開始的，患者掛完號最后，到醫院進行進行取號——簽到——候診——叫號流程。

最終在各科室的門診室里，醫生進行診療。

即使，當日有檢查檢驗，也是基于醫生門診診斷后開的單。

當然，急診、急救會有所不一樣，這里不做過多的描述。

掛號是去醫院看病就醫的一切行為的開始，到醫院看病從掛號開始，患者到醫院掛號后才能就醫。

互聯網醫療從掛號開始，然后才能到醫院取號，門診后，醫生將會做出診斷，才會知道后續要去做什么。

2. 預約掛號功能的定位

掛號功能是互聯網診療業務的開始，掛號行為也是患者在實體醫院就醫的開始。

國家衛健委對掛號的功能及范圍作了詳細規定，并且在互聯網醫療平臺、互聯網醫院不斷發展的過程中不斷完善政策扶持。

1）對于實體醫院

掛號對于實體醫院的定位是醫療綜合業務的開始、基礎收入之一、流量入口。

醫院并不會過于關注掛號費用，而是關注掛號后到院就醫的門診量。

醫院的門診量基本上相對固定的，大型三甲醫院的年門診量一般在100-200萬左右。

符合國家智慧醫院的建設方向，是公立實體醫院建設互聯網醫院的核心標準功能之一。

2）對于互聯網診療平臺

對于互聯網診療平臺（微醫、微脈、好大夫等）來說，是流量入口，因為掛號收入全部是醫院的，并不能從里面獲取任何的收益。

相對于互聯網營銷、廣告等，掛號功能對于互聯網診療平臺來說，就是用戶剛需的功能。

并且其實投入成本相對有限，和醫院進行掛號對應系統的1對1的對接，后期負責維護及跟進問題。

但是能夠帶來流量，用戶一定的粘性，獲取用戶的就醫部分數據進行分析，有利于未來對用戶在藥品、在線咨詢、服務包等方面進行推薦。

3）掛號的其他理解及樣板

互聯網醫療領域，掛號已然完全和互聯網診療平臺、互聯網醫院、區域衛健委主導的健康管理平臺（政府自建和聚合）完全融合在一起，是最基礎的功能之一。

互聯網醫療行業的早期，是從掛號展開的商業模式，以互聯網的思維獲取流量，然后再疊加其他的業務和流量。

但是，最后互聯網思維，并未完全在這里展現。

因為醫療場景的特殊性，更像是一種便捷工具，而且是企業基本沒有任何機會抽取掛號費用的費率。

因為國家政策規定的所有費用都是直接到醫院的，因此掛號功能的定位就很清晰，引流→轉化其他商業模式，在線咨詢、賣藥、賣保險、保健等業務模式。

微醫的發展基本符合以上邏輯，最早成立于2010年。

曾經就叫掛號網，以解決患者掛號難問題起家，是互聯網醫療領域的探索者，于2015年獲得3.94億美元融資后改名微醫。

微醫于2015年創建了全國首家互聯網醫院——烏鎮互聯網醫院，開創了中國在線診療、處方流轉、醫保在線支付等新業態，習近平總書記在第二屆世界互聯網大會主旨演講中稱為“中國互聯網創新發展的縮影”。

核心業務覆蓋醫療、醫藥、醫檢、健保等領域，是行業內唯一覆蓋“互聯網+醫療健康”全產業鏈的數字健康平臺。

3. 預約掛號的角色及基礎設計

國家對掛號功能技術標準做了官方的定義及背書。

中華人民共和國衛生行業標準WS/T 790.15-2021號文件《區域衛生信息平臺交互標準 第 15 部分：預約掛號服務》里，預約掛號服務角色定義如下：

• 預約掛號服務（RRS）：提供預約排班信息管理、預約管理服務。包括預約排班信息提交、預約排班信息更新、預約排班信息刪除、預約排班信息查詢、預約申請、預約取消、預約查詢、預約排班信息訂閱，向預約排班信息提供者發送預約申請通知、預約取消通知，向預約申請者發送預約排班信息更新通知、預約排班信息刪除通知；
• 預約排班信息訂閱者（SISub）：為預約排班信息提供者及預約申請者訂閱通知；
• 預約排班信息提供者（SIP）：提供預約排班信息，向預約掛號服務提交、更新、刪除預約排班信息，接收預約申請通知、預約取消通知；
• 預約申請者（RA）：查詢預約排班信息，申請、取消、查詢預約，接收預約排班信息更新通知、預約排班信息刪除通知。

4. 預約掛號功能里的角色

用一張圖可以完整地表達預約掛號功能里的角色。

患者是標準文件里定義的預約申請者，可以預約掛號。

醫生是服務提供者。

管理人員是信息提供者，為醫生排班，并且制定號源等患者掛號后到醫院取號后，掛號流程結束。

簽到——候診——門診等屬于門診行為。

國家衛健委在2021年11月08日發布的WS/T 790.15-2021號文件《區域衛生信息平臺交互標準 第 15 部分：預約掛號服務》文件里，說明了預約掛號的角色官方標準定義。

患者在里面的角色是預約申請者，醫生是預約掛號服務的服務提供者，醫院管理人員是預約排班信息提供者在業務里共同組成了掛號的業務。

在互聯網醫院、互聯網診療平臺里更多的只涉及到患者、調取醫院對應醫生、醫院、號源等信息來完成功能。

這些數據并不是憑空產生的，而是已經在運行很多年的。

5. 預約掛號的業務模式

醫生的掛號收費標準都是由衛健委統一制定的標準，醫院收費時不得擅自修改。

并且任何第三方的平臺不得從公立醫院的掛號費用之中提取任何傭金，相當于省平臺、互聯網診療平臺里的預約掛號功能。

所有的錢都是直接打到醫院的對公賬戶里的，第三方平臺將會無任何收益。

所以，即使阿里健康、微醫、微脈、好大夫每日掛號單量超過十萬，掛號費用收益也和他們沒有任何關系。

只獲取了用戶流量，并且是依托于實體醫院線下醫療服務的流量。

患者在醫院的APP/小程序/微信公眾號上預約掛號，下單后訂單返向互聯網醫院/在線診療平臺。

系統將訂單反饋給醫生，醫生在診室坐診，到了預約當日患者到達醫院，完成取號——簽到——候診——叫號后到達門診室，由醫生接診。

并在這個過程中提供高度專業的醫療服務（診斷治療、健康咨詢、用藥咨詢等），醫生開醫囑、治療、開單后，門診流程結束。

這項功能的業務管理一般在醫院的HIS的醫生管理后臺，負責叫號、接診、診結、開醫囑、開藥、開檢查檢驗單等。

一般醫院都是有這樣的管理后臺的，基本不需要企業來進行開發。

如果有在2022年的現在有企業需要做這個功能，那基本上是HIS重構迭代、醫院綜合管理系統或者門診系統重構等項目。

除此之外關于醫生端的醫生管理后臺，是完全不需要考慮的。

因此，掛號功能的后臺，基本上只會設置排班、業務開啟關閉、訂單查看、訂單數據統計等功能，并不會很復雜。

6. 預約掛號的流程

預約掛號的流程并不復雜，從開始掛號到下單，需要選擇醫院、科室、醫生、號源后，就可以下單了。

但是一般情況下，必須綁定就診人，錄入姓名、身份證、手機號碼，同時會在該院生成病案號，這樣才能在醫院下單，這是國家規定掛號必須實名制。

掛號成功后，患者在預約的日期——時間到醫院進行取號，然后候診治療。

在這中間綁定就診人流程的處理，常規是放在下單前的頁面，或者在一開始選擇掛號功能時就需要綁定或選擇。

一些特殊的情況：

1. 在醫院看來預約掛號、當日掛號定義會不一致，預約（預約號源）指的是提前選擇號源并且下單，并不一定需要支付；掛號（當日掛號），指的是選擇當日號源，一般是需要支付的，并且只能到醫院的繳費窗口進行取消；
2. 預約掛號，一般在掛號日當日0:00前可以取消，超過了以后只能到醫院窗口處??；當日掛號，掛的是當日的號源，掛號后不能取消；
3. 醫院的科室并不一定和國家標準科室匹配，可能科室、門診制定并不會標準；
4. 支付預約費用的情況，在各家醫院的情況不一致；
5. 互聯網診療平臺的掛號，是設計產品流程后，調用醫院或者政府的統一掛號接口，來實現掛號功能，本質上來說是從醫院HIS里調取接口，下單后再向醫院傳輸數據；
6. 如果當日未能到院就醫，并且訂單沒有取消，則會被記錄到醫院的黑名單，一般情況來說，如果在幾個月內超過3次違約，那就會在一段時間內無法到達該醫院就醫。

7. 預約掛號的界面

掛號的界面里，設計并不復雜。

選擇科室的頁面要素是一級科室、二級科室（一般是門診），選擇醫生頁面（常規是選擇日期和醫生），選擇號源（頁面內有醫生信息和號源）。

只要在產品設計時考慮這些要素，掛號功能就可以能夠較好地設計了。

二、拆解和重組——構建產品萬能公式

如果作為一名產品經理，將針對一家醫院的定制化內容轉化為最有利于企業發展的核心架構？

由掛號衍生的醫療平臺的業務中臺思考，當醫院越來越多時，絕對不能是簡單的進行好處理，而是需要一個架構，來讓所有的內容標準化。

然后才能快速接入到各家醫院的業務。

憑心來說，這樣的平臺可以是衛健委管轄下的區域醫療聚合的平臺，也可以是以互聯網掛號、在線咨詢、體檢預約、?？品战Y合的在線診療平臺。

同時也可以聚合處方外流等內容和業務，醫院實際經營和平臺之間會存在較大的問題：

每一家醫院都有結合著醫院內部業務的功能——在線問診、開藥、檢查檢驗預約、查報告等。

如何才能更好地實施呢？微醫、微脈、阿里健康、平安好醫生、好大夫等，是如何處理多家醫院的預約掛號功能的呢？

業務和醫院關聯度較高的其他產品，在線咨詢、診后隨訪、體檢、檢查檢驗預約等功能，又是如何處理的呢？

1. 我的底層思維邏輯本能——拆解和重組

在我的眼里，世界上所有的事情都是簡單——復雜——簡單，將簡單的事情歸納總結，逐漸成為復雜的體系，再從標準復雜的體系里，從不同的視野看待重組簡單的事。

復雜——簡單——復雜，將復雜的事情格局各類要素拆解為核心簡單的事情，再把簡單的事情按照合適的框架、邏輯、模型組合成復雜的事。

這是我的本能之一，所以很多事務的難度，都是相對的，在這樣的思維邏輯本能下，沒有太多的秘密可言，難度也是可以從地獄級拆成無數個可控難度逐一處理。

而后，其他的，思維邏輯、運營能力、產品能力、商業思維、軟性知識廣度等都只是技能工具，只為實現想要拆解重組一件事服務。

1）簡單——復雜——簡單

這里的簡單指的是有多種簡單的概念混雜，雖然因素很多，但是單一因素是極為簡單容易理解的。

簡單到復雜的過程，指的是提煉這些簡單事務之間的相似內容，并且根據產品設計框架、商業分析、咨詢分析等框架下進行內容擴展。

復雜——簡單，將擴容后有序的完整內容，再次壓縮至可以用一句話進行描述，用一個最簡單的結構描述這些最初最簡單的事務。

2）復雜——簡單——復雜

復雜指的是多項無序、混合、復雜的事務，可以是業務邏輯，也可以是跨企業、多部門、多角色、多目標方向上帶來的目的極度復雜。

復雜——簡單，將復雜的事務之間，總結歸類最終歸納為簡單的可被理解事務。

簡單——復雜，將整理出來簡單的事務重組，按照對應需求使用合適的框架結構，重新將事務建設為所需要的、有序的、可被理解的內容。

3）嚴謹科學的實驗方法論

當任何事務經歷過拆解和重組之后，將類似的內容合在一起，提煉事物之間的規律，最終將會獲取到對已有和未知內容的底層思考和理解。

再代入一定的模型框架里去，最終就合成了任何想要的東西，這是一種非常嚴謹的科學實驗法方法。

而產品設計同樣如此，下面的方法其實挺科學的，將產品設計看作公式，而這個公式可以是化學公式、技術UML邏輯框架下的公式。

2. 互聯網醫療產品萬能公式

任何事務都是有規律的，即使是永遠在做不規則分子運動的單個分子個體。

當他們聚集足夠多的數量時，不同分子為主導的物體也會表現為肉眼可見穩定的物質（水、鐵、石頭、塑料等）。

氫氣和氧氣在燃燒的條件下生成水并產生熱量，醫生和患者在醫療行為的條件下，最終組合成為了一些功能，實際他們的在本質上是不一樣的。

但是可以將其想象成為化學反應公式，并且不僅僅是醫療領域，仔細思考也適用于其他大部分功能的設計。

醫療產品設計方程式：有某種醫療需求的患者攜帶著一些信息，和醫生在線上、診室發生了反應。

有一些醫療行為和醫療器械催化下發生了反應，最后標準化的數據、流程、行為就是所需要的功能。

產品意義上的場景是，醫療行為+醫療器械，在公式里可以視為催化劑，沒有了醫療行為和醫療器械，對應的流程將不會發生。

從某些維度上來說，氫氣和氧氣攜帶著很多H?分子和O?分子，和醫生的基礎屬性+患者基礎屬性。

最終在掛號的業務流程下，最終構成了掛號功能在某些邏輯上是能夠尋找到一致性的。

舉例，圖文咨詢：患者（基本信息、病情描述等），向某醫院婦科專家付費咨詢婦科疾病，醫生在線接診，在醫院系統里調取患者門診、住院電子病歷了解患者疾病信息，和患者進一步溝通后，下達咨詢建議幫助患者。

3. 產品公式在掛號功能里的實際使用

在掛號功能里，患者在下訂單時，預約了醫院的醫生，訂單產生時攜帶了患者基礎屬性、醫生的基礎屬性、號源信息等構成了這一個掛號的訂單。

那就可以理解為攜帶患者相關的字段、醫生字段、號源字段在患者選擇了號源下單了（醫療行為），構成了這一次的掛號流程。

其實，這種思維在技術視角挺常見的，因為在技術眼里，角色之間在一定的行為和流程下產生了業務數據，訂單狀態會隨著角色行為發生變化，最終形成了一個功能。

1. 患者的基礎屬性：姓名、年齡、身份證號、病案號。
2. 醫生的基礎屬性：姓名、性別、職稱、科室、醫院。
3. 醫療行為：掛號是由患者預約醫生的門診服務，在線上下單后，在預約的到院日期到達醫院后，取號就診的醫療行為。
4. 醫療器械：取號機、簽到機、叫號機等會在這一流程產生影響；一般來說，掛號的功能，掛號成功之后，到院取號之后，掛號功能的流程就結束了。
5. 掛號到院取號之后的簽到——候診——叫號——門診等行為是到醫院后的門診流程。

4. 產品架構設計——更深層次的邏輯延伸

在作為一名產品經理時，根據公司業務需求，梳理業務邏輯、產品市場分析、用戶分析等。

將無序、未知、未被驗證的內容整理為已知及其可見的思維路徑、業務流程、界面設計、決策模型等。

當思考足夠深入，知識寬度足夠廣，綜合技能足夠全面，視野、邏輯、格局、業務理解足夠深度時，自然而然地將能夠設計產品時糅合在公司未來發展戰略中。

或者從未來可能方向中發掘有利于未來發展的功能。

很多時候會好奇，前端如何實現頁面交互邏輯的，后端研發是如何實現技術邏輯的，如何存儲數據？

剛成為產品經理的時候，由于多年做運營的經驗，淺薄的認為，大部分移動端的業務流程，都是已經有了業務模式的前提下，前端帶著字段、數據、規則向后端傳輸和調取數據。

本質上來說，最初很多概念就在大腦框架中，就已經存在了技術范圍、實現機制框架，只是沒有系統的去整理。

產品的底層邏輯就是角色數據+屬性數據+業務流程=功能，角色會有基礎數據字段，業務相關的內容也會有基礎數據字段。

在符合該項業務流程里不同角色的行為們構成了業務流程，最終就形成了一個完整的功能。

三、產品架構設計——以預約掛號功能為例

1. 一般互聯網醫院數據調用方法

通過項目經歷，多次和研發交流，看各種類型的接口文檔，看其他互聯網醫院的接口文檔，也看了有贊、微信等的接口文檔。

同時和不少醫療產品經理的交流，發現互聯網醫院的調用在技術上就是：

• 入參：帶著數據調用；
• 出參：調取數據。

這一類的調用方式，和做G端政府項目、B端少部分項目時是一樣的。

通過調取他們已經完成標準封裝的接口獲取數據，然后再完成對應的功能開發。

還有一種場景大家可能很少想到的，阿里巴巴、騰訊等作為總包，設計好了大型的中臺體系。

對內對外將復雜繁雜的業務相關的研發內容外包，由內外部團隊去進行某些業務開發時，這些團隊在做數據調用時也和這個類似。

2. 單業務線的標準接口合集

當熟悉了掛號的業務功能之后，就知道需要讓這一項業務推送起來需要獲取到醫院的哪一些數據。

在什么時候什么條件下去獲取能夠滿足業務的正常進行，這就是調用規則和方法。

那這時候，就可以把這些所需要的使用到的數據，內部進行一個標準的封裝，作為數據接收器。

這樣外部不同醫院主體不同的混亂數據和流程將無法影響到內部的業務流程，并且能夠極大地提升部署速度、工作效率，降低工作難度。

1. 標準接口（內部）：滿足這項業務流程時，所需要的數據合集，封裝為公司內部定義的標準流程的接口；
2. 標準數據（外部）：經接口轉換器將不同醫院的掛號數據不同命名方式、狀態變化方式，最終轉化為的符合標準接口（內部）能夠完成業務流程的數據；
3. 調用方法（預約掛號）：1——在用戶點擊掛號功能后，調用醫院科室——門診等信息；2——用戶選擇科室時，會展示對應門診；3——用戶選擇門診后，調用未來7日門診下坐診醫生的號源信息，并且進行展示；4——選擇對應日期，展示號源滿足該日期坐診醫生；5——選擇醫生后，調取對應醫生的號源，選擇對應日期——上下午號源后，調取當日——上午或下午的可選擇號源；6——選擇號源后，跳轉確定頁面，確定后在醫院HIS下單，并返回下單是否成功狀態；7——下單成功后，自動推送或調用獲取到該狀態；8——用戶取號、取消掛號、違約等流程結束，號源釋放回醫院號源池；
4. 接口轉換器：當用戶行為發生變化時，從標準接口的數據中，向醫院數據庫里發起符合掛號業務流程掛號方法1-8流程的數據請求，然后返回到標準數據庫（外部）→標準數據庫（內部），最終完成業務流程；
5. 單業務線的標準接口合集：多家醫院接入時，工作將會變得簡單；并且是經歷過轉換后的數據是互通的。

3. 對外業務中臺概念（偽）——標準接口合集

當標準接口完成封裝，從掛號衍生到其他功能時，將前面的步驟重復，多個符合互聯網醫院業務的單業務線標準接口合集組合。

外部使用不同的接口轉換器的調用方法實現標準數據傳輸，實現功能的標準化，自然而然地形成了對外業務中臺概念（偽）——標準接口合集。

能夠降低接入醫院帶來的額外定制化研發的工期，有利于未來真正醫療業務中臺研發，不同業務線的相互干擾較少。

4. 構建單業務的產品架構

四步走的核心在于前三步，第四步只是重復性的工作，基本工作思路差不多，具體實際去執行的技術細節差別非常大。

梳理業務流程是第一步，然后是將產品功能設計出來，再到標準接口封裝（內部），將外部醫院的不標準數據，轉化為標準數據（外部）來實現產品功能。

5. 產品架構設計——互聯網醫療對外業務中臺（偽）的產品架構

這是一個省時又省力的產品架構路徑，五個步驟就可以完成基礎框架設計，并且符合技術研發的路徑。

而且可以把較大的工程量逐漸拆的瑣碎，后期也方便設計產品計劃、項目計劃、研發計劃。

這將會是一個浩大的工程量，從內部接口的預封裝，到單一業務處理，最終到統一接口/數據/業務管理。

產品架構的整體的實現難度會很大，但是目前也有一些企業處理的很好，經典產品處理案例：微醫、微脈、阿里健康、平安好醫生、好大夫等。

業務和醫院關聯度較高的產品，處理掛號、在線咨詢、診后隨訪、體檢、檢查檢驗預約等功能。

相信他們在做這些功能的時候，都是按照五步走的思路設計的產品架構。

不然很難說能夠短期快速地接入100家、1000家、1000家甚至是幾萬家的醫院，十幾萬的醫生，還能保持業務的標準化，和快速接入。

1. Step 1——預封裝；
2. Step 2——單一業務處理；
3. Step 3——n項業務接口封裝；
4. Step 4——n定制化研發（醫院+業務）；
5. Step 5——統一接口/數據/業務管理。

四、UML和產品架構

照葫蘆畫瓢去設計功能是初級產品助理應該去做的事，產品專家應當是去理解更深層級的理解。

甚至能夠基于理解去設計產品架構，以全局視野去匹配公司技術路徑、業務路徑、未來發展。

有了一個良好的產品架構，能夠讓產品經理為主導的團隊里，設計、技術等在混亂不堪的公司方向里。

有一個清晰的未來方向，并且可以在設計具備了之前思維的情況下，再回過頭看到UML知識的內容，才會深刻理解這樣的思維方式，是符合技術的一些思考、表達方式的。

然后，再把自己的理解，逆向推導及代入到UML的框架里做映照。

1. 關聯的知識1——結構型的UML

在技術的視角下，大部分研發的基礎是，分析產品設計完成業務類圖、Person類圖，以便建立對應數據表單。

最終根據業務模型，實現數據在不同行為流程里的調用。

技術實現邏輯是預約掛號——單業務線的標準接口合集——調用方法描述，將產品流程里的規則變化使用代碼編寫為規則，最終能夠實現產品功能的代碼合集，就是調用方法。

所有功能的技術實現都是可以進行分割的，只有在特定的場景下，孤立對象之間進行了某些信息交互才表現出我們所看到的那樣一個過程。

UML是描繪計算機語言實現產品功能邏輯的一個工具，本質上去認知業務流程，UML能夠面向對象的分析設計方法。

用不太恰當的話來說，屬性類圖、Person類圖轉換為了數據庫表單，構件圖、部署圖凝練為了接口、技術架構、規范或中間件。

2. 關聯的知識2——行為型的UML

技術研發，特別是后端在做開發時，大概率會使用到以下的行為型UML邏輯。

但是大部分時候產品經理使用較多的是流程圖、用例圖，其他的并不一定了解，很多時候，涉及的行為型UML概念相對抽象。

1. 活動圖：多個活動和行為之間的順序流程，和流程圖很像；
2. 狀態機圖：針對做某件事、某個行為在不同的階段具備不同的狀態，狀態變化的展示；
3. 順序圖：多個角色之間如何共同參與到這個業務流程里；
4. 通信圖：表示不同角色之間傳遞信息，需求分析時較少用到；
5. 用例圖：不同的角色能通過軟件做什么事；
6. 時序圖：某些事物伴隨時間而變化的狀態，比如訂單15分鐘未支付自動取消。

3. 六步法——將產品行為如何歸納到UML體系

如何使用將思維嫁接入UML技術知識體系內，來思考產品架構呢？

通過這樣的思考，設計出來的產品大概率能夠較為快速地讓研發理解產品思維路徑，較好的在同一個共同思考層級上進行溝通。

而且極為嚴謹，六步法走完，就可以基于全局意識下的對功能的業務流程、狀態變化、數據傳輸、用戶可以做什么等進行設計。

1. 把多個人的行為按照事件發生的順序寫出來——活動圖；
2. 并且思考歸納出，某些行為前后會產生的狀態變化，并對狀態命名——狀態機圖；
3. 將不同角色行為按照事物發生的流程關聯起來——順序圖；
4. 角色在什么動作發生時會向其他角色傳遞信息，信息是什么，才能讓流程自然進行——通信圖；
5. 歸納出不同角色在這套系統里可以做什么事——用例圖；
6. 表示某東西的狀態隨時間變化而變化——時序圖。

這是技術思維路徑下對于產品功能設計的思考，極為嚴謹，更接近于代碼實現邏輯機制。

不同于于運營思維，從用戶屬性、商業模式、市場機會開始的思考，運營時考慮投入產出比、新增、留存、增長。

也不同于產品思維，集中于用戶需求、用戶習慣、客戶需求、新增-留存-增長，以實現C端用戶需求、B端客戶需求為核心.

4. 技術正向思維——四步走正向推導產品架構

站在產品經理的視角的技術思維，優先盤點產品做競品分析，然后才能逐漸展開當前基于醫療向的信息。

HIS底層數據決定了能夠做什么，官方技術文件，劃定了對應醫療業務的部分準則，然后就可以逐步推進到后續步驟。

1. 產品盤點：競品分析，HIS底層數據盤點，衛生部官方技術文件，基于已有產品流程盤點；
2. 根據客戶已有接口，對照及提煉內部核心，提煉不同客戶的產品共性，符合行業廣泛適配性的標準流程；
3. 解析技術結構：完成企業內部能滿足業務流轉的接口封裝，外部根據情況，定制化研發；
4. 實施部署：服務于技術可實施路徑的產品架構設計，和技術討論可實施性，符合技術需求的架構。

5. 業務逆向思維——四步走反向逆推產品架構

基于業務思維的逆向推導，符合運營思維邏輯，優先展開對行業、業務流程等內容的分析，再到功能實現。

中間最大的問題在于，太多時候，由于產品經理局限于單一功能，或者在廠里擰螺絲，喪失了從業務展開分析。

再設計可內部標準化封裝接口的產品，朝著SaaS、PaaS等較大結構及框架的思維。

1. 業務盤點：行業背景、市場及客戶，業務流程盤點，涉及字段——表單——數據的分析；不熟悉業務流程，不知道涉及字段——表單——數據等，是沒有資格進行產品功能設計的，除非是抄作業；
2. 產品設計：根據盤點的業務，設計產品流程，完成功能設計，產品流程是符合行業廣泛適配性的標準流程，提煉能夠滿足技術路徑的標準數據接口；
3. 解析技術結構：完成企業內部能滿足業務流轉的接口封裝，外部根據情況，定制化研發；
4. 實施部署：服務于運營業務增長的產品架構設計，和技術討論可實施性，符合業務需求的架構。

五、UML面向對象分析設計的完整過程

UML本身被設計成為一種不但適于現實世界理解，也適于對象世界理解的語言。

將現實世界的人——事——物通過用例和場景用UML語言描述出來，完成從現實世界到業務模型的設計。

將現實世界抽象出來，通過計算機語言的邊界、控制、實體固定元素來進行描述建立分析模型，再轉化為計算機視角能夠識別的包、組件、節點概念，從業務模型到概念模型。

將計算機理解的概念模型，再進一步細化為可執行代碼，采用合適的編程語言、技術架構、規范及中間件將概念轉化為代碼，從概念模型到設計模型。

1. 從現實世界到業務模型——符合技術語言的業務模型

建立模型是人們解決現實世界問題的一種常用手段。

我們通常接觸到的建模是為了解決某個問題而建立的一個數學模型，通過數學計算來分析和預測，找出解決問題的辦法。

從理論上說，建立模型是指通過對客觀事物建立一種抽象的方法，用來表征事物并獲得對事物本身的理解。

再把這種理解概念化，并將這些邏輯概念組織起來，形成對所觀察的對象的內部結構和工作原理的便于理解的表達。

使用參與業務模型的人，作為基礎信息來源的提供者，使用業務流程的需求者，例如掛號里的患者，需要掛號獲取醫院號源。

UML中采用Use Case來表示基礎的驅動業務目標，假定為現實中可以實現的事。

通過建立對應的業務場景、用例場景，這就是技術語言上的業務模型。

2. 從業務模型到概念模型——產品架構一般在這里誕生

概念模型，UML通過概念化建立適合計算機理解和實現的模型，稱之為分析模型。

分析模型中有邊界類、實體類和控制類。

1. 邊界類：大家所熟悉的界面操作，所有前端交互都在界面進行，而前端界面的操作行為將會如何影響后端數據庫的交互方式；
2. 實體類：可以看做是業務實體的實例化結果，映射了現實世界的業務中參與完成業務時設計的事務；
3. 控制類：邊界和實體都是靜態的，本身并不會有動作，而控制類就是用來表示原始需求中的動態信息。

即業務或用例場景中的步驟和活動，換成產品經理常見的語言就是，產品的業務流程、操作行為與之產生的關聯影響。

在實際思考中，從業務路徑的思維，轉化為包含邊界類、實體類、控制類的分析模型組合。

再將分析模型組合凝練為計算機語言里的包、組件、節點概念，這樣就最終轉換為了概念模型。

而產品經理里的業務流程、界面操作流程等，就是從這里簡化為現實世界中的實物，通過對應業務流程、操作流程串聯起來而產生的。

3. 從概念模型到設計模型

概念模型已經獲得了軟件的藍圖，獲得了所需要組成內容的研發所需的必要內容。

概念模型中的邊界類可以轉化為操作界面或者系統接口。

控制類可以被轉化為計算程序或控制程序，如工作流、算法等；實體類可以轉化為數據庫表，XML問答或者其他帶有持有化特征的類。

4. 統一過程一般抽象層次

抽象層次越高，具體信息越少，但是概括能力越強；反之，具體信息越豐富，結果越確定，但相應的概括能力越弱。

從信息的表達能力上說，抽象層次越高表達能力越豐富，越容易理解。

抽象有兩種方法，一種是自頂向下，另一種是自底向上。自頂向下的方法適用于讓人們從頭開始認識一個事物。

自底向上的方法適用于在實踐中改進和提高認識。但是，層級較高的業務模型信息量較少時，就不便于分析。

層級較低，信息量過多時，變不利于優化迭代業務流程；因此，思考的方式及路徑，前提一定是采用合適的。

5. 醫院管理系統結構圖

這是一張較為符合醫院實際運營管理的管理系統，包含門診、急診、門辦管理等。

涵蓋醫生、護士、管理員角色，較為綜合全面的產品功能結構圖。

六、后記——能力及工作階段的躍遷變化思考

做運營時期，核心競爭力是自己在公司承擔的核心角色，不斷地深度學習，梳理業務線sop，管理能力，做出最好的業績。

但是，一旦脫離原來的環境，反而不是優勢，反而是對于行業的理解，商業模式理解，以及一線人員的工作內容的理解。

當剛成為產品經理時，一直堅信具備別的產品經理不具備的超強的邏輯思維能力、商業思維、運營理解及同理心，對公司發展的理解，是核心競爭力。

但是，后來完善訓練產品基礎技能，覺得能力不能停滯不前，開始了更深入對于產品經理、行業、商業、運營的理解，自己也開始輸出自己的思考。

人，總是不能停下來對自己的要求，往前走就會是一件單純幸福而又快樂的事。

我的人生過于坎坷，不會感嘆命運太薄，成為理智及正常的自己。

只單純的追求兩件事能夠帶給我的快樂：成為產品&運營專家的路途上的經歷。

對未知的事物保持旺盛的好奇心，感興趣的事務不斷地學習。

以無知的全能去要求自己，自己的能力終歸會在未來某天在某個領域某個行業登頂，金錢、權利、家庭等最后再說。

七、免責申明

本文僅代表個人觀點，數據來源于部分互聯網公開信息，特此申明。

如需私下交流或侵權等問題，請發郵箱：aigbert.li@qq.com， 歡迎各位指正和交流。

八、引用及參考文獻

1. 《大象：Thinking in UML》（第二版），譚云杰，中國水利水電出版社；
2. 《火球 UML大戰需求分析》，張傳波，中國水利水電初版社；
3. 《醫療行業峰會后深度思考：互聯網醫院行業、醫療產品公式、未來格局》，LS邋遢道人，2021.05。

#專欄作家#

LS邋遢道人，公眾號：LS邋遢道人，人人都是產品經理專欄作家。資深運營和產品，連續創業者，現任某公司產品負責人。關注虛擬現實、虛擬增強、電商、新零售和生鮮領域，擅長運營分析、行業分析和產品分析。

本文原創發布于人人都是產品經理，未經許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。