互联网患者社区从零开始【七】——产品开发

互联网时代的今天，人人手机上都少不了几个社区应用，许多应用也将社区作为其重要的功能模块。对于开发自研产品的必要性，该系列文章的前面几篇已经有一些零星叙述。当社区规模增长到一定程度、或社区面向的潜在患者群体巨大，那么就应当考虑研发自己的社区产品，或将其加入社区的长远规划之中。本文我们将以业余产品经理和资深程序员的角度，从产品和技术两个方面，对开发一款互联网患者

No. 1 竞品调研

竞品调研通常是我们开发一款产品的第一步，不论你所面对的产品是一个手机应用还是一件实实在在的商品。顾名思义，竞品调研的对象是竞争对手的产品，当然也可以是潜在的竞争对手。采用的方法是调研，不论何种具体形式，目的都是系统客观的收集信息并进行研究分析。

产品调研可大可小可粗可细，但对于初创团队来说，更应当注意如何充分利用有限的时间对相关领域作出准确的判断。调研的目的是为了指导项目的启动，而不能一味的力求全面彻底，具体来说一定程度达到下列目的即可，

• 了解市面上是否已经有相似的产品存在；
• 了解市面上已有的产品存在哪些优势与劣势；
• 了解市面上已有产品的用户数量与活跃度；
• 了解市面上相同方向的其他类型产品；
• 了解市面上其他领域的相同类型产品。

更进一步，对于患者社区来说，在产品层面可以借鉴的案例其实非常之多，进行产品调研的更重要目的是寻找可以参考的对象，在此基础上再发现总结现有产品的不足，进而通过不断的微创新来持续演进。这里我们也将曾经调研与参考过的上百个案例去粗取精，按功能分类列出如下，

• 患者社区。腾讯医典微信小程序，腾讯医典APP，咚咚癌友科APP，觅健APP。
• 挂号问诊。微医APP，好大夫APP，腾讯医典微信小程序。
• 社区应用。知乎APP，知乎微信小程序，百度贴吧APP。
• 科普患教。腾讯医典微信小程序，腾讯医典APP。
• 管理工具。Keep APP，薄荷健康APP，糖护士APP，变啦APP。
• 电子商务。淘宝APP。
• 视频直播。抖音APP。
• 即时通讯。微信APP。

选取这些案例所遵循的一些基本原则也分享如下，

• 选取一个功能集合最为相似的案例作为蓝本，如果一个功能在已有APP中存在多种实现，优先参考蓝本案例；
• 如果一个功能存在于任何一个现象级应用中，优先参考该现象级应用；
• 如果一个功能存在于一个已有APP中，优先参考而不重新设计；
• 如果一个功能在不同应用平台有多种实现，优先参考与你目标平台相同的案例。

这样做的目的主要是为了保证产品的快速迭代、保持统一的产品风格、维持既有的用户使用习惯。上述的思路也仅供参考，在实践过程中，产品开发团队可以根据具体需要依此进行拓展与延伸。

No. 2 产品分析

在现有的案例中，腾讯医典、咚咚癌友科、觅健都是比较完备的患者社区产品，对它们简单观察即可发现，科普患教、社区、挂号问诊、工具是基本的必备核心功能。本文将主要对这些功能进行系统介绍，而对于信息流、个人中心、消息推送等通用功能则不详细展开，也仅对如电商、群聊、直播这样的附加功能略作提及。

科普患教

通过互联网自媒体进行科普已经是当下的潮流，每个人的日常生活中都会有多多少少的接触。目前主流的形式有两种，一是文图混排的文章形式，一是视频的形式。

图文混排的文章一直以来都是最为常见的互联网媒体类型，将其发挥到极致的是微信公众号，该功能可参考的案例非常多，开发成本也较低。视频在过去的很长一段时间主要集中在桌面端，随着手机流量和带宽的升级，如今在移动端也得到普及，参考案例也非常多，开发成本相对较高。

对于内容为主的功能，所需面对的最重要问题是制作与版权。科普内容不适合以UGC的方式生产，但可以考虑开放评论功能以增加用户参与度。对于如何生产内容，请参考《9病X1：互联网患者社区从零开始【五】——医学科普与媒体运营》一文。而为了更好的鼓励PGC内容的生产，则可以参考各类已有的成熟内容生态模式，如微信公众号、Bilibili、Youtube等。

