研发工时分配桑基图：团队产能
展示一个迭代的人天去了哪里：从团队到功能开发、缺陷修复、技术债、会议和值班，再到计划内与计划外。
研发产能桑基图显示一个团队的工作日究竟花在了哪里。它把计划内的工作和临时冒出来的工作分开，让计划外工作不再藏在速度数字里。
示例是一个迭代中的 150 人天，来自三个团队。它们流向五类工作：功能、缺陷修复、技术债、评审与会议，以及支持与值班。最后一列把同样的人天分成计划内与计划外，所以迭代中途进来的缺陷，和计划会上承诺的功能，读起来是不同的。
大多数跟踪工具能告诉你团队的点数，却不容易看出平台团队 40 天里有 24 天花在了技术债和值班上。这张图用于讨论，而不是给人打分：人天只是估算，一个人的一天也可以拆给几类工作。关于计划内工作后来变成了什么，请看 /zh/sankey/roadmap-delivery。
如何阅读此图表
- 150 人天中，98（65%）是计划内的，52（35%）不是。
- 功能开发为 55 天（37%）；其中 50 天在计划内，5 天是迭代中途加入的。
- 25 天缺陷修复和 20 天值班全部是计划外：共 45 天，占产能的 30%。
- 平台团队 40 天里有 24 天（60%）花在技术债和值班上。
图表背后的数据
数字为虚构，仅作说明，并非任何真实机构、团队或系统的数据。单位为人天，仅一个迭代。
| 来源 | 目标 | 数量（人天） |
|---|---|---|
| 平台团队 | 功能开发 | 8 |
| 平台团队 | 技术债 | 12 |
| 平台团队 | 评审与会议 | 8 |
| 平台团队 | 支持与值班 | 12 |
| 产品 A 团队 | 功能开发 | 30 |
| 产品 A 团队 | 缺陷修复 | 12 |
| 产品 A 团队 | 技术债 | 5 |
| 产品 A 团队 | 评审与会议 | 13 |
| 产品 B 团队 | 功能开发 | 17 |
| 产品 B 团队 | 缺陷修复 | 13 |
| 产品 B 团队 | 技术债 | 3 |
| 产品 B 团队 | 评审与会议 | 9 |
| 产品 B 团队 | 支持与值班 | 8 |
| 功能开发 | 迭代开始时已计划 | 50 |
| 功能开发 | 计划外 | 5 |
| 缺陷修复 | 计划外 | 25 |
| 技术债 | 迭代开始时已计划 | 18 |
| 技术债 | 计划外 | 2 |
| 评审与会议 | 迭代开始时已计划 | 30 |
| 支持与值班 | 计划外 | 20 |
同样的数据（CSV）
source,target,value
平台团队,功能开发,8
平台团队,技术债,12
平台团队,评审与会议,8
平台团队,支持与值班,12
产品 A 团队,功能开发,30
产品 A 团队,缺陷修复,12
产品 A 团队,技术债,5
产品 A 团队,评审与会议,13
产品 B 团队,功能开发,17
产品 B 团队,缺陷修复,13
产品 B 团队,技术债,3
产品 B 团队,评审与会议,9
产品 B 团队,支持与值班,8
功能开发,迭代开始时已计划,50
功能开发,计划外,5
缺陷修复,计划外,25
技术债,迭代开始时已计划,18
技术债,计划外,2
评审与会议,迭代开始时已计划,30
支持与值班,计划外,20运作方式
选定一个周期
取一个迭代或一个月，列出扣除假期和休假后可用的人天。
把工作分成五六类
使用你的跟踪工具里已有的标签，例如功能、缺陷、技术债和支持。超过六类，中间一列就没法读了。
每个工作日只算一次
估算每个团队在每类工作上的人天，再标出哪些在迭代计划之内。
检查平衡
每类工作流出的人天必须等于流入的人天，总数必须等于产能。
常见问题
这是衡量生产力的指标吗？
不是。它显示时间去了哪里，而不是用得好不好。用它来讨论计划，比如为什么三分之一的产能是计划外的，而不是用来比较个人。
一天拆给两类工作时怎么算？
在数据里拆开：每类半天。每个周期使用同一条规则，图表才能互相比较。
编辑这张研发工时桑基图
把示例作为你自己的图表打开，填入你团队的人天。