b端|两个企业级产品设计思路：流程效率指标&功能生命周期长度( 二 )

（4）单用户操作次数
用户在这个页面中完成动作需要进行几部操作，例如：审批中我们点击审核 → 填写5-10个汉字（20-40次键盘操作） → 点击同意 → 确认是否同意 → 点击关闭弹窗 → 点击左上角返回 → 点击下一个审批事项，总计7次操作。
为什么要这么做呢？
作为一个成熟的B端产品，它面向企业内部需求明确，因此其存在的核心意义在于帮助用户更高效的去完成任务而不是继续添加负担。
所以我们产品的重点就应是帮助用户提升效果，减少成本，规范流程，我们不能单纯的依靠感觉去评估，而是需要一个精准的数字去告诉我们当前产品的复杂程度并去找到这里问题的所在。
让我们以一个我以前生产中的例子来看看上面的指标如何发挥作用。
我们有一款面向企业的管理系统，在我们的软件中带有付费套餐，客户可以根据自己的需求来购买。
之前由于历史原因我们的产品内部购买历史都是由财务手工统计，现在由于公司市场部需要，我们要开发一个统计客户消费的模块，而客户的消费类型可分为如下两类：

产品内购：客户可直接在产品内部进行服务购买，购买后需要财务确认，再由CRM用户将此订单信息进行记录，随后解除用户在产品内的权限。
线下成单：通过线下销售团队去线下完成产品销售，与打款确认流程，随后将信息录入系统，由于线下销售一般拥有一定的灵活性，因此我们的系统要支持销售的自定义用户套餐修改，比如多赠送几个套餐包等操作。

在这样的业务背景下我们可以设计出第一版的付费管理流程：

文章插图
图3.流程A业务交互
接下来让我们对CRM中这个付费记录流程的效率开始评估：(我们以需要人接入的页面为统计基准)。
在我们按如上拆解了后，就对这个流程具体的用户复杂度有了清晰的认识，我们的系统单独一个信息记录就需要3个系统与6个页面的跳转，这对于一个记录流程来说是太过于臃肿了。好在找到问题后就可以有的放矢地进行优化。
首先我们分析下“横跨系统子项“，”参与此动作的人”这两个指标由于这其中三者每个都有专业分工所以无法精简，那么我们就锁定了我们的优化方向在信息流转页面与操作上进行优化。
仔细来看流程A的设计思路其实是以技术实现最简单为导向的，我们将所有的操作与逻辑判断都交给了用户，用户推一步流程进一步，那么是不是所有的动作都是用户必须要去完成的呢？带着这个出发点，我们就得到了流程B：

文章插图
图4.流程B业务交互
既然要去减少信息流转页数与操作次数，那么我们必须要去大量引入系统判断逻辑来完成。
第一个优化内容：这里财务已经确认到款了，那项目必然为付费状态，此时完全不需要CRM用户再去修改付费状态，系统就以财务确认为触发点进行状态自动修改。
第二优化内容：由于是产品内购，所以我们所有的购买信息都是标准化且可以直接获取到，那么此时完全不需要再让CRM用户去录入一遍购买信息与权限，直接使用系统内置信息就行了。
第三个优化内容：作为优秀的产品设计必须要考虑到意外性与扩展性，假设就是出现要去调整付费信息与权限的场景，如果我们直接武断的拿走调整功能，届时系统就不再支持了。但是这个场景又不是非常高频，所以要如何设计呢？
这里我们就引入了判断，如果CRM管理员不做任何修改，信息流与权限流直接就使用默认而出现了意外情况可以随时上线调整，这样就解决了这个看似矛盾的问题，同时也将绝大场景下操作进行了精简，由2步操作变为了0步与低频的1步。
在做完上述优化后让我们再看一下两者的流程效率对比：

文章插图
通过这样拆分我们清楚的看到了这次优化的效果，优化最高提升了接近76%的操作，这对于一个流程来说几乎是脱胎换骨的提升。
2. 着手方向2：功能生命周期这里的概念相对于上面的来说就很容易理解了，功能生命周期由软件生命周期演化出来的一个参考维度，是指一个功能从上线到迭代被更新或替代的时间周期。通过这里我们可以看出来产品设计能力的高低，能力高决定功能生命周期长，反之就短。
对于B端产品来说假如一个功能生命周期过短，都意味着每次的开发人力被浪费了，此外更严重的是新的可盈利的开发时间被延误。所以不仅仅再是此功能需要返工，同时新的模块开发进度也被耽误，从而造成是两倍以上的损失。