路线图交付桑基图：计划与交付
比较一个季度的路线图承诺了什么，与实际交付、顺延或砍掉了什么，包括季度中途新增的工作。
路线图交付桑基图跟踪计划项和季度中途新增项，看哪些已交付、哪些顺延、哪些被砍掉，并给没有交付的条目补上原因。
示例有 72 个路线图条目：季度初计划的 60 个，分属增长、可靠性、平台和客户请求，另有 12 个是季度中途新增的。总计 45 个已交付，19 个顺延，8 个被砍掉。最后一列给出顺延的原因（低估、被依赖阻塞、产能被新增工作占用）和砍掉的原因（重新排优先级、不再需要）。
它与桥形图的不同在于没有期初和期末余额，只有承诺及其结局。平台主题 15 项交付了 7 项，是四个主题中最弱的；12 个新增条目中有 8 个交付，这就是新增工作与计划争夺资源的方式。其背后的产能请看 /zh/sankey/engineering-time-allocation。
如何阅读此图表
- 72 个条目中，45 个（63%）已交付，19 个（26%）顺延，8 个（11%）被砍掉。
- 60 个计划条目中有 37 个（62%）交付；12 个新增条目中有 8 个（67%）交付。
- 平台交付最少：15 个中的 7 个（47%），6 个顺延。
- 低估是顺延的最大原因：19 个条目中的 8 个。
图表背后的数据
数字为虚构，仅作说明，并非任何真实机构、团队或系统的数据。单位为路线图条目，仅一个季度。
| 来源 | 目标 | 数量（个路线图条目） |
|---|---|---|
| 增长 | 已交付 | 13 |
| 增长 | 顺延 | 5 |
| 增长 | 砍掉 | 2 |
| 可靠性 | 已交付 | 12 |
| 可靠性 | 顺延 | 2 |
| 可靠性 | 砍掉 | 1 |
| 平台 | 已交付 | 7 |
| 平台 | 顺延 | 6 |
| 平台 | 砍掉 | 2 |
| 客户请求 | 已交付 | 5 |
| 客户请求 | 顺延 | 3 |
| 客户请求 | 砍掉 | 2 |
| 季度中途新增 | 已交付 | 8 |
| 季度中途新增 | 顺延 | 3 |
| 季度中途新增 | 砍掉 | 1 |
| 顺延 | 低估 | 8 |
| 顺延 | 被依赖阻塞 | 7 |
| 顺延 | 产能被新增工作占用 | 4 |
| 砍掉 | 重新排优先级 | 5 |
| 砍掉 | 不再需要 | 3 |
同样的数据（CSV）
source,target,value
增长,已交付,13
增长,顺延,5
增长,砍掉,2
可靠性,已交付,12
可靠性,顺延,2
可靠性,砍掉,1
平台,已交付,7
平台,顺延,6
平台,砍掉,2
客户请求,已交付,5
客户请求,顺延,3
客户请求,砍掉,2
季度中途新增,已交付,8
季度中途新增,顺延,3
季度中途新增,砍掉,1
顺延,低估,8
顺延,被依赖阻塞,7
顺延,产能被新增工作占用,4
砍掉,重新排优先级,5
砍掉,不再需要,3运作方式
列出季度初承诺的路线图
按主题把条目分组，并单独标出季度开始后新增的内容。
记录每个条目的结果
使用三种结果：已交付、顺延或砍掉。事先决定部分交付的条目怎么算。
为每个未完成项加一个原因
从一个简短的列表里为每个条目选一个主要原因，每个季度都用同一份列表。
检查平衡
顺延和砍掉流出的条目数必须等于流入的。已交付在第二列结束。
常见问题
条目要按规模加权吗？
计数会把一周的条目和六周的条目同样对待。如果规模重要，可以改用以天计的投入作为单位并写明。
交付率低就是不好吗？
本身不是。什么都能交付的路线图，可能定得过于保守。这张图用来追问条目为什么没完成，而不是设定目标。
编辑这张路线图桑基图
把示例作为你自己的图表打开，填入你这个季度的条目。