研发流动效率如何计算:指标、口径与验证方法

研发流动效率的核心算法是:流动效率 = 有效加工时间 ÷ 流动时间 × 100%。有效加工时间指工作项处于设计、开发、测试等增值状态的时间之和,流动时间指工作项从进入流程到交付完成的总时长。要得到可复算、可比较的结果,计算前需要先确定工作项类型、状态映射、时间窗和缺失值处理规则,再按团队或工作项类型分层统计,并结合等待时间占比定位瓶颈。



要点总览(TL;DR)


  • 流动效率 = 有效加工时间 ÷ 流动时间 × 100%,分子是设计、开发、测试等增值状态的时长之和,分母是工作项从进入流程到交付完成的总时长。
  • 计算前先固定工作项类型、状态到加工/等待的映射、时间窗和缺失值处理规则,口径中途调整会让前后数据不可比。
  • 返工与回退的时间归属要事先约定,计入加工或单列返工时长都可行,报告中注明采用哪一种。
  • 多工作项汇总时先加总分子和分母再相除,同时输出中位数、分位数和等待时长分布,避免平均值掩盖长周期工作项的影响。
  • 流动效率用于定位等待瓶颈和验证改进,需与在制品数量、等待时长分布、周期时间配合解读,不宜作为个人绩效结论。


评估目标:流动效率要回答什么问题


流动效率用于回答一个具体问题:在工作项从进入流程到交付完成的这段时间里,有多大比例真正用于设计、开发、测试等推动交付的动作,其余时间消耗在哪些等待环节。它衡量的是流程中等待浪费的严重程度,适合用来定位瓶颈环节、验证流程改进是否减少了等待,以及比较同类工作项在不同阶段的流动状况。


评估对象需要事先明确。常见的选择有三种:按团队统计,观察某个交付团队的流程健康度;按工作项类型统计,例如需求、缺陷、技术任务分别计算,避免不同类型混在一起;按价值流阶段统计,例如从开发完成到测试通过这一段,观察交接环节的等待。三种口径回答的问题不同,同一份数据按不同对象统计会得到不同数值,因此报告结论时必须注明评估对象。


这个指标有明确的使用边界。它描述流程时间结构,不直接反映项目进度是否偏离计划,进度纠偏仍要依赖里程碑、交付预测等信息;它也不衡量开发者的工作体验、协作满意度等主观感受,这类问题需要访谈、问卷等定性方法。把流动效率当作个人绩效考核依据,容易诱导拆分工作项、频繁改状态等行为,使数据失真,因此更适合作为流程改进的诊断输入,而非对人的评价结论。



指标与范围:流动效率的公式与统计边界


流动效率的计算公式为:流动效率 = 有效加工时间 ÷ 流动时间 × 100%。分子是工作项处于增值状态的时间总和,分母是工作项在流程中的总停留时长。两者必须使用同一时间单位,并采用同一计时方式,否则比率没有意义。


要素 定义 常见口径选择
有效加工时间(分子) 工作项处于设计、开发、测试等增值状态的时间之和 按状态流转记录逐段累加;返工时间可计入或单列
流动时间(分母) 工作项从进入流程到交付完成的总时长 起点可选“进入待办”或“开始处理”;终点为“交付完成”或“验收通过”
计时单位 自然时长或人时 自然时长适合观察流程等待;人时适合观察人力投入结构,两者不可混用
统计范围 纳入计算的工作项集合 限定工作项类型、状态集合、完成时间窗
返工处理 回退、重开产生的时间 计入加工时间,或单列为返工时间并在报告中注明

统计范围要写清楚三件事。第一是工作项类型,需求、缺陷、技术任务的流程差异大,混算会掩盖真实瓶颈。第二是状态集合,哪些状态算增值、哪些算等待,必须形成固定映射,中途调整映射会导致前后数据不可比。第三是时间窗,通常按完成时间选取最近一个完整周期内交付的工作项,避免纳入尚未完成、分母不完整的工作项。返工是否计入分子需要在口径中事先约定,两种处理方式的结果差异可能很大,报告中应注明采用哪一种。



