研发吞吐量衡量给定时间窗内团队完成并交付的工作项数量，常用公式为“吞吐量 = 时间窗内达到完成状态的工作项数 ÷ 时间窗长度”，单位可取项/周或项/迭代。要得到可复算、可比较的结果，先要固定工作项类型、完成状态、去重规则和时间窗。本文按目标、范围、取数、计算、示例和解读的顺序，给出完整口径。
要点总览（TL;DR）
- 研发吞吐量 = 时间窗内达到完成状态的工作项数 ÷ 时间窗长度，单位取项/周或项/迭代，统计前先固定工作项类型、完成状态、时间窗和去重规则。
- 完成状态要落到具体状态名，并约定以首次到达该状态的时间计入；同一工作项往返完成状态只计一次，拆分合并按叶子节点或主工作项处理。
- 完成时间缺失的记录从分子中排除并列入异常清单；分母为零或时间窗过短时展示原始计数并注明样本不足，可合并时间窗或改用迭代口径。
- 两周完成23项即11.5项/周或23项/迭代，两种口径描述同一交付量，汇报时需同时说明单位。
- 吞吐量反映交付节奏，解读要看连续多个时间窗的区间，并与周期时间、在制品数量结合，不宜单独用于个人考核或跨团队排名。
评估目标：吞吐量要回答什么问题
吞吐量适合回答“团队在一段时间内稳定交付了多少个工作项”。它观察的是交付节奏和容量水平：过去几个时间窗的完成数量大致在什么区间，下一个迭代按现有节奏能承接多少工作，交付数量在某周或某迭代是否出现明显下降。把吞吐量放进迭代计划会前讨论，可以帮助团队用历史完成量校准承诺量，减少凭感觉排期。
吞吐量与发布执行、等待阻塞定位承担不同任务。发布执行关注版本是否按计划上线、发布检查项是否完成；等待阻塞定位关注工作项在哪个状态停留过久、队列在哪里积压。吞吐量只回答“完成了多少”，不回答“为什么快或慢”。当吞吐量出现异常时，通常需要借助周期时间、状态停留时长和在制品数量进一步定位原因。
使用前应形成一份简短的度量目标声明，写清三件事：用途是观察节奏、评估容量和支撑计划；使用者是团队负责人、项目经理或研发管理者；不适用范围包括个人绩效考核、跨团队排名和对外承诺。吞吐量受工作项大小、类型构成和拆分习惯影响，把它直接用于个人考核容易诱导“拆小项冲数量”，使数据失去参考价值。度量结果更适合作为团队改进讨论的输入。
指标与范围：统计对象、单位与时间窗
统计对象要先确定工作项类型。常见选择包括需求、任务和缺陷，三类可以合并统计，也可以分开统计。合并统计得到的是团队整体交付数量，适合观察总节奏；分开统计能看清交付结构，例如需求完成量下降而缺陷修复量上升，说明团队时间被质量问题占用。无论选哪种，同一份报表在多个时间窗之间应保持一致，中途改变类型范围会让前后数据不可比。
完成状态需要明确到具体状态名。以常见流转为例，工作项从“待处理”进入“进行中”，再到“待验证”，最后到达“已完成”或“已关闭”。统计时应选定一个终点状态作为完成标志，并确认该状态代表工作已经交付，而非仅开发自测通过。若团队同时存在“已完成”和“已关闭”两个状态，需要约定以先到达的那个为准，避免同一工作项在两次统计中被重复计入或漏计。
统计单位与时间窗长度要匹配。按周统计使用“项/周”，按迭代统计使用“项/迭代”。时间窗长度应固定，例如统一采用自然周（周一至周日）或固定两周迭代。时间窗过短会让数量波动被放大，一周只完成两三项时，多一项少一项都会造成大幅百分比变化；时间窗过长则会掩盖节奏变化。团队规模较小时，可优先使用迭代口径。
团队与项目范围边界同样需要写清。按项目统计时，只计入归属该项目的工作项；按团队统计时，需要处理跨团队协作项的归属。常见规则是“由完成该工作项主要开发工作的团队计入”，或“按工作项所属项目计入”，两种规则选其一并保持稳定。跨团队工作项若被双方同时计入，汇总数会大于实际交付量；若双方都不计入，则会出现漏计。
| 定义要素 | 需要写清的内容 | 示例 |
|---|---|---|
| 统计对象 | 工作项类型及是否合并 | 需求与缺陷合并统计，任务不计入 |
| 完成状态 | 作为完成标志的状态名 | 到达“已完成”即计入 |
| 统计单位 | 项/周或项/迭代 | 项/周 |
| 时间窗 | 固定长度与起止规则 | 自然周，周一 00:00 至周日 24:00 |
| 范围边界 | 团队、项目及跨团队归属 | 按工作项所属项目计入 |
数据口径：取数来源、去重与缺失值处理
取数应来自工作项管理系统中的原始记录，至少包含以下字段：工作项ID、工作项类型、创建时间、完成时间、当前状态，以及状态变更历史。完成时间通常取自状态流转记录中首次进入完成状态的时间，而非最后修改时间。若系统只保留当前状态，需要借助状态变更日志还原完成时点；缺少日志时，只能用最后更新时间近似，并在报表中注明该近似口径。
| 字段 | 用途 | 缺失或异常时的处理 |
|---|---|---|
| 工作项ID | 唯一标识与去重 | 重复ID保留一条，以最新状态记录为准 |
| 工作项类型 | 按范围过滤 | 类型为空的不计入，单独列出待补 |
| 创建时间 | 判断是否在统计周期内创建 | 缺失时不影响完成口径，但需标注 |
| 完成时间 | 判断是否落在时间窗内 | 缺失则不计入分子，列入异常清单 |
| 状态变更历史 | 确认首次完成时点 | 状态跳变时以日志中首次到达完成状态为准 |
去重主要处理三类情况。同一工作项多次在完成状态与其他状态之间往返时，只按首次进入完成状态计一次，返工不重复计数。工作项被拆分时，子项各自作为独立工作项统计，父项若仍保留并再次完成，需要排除父项或明确只统计叶子节点。工作项被合并时，保留合并后的主工作项，被合并项不再单独计数。去重规则应写入报表说明，保证其他人用同一份原始数据能算出相同结果。
缺失值要标记而非静默丢弃。完成时间缺失的工作项无法判断是否落在时间窗内，应从分子中排除，同时在异常清单中记录ID和原因，便于后续补录。状态跳变指工作项从“进行中”直接跳到“已关闭”，中间缺少验证环节，这类记录仍可计入，但应在数据质量说明中标注比例。分母为零或时间窗过短时，不建议输出“0项/周”作为结论，可改为展示原始计数并注明样本不足；连续多个时间窗计数都很少时，应合并时间窗或改用迭代口径。
当工作项的状态流转和完成时间都记录在统一系统中时，取数会简单很多。以ONES为例，工作项的类型、状态和流转记录集中管理，团队可以按项目和时间范围筛选已到达指定完成状态的工作项，再导出计数用于计算；状态变更留痕也为确认首次完成时点提供了依据。把完成状态和统计范围在系统中固定下来，能减少每次取数时的人工判断。
计算步骤：从原始记录到吞吐量数值
计算可以拆成三步，每一步都留下可复核的中间结果。
第一步，按时间窗筛选。确定统计区间，例如某年某月第1周周一00:00至周日24:00，从状态变更记录中筛出完成时间落在该区间内的工作项。注意使用完成时间而非创建时间，创建于区间之前、完成于区间之内的工作项应计入本期。
第二步，按类型与状态过滤并去重。保留约定范围内的工作项类型，确认完成状态与定义一致，再按工作项ID去重，处理往返、拆分和合并记录。过滤后得到有效完成工作项集合，记录其数量N。
第三步，计数并除以时间窗长度。公式为：
吞吐量 = N ÷ T
其中N为有效完成工作项数，T为时间窗长度。按周统计时T以周为单位，结果为项/周；按迭代统计时T以迭代为单位，结果为项/迭代。
两种粒度可以换算，但要注意换算前提。一个两周迭代包含两个自然周，若两周完成20项，迭代口径为20 ÷ 1 = 20项/迭代，折合周口径约为20 ÷ 2 = 10项/周。这种换算假设两周内交付均匀，实际常出现迭代末集中完成，折算出的周均值会掩盖周内波动。需要观察周节奏时，直接按周统计更可靠；需要与迭代计划对齐时，使用迭代口径。
例子：一个两周时间窗的完整计算
假设某团队统计一个两周迭代（第1周周一至第2周周日，共2周）的吞吐量，范围内包含需求和缺陷两类工作项。原始记录共24条到达完成状态，其中需求14条、缺陷10条。
去重与缺失值处理后：有1条需求在完成与进行中之间往返两次，按首次完成计1条，不重复计数；有1条缺陷完成时间缺失，从分子中排除并列入异常清单；有1条需求由父项拆分为两个子项，父项排除，两个子项各计1条。调整后有效计数为：需求14 − 1（父项排除）+ 1（拆分子项补入，原父项已含在14条内，净变化为0）＝14条；缺陷10 − 1（完成时间缺失）＝9条；合计N = 23项。
代入公式：吞吐量 = 23 ÷ 2 = 11.5项/周。若改用迭代口径，T = 1个迭代，吞吐量为23项/迭代。同一组数据在两种口径下分别得到11.5项/周和23项/迭代，数值不同但描述的是同一交付量，汇报时需要同时说明单位，避免读者误读。
| 项目 | 需求 | 缺陷 | 合计 |
|---|---|---|---|
| 原始完成记录 | 14 | 10 | 24 |
| 往返去重 | −1 | 0 | −1 |
| 拆分合并调整 | 0 | 0 | 0 |
| 完成时间缺失排除 | 0 | −1 | −1 |
| 有效计数N | 14 | 9 | 23 |
| 项/周（T=2） | 7.0 | 4.5 | 11.5 |
| 项/迭代（T=1） | 14 | 9 | 23 |
解读与限制：波动、可比性与因果边界
读吞吐量先看区间，再看单点。连续四到六个时间窗的数值构成一个区间，例如每周9至14项，这个区间比某一周的单个数字更能反映团队节奏。单周从12项降到8项，可能只是工作项大小不同或拆分方式变化，未必代表效率下降。工作项越大、类型越杂，吞吐量的波动通常越明显；把大需求拆成多个小任务统计，数值会上升，但实际交付内容未必增加。
跨团队、跨项目比较需要满足前提：工作项类型范围一致、完成状态定义一致、时间窗长度一致、去重规则一致，并且工作项平均大小接近。缺少这些条件时，数值高低更多反映统计口径差异。即使口径统一，不同团队的业务复杂度、依赖数量和验证要求不同，也不宜直接用吞吐量排名。
吞吐量是单指标，不能代表整体绩效。它不反映交付质量、返工率、周期时间和客户价值。一个团队吞吐量高，可能伴随缺陷率上升或需求返工增加。解读时应与周期时间、在制品数量、缺陷逃逸率等指标一起看：吞吐量回答“完成了多少”，周期时间回答“花了多久”，在制品数量回答“同时压了多少活”。三者结合，才能判断节奏变化是容量提升还是队列积压后的集中释放。
数据质量不足时，结论要相应收窄。完成时间缺失比例较高、状态跳变频繁或拆分合并规则执行不一致时，吞吐量只能作为趋势参考，不宜用于精确的容量承诺。报表中应附上有效计数、排除记录数和异常说明，让读者知道数字背后的样本情况。度量结果用于改进讨论时，重点应放在“哪个环节让完成数量变化”以及“下一期如何调整计划”，而非给个人或团队下绩效结论。
常见问题
团队刚起步、每周只完成两三项，吞吐量还有参考价值吗？
样本很小时，周口径的百分比波动会被放大，多一项少一项看起来变化很大。此时可以改用迭代口径，或把连续几个时间窗合并统计，先看原始计数再看比值。报表中注明样本量，结论只用于观察趋势，不用于精确的容量承诺。
工作项在“已完成”和“进行中”之间反复往返，应该算几次？
按首次进入完成状态计一次，返工不重复计数。若团队把返工视为新的交付，需要单独建立返工统计口径，并在报表说明中写清，避免同一份数据在不同人手里算出不同结果。
需求拆成子任务后，吞吐量数值明显上升，这算效率提升吗？
拆分粒度变化会直接改变计数，数值上升不一定代表交付内容增加。保持统计对象范围稳定，例如只统计需求层级的叶子节点，或明确任务不计入，才能让前后时间窗可比。拆分规则调整时，应在报表中标注变更时点。
两个团队吞吐量数值差距较大，能直接比较吗？
需要先确认工作项类型范围、完成状态定义、时间窗长度、去重规则一致，且工作项平均大小接近。条件不满足时，数值差异更多来自统计口径。即使口径统一，业务复杂度、依赖数量和验证要求不同，也不宜直接用吞吐量排名。
完成时间字段大量缺失，还能算吞吐量吗？
可以算，但结论要收窄。缺失记录从分子中排除，同时统计缺失比例并列入异常清单。缺失比例较高时，结果只作为趋势参考；优先补齐状态变更日志，或改用系统记录的首次进入完成状态时间，再恢复常规统计。