在版权方面，目前国内的现状依然非常混乱，大平台各自为政，既缺乏对于创作者的有效保护，也缺乏方便的授权方式以促进内容的流通，在使用非原创内容时必须考虑法律风险，至少要严格标明作者、来源与转载声明。值得一提的是微信小程序，其中可以如微信公众号一样对腾讯视频中的内容进行引用，是一个无开发成本的很好内容源。

与微信公众号等媒体平台相比，一款应用最大的优势在于可以对内容进行灵活的管理和组织。除了信息流、搜索、标签、推荐等常见方式之外，这里要强调一种针对患者教育比较好的形式，我们称之为“科普聚合页”。对于纷繁复杂的科普资讯，可以以疾病类型、治疗手段等维度将其抽象成几类，每一类首先建立医学百科进行综合介绍，再将相关的各种科普内容精选后按照百科的结构分别纳入其中作为引申材料。这种内容组织方式更加适合于目的性阅读，有利于系统性掌握患教知识，也便于查阅，还可以有效避免信息爆炸所带来的副作用。

最后简单提一下直播，相较于静态的内容，其互动性更强、效果更好，但开发运营成本都更高。此外，直播需要额外的资质许可，如《信息网络传播视听节目许可证》 、《网络文化经营许可证》等，这些对于微信小程序的开发是强制要求，对于APP则存在监管的灰色地带。

社区

作为常见功能，社区可参考的案例也非常多，随着互联网进入垂直时代，几乎一切应用在发展到一定规模后都会或多或少的引入社区功能。社区重运营和积累，也是患者社区整体文化和理念的缩影，此处可综合阅读本系列的各篇文章。社区很重要，也是形成壁垒的一种重要方式，但从狭义的产品角度反而能讲的不多。

社区的用户体验经过几十年的不断优化，已经有了较高的门槛。富文本展示、发布、点赞、收藏、评论、评论回复、分享，这些平时觉得再普通不过的标配功能虽然不复杂，但是全部实现下来成本依然不低。其中的各类细节也很多，在横向对比过程中甚至经常会发现明显冲突的不同交互方式，造成这样结果的原因可能更多是来自于迭代过程中的AB测试，而不是什么特别的产品逻辑。

尝试利用开源的社区软件也是一种方式，可选的比较知名的有国内的discuz，或者国外的DIscourse。前者应用非常广泛，平时所见的论坛或者BBS有很多都是基于discuz搭建的，但目前已经停止开发维护。后者在国外比较流行，用户体验比较偏极客风格，不太符合国内用户的使用习惯。此外，两者在移动端的体验都很差。

社区的内容监管一直也是一个绕不过的话题，最著名的案例可能算是微博混战时代被一夜关停的饭否网。微信小程序曾经要求社区类应用提供《ICP增值电信业务经营许可证》，中介办理费用为几千元、周期为几个月。该规定在去年被取消，转为仅需要ICP备案信息，但是依然要警惕未来再变严格的可能。同样，APP方面存在监管的灰色地带。

挂号问诊

挂号问诊的前置需要是医院与医生的基本展示，这里的难点在于信息的录入与实时更新，而数据的准确性在好大夫、微医等大型平台中都存在瑕疵。如果是疾病领域比较狭窄的社区，手工录入还尚能接受，在数据量较大的情况下则必须要依赖网络爬虫。但除了已有的挂号问诊平台之外，医院的信息建设水平参差不齐，人工的数据辅助校验依然必不可少。

该功能可参考的案例也非常之多，成熟度虽不及社区高，但也大同小异，此处不加赘述，只强调两点。挂号涉及与医院系统的对接，而问诊需要额外开发医生端系统，这两方面工作都比客户端的实现要复杂很多。此外，挂号问诊也需要额外资质，如微信小程序即要求提供《医疗机构执业许可证》、卫健委（卫生健康委员会）批文或医管局批文等。

工具

相较于上述其他产品模块，工具类功能在不同患者社区中的侧重与具体形态会有很大不同，它不一定是必须的，但往往才是体现产品创新的地方。

数据管理是健康类应用的常见功能，但是针对不同健康问题其实现方式会有不同。在薄荷这样的健康管理应用中，用户记录自己的日常健康指标，这些数据按照体重和抗衰老两类进行组织管理，再进行可视化展示。如变啦等糖尿病管理应用中，还会结合连接血糖仪等设备进行自动数据采集录入。而咚咚癌友科所提供的则是病历数据管理，且要覆盖全部的不同类型癌症。

