报告 · 集成
基于 Jira API 的团队 KPI 仪表盘
用数据而不是口头回答“这周团队做了什么？”
角色IT 业务分析师
- 自动化数据来源
- Jira API
- 跟踪看板中的 Jira 事项
- 1,333
- 客户报告的缺陷当天建单（Sprint 29）
- 100%
- 完成的承诺工作（Sprint 33）
- 84%
客户名称已隐去；例子和数据均经过模拟。流程、方法与成果数据是真实的。
问题
客户每周都会询问进度。从 Jira 手工汇总既耗时，又容易因为状态统计错误而出现偏差。团队内部也很难看出谁的负荷过重、哪个缺陷挂得最久。
有仪表盘之前
- 客户询问进度每周
- 从 Jira 手工汇总耗时，状态容易统计错
- 没人相信的数字
背景与角色
- 项目看板 1,333 个事项中有 624 个是我创建的，是团队中最多的。
- 客户不想为了了解进度而打开 Jira。
- 我的角色：统一 KPI 定义，通过 API 获取数据，搭建仪表盘，并为客户和主管撰写报告。
- 约束：API 密钥只有读取权限；不向团队之外泄露个人信息。
第 1 步：取数之前先确定 KPI 定义
KPI 含糊，仪表盘就没有意义。每个 KPI 都需要一个它要回答的问题、一个公式和数据来源。
KPI 定义每个指标只回答一个问题
| 回答的问题 | 公式 | |
|---|---|---|
| Sprint 完成率 | 本 Sprint 完成了承诺内容的多少？ | 已完成点数除以承诺点数 |
| 吞吐量 | 每周完成多少工单？ | 本周转为 Done 的工单数 |
| Cycle time | 一个工单从开始到完成需要多久？ | 从 In Progress 到 Done 的时长中位数 |
| 被阻塞 | 有什么卡住了？ | 标记为阻塞超过一天的工单 |
| 缺陷存续时长 | 未关闭最久的缺陷有多少天？ | 对未关闭的缺陷，用今天减去创建日期 |
| 缺陷率 | 每个已完成的 story 对应多少缺陷？ | 新建缺陷数除以已完成 story 数 |
| 客户反馈积压 | 还有哪些反馈未处理？ | 带客户反馈标签且未 Done 的工单 |
| 按人员统计的工作量 | 每个人手上有多少工作？ | 按经办人统计的未关闭工单 |
第 2 步：通过 Jira REST API 获取数据
GET /rest/api/3/search
jql = project = PRJ AND updated >= -14d
fields = summary, status, issuetype, assignee, created, labels, story points
expand = changelog
数据的流向
- Jira分页调用，直到取完所有工单
- 变更历史取进入 In Progress 和 Done 的时间点
- 计算 KPI按已确定的公式
- 匿名化经办人变为 Dev A、Dev B
- 仪表盘与周报
变更历史中的一个工单Cycle time 来自变更历史，而不是关闭日期
- 创建
- In Progress开始计时
- Done手动拖过去，没有关闭日期
- cycle time
第 3 步：仪表盘与周报
单页仪表盘：上方是一行 KPI，中间是图表，下方是各明细表。周报基于同一份数据撰写。
布局单页仪表盘
第 1 行
Sprint 完成率
周吞吐量
Cycle time
被阻塞
第 2 行
按周的吞吐量
第 3 行
被阻塞的工单附原因
未处理的客户反馈
按人员统计的工作量
第 4 步：用仪表盘做决策
与客户开会时仪表盘上的信号，以及随之而来的决定
| 决定 | |
|---|---|
| 缺陷存续时长集中在某一个模块 | 先留出时间清理缺陷，再接新的 story |
| 工作量集中在一个人身上 | 在做 Sprint 计划时重新分配 |
| 客户反馈积压持续增加 | 每周增加一个固定时段，用于对反馈进行分类 |
第 5 步：给客户的缺陷登记表
客户需要一个不用打开 Jira 就能跟进缺陷的地方。我搭建了一条把缺陷从 Jira 推送到 Google Sheet 的流程，表中有仪表盘和追踪重复缺陷的列，并配有运营 SOP。
缺陷登记表
- Jira 中的缺陷
- 数据导出与仪表盘自动运行
- 写入客户手工编辑的标签页确认后才执行
结果
Sprint 报告的数字可以核对：
已通过开发阶段的工作，Sprint 2974.1%58 项中的 43 项
客户报告的缺陷当天建单，Sprint 29100%
完成的承诺工作，Sprint 3384%
- 团队的进度和 KPI 通过直接从 Jira 取数的仪表盘向客户汇报。
- 每个 KPI 都有客户和主管一致认可的定义与公式。
- 周报不再依赖手工汇总。
我学到的
- 取数之前先与客户统一 KPI 定义。否则只会得到一个好看却没人相信的仪表盘。
- 在 Jira 中，状态变更历史是最可信的数据来源。
- 把问题放在报告最前面，是赢得客户信任最快的方式。
- Jira API
- REST API
- KPI
- 仪表盘
- Sprint 报告