交付效率报告的价值在于让团队和管理层据此调整动作，因此编写时应先确定报告服务的决策问题与统计口径，再固定一组少而稳的指标，按“口径说明—数据与图表—异常与原因—结论与行动项”的顺序成文。本文围绕这一顺序，给出指标定义、编写步骤、角色分工、填写示例和发布前检查清单，适用于以迭代或固定周期开展研发交付的团队。
要点总览（TL;DR）
- 编写交付效率报告先定口径：明确读者与决策问题，固定五类左右可重复计算的指标，并写清时间窗、数据来源、工作项范围、完成定义和计算方式。
- 正文按四段展开：口径说明、数据与图表、异常与原因、结论与行动项；每个数字可追溯，每条结论有数据支撑。
- 报告编写分四类角色：数据提供方、分析撰写方、评审方、行动项负责人，交接时点写清楚，行动项在下期报告中闭环验证。
- 发布前逐项核对口径一致性、数据可追溯、异常分类、结论支撑和行动项完整性；口径不明、数据不可追溯、结论无行动项属于阻断项。
报告先定口径：写给谁、统计什么、按什么时间窗
编写交付效率报告的第一步是写清楚口径，再开始拉数据。口径决定了数字能否跨期比较，也决定了读者能否据此做出判断。建议在动笔前用一张口径说明表把关键要素固定下来，之后每期沿用，变更时单独注明。
先确认读者与决策问题
同一组指标，面向不同读者时呈现重点不同。编写前先回答“这份报告要支撑谁做什么决定”：
- 团队复盘：关注本周期内哪些工作项拖长了交付周期、在制品是否堆积，结论落到具体工作项和调整动作。
- 项目管理层：关注按期交付率与吞吐量的趋势，判断资源投入与排期是否需要调整。
- 跨部门例会：关注与其他团队的交接环节对交付周期的影响，结论落到协作约定。
读者确定后，报告的范围也随之确定：只统计该读者关心的团队、项目或工作项类型，避免把不同范围的数据混在一张图里比较。
指标选择：少而稳、可重复计算、与交付动作相关
指标并非越多越好。建议每期固定使用五类左右指标，保证每期都能用同样方式算出，且指标变化能对应到团队可调整的动作。常用指标及定义如下：
| 指标 | 定义 | 反映的问题 |
|---|---|---|
| 需求交付周期 | 从需求进入开发队列到完成定义所规定状态的时长，通常取中位数或85分位 | 整体交付快慢与长尾拖延 |
| 吞吐量 | 统计周期内达到完成定义的工作项数量 | 团队实际产出规模 |
| 流动效率 | 活跃工作时间占交付周期的比例 | 等待与阻塞占用的时间 |
| 在制品数量 | 统计时点处于进行中状态的工作项数量 | 并行任务是否过多导致切换损耗 |
| 按期交付率 | 在承诺日期内完成的工作项占承诺总数的比例 | 承诺兑现的稳定程度 |
选择指标时逐条自问：这个指标能否用现有数据重复算出？它变化时团队是否有对应动作可调整？两个问题都成立再纳入固定指标集。
统计口径的五个要素
每个指标都要写清以下要素，缺一项就可能在跨期比较时产生歧义：
- 时间窗：统计起止日期，以及按进入时间还是完成时间归入周期。
- 数据来源：工作项系统、流水记录或其他系统，注明导出时间。
- 工作项范围：包含哪些项目、工作项类型，排除哪些（如缺陷修复、技术任务是否计入）。
- 完成定义：工作项达到哪个状态才算完成，是否要求已上线或已验收。
- 计算方式：周期取均值、中位数还是分位数，比例的分母如何确定。
这一步的输入是读者需求与现有数据源，动作是逐项确认并填表，输出是一份口径说明表，完成标志是所有参与编写的人对表中每一行无异议。
按四段结构成文：口径说明、数据图表、异常原因、结论行动
口径确定后，正文按固定四段展开。固定结构的好处是读者每期都能快速定位信息，编写者也不会遗漏关键部分。
第一段：口径说明
用半页以内的篇幅交代本期报告的时间窗、数据来源、工作项范围、完成定义，以及与上期相比是否有口径变更。必填项与上文口径说明表一致，变更处单独标注并说明原因。这一段由分析撰写方起草，评审方确认后定稿。
第二段：数据与图表
按指标逐一呈现，每个指标配一张图加一句结论式说明。呈现方式按信息目的选择：
- 趋势：折线图展示近若干周期的变化，用于判断指标是在改善还是恶化。
- 对比：柱状图对比本期与上期、或不同团队之间，用于定位差异。
- 分布：散点图或分位数展示交付周期的分布，避免均值掩盖长尾。
图表下方写明数据口径引用（对应第一段哪一条），确保读者能把数字和定义对上。这一段的输出是完整的指标图表集，完成标志是每个数字都能追溯到数据来源。
第三段：异常与原因
先识别异常：指标明显偏离历史区间、或与预期方向相反的点。然后区分两类原因：
- 数据问题：状态流转记录缺失、工作项未及时更新状态、范围口径变化导致的跳变。这类问题应修正数据或注明，不进入流程改进讨论。
- 流程问题：在制品过多导致切换频繁、评审等待时间长、需求范围中途变更等。这类问题需要给出初步判断和待验证的假设。
原因描述写到可验证的程度，例如“本期在制品峰值达到团队人数的两倍，同期交付周期中位数上升”，避免只写“效率下降”。
第四段：结论与行动项
结论回应第一段确定的决策问题，行动项则要具体到可执行：每条行动项写明做什么、负责人、截止时间、验证方式（下期看哪个指标或哪个工作项状态）。行动项数量控制在团队一个周期内能完成的范围内，宁少勿多。
四段写完后通读一遍，检查结论是否都能在第二、三段找到数据支撑，行动项是否都能对应到某个异常。
角色分工与交付物：谁出数、谁分析、谁拍板
报告编写涉及四类角色，职责和交接时点写清楚，可以避免数据无人认领或结论无人执行。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 数据提供方 | 按口径导出工作项与流水数据，校验完整性 | 原始数据文件与导出说明 | 统计周期结束后第一个工作日 |
| 分析撰写方 | 计算指标、制作图表、初判异常原因、起草正文 | 报告初稿 | 数据交付后两个工作日内 |
| 评审方 | 确认口径、校准结论、审定行动项 | 评审意见与定稿 | 初稿完成后一个工作日内 |
| 行动项负责人 | 承接改进动作，在下期报告前反馈结果 | 行动项执行反馈 | 下期报告编写前 |
小团队中数据提供方与分析撰写方可以由同一人承担，但评审环节建议保留独立角色，避免口径和结论由同一人自行确认。行动项负责人的反馈应进入下一期报告的数据或异常部分，形成闭环。
报告所需的工作项状态流转、周期统计和行动项跟踪，如果分散在多个表格中手工汇总，容易在交接时出现口径不一致。ONES 可以承载工作项的状态流转与周期数据，报告中的指标可从同一数据源导出，行动项也可作为工作项指派负责人并跟踪状态，使每期报告的口径与上期保持一致、行动项有据可查。
一份填写示例：两周迭代的交付效率报告
以下示例为演示情景，数据为虚构，用于说明写法，不代表任何真实团队的水平。
示例背景与统计范围
某研发团队按两周迭代交付，本期统计窗口为某月第1周至第2周，数据来源为工作项系统导出记录，范围为该团队负责的两个项目中的需求类工作项，完成定义为实现完成并通过验收。上期口径相同，无变更。
指标数值与图表呈现
- 需求交付周期中位数：9.5天，上期8.2天，折线图显示连续两期上升。
- 吞吐量：本期完成14项，上期16项。
- 流动效率：52%，上期61%。
- 在制品数量：期末进行中18项，团队人数9人。
- 按期交付率：79%，上期86%。
异常识别与原因描述
异常点有两处：交付周期中位数上升且流动效率下降；在制品数量达到团队人数的两倍。初步判断为流程问题：迭代中期插入若干紧急需求，导致并行任务增多、切换频繁。同时发现3个工作项状态更新滞后，属于数据问题，已在计算中按实际完成时间修正并注明。
结论与行动项写法
结论：本期交付变慢的主要原因是迭代中期需求插入导致在制品过高。行动项示例：
- 迭代内新增需求统一进入下期排期，紧急插入需评审方确认——负责人：迭代负责人，截止下期迭代开始前，验证方式：下期在制品峰值不超过团队人数的1.5倍。
- 每日站会检查进行中工作项状态是否及时更新——负责人：各工作项负责人，验证方式：下期数据问题条数降为零。
示例中每个结论都能对应到具体指标，每条行动项都能在下期报告中找到验证依据，这是报告可用的基本标准。
完成检查：发布前逐项核对的清单
报告定稿后、发布前，按以下清单逐项核对，全部通过再发出。
| 检查项 | 通过标准 |
|---|---|
| 口径一致性 | 与上期口径逐项一致；有变更的已单独注明并说明原因 |
| 数据可追溯 | 每个数字都能对应到数据来源、导出时间和工作项范围 |
| 异常分类 | 数据问题与流程问题已分开描述，数据问题已修正或注明 |
| 结论有支撑 | 每条结论都能在数据或异常部分找到对应依据 |
| 行动项完整 | 每条行动项有负责人、截止时间和验证方式 |
| 读者匹配 | 报告重点与第一段确定的读者和决策问题一致 |
以下情况视为阻断项，出现任一项应退回修改后再发布：口径不明或与上期不一致且未注明；数据无法追溯到来源；结论没有对应行动项。检查通过后，报告按固定渠道发布，并将行动项同步给负责人，作为下期报告的输入。
常见问题
团队刚开始做交付效率报告，指标能不能先少选几个？
可以。起步阶段建议先固定三到四个指标，例如需求交付周期、吞吐量和在制品数量，保证每期都能用同样方式算出，再逐步补充流动效率和按期交付率。指标少但口径稳定，比指标多但每期算法不同更有比较价值。需要留意的是，指标一旦纳入固定集，就不要在期中随意更换定义；确需调整时在报告口径说明中单独注明变更原因和影响范围。
报告里的数据由多个系统导出，口径对不上怎么办？
先以报告口径说明表为准，逐项核对各数据源的时间窗、工作项范围和完成定义是否一致。常见差异来自状态更新滞后、工作项类型统计范围不同、按进入时间还是完成时间归入周期不一致。处理方式有两种：一是统一从一个可追溯的数据源导出，二是在报告中注明差异并说明采用哪一口径。差异无法消除时，应在异常部分作为数据问题单独说明，不混入流程改进讨论。
行动项上期定了但没完成，这期报告怎么写？
如实记录并说明原因，不删除也不重复挂账。建议在结论与行动项部分保留上期行动项的当前状态：已完成、进行中或未启动，未完成的写明卡点和新的截止时间。如果同一行动项连续多期未推进，应把它作为异常提出来，重新判断是负责人资源问题、行动项本身定义不清，还是问题判断有误。行动项跟踪本身也是报告闭环的一部分，可以在工作项系统中指派负责人并更新状态，下期报告直接引用。
报告周期和迭代周期不一致时，统计时间窗怎么定？
以报告读者的决策节奏为准，同时保证跨期可比。如果报告按月出、迭代按两周跑，可以按自然月统计，在口径说明中写明包含哪几个迭代、跨月迭代的工作项按完成时间归入哪一期。关键是每期沿用同一规则，变更时注明。不要为了凑整月而截断迭代数据后不说明，否则读者无法判断指标变化来自交付本身还是统计方式。
交付效率报告需要给管理层看，和团队复盘版要分开写吗？
可以共用一套数据和口径，按读者调整呈现重点。团队复盘版侧重具体工作项、异常原因和可执行的调整动作；管理层版侧重趋势、按期交付率和需要决策的资源或排期问题。两版的口径说明应保持一致，避免同一指标出现两个数字。如果篇幅有限，建议先写完整版，再从中抽取管理层关心的指标趋势和结论，而不是另起一套算法。
