交付效率报告示例通常由一张指标表和一段结论组成：表格按“统计口径—数据来源—本期数值—上期数值—变化—偏差说明”组织，覆盖周期时间、吞吐量、在制品、流动效率、交付准时率五项核心指标；结论段落说明本期主要偏差和下一步动作。下面给出一份已填写的季度样例，数值均为演示情景，供研发负责人、项目经理或效能度量岗直接替换成团队真实数据使用。
要点总览（TL;DR）
- 示例由一张七列指标表和一段结论组成，覆盖周期时间、吞吐量、在制品、流动效率、交付准时率五项指标，可直接替换为团队真实数据。
- 周期时间按需求进入开发到上线取中位数，吞吐量按完成项数统计，在制品与流动效率结合看能区分并行过多与队列挤占两类问题。
- 偏差说明先写可核对的事实，再写原因假设，避免“效率有待提升”这类无法转化为动作的评价。
- 换团队时保留口径与来源两列，按交付形态增减指标、按节奏调整周期，对照期至少保留一个。
- 示例数值为演示情景，不能作为行业基准或考核线；口径中途变更需注明并重算对照期。
这份示例要解决什么问题
这份示例回答的是一个具体问题：交付效率报告长什么样，每个格子该填什么。它面向研发负责人、项目经理和承担效能度量职责的岗位，使用方式是先照抄表格结构，再把演示数值替换为本团队数据，最后按示例的写法补一段结论。读者拿到它，应当能在一到两个小时内产出一份可提交的季度报告初稿。
示例的交付物有两部分。第一部分是报告表格，包含指标名称、统计口径、数据来源、本期数值、上期数值、变化和偏差说明七列；第二部分是表格下方的结论段落，写清本期主要偏差与下一步动作。两部分合起来才算一份完整报告，只有表格没有结论，读者无法判断数字意味着什么。
需要提前说明的是，示例中的所有数值、团队名称和业务背景均为演示情景，不对应任何真实团队，也不能作为行业基准或考核线使用。示例的价值在于结构和写法，数字本身只用于演示如何填写。发布执行流程、上线操作、等待与阻塞的具体定位不在本文范围内，这些内容属于研发交付管理和流动效率专题的讨论对象。
完整示例：一份季度交付效率报告
以下是一份演示情景下的季度报告。假设某研发团队负责一条业务线的迭代交付，本季度与上季度团队规模基本持平，需求来源为业务方提出的功能需求与优化项。报告统计周期为自然季度，统计对象为本季度内进入开发的需求项。
| 指标 | 统计口径 | 数据来源 | 本期数值 | 上期数值 | 变化 | 偏差说明 |
|---|---|---|---|---|---|---|
| 周期时间 | 需求从进入开发到上线的时间，取中位数 | 需求工作项的状态流转记录 | 14 天 | 11 天 | +3 天 | 本季度有两个需求在联调阶段等待外部接口，单个需求停留 6 天以上，拉高了中位数 |
| 吞吐量 | 本季度完成并上线的需求项数 | 需求工作项的完成状态 | 26 项 | 24 项 | +2 项 | 完成项数小幅上升，但其中 5 项为小优化，单项目工作量低于上季度平均水平 |
| 在制品 | 季度末仍处于开发中或待测试状态的需求项数 | 季度末工作项状态快照 | 9 项 | 6 项 | +3 项 | 季度末集中启动了一批需求，其中 4 项处于开发中，尚未进入测试 |
| 流动效率 | 活跃工作时间占周期时间的比例 | 状态流转时间戳，按状态归类计算 | 42% | 51% | -9 个百分点 | 等待评审与等待联调的时间占比上升，与周期时间延长相互印证 |
| 交付准时率 | 按承诺上线日期完成的需求项数占应交付项数的比例 | 需求工作项的承诺日期与实际上线日期 | 81% | 88% | -7 个百分点 | 5 项延期，其中 3 项因联调等待，2 项因需求范围在开发中变更 |
结论段落（示例写法）：本季度交付效率较上季度有所下降。周期时间从 11 天延长到 14 天，流动效率从 51% 降到 42%，两项指标同向变化，说明时间主要消耗在等待环节而非开发本身。交付准时率降至 81%，5 项延期中有 3 项与外部接口联调等待相关，2 项与开发中需求范围变更相关。吞吐量虽从 24 项升至 26 项，但新增部分以小优化为主，不能据此判断交付能力提升。下一步动作有三项：一是与外部接口方约定联调窗口，将联调等待纳入迭代计划；二是对开发中变更的需求建立变更记录，评估变更对承诺日期的影响；三是控制季度末同时在制需求数量，避免在制品堆积延续到下季度。
逐项解释：每个字段为什么这样填
周期时间为什么按“进入开发到上线”统计
周期时间的起点和终点决定了这个数字的含义。示例选择“进入开发”作为起点，是因为在此之前需求还处于评审和排期阶段，受业务决策影响大，纳入统计会让研发团队难以通过自身动作改善指标。终点选择“上线”而非“开发完成”，是因为只有上线才算真正交付给用户。取中位数而非平均值，是为了避免个别超长需求拉偏整体判断；如果团队更关注最差情况，可以同时补充 90 分位数值，但要在口径列写清楚。
吞吐量按项数还是按故事点
示例按完成项数统计，理由是项数口径简单、跨季度可比，且数据直接从工作项状态取得，不依赖估算质量。按故事点统计能反映工作量差异，但前提是团队估算口径稳定；如果估算标准在季度间发生调整，趋势对比就会失真。一个折中做法是主指标用项数，备注中说明本季度完成项的工作量分布，示例中的偏差说明正是这样写的：项数上升但新增部分以小优化为主，避免读者误读为产能提升。
在制品与流动效率如何相互印证
在制品是时点数据，反映季度末有多少需求同时处于未完成状态；流动效率是区间数据，反映周期时间内有多少比例处于活跃工作状态。两者结合看，能区分两种不同的问题：在制品高而流动效率正常，说明团队并行处理能力强但入口需求过多；在制品高且流动效率低，说明需求在队列中互相挤占，等待时间被放大。示例中在制品从 6 项升至 9 项、流动效率从 51% 降到 42%，属于后一种情况，结论段落据此把动作指向控制同时在制数量。
偏差说明写事实与原因假设
偏差说明是整张表最容易被写坏的一列。示例的写法是先陈述可核对的事实，再给出原因假设，两者用“与……相关”“可能因为”这类措辞区分。例如“5 项延期，其中 3 项因联调等待”，延期项数和原因是可核对的事实；“说明时间主要消耗在等待环节”是基于多项指标同向变化的推断。需要避免的是“本季度效率有待提升”“团队协作不够顺畅”这类笼统评价，它们既无法核对，也无法转化为动作。
数据从哪里来
示例中五项指标的数据来源都指向同一类记录：需求工作项的状态流转与时间戳。这类数据要在日常工作中自然沉淀，而不是季度末回头补录。以 ONES 为例，需求作为工作项在系统中流转，每次状态变更留下操作记录和时间戳，周期时间、在制品快照和流动效率都可以从这些记录中按口径提取，报表按项目或周期汇总。团队如果使用其他研发管理工具，只要状态流转记录完整，同样可以支撑这张表。数据来源列写清楚具体记录类型，是为了让下一个接手的人能复现同样的数字。
可迁移规律：换团队换季度怎么改
示例的结构可以整体迁移，需要替换的是指标集合、统计周期和对照期。迁移时保留“口径”和“来源”两列不动，这两列是报告可复现的基础；数值列和偏差说明列随团队数据更新。
- 指标按交付形态增减。以项目制交付为主的团队，可以把吞吐量换成“按里程碑完成的项目数”；维护型团队可以增加“缺陷修复周期时间”。增减指标时同步更新口径列，新增指标要有对应的数据来源，否则宁可先不加。
- 周期按月、季度或版本节奏调整。迭代节奏快的团队按月出报告，对照期取上月；按版本发布的团队以版本为周期，对照期取上一版本。周期越短，单期数值波动越大，偏差说明要更注意区分偶发因素。
- 趋势对比至少保留一个对照期。只有一个时间点的数字无法判断好坏，示例保留上期数值和变化列。条件允许时可以拉三个周期，用简短的文字描述走向，不必画图。
- 结论段落固定写两部分。前半段写本期主要偏差，指明哪几项指标变化、变化之间是否相互印证；后半段写下一步动作，每条动作对应一个偏差，写清由谁在什么时间做什么。动作数量控制在三条左右，多了难以跟踪。
如果团队第一次做这类报告，建议先用一个季度建立基线，第二季度开始加对照期和变化列。基线期的报告可以只有本期数值和偏差说明，不必强行填写变化。
适用边界与常见误用
这份示例的适用范围是帮助团队组织一份内部交付效率报告。它不提供行业基准值，示例中的 14 天周期时间、42% 流动效率只用于演示填写方式，不同业务类型、不同需求粒度的团队数值差异很大，直接拿示例数字做横向比较或设定考核线会得出错误结论。发布执行流程、上线操作规范属于研发交付管理的范畴，等待与阻塞的具体定位方法属于流动效率与瓶颈分析的范畴，本文均不展开。
常见误用有四种，填写前值得对照检查：
- 只列数字不给偏差说明。表格填满但偏差说明列写“正常”“无明显变化”，读者无法判断是否需要采取动作。每一项指标变化都应有一句事实加一句原因假设。
- 口径中途变更导致趋势失真。例如上季度周期时间按平均值统计，本季度改为中位数，变化列的数字就失去意义。口径调整应在报告中注明，并把对照期数据按新口径重算。
- 把演示数值当基准。示例数字不对应任何真实团队，不能作为目标值下发，也不能用于团队间排名。
- 指标越多越好。五项指标已经能覆盖交付速度、节奏和准时性，继续增加指标会稀释结论段落的重点。确有需要时，先确认新增指标有稳定的数据来源和明确的使用场景。
报告写完后可以用三个问题自检：每个数字能否追溯到具体记录；每项变化是否配有偏差说明；结论段落的每条动作是否对应一个偏差并有责任人和时间。三问都能回答，这份报告就达到了示例所展示的完成度。
常见问题
团队第一次做交付效率报告，没有上期数据怎么办？
第一个季度可以先建立基线，报告只填本期数值和偏差说明，变化列留空或标注“基线期”。从第二个季度开始补上对照期和变化列，趋势对比才有意义。如果团队此前有零散的历史记录，也可以按新口径回溯重算一个对照期，但要在报告中注明重算方式，避免读者误以为数据是当期采集的。
周期时间用平均值还是中位数，两者差别大吗？
差别可能很大。需求周期时间通常呈偏态分布，少数超长需求会把平均值拉高，中位数更能代表多数需求的典型耗时。示例取中位数，是为了让指标反映团队日常交付节奏。如果团队更关注最差情况，可以同时补充 90 分位数值，但要在口径列写清楚两个数字各自的含义，并保持跨季度一致，否则趋势对比会失真。
报告里发现流动效率下降，下一步该做什么？
先结合在制品判断问题类型。在制品高且流动效率低，通常是入口需求过多、需求在队列中互相挤占，动作应指向控制同时在制数量、明确进入开发的前置条件。在制品正常而流动效率低，则要拆解等待时间分布，看评审、联调、测试哪个环节停留最长。等待与阻塞的具体定位方法属于流动效率与瓶颈分析的专题内容，本文示例只负责把偏差如实呈现出来。
不同团队的报告可以直接横向比较吗？
不建议直接比较。需求粒度、业务类型、外部依赖程度不同，周期时间和流动效率的绝对值差异很大。示例中的数值只用于演示填写方式。如果确实需要跨团队对比，应先统一统计口径和数据来源，并说明各团队的交付形态差异，把比较限定在趋势方向而非绝对数值上。
报告数据需要季度末专门补录吗？
不需要，也不建议。示例中五项指标的数据来源都是需求工作项的状态流转与时间戳，这类记录应在日常流转中自然产生。以 ONES 为例，需求作为工作项在系统中流转，每次状态变更留下操作记录和时间戳，周期时间、在制品快照和流动效率可按口径从这些记录中提取。季度末补录既增加工作量，也容易因记忆偏差导致数据失真。
