编辑导语：随着互联网技术的普及和不断发展，互联网医疗也走进越来越多人的生活，本篇文章作者从产品经理的角度出发，详细地讲述了如何从单纯的医疗业务去逆推未来的产品架构，干货满满，一起来学习一下。

这次文章里将会讲到如何从单纯的业务去逆推未来的产品架构，再从单业务线延伸的方向可以是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. 预约挂号的界面

挂号的界面里，设计并不复杂。

选择科室的页面要素是一级科室、二级科室（一般是门诊），选择医生页面（常规是选择日期和医生），选择号源（页面内有医生信息和号源）。

只要在产品设计时考虑这些要素，挂号功能就可以能够较好地设计了。

二、拆解和重组——构建产品万能公式

如果作为一名产品经理，将针对一家医院的定制化内容转化为最有利于企业发展的核心架构？

由挂号衍生的医疗平台的业务中台思考，当医院越来越多时，绝对不能是简单的进行好处理，而是需要一个架构，来让所有的内容标准化。

然后才能快速接入到各家医院的业务。

凭心来说，这样的平台可以是卫健委管辖下的区域医疗聚合的平台，也可以是以互联网挂号、在线咨询、体检预约、专科服务结合的在线诊疗平台。

同时也可以聚合处方外流等内容和业务，医院实际经营和平台之间会存在较大的问题：

每一家医院都有结合着医院内部业务的功能——在线问诊、开药、检查检验预约、查报告等。

如何才能更好地实施呢？微医、微脉、阿里健康、平安好医生、好大夫等，是如何处理多家医院的预约挂号功能的呢？

业务和医院关联度较高的其他产品，在线咨询、诊后随访、体检、检查检验预约等功能，又是如何处理的呢？

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协议。