数据口径:状态映射与取数规则


取数的基础是工作项的状态流转日志,配合工作项的创建时间、完成时间等字段。计算时把每一次状态变更视为一个时间区间的起点,相邻两次变更之间的时长归入前一状态,再按映射表把各状态时长分别累加到加工时间或等待时间。


状态类别 示例状态 时间归属
增值状态 设计中、开发中、测试中 计入有效加工时间
等待状态 待评审、待开发、待测试、阻塞 计入等待时间,不进入分子
交接状态 待移交、待验收 按口径约定归入等待,或单列交接时间
回退状态 测试不通过退回开发 按约定计入加工或单列返工时间

映射表需要覆盖团队实际使用的全部状态,包括自定义状态。多状态并存时,以状态流转日志中的实际停留为准,不按当前状态倒推。返工与回退的时间归属要在口径中固定:若回退后的开发时间仍属于增值动作,可计入加工时间;若希望单独观察返工成本,则单列返工时长,分子只计首次加工时间。两种方式都合理,关键是全周期保持一致。


缺失数据处理需要规则化。状态记录缺失的工作项,若缺失区间无法判断归属,宜标注为数据不完整并排除出比率计算,同时报告排除数量;跨天、跨时区的记录统一换算到同一时区后再切分区间,避免因时区差异产生数小时的偏差。数据来源应保留原始流转日志,便于复核和口径调整后的重算。



计算步骤:从原始记录到流动效率


计算过程可以拆成四步,每一步都产出可核对的结果,便于他人复算。


  1. 确定工作项样本与时间窗。按工作项类型和完成时间筛选出已交付的工作项,记录样本量与排除项,形成计算清单。
  2. 按状态映射切分时间区间。对每个工作项读取状态流转日志,逐段计算各状态停留时长,并按映射表归入加工或等待。
  3. 汇总加工时间与流动时间。对单个工作项,加工时间为各增值状态时长之和,流动时间为首次进入流程到交付完成的总时长;核对两者关系,加工时间不应大于流动时间。
  4. 按团队或类型分层计算并输出分布。分别计算各层的流动效率,同时输出样本量、等待时间占比和等待时长分布,避免只看平均值。

分层统计适用于工作项类型差异较大的团队;单一团队、流程相对统一时,可以先按整体口径观察趋势,再逐步细分。输出结果时建议同时给出中位数和分位数,平均值容易被少数长周期工作项拉偏。



算例:一个工作项的流动效率计算


以下为演示情景,用于说明取数与计算过程,不代表真实客户数据。某需求工作项从进入待办到验收通过,状态时长明细如下。


状态 时长(小时) 归属
待评审 16 等待
设计中 8 加工
待开发 24 等待
开发中 32 加工
待测试 12 等待
测试中 16 加工
待验收 12 等待

加工时间为 8 + 32 + 16 = 56 小时,流动时间为 16 + 8 + 24 + 32 + 12 + 16 + 12 = 120 小时,流动效率为 56 ÷ 120 × 100% ≈ 46.7%。等待时间合计 64 小时,占总时长的 53.3%,其中待开发 24 小时、待评审 16 小时是最大的两个等待环节,改进应优先关注评审排期和开发排队。


多工作项汇总时,不能简单平均各工作项的比率,而应先分别加总分子和分母再相除,即加权计算:总流动效率 = Σ有效加工时间 ÷ Σ流动时间 × 100%。这样长周期工作项的影响与其实际占用时间相匹配。若需要观察分布,可同时给出各工作项流动效率的中位数和四分位数。



解读与限制:数值怎么用、哪里会失真


流动效率的数值高低受流程设计、工作项类型、统计口径共同影响。不同团队、不同类型、不同时间窗下的数值不宜直接比较,只有在口径一致时才具备可比性。数值上升可能来自等待减少,也可能来自状态映射调整或样本结构变化,解读时要回到原始数据核对。


