编辑导语：ER模型是软件工程中的核心概念。作为一名产品经理必须掌握ER建模工作。如何用ER模型直到产品设计?这是产品经理工作中难点也是重点，如何在沟通需求时，去伪存真、流程清晰、明确轻重缓急？作者运用大量案例在本文中详细地为大家介绍具体操作方法，一起来看看吧。

一、Takeaway

如何在沟通需求时，去伪存真、流程清晰、明确轻重缓急，笔者建议先用ER模型筛一遍。如下以真实案例来尝试阐述该方法。

二、背景

和同事一起午饭时，他的手机收到免密扣款通知，而费用明细中显示收款方是某出行服务商，在这个有充分不在场证据，且也有我这个人证的情况下，我们最初都认为这个付款有问题，脑海中大大的问号：

为什么我在吃放，却扣了车费，我有充分的不在场证据啊？

和出行APP的客服反馈了这个问题，客服答复说72小时内给答复。

但作为一个产品，感觉这个问题有意思，可以尝试思考下到底发生了什么，而此时的思考模型就是ER模型。事后梳理步骤整理如下。

三、角色拆解

首先我们将这个交易的主要角色罗列下，并且看下他们在这个交易链路中的必要性。

• 某滴平台：提供自己平台注册的司机作为运力，同时也聚合三方网约车平台的运力，以运力提供方的角色出现，来满足客户从A点到B点的快捷、舒适、低成本等需求组合；
• 三方平台：运力提供方，可能是租车公司，也可能是另外一个网约车平台，但是同时也将自己的运力提供给其他平台使用，比如享道出行和T3出行；
• 乘客：需求方，在价格（比如快车、优享和专车）、耗时（比如拼车）、乘坐舒适性（比如专车、六座商务车、行政级别专车）间按需选择，享受服务并支付;
• 司机：最终服务提供方，负责接单、开车载客到目的地等实际线下履约服务，履约完成后获得相应收入，其成本主要是人力成本、硬件成本（自由车损耗，租车租金）、油费或电费等；
• 支付机构：乘客、司机、平台的钱流承载和支持方。

四、需求拆解

在如上的角色中，每个角色都有自己的需求，但是核心可以拆解为两个（至于安全、声誉、未来价值这些暂不讨论啊）仅仅看对于分析今天问题最有帮助的两个。

• 从A点到B点：某滴平台、三方平台和司机的整体组合就是为了满足乘客的这个需求，也就是从A点到B点的需求；
• 利润：提供服务后，某滴平台、三方平台和司机将乘客支付的服务费在各个角色间分成；
• 所以基于以上两个核心需求看，某滴平台的核心价值就是司机和乘客的匹配；
• 它能帮乘客更快、更便宜、更舒适的出行，那么乘客就越多，而此时就需要各种不同等级的出行服务提供者——司机和三方平台；
• 它能帮司机更快、更多、更省力的获得更多订单，那么司机就越多，而此时就需要更看重时间、更看重价格、更看住舒适的不同偏好的乘客。

五、关系拆解

当我们罗列出这个交易中各个角色后，再看各个角色的关系：

• 打车、付钱：乘客与某滴平台间是打车付钱的关系，乘客对平台来讲既是需求提供方，又是收入提供方；
• 运力提供、收钱：三方运力平台对某滴平台来说是运力的提供方，也是收钱的一方；
• 平台匹配、收钱：某滴平台在中间因为提供了匹配服务而收费，相当于匹配费用；
• 支付机构方便收付钱：支付机构主要为整条业务流提供了交易的便利性，中间也会有服务费费用产生。

六、属性拆解

在如上拆解后，可以确定业务角色在整个业务闭环中的所提供的服务和所需要的服务，但是在现实场景中，还需要考虑各方的一些附加的需求，可以理解为在显性需求下的心理层面需求，我们可以姑且称他们为属性吧。

比如对乘客来讲的安全属性，尤其是像顺风车类产品，所以此角度就不赘述。

那么作为服务的提供方，除了能有更多订单、更多好订单（不堵车、长距离、帮助完成指标等）外，还有什么哪？

是否包括客户逃单，也就是白嫖了打车。读者可能会问“现在都是免密支付，怎么可能白嫖”，那我们先对下网约车之前和现在：

• 之前：用户下车前，用现金支付，必需当面交易，逃单跑了也跑不过司机开的车啊，所以逃单概率不高；
• 现在：因为是免密支付，用户下车即离开，是否是因为网络环境导致车费没有马上到账，还是因为用户没有开通免密支付，亦或是用户卡里没有钱了等因素导致，以上对司机来说很难判断，所以为了增加司机师傅的安全感，而不用在有沉没成本后还继续付出。

由上可见，我们可以认为司机是有收入确定性的属性。

同时我们在延伸下，如果司机有这个心理属性，但是平台不保证，那么会导致司机的流失，因为有别的平台会保证这件事情，那么当前未支持该属性的平台在供给侧可能会减少，而平台是需求和供给的双向匹配，那么会导致需求侧也减少。

所以，平台需要提供方式来增加确定性属性，也等同于说：尽量不被白嫖。

七、需求设计

在如上的分析拆解过后，我们可以理出两个核心需求：

• 让乘客尽快有车：在提供更多运力的情况，让运力效率最大化，比如附近优先匹配，以减少路上接人时间；
• 让司机收入更多：有更多的订单，尽量少跑空车，都能增加收入，再结合刚才说的确定性问题，也需要设计减少乘客白嫖的机制。

结合文章开始描述的实际场景和上文的分析，那么针对三方平台的付钱逻辑可以整理如下：

1. 订单完成后，生成订单，推送给客户；
2. 如果客户支付，按比例分成给到下游平台；
3. 如果客户未支付，那么在用户下次打开APP时，会优先出现待支付订单，如果不支付，则无法使用其他功能；
4. 如果客户未支付超过N天，那么用用户已经开通的免密支付方式支付金额；
5. 如果客户未支付超时N天且通过免密支付不行，那么可能会触发客服电话联系或者滴滴补偿支付。

所以我们会发现大部分客户都是集中在a到c的场景中，毕竟网约车也是高频使用APP，而d和e是更加低频的场景，基于这个推断，我建议朋友看下某滴平台、支付平台订单支付金额是否一致，在金额精确到小数点后两位的情况下，验证金额一直，可以反推会上面基于ER的层层分析和拆解是大概率符合实际的。

而在笔者写完这篇文章时，客服依然没有联系我们，所以无法用客服的反馈的来进行双向验证，但是起码订单金额是一致的，大概率是符合推断。

八、写在最后

古龙说有人的地方就有江湖。而人都会有各种需求和属性，人和人的关系组成了这个江湖，而需求就在江湖里。

#专栏作家#

代成龙，人人都是产品经理专栏作家，智能硬件创业公司产品狗，从视频巨头公司到玩智能硬件的公司，继续产品设计工作。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 pexels，基于CC0协议。