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

Celery 2023-07-25 14:18:56

转眼间毕业两年了，我的产品经验也有两年半了，在第一家公司切换过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的接口，查询需要获取的信息。具体实现逻辑可以查阅接口文档或者和开发讨论。