人工智能在医疗领域的应用也是目前的热点，如利用眼底照相智能分析视网膜病变的风险就属于比较成熟的领域，中山大学中山眼科中心也推出过人工智能近视筛查微信小程序。另一个应用比较多的领域是知识图谱，通过它可以构建智能医生或智能医导，部分替代医生的工作，左医医生是这方面的一个ToB案例。至于机器学习在数据处理层面的应用就更多了，这里就不再详细列出。这些依托于人工智能的创新功能都可以结合入社区产品之中，甚至为产品创造出技术的壁垒。

健康管理也是一个重要的工具类产品方向，最常见的形式是如健身类应用中的各类课程，还有通过问卷形式实现的各类健康评测工具。打卡其实也是非常好的一种健康管理交互方式，适用于慢性病或者是需要长期居家自我管理的健康问题。该类功能的关键是既要有医学专家知识作为管理方案的核心理论依托，也要通过产品方面的设计实现用户参与的正向反馈，如果再结合一些语音识别、运动检测等人工智能方法来优化体验则效果更佳。

No.3 技术分析

跨平台

作为客户端产品，在研发方面首先要考虑的是如何解决跨平台的问题，即应用在苹果、安卓及电脑端的可用性，其中电脑端主要指基于网页的实现。目前来说跨平台的解决方案主要有三种，实际开发中通常是以一种为主，同时相互结合使用。

基于网页的跨平台解决方案是最早的一种思路，它是指产品的核心功能都通过普通的网页开发实现，通过Cordova与操作系统交互，同时支持桌面版网页、移动版网页、平板端网页、苹果APP、安卓APP等，只在APP中需要结合非常少量的原生开发。其特点是，一套代码开发成本低；类网页的用户体验较差；学习成本低；支持的平台最多。

因此，一般来说采用该方案的产品都有这几方面特点，曾经在网页端有很深的产品和技术积累、非常依赖网页版、对于用户体验要求不高。目前行业中最大、也可能是唯一的大型案例是亚马逊的购物APP，但该技术几乎总会结合入其他跨平台解决方案之中来实现一些辅助功能，如微信中公众号的内容即是以网页形式实现的。

基于跨平台客户端框架的解决方案是目前的主流，它是指借助Flutter等框架达到一个技术栈支持多个平台的目的，它也是在网页开发的基础上逐渐发展衍生出来的。该方案的特点是，一套技术栈或代码开发成本低；用户体验与原生应用相同或接近；学习成本居中；支持的平台也很多。

跨平台客户端开发框架的先行者ReactNative是Facebook的网页开发框架React的衍生，但它只能支持移动APP，在网页端需要重新用类似的React开发、甚至重用代码。谷歌的Flutter后来居上，目前来看应当是排在第一的跨平台解决方案，而且可以同时支持网页端。这两者提供的用户体验都是原生的，但是框架本身需要额外的学习成本。此外提一下Ionic，是一款基于网页开发技术的跨平台解决方案，用户体验类似网页但经过专门优化，支持所有平台，可以用Vue、React、Angular等网页技术开发。

基于小程序算是中国特色的一种情况，也就是指通过微信小程序为主的各类小程序实现跨平台的需要。这套方案的特点是，一套代码开发成本低；用户体验与网页相同；学习成本居中；无法支持网页端；需要额外考虑所在平台的监管审核；需要额外考虑特殊的开发要求，如腾讯要求社区类微信小程序接入它们的内容安全接口。

各类小程序都有自己的一套开发框架与标准，而根据普及情况来看，则只需要考虑微信即可。目前行业中流行的开发方式大概有两种，一是利用微信小程序的自有框架，二是使用第三方的uni-app。这两者都可以选择使用Vue这一网页技术来进行开发，这进一步节省了学习的成本。uni-app在跨平台方面虽然还可以同时支持所有的移动客户端，包括小程序、移动网页及APP在内，但根据我们在微信小程序的实践经验来看，兼容效果并不很理想。

与上述跨平台解决方案相对的是进行原生开发，即苹果APP、安卓APP、网页端三者分别使用各自的框架来开发。这样的特点是，一个平台即对应一套代码，开发成本高；用户体验最好；学习成本高；当然也可以支持所有平台。原生开发是大企业所可能选取的开发方案，主要是看重其更好的用户体验，对于交互要求很高的产品也有考虑的必要。

技术栈

在项目增长到很大规模之后、或者对于大公司来说，技术开发所考虑的更多是如何兼容固有系统以及保证向未来的可扩展性，选用什么技术栈非常次要，庞杂的系统中也经常会混用各类框架。

