毕业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协议。