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

近几年，构建最小可行化方案（MVP）快速试错，找寻市场切合点的敏捷开发的方法论受到各个互联网公司的追捧。

但面向B端的产品天然具有着开发周期长，功能定制化的特点，为了用户需求可以快速响应的同时，实现功能的复用，往往在一个功能的早期不会设计和开发的尽善尽美，故会存在一个运维或者运营人员高强度支撑产品的阶段。

有时候运维或者运营人员甚至会介入正常的业务流程中，充当“人肉补丁”，以保证在特殊情况下的业务可以正常进行。这些情况都是产品初期是正常操作，不可避免的。

所以我们通常需要支撑功能和产品功能共同实现一个业务需求，所谓支撑功能与产品功能，我们内部定义为：

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

支撑功能和产品功能在设计实践中，存在以下特点：

1. 支撑功能与产品功能不存在明显的业务范围界限

如关闭订单接单前部分退货的功能，可以由门店在界面上单独配置，也可以由运营人员在项目级别关闭，实现的业务场景基本一致，故不存在明显的业务范围界限。

2. 支撑功能与业务功能在一个业务流程期间可能交叉出现

如一个商家入住过程，可能存在商家入驻申请，运营配置租户，商家完善信息等阶段。

3. 支撑功能由于面向内部专业人员，大部分时候不需要交互良好的流程和界面，故开发周期更短

如配置每5分钟拉取一次或每天7带点定时数据拉取的功能，就可以通过corn表达式的方式来控制，而不用提供繁多的控件。

由此可见，支撑功能和产品功能在如何更有效率的满足业务场景方面存在重叠，在业务流程中交叉出现；而支撑功能开发周期较短，有利于快速响应用户需求，节省资源，为日后的产品优化提供空间。

所以我们在日常实践中，我们该如何权衡产品功能和支撑功能的设计呢：

一、用户关注侧重点的和运营关注侧重点的权衡

B端产品的产品价值在于解决问题，提高客户工作效率。故对于产品用户来说，他们并不关心一个功能是怎么实现的，他们只关心在什么场景下用什么方式实现什么目标，故需要权衡用户关注侧重点的和运营关注侧的重点。

以数据聚合功能为例，为了将各个前台系统数据进行聚合，需要进行以下流程：接口授权→数据拉取机制设置→数据展示

接口授权：即获取数据源的接口授权，此操作由于涉及到接口账号及密钥的配置，属于接口层面的对接操作，用户由于缺少对系统底层实现逻辑的认知和关注；此时交由用户自行配置，用户的学习成本较高，故应由运营人员进行操作，很明显应设计成支撑功能。

数据拉取机制设置：产品支持设置时间间隔或固定时间点去拉取数据进行加工并邮件分发给预设用户的邮箱，由于产品资源有限，同时对所有租户在同一时间节点进行数据拉取与加工，对服务器性能有一定影响。

同时产品经理在调研后得知：

1. 系统自动分批加工功能本期暂未无法上线，需要运营人员手动设置数据加工时间；
2. 用户对于数据的发送没有很强的时间点要求，一般工作日中午之前获取到数据报表即可。

经过调研，我们得知：用户不关注数据拉取的机制设置；运营人员对于数据拉取机制较为关注。数据展示：应展示哪些数据字段，这是用户根据实际业务情况进行决定的，故应该做成产品功能。

二、 功能使用频率和开发资源的权衡

当功能的使用频率较低，但占用开发资源较多时，可以考虑使用支撑功能来实现。

以各个外卖平台都有的商品信息变动日志为例，此功能满足了用户在商品信息错误时，通过日志找到错误发生的时间及操作人，进而确认错误原因。经过调研，我们得到两个反馈：

1. 各项目分别发生商品信息错误需要排查日志确定问题原因的概率较低，但是目前存量客户整体出现这种业务诉求的次数较多；
2. 开发对日志功能方案进行了评估，指出如果做成产品功能，则对数据加工时效性有较高的要求，实现难度较大，需要提高数据库资源。

在这种情况下，耗费了大量的资源，实现了一个单个项目使用频率并不高的功能，在项目初期，投资回报率明显是低的了，故最终采用设计支撑功能的方式来满足此业务场景。

实现的方式为：使用mongoDB数据库记录日志，当用户期望排查日志确定商品信息异常变动问题原因时，向产品运营申请，产品运营在后台中定位日志并提供给用户；

三、 风险控制的权衡

在项目初期，权限控制，操作引导功能尚不完善，此时，如果识别到将功能交付给客户使用后风险较大，应采用支撑功能的方式来实现。

以异常数据修正功能为例：在日常工作之中，我们发现，由于系统计算逻辑未考虑全面，导致订单数据出现异常，通常表现在订单中相关金额计算异常，作为问题解决机制的一环，需要增加异常数据手工修正功能。

此功能设计时，由于对哪些订单的数据可以进行修正无法识别，故所有订单数据都允许进行修正。

但调研得知，目前权限控制系统较为粗糙，无法将此功能指定给组织中特定的用户，此时如果将该功能直接交付给所有客户，则会存在正常订单也被修改的风险。

权衡之后，采取了使用支撑功能的方案解决；

四、操作效率的权衡

在产品初期新上线了一个少部分项目不适用的一个新功能，故需要将功能设计成开关选项控制开启。但用户侧运营人员操作效率较低，可能在数天内都不进行选项的打开操作，进而造成功能无法大面积推广。

出于操作效率的权衡，我们设计了一个支撑功能，以实现在后台开启对应的业务功能。从这个例子可以看出，一各业务场景可能完全可以由用户自行操作。

但是因为各个用户的内部管理水平水平不一，为了功能的正常上线与推广，也是需要设计支撑功能的；

结语：

需要注意的一点是，当运营人员可以通过支撑功能替代部分产品功能支撑业务场景时，会发现支撑功能具有影响范围大，用户感知弱的特点，需要注意：

1. 操作结果同步：运营人员在后台使用支撑功能的结果应让用户可以感知到；
2. 操作日志记录：运营人员在后台使用支撑功能时，应记录操作日志，以在出现问题时，方便确定影响范围，进行回滚；
3. 与产品功能不冲突，控制优先级问题：当产品功能和支撑功能可以对同一个业务场景进行控制时，应考虑两者控制优先级问题，防止功能冲突；
4. 支撑功能的退出机制：支撑功能应在产品功能逐渐成熟后退出正常的业务流程，但需要考虑如何从支撑功能切换为产品功能，以对现有系统影响最小。

最后的最后，大部分支撑功能在产品逐渐成熟后，应减少对产品功能的直接干预。

大部分业务支撑功能，都能在完善用户权限体系，完善异常处理机制，完善系统自动化处理逻辑后，支撑功能作为资源不充足，功能不完善的情况下支撑系统的千斤顶，应逐渐转化为产品功能。

我们还需要了解到，产品经理大部分的工作都是在用户需求—开发资源中取得一个平衡点，动用无穷无尽的资源将产品功能在产品初期做到尽善尽美既不明智也不可能，支撑功能不是妥协，它是产品临时的但正式的功能，我们应该正视它。

笔者毕业两年，B端产品萌新一枚。期望可以将自己工作中的经验分享给大家，第一次发文，请大家多多指教。

本文由 @kathic 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Pexels，基于 CC0 协议