在初创项目中，我们则希望使用开发学习成本最小的、最为稳定的、社区支持最好的技术框架。因此对于互联网患者社区这样的项目，如果没有特殊的技术积累，全栈开发是不二的选择。

因为上述主流的客户端跨平台开发框架使用的都是Javascript+CSS+HTML，类似于网页开发，所以服务器端如能选择基于Javascript语言的框架，则可以达到最大可能的前后端技术复用。可选的组合很多，比如各类基于express的服务器框架Koa、egg等，再结合graphql、redis和elasticsearch的组合。至于数据方面，新项目建议使用非关系型数据库，主要是因为它结构易于扩展，可以更加灵活的应对可能的业务变化，可选的有PostgreSQL、mongodb等。

这里还要稍微提一下CMS，也就是内容管理系统，主要用于运营团队录入和管理数据、或管理团队进行运营指标监控汇报。与上述技术栈一致的解决方案也有许多选择，如Vue Element Admin。

运维

这里所指的运维主要包括基于各大云平台的服务器端资源管理、域名注册和备案、服务器部署及管理、应用发布等，这些都是项目初期需要经常面对的一些工作。对于服务器端有一些方案可供选择，列举如下，

• 基于IaaS为主。只使用云平台的运算服务搭建系统，购买云主机后自己安装和维护各类服务器端软件。
• 基于PaaS为主。结合使用云平台的多种服务搭建系统，如在阿里云中数据库、存储、服务器、搜索、缓存等各类软件都可以找到相应的云版本。
• 基于SaaS为主。直接使用云平台的服务实现彻底的serverless（无服务器）系统搭建，如腾讯云的云函数SCF或阿里云的函数计算FC。

实际中上述方案也可以混合使用，一般来说兼顾灵活性和运营成本的较好方式是使用云主机搭建主要的服务器系统，存储、消息推送等使用云服务实现，当然也可以考虑使用Docker。Serverless方案存在的主要问题是需要额外的学习成本、无法迁移、费用较高，但运营的成本最低。还要强调一点，国内无需考虑亚马逊的AWS，其对国内业务的支持很差。

上述的方案更多的涉及成本和灵活性的考量，但数据安全才是运营的重中之重，当然这需要和开发紧密协同。简单来说，一要做好数据备份，二要避免信息泄露——尤其是用户信息。

最后简单提一下客户端发布，如果开发的是微信等小程序，发布走的即是它们各自的流程，一般来说都是热更新，无需考虑版本更新率的问题。如果开发的是跨平台方案下的移动APP，绝大多数情况下也都是热更新，但在初次上线和有原生代码更新的情况下需要发布新的程序包。至于应用分发相关的具体流程，参考各大平台的介绍即可。

No.4 开发策略

零散的补充一些小的注意事项，首先是平台的选取。应用覆盖的平台越多，能够触及到的用户就越多，但是开发和维护成本也相应更高。对于社区类的项目，支持桌面端的必要性不大，尤其在项目的早期。比较妥当的方案是或者只选择开发微信小程序，或者只选择基于跨平台开发方案开发苹果应用和安卓应用。而相比之下，前者的开发和运营成本更低，但在项目长期发展的角度看灵活性和稳定性都不足够，因此选择微信小程序起步而在未来转向跨平台APP也是可行的。

项目早期的重要里程碑是做出PoC（Proof Of Concept），也就是能够基本展现项目思路的原型产品。在早期的产品调研、设计、研发、运营等各方面都应当明确这一点，也应当据此进行取舍，合理的控制原型的最小功能集合。如对于挂号功能，可以选择在早期只静态展示号源信息，具体的挂号业务流程可以将用户导入对应医院的在线就医平台来完成即可。在调研、设计、开发、测试等过程中，团队也一定会有很多优化产品的想法，可以将其记录并逐步加入未来的规划。

产品的设计与开发应当本着更小、更快、更敏捷的原则，应用要切分成系统、系统要切分成功能、功能要切分成模块。能以模块为单位开发和上线的，就不需要等整个功能完成，依次类推到整个应用的开发流程中。尽早的上线就可以尽早的投入生产环境测试，并收集用户反馈，以推动后续的迭代，此处也要注意用户使用数据的收集。

最后，互联网患者社区对于运营的依赖完全不亚于产品，两者对于推动增长来说同样重要。产品的负责人要综合考虑运营策略，至少要了解如何通过产品的设计来更好的将社区内的各种内容呈现给用户，并进而激发出用户参与的积极性。在更多时候，社区产品的负责人也会同时是运营的负责人。