毕业2年，经历4种业务：后端产品经理如何快速融入新业务

编辑导读：不管你是应届生开始第一份产品工作，还是跳槽到新公司，当面对一个全新的业务时，谁心里都**有点发慌，甚至不知所措。本文作者基于自身经验，以后端产品经理的身份，总结了一些处理新业务的方式，希望对你有帮助。

转眼间毕业两年了，我的产品经验也有两年半了，在第一家公司切换过3条业务线，然后跳槽到了第二家公司。

本篇分享一下如何融入新业务的经验，适用情况大概以下几种：

1. 产品新人的第一份工作
2. 公司内部换岗
3. 跳槽

后端产品，主要关注三个方面：数据层、业务层、表现层

1. 数据层：关注数据存储、数据传递和系统之间的交互
2. 业务层：关注业务逻辑、运算规则、模块边界等，对行业背景要求比较高
3. 表现层：用户或者业务同事需要操作的页面。后端产品经理一般只关注内部使用的页面，强调“可用性”，而不是“体验性”，这点和做用户页面时有差别

表现层比较基础，着重讲一下数据层和业务层。

先普及一些基础的技术知识：（大佬们可跳过）

MVC模型、前端、后端、客户端：

产品经理从0到1：不懂技术也能愉快地与开发相处（作者：莔莔有神）

系统的功能需求和非功能需求、系统模块化：

原来后端产品经理要懂的基础知识是这些！（作者：苒苒上升）

上面两篇文章，着重于**层面，下面我结合之前做过的业务，讲一讲如何实操。

Step1：搭建业务框架

接手新业务，首先是通过流程图搭建对这个业务的整体框架。

不一定是最全最准确的流程图，最开始可以先画一个比较简单的流程，知道整个业务如何运转的即可。

一般可以从以下两个方面着手：

1. 【宏观】先了解行业模式

通过大量泛读，了解行业如何运作，可以参考的资料：体系化的课程、行业书籍、行业资讯、行业分析报告、**商分析报告、咨询公司分析报告、相关公司财报、产品论坛上相关业务的调研和分析。

2. 【微观】再研究公司的该业务如何运作

可以参考的资料：产品文档、产品流程图、接口文档、开发的wiki文档（按照我的阅读经验，开发的wiki文档一般**划分系统模块及对应的功能，对后续输出产品方案有很大帮助）。

下图为我之前做过的两个业务的流程：

可能你**觉得很简单，其实事实上也并不复杂。把握了整个大体的框架，后续细化的时候，才知道自己做的需求是属于哪个环节，才能做到“既见树木，又见森林”。

Step2：根据流程图，抽象数据对象

先科普一下数据对象（纯属个人的粗浅理解，如有不对，欢迎指正）：

行为产生数据，比如客户下单**产生订单、学生考试**产生成绩，“下单”“考试”是行为，“订单”“成绩”是数据。对应到数据库里，“订单”“成绩”就是数据对象，可以简单理解为“订单”“成绩”各自有一张表，记录所有订单和所有成绩。

【以成绩为例】

数据对象：成绩

属性/字段：学生ID、姓名、语文、数学、英语

1. 提炼数据对象

投资的数据对象：产品、订单、持仓、还款计划

小贷的数据对象：授信订单、提现订单、还款计划

2. 根据数据对象画实体关系图（ER图）

实体关系图描述了各个数据对象的关系。

有两种画法：（以理财为例）

1）常规画法

2）带属性的画法

关系一般包含以下三种：

以理财举例，1个投资产品对应N笔订单（多个客户都可以买同一个产品，故产生N笔订单），1笔订单对应0到1笔持仓（订单失败则不创建持仓，订单成功则创建持仓），1笔持仓对应1笔还款计划（用户投资之后总有退出投资，所以有还款计划）。

顺带提一下，画法2的数据对象，带#的属性为主键，主键决定了每条记录的唯一性。

3. 分析数据处理的CRUD：增加(Create)、检索(Retrieve)、更新(Update)和删除(Delete)

