开发者体验看摩擦点
开发者体验度量聚焦日常摩擦：等待构建、排查不稳定的测试、修复本地环境、等评审、翻找文档。它不做宏大评分，而是把摩擦点清单化，用频率与痛感排序，优先处理既高频又刺痛的项。
基本信息
| 对象 | 构建等待、环境问题、评审等待、文档查找 |
|---|---|
| 方法 | 时间日志、短问卷、工具遥测 |
| 排序 | 频率乘以痛感，例如每周次数乘主观分 |
| 节奏 | 短问卷周期化，短而稳定比长而一次性更有效 |
典型使用场景
- 构建加速：构建等待频繁且痛感高，先做增量构建与缓存
- 测试稳定性：不稳定的用例反复重跑，先隔离再修根因
- 环境修复：本地环境初始化失败率高，做容器化与一键恢复
- 评审流转：评审排队时间长，设响应时限与评审清单
- 文档检索：找文档耗时，就建立索引与单一可信入口
摩擦清单示例
摩擦清单示例
# 按 频率乘痛感 排序，优先治理高值项
摩擦项 频率每周 痛感 1-5
构建等待超过 10 分钟 5 4
测试不稳定需要重跑 6 3
环境初始化失败 2 5 # 痛感高，优先治理
评审排队超过 1 天 4 4采集方式与适用场景
| 方式 | 优点 | 局限 |
|---|---|---|
| 时间日志 | 能定位真实耗时分布 | 需要手动记录，容易中断 |
| 短问卷 | 成本低、可比 | 偏主观，受近期事件影响 |
| 工具遥测 | 客观且可持续 | 只能看系统内活动，看不到等待与打断 |
| 结构化访谈 | 能挖到未预期的摩擦 | 样本小，耗时较长 |
三种来源的偏斜方向不同：遥测看不到等评审这类人际等待，问卷看不到自己没意识到的摩擦，日志会漏掉频繁但极短的中断。至少两两交叉验证，再排优先级。
只收集不治理比不收集更糟：团队会认为反馈只是走过场，之后问卷的回收率与真实性一起下降。每次采集后至少公布要处理哪两项、谁负责、何时复看。