几种情况会让结果失真。分母为零或工作项尚未完成时,不应输出比率,应标注样本量或改用等待时长分布等替代视角;样本过少时,单个数额的波动可能只是个别工作项的影响,宜拉长时间窗或合并同类项;状态口径前后不一致时,趋势判断失去意义,调整口径应保留旧口径数据以便对照。


流动效率是诊断指标,不能作为因果保证或绩效结论。它说明时间花在哪里,不说明为什么等待、也不保证改进后交付一定加快。实践中应与在制品数量、等待时长分布、周期时间配合解读:在制品数量上升往往伴随等待变长,等待时长分布能指出具体卡点,周期时间反映整体交付节奏。三者结合,才能形成从发现问题到验证改进的闭环。



用ONES承载流动效率的数据采集与复盘


流动效率的计算依赖完整的状态流转记录,这正是研发管理工具需要承载的基础数据。在ONES中,工作项的状态变更会形成流转记录,团队可以据此还原每个工作项在各状态的停留时长,作为加工时间与等待时间的取数来源。前提是团队的状态设置与映射表保持一致,自定义状态也纳入统一口径。


取数之后,可以按团队、工作项类型配置视图和统计视角,把同一口径下的工作项集合固定下来,定期输出流动效率与等待时间占比,减少每次手工筛选的口径偏差。复盘会议中,结合等待环节的时长排序定位瓶颈,例如评审等待或测试排队,再针对具体环节制定改进动作,并在下一个周期用相同口径复算,观察等待时间是否下降。这样,指标计算、瓶颈定位和改进验证形成一条可追溯的流程,流动效率才真正服务于流程改进而非停留在报表上。



常见问题


工作项还在进行中,能算流动效率吗?


不建议对未完成的工作项输出比率。分母不完整,算出的数值会偏低,且随着工作项继续推进不断变化,无法与其他工作项比较。常见做法是按完成时间选取最近一个完整周期内已交付的工作项作为样本,未完成的工作项只统计其当前等待时长,用于观察在制品积压情况。


如果确实需要观察在制品的流动状况,可以改用等待时长分布或在制品数量等视角,等这批工作项交付后再纳入比率计算。


状态映射表定好之后还能调整吗?


可以调整,但要保留旧口径数据以便对照。状态映射变化会直接改变分子和分母的构成,例如把某个交接状态从等待改为加工,流动效率会明显上升,这种上升来自口径变化而非流程改善。


建议在调整时记录变更日期和变更内容,新旧口径并行统计至少一个周期,确认趋势差异后再切换。团队新增自定义状态时,也应同步纳入映射表,避免这部分时长被漏算或误归。


不同团队的流动效率数值可以直接比较吗?


只有在工作项类型、状态映射、计时单位和时间窗都一致时才具备可比性。团队之间流程设计不同,状态划分粒度不同,直接比较数值容易得出误导性结论。


更稳妥的做法是先在同一团队内部观察趋势,确认改进是否带来等待时间下降;需要跨团队对照时,先统一口径,并同时给出样本量和等待时长分布,让读者看到数值背后的时间结构。


流动效率低,应该先改哪个环节?


先看等待时间的构成,而不是只看总比率。把各等待状态的时长排序,占比最大的环节通常是优先改进对象,例如评审排期过长、开发排队积压或测试资源不足。


改进动作要落到具体机制上,例如固定评审时间窗、限制同时在制品数量、调整测试介入时机。改完后用相同口径复算,观察对应等待环节的时长是否下降,再判断改进是否有效。


流动效率和周期时间应该一起看吗?


建议一起看。周期时间反映整体交付节奏,流动效率反映这段时间里有多少用于增值动作,两者结合才能判断问题出在总时长还是时间结构。


周期时间变长而流动效率下降,通常意味着等待环节在膨胀;周期时间变长但流动效率稳定,可能是工作项本身规模变大。配合在制品数量和等待时长分布,可以进一步定位是哪个环节在拖长交付。