编辑导语：B端产物凡是需要支撑成果和产物成果来配合实现一个业务需求，那么这两种成果在设计实践中，存在什么特点呢？我们在日常实践中，又该如何衡量产物成果和支撑成果的设计呢？关于这两个问题，本文作者团结本身的事情履历，为我们谈了谈他的一些观点。

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

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

有时候运维可能运营人员甚至会参与正常的业务流程中，充当“人肉补丁”，以担保在非凡环境下的业务可以正常举办。这些环境都是产物初期是正常操纵，不行制止的。

所以我们凡是需要支撑成果和产物成果配合实现一个业务需求，所谓支撑成果与产物成果，我们内部界说为：

支撑成果：为了支持业务正常举办提供应运营人员利用的成果；

产物成果：提供应客户侧人员利用实现业务场景的成果。

支撑成果和产物成果在设计实践中，存在以下特点：

1. 支撑成果与产物成果不存在明明的业务范畴边界

如封锁订单接单前部门退货的成果，可以由门店在界面上单独设置，也可以由运营人员在项目级别封锁，实现的业务场景根基一致，故不存在明明的业务范畴边界。

2. 支撑成果与业务成果在一个业务流程期间大概交错呈现

如一个商家入住进程，大概存在商家入驻申请，运营设置租户，商家完善信息等阶段。

3. 支撑成果由于面向内部专业人员，大部门时候不需要交互精采的流程和界面，故开拓周期更短

如设置每5分钟拉取一次或天天7带点按时数据拉取的成果，就可以通过corn表达式的 *** 来节制，而不消提供繁多的控件。

由此可见，支撑成果和产物成果在如何更有效率的满意业务场景方面存在重叠，在业务流程中交错呈现；而支撑成果开拓周期较短，有利于快速响应用户需求，节减资源，为日后的产物优化提供空间。

所以我们在日常实践中，我们该如何衡量产物成果和支撑成果的设计呢：

一、用户存眷偏重点的和运营存眷偏重点的衡量

B端产物的产物代价在于办理问题，提高客户事情效率。故对付产物用户来说，他们并不体贴一个成果是怎么实现的，他们只体贴在什么场景下用什么 *** 实现什么方针，故需要衡量用户存眷偏重点的和运营存眷侧的重点。

以数据聚合成果为例，为了将各个前台系统数据举办聚合，需要举办以下流程：接口授权→数据拉取机制配置→数据展示

接口授权：即获取数据源的接口授权，此操纵由于涉及到接口账号及密钥的设置，属于接口层面的对接操纵，用户由于缺少对系统底层实现逻辑的认知和存眷；此时交由用户自行设置，用户的进修本钱较高，故应由运营人员举办操纵，很明明应设计成支撑成果。

数据拉取机制配置：产物支持配置时距离断或固按时间点去拉取数据举办加工并邮件分发给预设用户的邮箱，由于产物资源有限，同时对所有租户在同一时间节点举办数据拉取与加工，对处事器机能有必然影响。

同时产物司理在调研后得知：

系统自动分批加工成果本期暂未无法上线，需要运营人员手动配置数据加工时间；

用户对付数据的发送没有很强的时间点要求，一般事情日中午之前获取到数据报表即可。

颠末调研，我们得知：用户不存眷数据拉取的机制配置；运营人员对付数据拉取机制较为存眷。数据展示：应展示哪些数据字段，这是用户按照实际业务环境举办抉择的，故应该做成产物成果。

二、 成果利用频率和开拓资源的衡量

当成果的利用频率较低，但占用开拓资源较多时，可以思量利用支撑成果来实现。