type
status
date
slug
summary
tags
category
icon
password
2020 年 2 月 2 日，某医院的医生戴上了 Yo!群捐赠的护目镜奔赴抗新冠肺炎的前线，这么多天的辛苦，历经需求对接、物资采购、物流打通等各个环节，终于发挥了其价值。
把时间拨回到一周前，2020 年 1 月 25 日，新冠肺炎疫情爆发，虽然大家都踏上了归家的旅途，但是却立即忙碌起来，开始在组织丁香医生上医生参与支援湖北疫情，提供免费问诊服务。
我们内部许多的医生群信息也开始多了起来，但是有一个医生的发言引起了我的注意。他们所在城市荆门也有不少疑似患者，但是物资储备却非常匮乏，很快就会被消耗完，问群里面大家哪里知道能募集到口罩护目镜之类的防护装备。
恰巧在几天前，我所在的 Yo!群（某互联网产品群）里正在发起动公益活动，希望能帮忙对接医院和捐赠方需求，我就试着在群里面丢了一下需求，然后就有了接下来的一段经历。很庆幸认识这么一群人一起做了一点事（后期因为工作原因投入精力渐少，略憾），具体过程可以查看结尾处的引用资料。
除捐赠本身社会意义外，协作中多是产品和技术同学（其实许多人都已经是 Founder 和高管了），所以基于产品思路的协作方式也让值得复盘。
我在其中主要做的一点事情，是建立了医院需求对接的数据表格及对接的标准操作，前者保证所有人的信息同步，后者则能让新加入的同学快速上手，迅速扩大规模。
上图是基础业务的结构说明，不理解没关系，先大概看看下面会展开讲。
1. 梳理业务模式
这次捐赠的目的是为了缓解前线的医院的压力。刚开始是以捐款为主，但是很快发现医院缺少的不是资金而是物资。所以中途转型开始用募捐的钱进行采购，这和创业公司非常像，在前进中不断地修正目标，而不拘泥于形式。
但因为刚上手做，货源信息和医院信息需要同时整理，加上大家都是志愿者，并没有立即明确详细的分工，加上没有统一的标准，都是在摸索中前进，许多信息拿来之后并无法辅助我们做判断，许多事情都需要在群里沟通，造成信息冗余非常大，需要不停地看着手机，或者不停的找人询问。
在大概参与了一个晚上之后，才初步梳理出来业务模型：
对接募资需求，进行募资和采购；对接医院的需求，进行信息整理和需求汇总，等待分配物资；对接物资供应商，进行定点采购（因为初期募集部分资金，所以优选考虑采购，然后是接受捐赠）；确定物资和医院的匹配需求，安排物流；送货到医院，履约完成；
2. 建立实体模型
初期许多信息都是在每个人脑子里面和散落在各个群里面，新加入的人很难上手，只能不停的发问，而同时疫情爆发很快，大家忙于对接也无暇告诉新人该干啥（我就懵逼了半天）。所以我便开始进行医院侧的信息整理（财务是@藤、物资是@子雄），希望能把大家脑子里的信息清晰的呈现在所有人面前，保证同步。
值得一提的是，这件事也让我意识到信息同步在组织中的重要性。在这个临时的组织中，所有人的动机和能力都没有问题，但因为初期信息同步的低效，产生了大量的冗余事务，并且许多事都处于模糊状态进度不明，只能不停地发问，但是信息很快就会被淹没。导致新人很难上手，组织也无法再扩大规模。所以如果一个团队低效，团队间摩擦大，不一定是能力和动机的问题，大概率是信息的同步问题。
做什么的问题已经很清晰，那么这一步需要回答的是我们做了什么以及接下来怎么做，那么在有基础业务模型后，就可以开始建模了。从上述业务模式能看到我们需要关注的「实体（即重要对象）」有如下几个：
物资（包含规格、厂家、外观、符合什么国家标准）医院（包含医院属性、医护人员数量、防护措施，物流情况等）资金（包含捐赠收入、采购支出等）物流（包含物流订单、收件人信息、物流状态等）
在每一个对象上，又包含属性和状态两方面，以医院侧为例
属性：名称、级别、所在地、医护人员数量、感染人员数量、联络人信息、收货人信息状态：信息是否齐备，物资是否分配，物流状态如何
其实一个业务不管多复杂，一定有几个重要的实体，而每个实体的属性定义和状态变化几乎是所有业务的核心。那么对于每个实体的属性的罗列及状态的穷举至关重要，只有这些清晰了之后，才能保证整体业务稳定。
下图是我们对接的部分医院信息，我们用表格做属性，颜色做状态，有效的跟踪每个医院的进展，而所有负责对接的人也知道彼此的进展，负责分配的人也知道哪些医院信息已经收集完成（下图是迭代的第三个大版本）
3. 确定接口标准
确定完是实体的属性和状态后，那么就需要对实体进行「增加、删除、改写、查询」，而这些动作的实现，就需要依赖「接口」进行「通信」（其实就是填表格啦）。
这里可以把「接口」想象成某种粗细口径的水管子，你想要家里面的热水器里面有水，必须通过一个口径合适的管子对接，太粗太细都不行。而且里面必须是自来水，不能是工业废水；又比如达到某种水压，不能一阵高一阵低。
所以抽象来看，「接口」最重要的作用是信息的「输入、输出」，而其本身重点则是「格式、顺序」
信息的完整性
初期一些情况是医院报的需求量大，但实际上是未雨绸缪；有些医院报的少，但是感染者多且物资奇缺，只是不好意思开口。这里面其实牵涉到的是信息的完整性。
其实外界（如对接募捐的医生们）信息多数情况下是处于非标准非结构化状态，很多时候是想到哪里说哪里，每个人都不同，部分情况下还会失真。如果定义好需要输入的内容，那么可以反向约束他们提供的信息，减少其不必要的信息传递，提高效率，保证信息的完整性。
所以我们提供了标准版「接口格式」，解决信息的完整度（感谢@xklxkl 提供的升级加强版「懒人包」），基本上上来直接丢这个懒人包，等待对方回答我们想要的信息即可，别的冗余信息可以不必理会和收集。
信息队列顺序
另外就是在信息不全的时候，同时同步许多双向信息，比如医院问你们有什么，我们要去问供应商有什么；反之有人愿意捐赠许多物资，但不知道医院是否有需求（如集成灶、蔬菜等），需要再去同步咨询医院。
这里面的问题是信息队列顺序，针对信息不全时双边匹配低效的情况，我们确定了供给和需求侧进行信息分工整理，并且只记录关键信息，其他的作为「冗余」仅备注，降低优先级。
最后交由统一的决策人决策，信息收集者不在收集过程中参与物资分配的决策。
下图是第一个版本的「标准化操作流程」，解决信息处理的顺序。
4. 建立决策机制
虽然民主也是一种决策制度，但是在这种快速迭代的情况下，最佳的方式还是大家就决策标准达成共识，然后让专人负责决策，效率更高。（这里感谢@大鹏 和@Summer 大力）
建立决策标准的好处是，所有人有了有明确的目标，反之就是有明确不做的事情。比如我们在讨论时就明确尽量帮助非武汉的湖北周边二甲以下医院，主要提供口罩和护目镜，这样其他的需求（如）暂时不对接，能更加有利于目的的达成。
这里插一句，其实从传统的观念上看这些人就是所谓的「领导」，但是在协作过程中能看到这只是一个「分工」而已，而且他们许多的判断也依赖于信息的整理和分析，并非是拍脑袋的决定。
5. 规模化匹配需求及系统迭代
有了这些基础工作之后，新来的许多小伙伴就能快速的上手参与到需求对接中来，截止到 31 日已经有 85 家医院的需求对接完毕。
比较有趣的是，做这件事过程中还被几个媒体报道了，许多志愿者想要加入活动中来。这时候便把上面的这套流程传授给他们，而这群充满了活力的 PM，在现有基础上，迭代的更加完善，反而让我收获颇多，看到了许多之前忽略的地方。在此向他们表示敬佩和感谢。
尾声
这样整个系统就已经被初步搭建完成，也有了自然成长的能力，实体对象（接受捐赠的物资种类）也在不断的增加，匹配效率不断提高。
这也是一种 MVP 的产品思路，即关注业务模型，抽象对象，定义属性及状态，确认接口形式和决策方式，希望在未来的新业务中也对你有一定的启发。
另外，还有一些组织采用了「抢单制」的模式，即拉入需求方，然后开始广播现有物资，等待抢单。就这种模式群内也有讨论，结论是虽然对于公益组织来说运营成本低，但是真正需要物资的医院和医生其实没空一直守着手机来抢，所以会造成最需要物资的人反而得不到有效的救助。
因丁香医生的湖北义诊项目超出预期，工作量陡增，所以我从 29 日下午开始投入的精力渐少。打开手机看到群内的信息近千条，便感觉到，产品经理除了画原型，我们也能做一些力所能及的事情。
2020 年 02 月 02 日 Update
项目已经移交给「转转」，他们会投入人力进行 2-3 个月的开发，目前已经部分产品化，很开心项目有了一个好的结尾，有兴趣的朋友可以点此链接查看：
- 作者:Tony·Chen
- 链接:https://www.tony-chen.xyz//article/b429a1fb-bb83-4873-8697-188c2b8280c0
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章