编辑导语：ER模型是软件工程中的核心概念。作为产品经理，必须掌握er建模。如何使用ER模型直到产品设计？这是产品经理工作的难点和重点。如何在保持真实的同时去伪存真，把过程讲清楚，把轻重缓急讲清楚？笔者在本文中用大量的案例详细介绍了具体的操作方法。让我们来看看。
# 1.外卖食品
在沟通需求时，如何在保持真实、清晰流程和清晰优先级的同时消除虚假，笔者建议首先使用ER模型。下面是一个真实的案例来尝试说明这个方法。
#二。背景
与同事共进午餐时，手机收到保密扣款通知，费用明细显示收款人是旅游服务商。在这个有充足不在场证明和我的见证的案子里，我们一开始都觉得这笔款项有问题，脑子里有一个大大的问号：
为什么我吃喝的时候会扣车费？我有充分的不在场证明。
而旅游APP的客服对这个问题进行了反馈，客服回复说会在72小时内回复。
但是作为一个产品，如果你觉得这个问题有意思的话，你可以试着去思考一下发生了什么，这个时候的思维模式就是ER模式。事后梳理步骤安排如下。
#三。角色分解
首先，让我们列出这个事务的主要角色，并在这个事务链接中看到它们的必要性。
*某平台：提供自有平台的注册司机作为运力，同时聚合三方网约车平台的运力，以运力提供者的角色出现，满足客户从A点到B点的需求组合，如速度快、舒适、成本低；
*三方平台：运力提供方可能是租车公司或其他网约车平台，但同时也向其他平台提供自身运力，如公路出行、T3出行；
*乘客：需求方可在价格(如快车、专车、专车)、耗时(如拼车)和乘坐舒适性(如专车、六座商务车、行政级专车)之间进行选择，享受服务并付费；
*司机：最终服务提供者，负责接订单、开车送乘客到目的地等实际线下演出服务，演出完成后获得相应收入，其成本主要包括人工成本、硬件成本(免车损、租车)、油费或电费等。
*支付机构：乘客、司机、运钞车、平台支持者。
#四。需求分解
在上面的角色中，每个角色都有自己的需求，但核心可以拆解成两个(至于安全、声誉和未来价值，我们暂时不讨论)，只看对分析今天的问题最有帮助的两个。
*从A点到B点：一个落客平台、三方平台和司机的整体组合，就是为了满足乘客的这个需求，也就是从A点到B点的需求；
*利润：提供服务后，某平台、第三方平台、司机将乘客支付的服务费在各个角色之间进行划分；
*因此，基于以上两个核心要求，某个平台的核心价值是司机与乘客的匹配；
*它可以帮助乘客更快、更便宜、更舒适地出行，所以会有更多的乘客。这时候就需要不同层次的出行服务商——司机和三方平台。
*它可以帮助司机更快、更多、更轻松地获得更多订单，所以会有更多的司机。这时候就要多关注不同喜好的时间、价格、舒适的乘客。
# 5.关系的分解
当我们列出此事务中的所有角色时，我们将查看角色之间的关系：
*打车付费：乘客与某平台之间存在打车付费关系，乘客既是平台的需求提供者，也是平台的收入提供者；
*能力提供和收钱：三方能力平台是能力的提供者，是为某个投放平台收钱的一方；
*平台撮合收钱：某平台中间提供撮合服务收费，相当于撮合费；
*支付机构收付方便：支付机构主要为整个业务流程提供交易便利，服务费会a
如上拆解后，我们可以确定业务角色在整个业务闭环中提供和需要的服务，但在现实场景中，我们仍然需要考虑各方的一些额外需求，可以理解为显性需求下的心理需求，我们可以称之为属性。
例如，针对乘客的安全属性，尤其是像乘车这样的产品，这里就不再赘述了。
然后，作为服务商，除了有更多的订单和更好的订单(没有堵车、长途、帮助完成目标等。)，你还能做什么？
包括客户是否逃单，即在白嫖打车。读者可能会问，“现在都是保密付款，怎么可能到白嫖？”然后我们来对比一下下车前后的情况：
*之前：用户下车前，现金支付，
必需当面交易，逃单跑了也跑不过司机开的车啊，所以逃单概率不高；* 现在：因为是免密支付，用户下车即离开，是否是因为网络环境导致车费没有马上到账，还是因为用户没有开通免密支付，亦或是用户卡里没有钱了等因素导致，以上对司机来说很难判断，所以为了增加司机师傅的安全感，而不用在有沉没成本后还继续付出。
由上可见，我们可以认为司机是有收入确定性的属性。
同时我们在延伸下，如果司机有这个心理属性，但是平台不保证，那么会导致司机的流失，因为有别的平台会保证这件事情，那么当前未支持该属性的平台在供给侧可能会减少，而平台是需求和供给的双向匹配，那么会导致需求侧也减少。
所以，平台需要提供方式来增加确定性属性，也等同于说：尽量不被白嫖。
# 七、需求设计
在如上的分析拆解过后，我们可以理出两个核心需求：
* 让乘客尽快有车：在提供更多运力的情况，让运力效率最大化，比如附近优先匹配，以减少路上接人时间；
* 让司机收入更多：有更多的订单，尽量少跑空车，都能增加收入，再结合刚才说的确定性问题，也需要设计减少乘客白嫖的机制。
结合文章开始描述的实际场景和上文的分析，那么针对三方平台的付钱逻辑可以整理如下：
1. 订单完成后，生成订单，推送给客户；
2. 如果客户支付，按比例分成给到下游平台；
3. 如果客户未支付，那么在用户下次打开APP时，会优先出现待支付订单，如果不支付，则无法使用其他功能；
4. 如果客户未支付超过N天，那么用用户已经开通的免密支付方式支付金额；
5. 如果客户未支付超时N天且通过免密支付不行，那么可能会触发客服电话联系或者滴滴补偿支付。
所以我们会发现大部分客户都是集中在a到c的场景中，毕竟网约车也是高频使用APP，而d和e是更加低频的场景，基于这个推断，我建议朋友看下某滴平台、支付平台订单支付金额是否一致，在金额精确到小数点后两位的情况下，验证金额一直，可以反推会上面基于ER的层层分析和拆解是大概率符合实际的。
而在笔者写完这篇文章时，客服依然没有联系我们，所以无法用客服的反馈的来进行双向验证，但是起码订单金额是一致的，大概率是符合推断。
# 八、写在最后
古龙说有人的地方就有江湖。而人都会有各种需求和属性，人和人的关系组成了这个江湖，而需求就在江湖里。
## #专栏作家#
代成龙，人人都是产品经理专栏作家，智能硬件创业公司产品狗，从视频巨头公司到玩智能硬件的公司，继续产品设计工作。
本文原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自 pexels，基于CC0协议。
