|B端产品功能与支撑功能的设计思考

编辑导语：B端产品通常需要支撑功能和产品功能来共同实现一个业务需求，那么这两种功能在设计实践中，存在什么特点呢？我们在日常实践中，又该如何权衡产品功能和支撑功能的设计呢？关于这两个问题，本文作者结合自己的工作经验，为我们谈了谈他的一些看法。

本文插图

近几年，构建最小可行化方案（MVP）快速试错，找寻市场切合点的敏捷开发的方法论受到各个互联网公司的追捧。
但面向B端的产品天然具有着开发周期长，功能定制化的特点，为了用户需求可以快速响应的同时，实现功能的复用，往往在一个功能的早期不会设计和开发的尽善尽美，故会存在一个运维或者运营人员高强度支撑产品的阶段。
有时候运维或者运营人员甚至会介入正常的业务流程中，充当“人肉补丁” ，以保证在特殊情况下的业务可以正常进行。这些情况都是产品初期是正常操作，不可避免的。
所以我们通常需要支撑功能和产品功能共同实现一个业务需求，所谓支撑功能与产品功能，我们内部定义为：

支撑功能：为了支持业务正常进行提供给运营人员使用的功能；
产品功能：提供给客户侧人员使用实现业务场景的功能。

支撑功能和产品功能在设计实践中，存在以下特点：
1. 支撑功能与产品功能不存在明显的业务范围界限
如关闭订单接单前部分退货的功能，可以由门店在界面上单独配置，也可以由运营人员在项目级别关闭，实现的业务场景基本一致，故不存在明显的业务范围界限。

本文插图

2. 支撑功能与业务功能在一个业务流程期间可能交叉出现
如一个商家入住过程，可能存在商家入驻申请，运营配置租户，商家完善信息等阶段。
3. 支撑功能由于面向内部专业人员，大部分时候不需要交互良好的流程和界面，故开发周期更短
如配置每5分钟拉取一次或每天7带点定时数据拉取的功能，就可以通过corn表达式的方式来控制，而不用提供繁多的控件。
由此可见，支撑功能和产品功能在如何更有效率的满足业务场景方面存在重叠，在业务流程中交叉出现；而支撑功能开发周期较短，有利于快速响应用户需求，节省资源，为日后的产品优化提供空间。
所以我们在日常实践中，我们该如何权衡产品功能和支撑功能的设计呢：
一、用户关注侧重点的和运营关注侧重点的权衡
B端产品的产品价值在于解决问题，提高客户工作效率。故对于产品用户来说，他们并不关心一个功能是怎么实现的，他们只关心在什么场景下用什么方式实现什么目标，故需要权衡用户关注侧重点的和运营关注侧的重点。
以数据聚合功能为例，为了将各个前台系统数据进行聚合，需要进行以下流程：接口授权→数据拉取机制设置→数据展示
接口授权：即获取数据源的接口授权，此操作由于涉及到接口账号及密钥的配置，属于接口层面的对接操作，用户由于缺少对系统底层实现逻辑的认知和关注；此时交由用户自行配置，用户的学习成本较高，故应由运营人员进行操作，很明显应设计成支撑功能。
数据拉取机制设置：产品支持设置时间间隔或固定时间点去拉取数据进行加工并邮件分发给预设用户的邮箱，由于产品资源有限，同时对所有租户在同一时间节点进行数据拉取与加工，对服务器性能有一定影响。
同时产品经理在调研后得知：