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

经过调研，我们得知：用户不关注数据拉取的机制设置；运营人员对于数据拉取机制较为关注。数据展示：应展示哪些数据字段，这是用户根据实际业务情况进行决定的，故应该做成产品功能。
二、功能使用频率和开发资源的权衡
当功能的使用频率较低，但占用开发资源较多时，可以考虑使用支撑功能来实现。
以各个外卖平台都有的商品信息变动日志为例，此功能满足了用户在商品信息错误时，通过日志找到错误发生的时间及操作人，进而确认错误原因。经过调研，我们得到两个反馈：

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

在这种情况下，耗费了大量的资源，实现了一个单个项目使用频率并不高的功能，在项目初期，投资回报率明显是低的了，故最终采用设计支撑功能的方式来满足此业务场景。
实现的方式为：使用mongoDB数据库记录日志，当用户期望排查日志确定商品信息异常变动问题原因时，向产品运营申请，产品运营在后台中定位日志并提供给用户；
三、风险控制的权衡
在项目初期，权限控制，操作引导功能尚不完善，此时，如果识别到将功能交付给客户使用后风险较大，应采用支撑功能的方式来实现。
以异常数据修正功能为例：在日常工作之中，我们发现，由于系统计算逻辑未考虑全面，导致订单数据出现异常，通常表现在订单中相关金额计算异常，作为问题解决机制的一环，需要增加异常数据手工修正功能。
此功能设计时，由于对哪些订单的数据可以进行修正无法识别，故所有订单数据都允许进行修正。
但调研得知，目前权限控制系统较为粗糙，无法将此功能指定给组织中特定的用户，此时如果将该功能直接交付给所有客户，则会存在正常订单也被修改的风险。
权衡之后，采取了使用支撑功能的方案解决；
四、操作效率的权衡
在产品初期新上线了一个少部分项目不适用的一个新功能，故需要将功能设计成开关选项控制开启。但用户侧运营人员操作效率较低，可能在数天内都不进行选项的打开操作，进而造成功能无法大面积推广。
出于操作效率的权衡，我们设计了一个支撑功能，以实现在后台开启对应的业务功能。从这个例子可以看出，一各业务场景可能完全可以由用户自行操作。
但是因为各个用户的内部管理水平水平不一，为了功能的正常上线与推广，也是需要设计支撑功能的；
结语：
需要注意的一点是，当运营人员可以通过支撑功能替代部分产品功能支撑业务场景时，会发现支撑功能具有影响范围大，用户感知弱的特点，需要注意：