开发者体验：度量模型设计

基于与客户的协同价值出发，设计相应的度量模型，构建适应度函数持续演进。

目录

1. 核心要素
   1. 基于协同价值
   2. 以过程改进为核心
   3. 适当的不可量化指标
2. 开发者体验度量模型示例
   1. 度量模型示例：API 度量
   2. 度量模型示例：APP
   3. API 指标示例： TTW
3. 度量体系度量与优化
   1. 用户体验管理
4. 案例
   1. Spotify
      1. Time-to-10th PR
      2. Proxy metrics
      3. 其它

---

核心要素

基于协同价值

即以帮助客户创造价值为出发点，设计度量体系。

以过程改进为核心

采用在《演进式架构》中推荐的 “适应度函数”，也是一个不错的方式。

又或者是采用流畅度模型 来进行定义。

适当的不可量化指标

在度量型中引入过度的量化指标，将会导致团队采用指标驱动的方式。过度追求指标的达成率，由于指标与 KPI 间的关系，会导致团队铤而走险 —— 采用非常规手段，达成指标。

开发者体验度量模型示例

度量模型示例：API 度量

指标示例：

Nordic API：Weekly Active Tokens (WAT)、Time to First Hello World (TTFHW)

API 开发者体验度量模型 - 如何改进：

错误呈现	文档体验	易用性	交互式	触点	支持
错误描述	开发者门户	一键式安装	低配置/零配置	文章	问题反馈渠道
报错即文档	发布日志	自动化版本迁移工具	声明式使用	演讲/分享	问题响应时间
报错即修改建议	代码生成文档	自助式搭建	可交互文档	Hackathon	开发者即服务
	版本迁移指南		沙盒及产品环境		开发者社区

API Maturity

度量模型示例：APP

指标	描述
TTFHW	开发者了解系统应用开源仓库，到可以修改定制编译成可以运行的 APP 所用的时间
TTFPA	从应用版本发布到第一个使用该版本源码修改第三方应用所用的时间
Dev-NPS	开发者将该API推荐给其它开发者的净推荐值

API 指标示例： TTW

TTW, Time to Wow

改进方式：

• 编写特定使用场景的文档
• 提供沙盒环境

Deno 示例：https://dash.deno.com/playground/phodal

refs: Growth Hacking: Creating a Wow Moment

度量体系度量与优化

开发者体验优化相关的步骤：

1. 定义价值度量维度
2. 匹配用户旅程，细化维度至可量化的指标
3. 建立体验度量体系
4. 度量与诊断
5. 分析与体验提升
6. 构建体验管理机制

从模式上来说，它和用户体验是极为相似的，同样的也是出于指标度量的维度来考虑问题的。

用户体验管理

1. 理解现有业务
   • 理解现有业务。进行桌面研究并执行内部调研（业务专家、一线员工等），理解关键业务
   • 执行深度用户研究。执行用户研究，制定目标用户画像。
   • 建立客户全渠道体验旅程。定义各触点渠道职能及互通策略，找到影响用户体验的关键触点
2. 搭建体验度量体系
   • 明确客户北极星体验指标。确定与核心商业目标相匹配的客户体验北极星指标
   • 行业框架研究。分析行业相关框架，总结出关键体验维度
   • 顾客视角的体验需求分析。通过用户之声等方式分析体验需求，进行归因分析定位到问题核心
   • 定义体验度量维度。根据业务目标下的价值维度，结合痛点的反向提炼，确定体验评估的维度以及评判的依据
   • 匹配用户旅程, 细化维度至可量化的指标。将度量维度基于各旅程阶段进行匹配与拆分，形成量化的指标和具象的问题用于批量收集
   • 建立体验度量体系。将所有维度和量化指标整合形成客户体验度量体系
3. 体验诊断与优化
   • 体验度量与诊断。确定各指标的度量方法和数据采集方式，进行数据处理，得到产品的体验评分
   • 分析与体验提升。从度量结果进行各维度的体验诊断，并从用户体验五要素进行体验提升
4. 体验管理机制搭建
   • 体验管理机制搭建。初步建立体验管理体系，包括运营机制规划及责任体系规划。明确度量体系实施方式，定义参与角色与职责，产品各周期的目标，实现产品的提效跟踪

案例

Spotify

How we measure Backstage success at Spotify

两个主要指标：

• 开发者的生产力是产出（即完成的工作数量）与投入（即努力、时间）的比率。这个指标很容易衡量，但它并不能说明全部问题。
• 开发者的效率是通过每单位最佳产出所使用的资源（即时间、计算能力、人力资源）的数量来衡量。它说明了所有需要的投入，所以你可以看到团队是否做了足够多的正确工作。

指标：

Time-to-10th PR

内部

Proxy metrics

指标	描述
我们的开发人员在说什么	每个季度我们都会通过 EngSat（Spotify 的官方工程满意度调查） 收到反馈。
插件贡献	查看开发的插件总数，有多少插件贡献来自核心 Backstage 团队之外的团队，以及至少贡献了一个插件的团队总数。
易于发现	换句话说，单个贡献者能够在几分钟内从卡住到解开。我们发现，对于不断发展的工程组织来说，维护一个在搜索的帮助下易于导航和探索的共享知识库非常重要。在 Spotify，我们使用搜索成功率、点击率和搜索结果相关性等指标。
减少上下文切换	减少上下文切换可以帮助工程师留在“区域”中。我们测量工程师为了完成某项工作而必须与之交互的不同工具的数量（即推动更改，将其投入生产并验证它没有破坏任何东西）。
传统指标	这些指标包括访问量（月活跃用户、日活跃用户等）和页面浏览量。大多数 Spotify 工程师每天都会访问 Backstage。

其它

指标	描述
每个开发人员/天的合并	花在不同工具之间和寻找信息上的时间更少意味着有更多时间专注于交付代码。 如果您按领域（服务、网络、数据等）对贡献进行分类，则可以确定第二级瓶颈。
部署到生产环境	上面指标的相近。工程师将更改推送到生产中的次数有多少？
MTTR	凭借对微服务生态系统中所有部分的明确所有权以及将所有工具集成到一个地方，Backstage 使团队能够更快地找到故障的根本原因并修复它们。
T 型工程师	T 型工程师是能够为不同工程领域做出贡献的人。拥有 T 型人的团队的瓶颈更少，因此可以更一致地交付。由于工具和基础设施在域之间是一致的，并且信息集中可用，因此后台更容易成为 T 型。
碎片化	软件模板有助于推动软件生态系统的标准化。通过测量不同软件组件之间的技术差异，可以了解生态系统中的整体碎片化情况。示例可能包括：框架版本、语言、部署方法和各种代码质量测量。