下图以订单和成绩为例，分析了四种操作，这些操作可能就是有待分析的需求或产品功能。

一般线上的用户数据都不**被删除，比如订单只支持撤销，很少看到从数据库里直接删除的。

Step3：数据对象的状态机图/生命周期

接手新项目，抽象出数据对象后，就需要用状态机图描述它们的状态流转，这对于之后了解系统交互很重要。状态机图描述了一个数据的生命周期。

下图以优惠**的状态机图为例，优惠**的创建一般有这些场景：运营人员在后台给客户发放优惠**、客户参加活动获得优惠**、客户花钱购买优惠**……

优惠**的初态是【待使用】，终态是【已使用】【已过期】。

Step4：泳道图 or 划分功能模块/系统

1. 有清晰的角色或系统时，可直接画泳道图

如果不是从0到1的项目，一般系统都是划分好的，这时候只需要把数据对象的状态流转带入泳道图即可。

下图为简单的一个运营系统的优惠**状态扭转泳道图，对比状态机图，可知，【待使用】【已过期】为运营系统内部维护的状态，【已占用】【已使用】和释放占用，都是由订单系统通知的。

通过泳道图，我们可以知道数据在各个系统之间如何流转，知道每个系统维护什么数据以及如何与其他系统交互。

2. 没有清晰的角色或系统时，通过数据流程图划分模块

数据流程图使用的元素：

下图红框圈出来的就是一个模块/一个系统，在划分功能模块时，需要满足“高内聚、低耦合”的标准，将相近、相似功能归为一个模块，如此便于开发和维护，提高整体分工效率。

Step5：基于泳道图，了解系统间数据传递的方式

1. 接口传输

接口就像一扇门，请求方从这扇门里获取想要的数据，而不关心门背后的具体逻辑。

同步调用模式和异步调用模式：

• 同步调用：接口的调用方一直等待被调用方的返回结果，比如前端请求服务端数据进行展示。一般处理结果较快，**使用同步调用，如上文的订单系统调用运营系统，通知运营系统占用优惠**，订单系统**一直等待运营系统返回优惠**的占用结果，作为订单状态的流转依据
• 异步调用：接口调用方给被调用方发出指令，但不**等待结果，一般耗时比较长的处理工作**用异步调用模式，并且调用方**给被调用方提供一个回调接口。比如小贷里的订单系统，将授信订单推送给风控系统，风控系统需要一定时间处理，甚至需要人工介入，所以不能立马给出结果。等风控系统处理完成后，**回调订单系统的接口，返回授信额度等关键信息

泳道图一般只展示了数据如何在系统间传递，但不涉及具体的实现方式。比如系统A要把数据同步给系统B，就有两种实现方式：①系统A调用系统B的接口，通知系统B相关数据；②系统B调用系统A的接口，查询需要获取的信息。具体实现逻辑可以查阅接口文档或者和开发讨论。

2. 数据库同步

接口传输，当数据量较大时，可能导致连接**时。使用数据库同步，可以实现数据的实时同步更新，一般应用在数据量大的场景下，主要适用于公司内部系统之间数据库对数据库的传输，占用资源少、交互更加简单。

有几种同步方法：

• 使用中间库：将目标数据放在一个中间库里，需要这些数据的系统对这个库都有访问权限
• 实时同步数据：使用Otter是一个常用的方法，Otter进程**根据定义的规则将数据表的内容从源头数据库更新到目标库中，也支持双向更新

按照上述方法论，画完一遍图，心里就对新业务有底了。我切换过几次业务，每次都屡试不爽（屡次试验都没有差错）。

对整体业务有了把握，做需求时再深入细节就好了。

希望对你有帮助~

作者：苒苒上升，互联网金融产品经理，就职于3亿用户平台，微信公众号：苒苒上升，输出干货包括但不限于成长秘诀、产品心经。

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

题图来自Unsplash, 基于CC0协议。