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

毕业2年，经历4种业务：后端产品经理如何快速融入新业务 / 转眼间毕业两年了，我的产品经验也有两年半了，在第一家公司切换过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. 没有清晰的角色或系统时，通过数据流程图划分模块 数据流程图使用的元素： 下图红框圈出来的就是一个模块/一个系统，在划分功能模块时，需要满足“高内聚、低耦合”的