研发吞吐量指在给定时间窗内完成并达到约定完成标准的研发工作项数量，计算核心是“分子（按完成口径计数的工作项）+分母（时间窗或投入规模）+统一单位”。常用公式为：吞吐量=时间窗内达到完成定义的工作项数÷时间窗（周/迭代），或按人均折算为工作项数÷投入人数÷时间窗。计算前须固定工作项类型、完成定义、计数单位、时间窗与缺失值处理规则，再按导出数据、清洗去重、分组计数、折算与交叉验证的步骤执行，并结合周期时间、在制品数量等指标解读，避免把单一计数当作效率结论。
要点总览（TL;DR）
- 研发吞吐量=时间窗内达到完成定义的工作项数÷时间窗（周/迭代/月）；需要人均口径时再除以投入人数。
- 计算前先固定四项口径：分子（完成定义与状态字段）、分母（时间窗或投入人数）、计数单位（需求、缺陷、任务是否混算）、统计范围（团队、项目、排除项）。
- 取数按导出→清洗去重→按完成时间归窗→分组计数→折算五步执行，跨窗口工作项按完成时间归窗，撤回重开以最终完成时间为准。
- 结果需与周期时间、在制品数量交叉验证，口径变更或团队调整后前后数据不可直接比较，也不宜设通用达标线。
先明确评估目标：吞吐量要回答什么问题
吞吐量是一个计数指标，算出来的数值本身没有意义，先要确定它服务于哪个判断。常见的用途有三类：观察团队或产品线的产能水平，评估交付节奏是否稳定，比较改进措施前后的完成数量变化。三类用途对时间窗和计数单位的要求不同，混在一起算会让结果无法解释。
用途确定后，再明确度量对象。对象可以是单个团队、一条产品线，也可以是某一类工作项（例如只统计需求）。对象越宽，数值越容易受工作项类型结构变化影响；对象越窄，数值越稳定但代表性有限。建议在评估目标说明中同时写清三件事：用途、对象、时间跨度。例如“评估某产品团队近六个迭代的需求交付节奏，用于观察改进前后的完成数量变化”。
需要提前说明吞吐量的解释边界：它只反映在约定口径下完成了多少工作项，不直接代表交付价值、质量水平或团队效率高低。同样完成20个需求，需求大小、拆分粒度和验收标准不同，实际投入可能相差很大。把吞吐量作为观察完成数量的入口，再结合周期时间、在制品数量等指标共同解读，才能支撑判断。
指标与范围：分子、分母和计数单位怎么定
吞吐量的指标定义可以拆成四个要素：分子、分母、计数单位、统计范围。四者需要在计算前写成一张指标定义卡，后续所有取数和计算都以此为准，避免不同人算出不同结果。
| 要素 | 定义内容 | 常见选项 |
|---|---|---|
| 分子 | 时间窗内达到完成定义的工作项数量 | 按完成时间落在窗口内计数；按状态字段判定完成 |
| 分母 | 时间窗或投入规模 | 周、迭代、月；人均口径再除以投入人数 |
| 计数单位 | 计入的工作项类型 | 需求、用户故事、缺陷、任务；单类统计或按约定混算 |
| 统计范围 | 纳入的团队、项目、状态与排除项 | 指定团队与项目；排除取消、重复、测试数据等工作项 |
计数单位是最容易出问题的部分。需求、缺陷、任务的颗粒度差异很大，混算会让数值随类型比例变化而波动。如果确实需要混算，应事先约定各类型的权重或分别统计后再汇总，并在指标定义卡中写明。统计范围同样要固定：纳入哪些团队和项目、哪些状态算完成、哪些工作项排除在外（如取消、合并、测试数据），这些边界一旦变化，前后数据就不可直接比较。
数据口径与证据：完成定义和取数规则
完成定义（DoD）决定分子怎么数。团队需要明确“完成”对应哪个状态字段，例如“已完成”“已验收”或“已关闭”，并确认该状态是否包含验收通过、文档齐备等条件。完成定义应写成可判定的规则，而不是“基本做完”这类模糊描述，否则不同人取数会得到不同结果。
取数规则表建议包含以下内容：
- 数据来源系统与导出方式，例如从工作项管理系统导出工作项列表及状态变更记录。
- 字段清单：工作项编号、类型、所属项目、当前状态、完成时间、创建时间、负责人、父级工作项。
- 去重规则：同一工作项多次导出或跨项目关联时，按工作项编号去重。
- 拆分与合并处理：拆分产生的新工作项按新编号计数，原工作项若已关闭则按规则排除；合并后的工作项只计一次。
- 缺失值处理：完成时间缺失的工作项不纳入分子，并在数据质量记录中标注数量。
- 跨窗口工作项：按完成时间归入对应时间窗，创建时间早于窗口不影响计数。
- 撤回重开：窗口内完成又被撤回重开的工作项，以最终完成时间为准；若最终完成时间落在窗口外，则从该窗口分子中剔除。
在 ONES 中，工作项的状态流转和完成时间由系统记录，ONES Performance 可自动收录系统内日常流转的研发数据并形成分析指标，减少手工整理数据源的工作。实际可用的字段名称、状态配置和导出方式以产品界面为准，取数前应先核对字段与完成定义的对应关系。
计算步骤：从原始数据到吞吐量数值
计算流程可以固定为五步，每一步都留下可复核的中间结果，便于他人复算。
- 导出：按取数规则表导出工作项数据，保留工作项编号、类型、状态、完成时间等字段。
- 清洗：按编号去重，剔除取消、重复、测试数据等工作项，标记完成时间缺失的记录。
- 按完成时间归窗：将每个工作项的完成时间与时间窗边界比对，归入唯一窗口；跨窗口完成的工作项只计入完成所在窗口。
- 分组计数：按团队、项目或工作项类型分组，统计每个窗口内达到完成定义的工作项数，得到分子。
- 折算：用分子除以时间窗得到基础吞吐量；需要人均口径时，再除以该窗口内的投入人数。
公式写法如下：
- 基础口径：吞吐量 = 时间窗内完成工作项数 ÷ 时间窗（周/迭代/月）。
- 人均口径：人均吞吐量 = 时间窗内完成工作项数 ÷ 投入人数 ÷ 时间窗。
单位与小数位需要约定。按周计算时单位写“个/周”，按迭代计算时写“个/迭代”，人均口径写“个/人/周”。建议保留一位小数，原始计数保留整数，避免四舍五入造成复算差异。分母为零或窗口内没有完成项时，结果记为0并注明“窗口内无完成项”，不写成空值或省略，以免在趋势图中被误读为数据缺失。
算例：一个迭代窗口的吞吐量计算
以下为演示数据，用于说明计算过程，不代表任何真实团队的水平。
| 工作项 | 类型 | 状态 | 完成时间 | 处理说明 |
|---|---|---|---|---|
| 需求A | 需求 | 已完成 | 迭代2第3天 | 计入迭代2 |
| 需求B | 需求 | 已完成 | 迭代2第8天 | 计入迭代2 |
| 需求C | 需求 | 已完成 | 迭代1第9天 | 计入迭代1，不计入迭代2 |
| 缺陷D | 缺陷 | 已完成 | 迭代2第5天 | 计入迭代2（若混算） |
| 任务E | 任务 | 已完成后重开 | 迭代3第2天 | 最终完成在迭代3，不计入迭代2 |
| 需求F | 需求 | 已取消 | 无 | 排除 |
按需求单类统计，迭代2完成需求A、需求B共2个，迭代时长为1个迭代，吞吐量为2个/迭代。若混算需求与缺陷，迭代2完成3个工作项，吞吐量为3个/迭代。两种口径的数值不同，原因在于计数单位不同，不能直接比较。假设迭代2投入人数为4人，按需求单类计算的人均吞吐量为2÷4÷1=0.5个/人/迭代。
这个算例说明三个处理要点：跨窗口完成的工作项按完成时间归窗；撤回重开以最终完成时间为准；取消的工作项不进入分子。计数单位变化会直接改变结果，因此报告数值时必须同时说明口径。
解读与限制：结果怎么用、不能怎么用
吞吐量出现波动是正常现象，常见原因包括批量大小变化、工作项拆分粒度调整和在制品数量增减。一次把大需求拆成多个小需求，完成数量会上升，但实际投入未必减少；在制品积压时，完成数量可能短期上升，随后因阻塞而下降。解读时应把这些因素与数值一起看，而不是只看数字高低。
建议与周期时间、流动效率交叉验证。吞吐量上升同时周期时间下降，通常说明流动改善；吞吐量上升但周期时间也上升，可能只是批量变大或统计口径变化。交叉验证的作用是判断数值变化来自真实交付节奏，还是来自计数规则调整。
使用时有几条限制需要守住：
- 不把单指标当作绩效结论。吞吐量只反映完成数量，不反映价值、质量和协作水平。
- 不把吞吐量变化当作因果保证。改进措施与数值变化之间需要结合其他证据判断。
- 口径变更、团队调整、项目范围变化后，前后数据不可直接比较，应分段报告并注明变更点。
- 不设通用达标线。合理的吞吐量水平取决于工作项粒度、团队规模和业务类型，应由团队基于自身历史数据确定观察区间。
当需要把吞吐量纳入常规度量时，可以把指标定义卡、取数规则和计算步骤固化为可重复执行的流程。ONES Performance 提供交付效率、交付质量、资源效率、完成情况四个维度的效能度量实践体系，并预置场景化仪表盘模板，可承载工作项状态与完成时间的统计展示；具体指标口径仍需按本文方法先行约定，再与系统字段核对后使用。
常见问题
迭代周期不固定，吞吐量还能按迭代算吗？
可以算，但需要先统一分母。迭代时长不一致时，按迭代计数得到的数值无法直接比较，建议改用固定时间窗（如自然周或自然月）作为分母，或把迭代吞吐量折算为“个/周”后再对比。若坚持按迭代统计，应在报告中标注每个迭代的实际天数，并在趋势分析时剔除时长异常的迭代。
一个需求拆成多个子任务，分子应该数需求还是数任务？
取决于评估对象。观察交付节奏时通常以需求或用户故事为计数单位，子任务作为需求内部的工作分解不单独计数；观察团队执行负荷时可以按任务计数，但结果反映的是任务完成量，不能与需求口径的数值混用。无论选哪种，都要在指标定义卡中写明，并保持前后一致。拆分粒度变化会直接改变数值，拆分规则调整的时间点应作为口径变更记录下来。
窗口内完成又被撤回重开的工作项怎么计数？
以最终完成时间为准。如果重开后在同一个窗口内再次完成，仍计入该窗口一次；如果最终完成时间落到下一个窗口，则从原窗口的分子中剔除，计入新窗口。为避免重复计数，按工作项编号去重，只保留最后一次完成记录。这类工作项的数量建议单独记录，便于解读数值波动时判断是否与返工有关。
团队人数中途变化，人均吞吐量怎么算才合理？
投入人数应与时间窗对应。人数在窗口内变化时，可用窗口内的人均投入人数（按人在岗天数折算）作为分母，而不是取期初或期末的瞬时人数。若无法取得在岗天数，可退而使用窗口内各时点人数的平均值，并在报告中注明折算方式。人数口径一旦确定，前后窗口应保持一致，否则人均数值的对比会失真。
用 ONES 统计吞吐量时，需要提前确认哪些字段？
需要确认三件事：完成定义对应哪个状态字段、完成时间由哪个字段记录、工作项类型与所属项目字段是否完整。ONES Performance 可自动收录系统内日常流转的研发数据并形成分析指标，ONES Project 中的业务数据也能同步，减少手工整理数据源的工作。具体字段名称、状态配置和导出方式以产品实际界面为准，取数前应先核对字段与完成定义的对应关系，再开始统计。
