B端产品经理必须懂的技术那点事良心总结

我是纯产品出身，没有码过代码，像我一样的产品经理在工作时可能经常听到开发讲这样一句话：“你这个方案实现不了”。

如果我们对技术一无所知的话，就无法理解怎么个实现不了，可能只能听从开发的意见；但是如果我们对技术有所了解，这个了解不是说我们必须知道怎么去码代码，而是要知道代码世界的运行规则，实现逻辑，知道这个之后，如果开发再说实现不了，那我们就可以理解他所讲的方案，甚至可以帮助想出其他可以实现的方案，毕竟对产品还是产品经理比较了解，产品经理可以帮助决策怎么以最小的成本实现想要的目标。

而且做B端产品经理最好要懂些技术，B端产品的逻辑和流程比C端复杂得多，很多东西需要产品经理抽象总结出来，如果不懂技术，出方案的时候就可能会犯浮于表象的错误。比如订单发货需要拆单，不懂技术的产品可能只知道这么出方案：“订单中的商品任意组合拆单，如取消拆单需恢复原单状态。”，方案可能出得没什么问题，但是他可能不知道恢复原单需要在订单表里面记录原订单ID，一层层溯源才能恢复原单，如果不知道这点，开发看需求也看露了，很可能这个功能就没有实现。

我工作过程中发现懂技术还有一个 好处，就是知道技术世界运行的规则后，可以反过来帮助你思考产品，查漏补缺，保证该考虑的场景都能考虑到，也能帮助产品反思自己所出的方案有没有问题，这样就不会发生上线后部分场景漏考虑导致流程卡壳的情况。

以上只是想说明做B端产品经理懂技术的好处，那么B端产品经理必须要懂哪些技术呢？我根据已有的工作经验总结了一部分，如有技术同学看到觉得不对的请及时指正哦。

API

API的全称是Application Programming Interface，中文是应用程序接口，API的作用是信息传递，比如，我们通过天猫API接口获取某笔订单的详细信息：订单号，收货人，订单商品信息，订单金额等。

获取信息的方式有两种：主动调用和被动调用。主动调用是我们通过别人的接口，获取自身想要的信息；被动调用需要我们提供API接口，让别人通过接口获取信息。

如何了解某个具体的API

通过API文档。无论是公司内部或公司之间通过API传递信息时，都会撰写API文档，API文档说明了这个API可以传输哪些信息，通过看一个公司提供的API文档其实也可以了解该公司的业务，大家感兴趣的话，可以去网上看看比如淘宝开放平台的API文档或者微信公众平台的API文档。

API文档中我们需要读懂以下两个信息：请求参数和返回参数。

请求参数是获取想要的信息需要告诉接口的条件，比如想要获取某笔订单的详细信息，就需要告诉天猫对应的订单号，天猫根据订单号告诉我们这个订单对应的详细信息。

返回参数是接口能告诉我们的信息，如上面所说订单的收货人、订单金额、订单商品有哪些。

前后端分离

什么是前端

运行在用户端，你能直接看得到的，比如我们看到的知乎的网页。

什么是后端

运行在非用户端（服务器端），你不能直接看到的，比如知乎里面一篇篇文章。

前端负责啥

网页的样式展示（比如知乎导航栏上头像放哪，消息提示放哪）、网页上的交互、网页跟网页之间的跳转。

后端负责啥

只负责提供数据，如知乎热搜有哪些，每篇文章的具体内容是什么由后端提供给前端进行展示。后端给前端传递信息的通道就是API，前端会根据跟后端约定好的API文档将请求参数发给后端，后端返回前端想要的数据。

同步异步

同步

就是在发出一个调用时，在没有得到结果之前， 该调用就不返回。如：你直接面对面问大神一个问题，等大神当面告诉你答案才走，这是同步。再比如：ERP调用天猫的接口修改用户地址，肯定要等天猫返回“成功/失败”，然后再把这个结果反馈给修改用户地址的客服。

异步

调用在发出之后，这个调用就直接返回了，所以没有返回结果。如：你去知乎向大神提问，提问完就干别的去了， 大神会看到消息然后再回复你，这是异步。再比如：OMS系统订单审核通过后，要生成WMS系统的出库单，这个操作是通过异步实现的，因为审核通过本身跟生成出库单是没有强逻辑关联的，不是一定要等出库单生成成功才能审核通过，所以OMS订单审核通过后，便自动排队等生成出库单了。

我理解所有的异步操作都可以通过同步实现，只是部分场景通过同步实现太浪费性能，也不是非得通过同步实现，那就可以改为异步实现。

数据库相关的基本知识

数据库

数据库可以理解为数据存储的仓库。

数据库管理系统

数据库管理系统是一种操纵和管理数据库的软件，用于建立、使用和维护数据库，它可以提供数据录入、修改、查询等功能。我们常听到的SQL Server、MySQL就是数据库管理系统。

