如何衡量前端基建的效能价值？

关注「前端向后」微信公众号，你将收获一系列「用心原创」的高质量技术文章，主题包括但不限于前端、Node.js以及服务端技术

写在前面
不同于商用产品，对内的工具/平台大多没有明确的直接业务价值，需要通过可量化的指标来衡量其效能价值，本文试图建立一个可直接套用的数据指标框架，让内部工具/平台的价值也能看得见、说得清

一.分析生产活动的核心要素
从面向对象的角度来看，前端工程是对象和对象间的关系及交互行为

（摘自面向对象视角下的前端工程体系）

其中，对象分为主体对象与客体对象两类：

对象，是对前端应用生产活动中各个实体的抽象，其中一些对象是主体（比如充当不同角色的人），另一些是客体（比如工具、平台等各种具体事物），对象之间通过一系列交互行为来完成前端应用的开发和交付

即人与工具，是直接关系到生产力的核心要素：

工具越强大、越智能，人的操作效率越高、心智负担越小

P.S.心智指的是人认识事物的方法和习惯，会影响用户如何认知周遭世界以及如何采取行动，取决于对应角色的认知情况、记忆、主动获取教育与被动教育的渠道和方法、以及基于角色的竞品使用习惯等，具体见工具类产品的体验度量四象模型（1）

二.找出工具的关键目标
对工具而言，兼顾效率和体验是不变的目标，但不同工具的侧重点可能有所不同，例如：

• 不直面用户的底层工具：如构建模块、发布模块等，效率相对重要一些，体验次之

• 用户直接与之交互的上层工具：如调试器、发布平台等，更关注体验，虽然效率也同样重要

• 另一方面，工具总是为解决问题而生的，选用一个工具不外乎 4 种情况：

• 无可替代：唯一能够解决目标问题的工具，没得选，所以不论体验、效率如何都不得不用

• 体验最好：同类工具中使用体验最好的一款，精准满足需求，效率上和其它工具没有明显差距

• 效率最高：同类工具中效率最高的一款，迅速解决问题，明显比其它工具快很多

• 体验还不错，效率也过得去：同类工具中在体验和效率上取得平衡的一款，没有太明显的缺点，勉强能解决问题，用起来也不很麻烦

• 除去没得选的情况，在效率没有明显差距时体验更好的工具更受欢迎，效率能拉开明显差距的工具如果没有体验硬伤一定会很受欢迎，这毫无疑问

• 然而，需要注意的是，如果体验、效率方面的最优选项都有明显的缺点，此时用户更倾向于选择一个不上不下的替代工具，而不是长期忍受其缺点：

啊。。是啊。。我不就是不想用 xxx 了

三.建立效能价值的度量模型
确定了关键目标之后，接下来的问题是如何量化效率和体验，使之可衡量

衡量效率
类比工作效率的计算公式：

工作效率 = 工作总量 / 工作时间
工具效率可以定义为：

工具效率 = 问题规模 / 操作时间
问题规模仍然不是一个可量化的东西，进一步具象为时间成本：

工具效率 = （不用该工具解决所需的）时间成本 / （用该工具解决所需的）时间成本
那么，有 3 种情况：

• 比值等于 1：用不用工具都一样，工具没有带来效率提升

• 比值小于 1：还不如不用，因为用工具花的时间反而更多了

• 比值大于 1：用工具效率更高，数值越大，工具带来的效率提升越明显

衡量体验
体验不像效率一样能够通过统一的规则计算得出准确的数值，但也可以建立度量模型：

体验即产品与用户心智的重合程度（上图心智一行），工具的功能和性能越贴近用户的心理预期，体验评价越高，体现在：

• 易用程度：从用户心智向产品功能做映射，极致的易用是符合直觉，上手即用

• 稳定程度：从用户心智向产品性能做映射，极致的稳定是完全信任，从不怀疑工具会出问题

即：

工具体验 = 易用程度 * 稳定程度

也就是说，工具体验是易用程度与稳定程度的乘积，只要稍有不好用或不稳定的缺点，体验就会急剧下降

衡量效能价值
综上所述，工具带来的效能价值体现在 2 方面：

效能价值 = 效率价值 * 体验因子

其中：

• 效率价值：降低用户解决问题的时间成本，让用户更快速地解决问题

• 体验因子：减少用户的心智负担，让用户更轻松愉悦地解决问题

二者相辅相成，体验升级可能会提高效率，效率提升同样也可能带动体验

因此，在体验有保障的前提下，可以简单地将效率作为效能价值的衡量标准，用一个准确的比值即可量化效能价值

四.选择合适的数据指标
有了度量模型后，接着将具体的数据指标框进来

时间成本
基于以上分析，（体验有保障时）效率收益的直接体现是工具所能节省的时间成本，与用户量、使用频次、使用时长等密切相关：

• 用户量：累计用户数、日/周/月 UV、日新增用户数、日/周/月活跃用户数（期间操作过核心功能的用户数）

• 使用频次：日/周/月 PV、功能使用率、核心操作次数、日均使用次数

• 使用时长：核心操作时长

P.S.功能使用率 = 使用某项功能的用户数 / 总用户数，也能用来衡量不同功能对整体的贡献

例如：

每天节省的时间成本 = 日用户量 * 日功能使用率 * (不用该工具解决所需的时间 - 操作时间)
= 100 * 35% * (1.5人日 - 0.8人日）
= 24.5人日

此外，另一些侧面数据也能体现效能价值：

• 用户分布：目标用户数、用户***率、各属性用户占比、各属性用户***率

• 产出结果分布：数量、重要程度、平均时间、各属性产出结果占比

P.S.用户***率可简单理解为用户***率 = 现有用户数 / 目标用户数

例如：

覆盖2/3的目标用户，包括60%以上的一线开发人员、10%的测试人员
覆盖8大产品线，半年支持40多个项目，包括效果极好的xx重点项目

易用程度
易用程度同样也能通过一些数值来衡量：

• 用户满意度：用户投诉与咨询数/率、抽样调查满意度

• 操作难度：误操作次数

• 心智负担：帮助文档字数、注意事项条数

此外，一种产品经理常用的需求采集方法是观察真实用户的实际操作，将用户遇到的挫折记录下来，过程中不要打断和急于提供帮助，往往能够精准地发现一些使用问题

稳定程度
稳定程度可以从异常指标反映出来，例如：

• crash 率

• bug 数

• 操作失败次数

其中，操作失败是个模糊的定义，包括运行时错误、服务接口错误、搜索不到结果等等，稳定性问题极易破坏使用体验，进而大幅拉低效能，比如工具总崩溃，几乎没法用的话，效能价值就无从说起

五.有数据就用数据说话
之所以要建立可量化的数据指标，是为了用数据说话，验证此前的一些假设，为工具的迭代、优化提供指导方向：

• 新功能是否得到了用户的支持？功能使用率如何？宣传渠道有没有效果？

• 用户操作是否顺畅，所花费的实际时间与预期是否存在较大差距？

• 产出结果如何，ROI 是否足够高，有没有必要继续做下去？

用 PM 的成熟方法论做事