研发吞吐量的统计口径要先把三件事定死：统计对象（以什么为“一个交付单位”）、统计边界（从哪个状态算进入、从哪个状态算完成）、时间窗与分母（按固定周期还是按投入人天折算）。口径确定后写成可复算的定义：吞吐量＝统计周期内满足完成定义的交付单位数，并明确单位、分母、缺失值处理与不可比情形，再用历史数据回算验证口径是否稳定、是否能解释波动。本文按“目标—定义—取数—计算—算例—验证”的顺序给出可直接落地的方法。
要点总览（TL;DR）
- 统计口径先定三件事：交付单位（需求、用户故事、缺陷修复或发布批次）、进入点与完成点的状态定义、时间窗与分母，三者写进同一张定义卡。
- 吞吐量＝统计周期内满足完成定义的交付单位数；按投入折算时分母为周期内投入人天，按团队规模折算时分母为平均在岗人数，分母口径固定后不跨周期切换。
- 完成时间以状态变更记录中进入完成状态的时间戳为准；跨项目先做状态映射与字段归一，缺失时间戳、回退、重复记录按书面规则处置。
- 口径确定后用历史数据回算，检查结果是否落在可解释区间、波动能否对应已知事件、不同人复算是否一致；团队规模或工作类型变化时标注断点，前后不直接比较。
- 吞吐量是单指标，适合与交付周期、质量指标配套观察，不单独作为绩效或因果结论的依据。
先明确评估目标：吞吐量要回答什么问题
统计口径的严格程度取决于评估目的。同一个团队，用于内部趋势观察的口径可以相对宽松，用于对外承诺或考核的口径必须能逐条复算。先写清目的，再决定口径细节，可以避免后期反复改定义导致历史数据不可比。
用于容量与趋势判断时，口径的核心要求是“同一把尺子长期不变”。此时重点是交付单位类型稳定、完成定义稳定、时间窗固定，允许一定程度的近似，例如按周或按双周统计，只要每期使用同一规则即可。目的是看团队产出是否在合理区间波动，而不是精确到个位数。
用于对外承诺或考核时，口径需要额外满足三点：一是完成定义可被第三方核验，例如以状态变更记录的时间戳为准；二是纳入与排除规则书面化，取消、合并、重复记录如何处理有明确条款；三是保留原始数据，任何一次统计结果都能回溯到具体工作项。考核场景下还应提前约定数据不可比时的处理方式，避免争议。
吞吐量与发布执行、瓶颈定位有分工边界。吞吐量回答“一个周期内完成了多少交付单位”，发布执行关注版本上线流程是否顺畅，瓶颈定位关注等待与阻塞发生在哪个环节。三者可以配套使用，但吞吐量口径本身不承担解释“为什么慢”的任务，把因果分析压在吞吐量上会导致口径被不断加码、失去稳定性。
指标定义与统计范围：交付单位、进入点与完成点
吞吐量的可复算定义由四个要素组成：交付单位、进入点、完成点、纳入排除范围。四者写在同一张定义卡上，任何人按卡取数应得到相同结果。
交付单位的选择
常见交付单位有四类，选择依据是评估目的与团队工作方式：
| 交付单位 | 适用场景 | 注意事项 |
|---|---|---|
| 需求 | 以业务价值交付为主的团队，需求粒度较统一 | 需先约定需求拆分粒度，避免大小混杂 |
| 用户故事 | 迭代制开发，故事点或规模相对稳定 | 故事拆分标准需书面化 |
| 缺陷修复 | 维护型团队或质量改进阶段 | 与需求分开统计，避免混算 |
| 发布批次 | 按版本节奏交付的团队 | 批次内工作量差异大时需配合其他指标 |
一个团队在同一统计周期内应只选一种主单位，其他类型作为辅助口径单独统计。混用需求与缺陷会让吞吐量随缺陷数量波动，掩盖真实交付能力。
进入点与完成点的状态定义
进入点决定哪些工作项进入统计池，完成点决定哪些算“已完成”。常见做法是以工作流状态为准：进入点设为“已排期”或“开发中”，完成点设为“已完成”或“已验收”。完成点应选择代表交付责任转移的状态，而非开发自测完成的状态。进入点与完成点之间的状态流转记录，是后续取数与核验的基础。
纳入与排除范围
需要在定义卡中写明：取消或关闭未交付的工作项不计入；被合并的重复工作项只计一次，以保留项为准；跨周期完成的工作项计入完成所在周期，不按开始时间分摊；统计周期内完成又回退到未完成状态的工作项，按回退后的最终状态处理。这些规则提前写清，可以避免同一批数据出现两种计数结果。
数据口径与证据：字段、时间戳与缺失值处理
定义卡确定后，取数规则要落到字段级别。核心是回答三个问题：从哪个字段判断完成、用哪个时间戳归属周期、异常数据怎么处理。
完成时间戳与状态变更记录
完成时间应以状态变更记录中“进入完成状态”的那次变更时间为准，而不是工作项的创建时间、更新时间或计划完成时间。更新时间会被后续评论、附件上传等操作刷新，用它判定完成会把已完成工作项错误地推到后续周期。状态变更记录通常包含变更前后状态、变更时间和操作人，是核验完成点的直接证据。
跨项目字段不一致的归一方法
多个项目并行时，状态名称和字段结构往往不一致。归一的顺序是：先建立状态映射表，把各项目的状态名映射到统一的“未开始、进行中、已完成、已取消”四类；再统一交付单位字段，确认每个项目用哪个字段标识需求或故事；最后统一时间字段，确认各项目都记录了状态变更时间。映射表应随项目配置变化更新，并保留版本记录。
缺失值与异常记录的处置
| 情形 | 处置规则 |
|---|---|
| 缺少状态变更时间戳 | 标记为不可核验，单独列出，不计入主口径 |
| 完成后又回退 | 按周期结束时最终状态计数，回退记录保留备查 |
| 重复记录 | 按唯一标识去重，保留最早创建的一条 |
| 状态名称未在映射表中 | 暂停计入，补充映射后再回算 |
在工具层面，ONES 效能管理可自动收录系统内日常流转的研发数据并形成分析指标，其工作项状态与字段管理为上述映射和取数提供了承载位置；具体字段命名与时间戳规则需在实际配置时确认。ONES 效能管理还支持对研发过程数据进行多维度、自定义的分析，便于按统一口径复算不同周期的结果。
计算步骤与公式：分子、分母、时间窗与单位
口径落到计算层，需要给出公式、时间窗和单位。基本公式为：
吞吐量＝统计周期内满足完成定义的交付单位数
分子是周期内进入完成状态且通过纳入排除规则的工作项数量；分母取决于表达方式。若只报绝对数量，分母为1，单位为“个/周期”；若按投入折算，分母为周期内投入人天，单位为“个/人天”；若按团队规模折算，分母为周期内平均在岗人数，单位为“个/人·周期”。分母口径必须在定义卡中固定，不能在不同周期之间切换。
固定周期与滚动窗口
固定周期按自然周、双周或月统计，优点是口径简单、便于横向比较，缺点是周期边界附近完成的工作项归属可能受偶然因素影响。滚动窗口取最近若干周的平均值，能平滑波动，适合观察趋势，但不适合作为单期考核依据。常见做法是固定周期出数、滚动窗口看趋势，两者使用同一套完成定义。
分母为零与数据不可比
周期内无投入人天或无在岗人员时，折算型吞吐量分母为零，此时不计算比值，直接标注“本期无有效分母”，并保留绝对数量。数据不可比的情形包括：交付单位类型变更、完成定义调整、团队规模大幅变化、工作类型从需求为主转为维护为主。出现这些情形时，应在趋势图上标注断点，断点前后不直接比较。
算例：一个两周窗口的吞吐量回算
以下为演示情景，用于说明口径如何落地，数值为示例数据。
某团队以“需求”为交付单位，进入点为“已排期”，完成点为“已完成”，统计窗口为某月第1周至第2周，共10个工作日，投入人天合计80人天。
窗口内状态变更记录显示：进入完成状态的需求共14个。逐条核对后：其中1个在窗口结束后回退到“开发中”，按规则不计入；1个为重复创建，与另一需求合并，只计保留项；1个在窗口开始前已完成，仅更新时间落在窗口内，不计入。最终有效计数为11个。
计算：绝对吞吐量为11个/双周；按投入折算为11÷80≈0.14个/人天。若该团队上一窗口为9个/双周、投入76人天，折算约0.12个/人天，则本期在绝对数量和折算值上均有小幅上升，可结合需求规模分布判断上升是否来自交付单位变小。
被排除的三项应保留在明细中并注明排除依据，便于他人复算时得到相同结果。结果表达需同时给出数值、单位和窗口，例如“11个需求/双周（80人天，折算0.14个/人天）”，避免只报数字造成误读。
口径验证与解读限制：稳定性、可比性与常见误读
口径写完后，用历史数据回算是最直接的验证方式。取过去若干周期的数据，按新口径重新计数，检查三件事：结果是否落在可解释的区间内；波动是否能对应到已知事件，如假期、需求集中上线、人员变动；不同人按同一规则复算是否得到相同数字。三项都通过，口径才具备稳定性。
验证清单可包括：完成定义是否唯一对应一个状态；状态映射表是否覆盖全部在用状态；缺失时间戳的记录占比是否在可接受范围；排除项是否逐条有依据；分母口径是否在全部周期保持一致；口径变更是否留有版本记录。任何一项不满足，应先修正口径再出数。
解读时有几条边界需要守住。团队规模变化时，绝对吞吐量上升可能只反映人数增加，应结合折算值看；工作类型从新功能开发转向缺陷维护时，交付单位含义变化，前后数据不可直接比较；吞吐量是单指标，不能单独作为绩效结论，也不能用来证明某项改进带来了产出提升，需与交付周期、质量指标配套解读。ONES 效能管理从交付效率、交付质量、资源效率、完成情况等维度组织度量，并提供场景化仪表盘模板，可作为把吞吐量放入配套指标体系进行观察的承载方式；具体指标默认口径以实际配置为准。
常见问题
团队同时有需求、缺陷和发布批次，吞吐量应该按哪种单位统计？
同一统计周期内只选一种主单位，其他类型作为辅助口径单独统计。选择依据是评估目的：以业务价值交付为主的团队用需求，迭代制开发用用户故事，维护型团队用缺陷修复，按版本节奏交付的团队用发布批次。
混用需求与缺陷会让吞吐量随缺陷数量波动，掩盖真实交付能力。如果确实需要同时观察两类工作，可以分别出数，在报告中并列呈现，但不要把两类数量相加成一个吞吐量数字。
工作项在周期内完成、周期结束后又回退，应该计入哪个周期？
按周期结束时工作项的最终状态计数。周期内进入完成状态、周期结束后回退的，不计入该周期的吞吐量；回退记录保留备查，便于复算时说明差异。
这条规则要提前写进口径定义卡，并在明细中标注排除依据。如果团队回退频繁，说明完成点的状态定义可能偏松，例如把开发自测完成当作完成点，此时应先收紧完成定义，再讨论计数规则。
按人天折算吞吐量时，投入人天从哪里取、包含哪些人？
投入人天应取统计周期内实际投入该交付单位相关工作的人数与工时记录，口径需写明包含的角色范围，例如是否包含测试、设计、产品人员。只统计直接参与交付的角色，还是把支持角色按比例分摊，两种做法都可以，但必须在定义卡中固定，不能逐期调整。
分母为零时（周期内无有效投入记录）不计算比值，直接标注“本期无有效分母”并保留绝对数量。折算值用于跨团队或跨周期比较时，要确认各方的角色范围一致，否则比较结果没有意义。
口径中途调整过，历史数据还能和新数据放在一张趋势图里吗？
可以放在同一张图上，但要在口径变更的时间点标注断点，断点前后不直接比较。口径变更包括交付单位类型调整、完成定义修改、纳入排除规则变化、分母口径切换。
更稳妥的做法是用新口径回算历史周期，得到一条口径一致的历史序列；如果历史数据缺少必要字段无法回算，就保留断点标注，并在报告中说明变更原因和影响范围。口径变更应留有版本记录，方便后续追溯。
用工具承载吞吐量统计时，需要提前确认哪些配置？
需要确认三件事：工作项状态在各项目中的命名与映射关系，状态变更时间戳是否完整记录，交付单位对应的字段在各项目中是否一致。这三项决定了取数能否按统一口径复算。
ONES 效能管理可自动收录系统内日常流转的研发数据并形成分析指标，支持对研发过程数据进行多维度、自定义的分析，工作项状态与字段管理为状态映射和取数提供了承载位置；具体字段命名、时间戳规则与默认口径需在实际配置时确认。