数据库表（仅限关系型数据库）

数据库中存储具体数据对象的二维表。比如订单的基本信息会存储在订单主表和订单明细表中：订单表中一个订单一行数据，存储了这个订单的订单ID、订单编号、订单金额、下单用户、下单时间、支付时间、收货人等信息；而订单明细表中存储了每个订单的购买的详细的商品，一个订单一个SKU一行数据，如订单明细ID、订单编号、商品ID、商品名称、商品规格、购买数量、实付金额等等。

可以先从现有的业务了解起，知道系统的每个业务的数据在数据库的哪些表中存储，每个表之间的关系如何， 知道这些后会对自己以后出产品方案有帮助。

SQL

SQL全称是Structured Query Language，结构化查询语言，通过编写SQL语句可以查询、新增、删除、更新数据库中的数据。我们可能经常会让开发帮忙拉数据，比如想知道昨天同时购买了口红+香水的订单有哪些，这时候开发就是通过写SQL帮忙查出来的。

产品运用SQL一般是用来查找数据进行统计分析，不会涉及新增、删除、更新数据库操作，所以我们只用学会基本的查询语句即可。一般而言，用点心思的话，一周可以学会了，可以像我一样买本《SQL即查即用》学下，够用了。

ER图

ER图全称是Entity Relationship Diagram，实体-联系图，用于描述实体对象之间的关联关系。我们设计产品时经常要讨论一些对象的关系，是一对多，还是多对多，就会用到E-R模型。理出相关业务的ER图，有助于产品理解对象之间的关联关系，也有助于产品信息结构的设计。

下面是简单的订单、发货单之间的ER图，一个订单对应多个订单明细，一个发货单对应多个发货单明细这个很好理解，那订单明细跟发货单之间为啥是多对多的关系？一个发货单有可能发多个订单明细（比如发牛奶+抽纸），一条订单明细也有可能拆成多个发货单进行发货，比如客户买了5台iphoneX黑色256G，但是由于缺货，可能先给用户发2台，剩下的3台等到货再发，这样这笔订单是通过两个包裹完成的，一条订单明细就会存在两个发货单。

订单-发货单ER图

数据流图

数据流图，全称是Data Flow Diagram，描绘了数据产生和流动的情况。有助于产品自身从技术的角度去理解业务涉及的各项数据是如何产生及如何流转的，也有助于开发理解产品需求。

下图是采购业务中的数据流程图，可以清晰的看到从采购到财务给供应商付款，数据层面是如何流动的，当然这个只是简单地画了一下，希望能帮助大家能透过这个事例理解。

采购业务数据流图

其他小常识

1、相同的功能开发只会写一个方法，供不同的地方进行调用，比如订单支持单个订单的换货和多个订单的批量换货，那么换货逻辑开发只会写一套，不会分开写两套（当然如果开发没有这种意识的话另谈），这样一来如果换货逻辑有变更，如修改换货后的库存占用逻辑，只需要修改一个地方即可，不用怕有地方漏改；

2、能不写死的尽量不要让开发写死，比如公司新在天猫上开一个店，需要在ERP系统录入店铺结算的相关信息（如：跟天猫结算扣点，每笔订单需要的处理费，方便后面查看报表销售数据），这种数据如果写死在代码里面，每加一个店铺有可能报表的取值逻辑都要写一遍，特别不方便扩展，最好的是加一张表存储店铺结算信息，报表字段直接从这张表里面取，这个表就是上面说的数据库表，以后每新增一个店铺就往表里面插入一行数据，这么做也方便日后如果想通过页面配置这些信息的话，只需要前端动动手指就行了，后端的工作基本是完成了。

3、产品的PRD文档一定要写清楚，这个写清楚不是写给自己看的，是写给开发看的，一定让开发读了你的文字之后没有疑问。比如你想统计每天财务的收款金额，不能直接写成某某字段为财务当天的收款金额，一定要具体点，如汇总收款时间为当天的且状态为“收款完成”的收款单的金额。

4、考虑需求对老数据的影响。如你的新需求需要开发在原有的表里面新增一个字段，那老的数据需不需要考虑，需不需要初始化，要考虑到，不然上线后老数据全都不正常了可能。再比如原有的业务单据有类型区分，你如果有个新的单据也要生成这个单据的数据，那你的这个数据需要跟原有的类型做对应吗，还是要新增一个类型，这些都要考虑。

5、测试用例的基于产品文档撰写的，所以产品文档中一定要将需要测试的场景罗列全。

做B端产品经理要达到这种程度，你每提一个需求，都能透过现象看到技术脉络，知道哪些地方会被改动。所以你要懂些技术（不需要到会码代码的地步哦），还要懂原有的业务，这样做需求才不至于被动。

以上不一定是对的。

作者：青柠，微信公众号：【一只进化中的产品汪】（pm_move_forward），欢迎关注交流。

扫我关注公众号可查看更多内容哦