编辑导语：想做B端，但对于B端系统操作不熟练、不知道从何入手？作者为我们分享了一些快速上手B端系统的方法，供你阅读参考。
最近一段时间都比较忙，刚接手了一个新系统，又赶上H1的项目，每天边熟悉系统边出方案，回过头甚至有点惊讶，看似头大无从下手的事情竟然不知不觉做完了。复盘一下接手新系统的一些体验和收获，希望可以给你带来帮助～
一、先业务，后系统
了解系统前，先要了解系统背后支撑着什么业务、业务的运行模式，这样可以让你宏观地了解整个系统的价值。例如了解它的用户群体、它的定位、它的目标。
在这个基础上结合现状，结合目标制定后续的规划。
举个例子：
如果你负责的是一套交易的策略后台系统，那你需要搞清楚以下知识点：
- 使用这套系统的业务方分别有哪些、他们各自是什么角色。如不同业务方向的各个策略运营团队。
- 在交易的全链路过程中的哪个节点会用你的系统，分别会做什么操作。如配置策略、编辑策略、删除策略、查询策略。
- 这些操作在整个流程中起什么作用。如新增策略后，用户提单时才能依赖策略算价，或依赖策略校验来保证成单；再比如通过查询策略能看出策略的改动频次、策略改动的范围，来判断业务变化的趋势。
- 异常情况：如中途删除策略后是否导致部分模块走不通，调整策略后是否提前同步用户以免影响体验，策略配置错误产生线上数据后推动规范运营的sop，以及系统如何提前监控预警等。
二、数据来源
如何快速上手一个系统最核心的是：
- 知道所有的底层数据从哪来；
- 有怎样的取值逻辑；
- 基于此系统上做了什么展示逻辑；
- 操作逻辑等。
举个例子：
你的策略系统有一个功能叫新增策略，业务在系统上配置策略时可能会基于各种维度，比如：
- 策略类型，是属于基础的策略，还是促销玩法的策略？
- 策略性质，内部测试的还是外部使用的？
- 满足用户的角色，哪些用户可以命中这条策略？
- 这条策略所生效的商品名称、所生效时间、所生效的售卖渠道等信息。
要么这些字段的值就是写死的，但是大多数情况下是分别调用各个系统、各个模块的接口读到的，比如角色系统、商品系统等，这就是数据来源。
这样做的好处是你不用单独维护一份别人的数据，后续人家数据变更时你无需感知。
三、数据交互
数据的流转和交互是B端系统设计时必不可少的一点。我会把数据交互当做两种来看，一种是系统内部的数据交互，另外一种是和外部系统的数据交互。
还是用策略系统举个栗子，假设你要针对于某个A渠道，配置一条新的策略B。
如果渠道信息是在策略系统上的某个模块维护的话，需要先前置建立好这个渠道A，那么可能需要用到渠道id、渠道名称等一些业务属性的信息。配置好渠道A后，再配置策略B，这个就是系统内部的数据交互。
系统外部的数据交互，比如这条策略B应用于A渠道，那用户在A渠道下单时，就会命中策略B，策略会为用户进行算价，展示在C端，这就是系统外部的数据交互。
四、系统边界
我们一般说的系统边界问题其实就是一句话，做自己该做的事儿～
哪些能力是你系统该做的，哪些能力不属于你的，以及哪些数据你直接从上游获取是合理的，而你还在弯弯绕绕从其他系统查。
举个很经典的例子：中台系统和业务系统的边界。
中台系统提供的是基础服务，是通用化的能力，它对接的是多个业务系统，但不耦合业务逻辑，不做定制化需求。中台系统的核心是维稳，提供通用化、稳定的服务和能力，业务侧不必二次开发，可以直接复用。
业务系统最重要的还是贴合业务，一定和业务强耦合，一些基础的服务不需要自己开发，但是针对业务有很重的业务逻辑就必须内部闭环。
边界不清最大的问题是各个系统之间耦合严重，牵一发而动全身，各自承担着不该自己承担的功能，效率低下，稳定性差，PM必须识别出这个问题，不做冗余的功能，这样对自己的系统有更多话语权。
本文由 @闫秀儿 原创发布于人人都是产品经理，未经作者许可，禁止转载。
题图来自Unsplash，基于CC0协议。
文章评论