统计需求状态停留时长和回退，关键在于两件事：一是找到可靠的状态变更记录，二是提前把口径定清楚。停留时长按“进入某状态到离开该状态”逐段计算，回退则要先定义状态顺序，再识别从后状态回到前状态的变更事件。本文给出一套可复算的指标定义、取数条件、计算步骤和示例，并说明结果怎么解读、哪些情况不宜直接下结论。
要点总览（TL;DR）
- 统计停留时长以状态变更记录为数据源，按“进入状态到离开状态”逐段计算，再按需求、状态、时间窗三层汇总。
- 回退统计要先维护状态顺序表，把从后状态回到前状态的变更识别出来，回退率的分母需明确采用变更事件数还是需求数。
- 平均值与中位数应并列呈现，少数长期停滞需求会拉高平均值，中位数更能反映典型停留情况。
- 进行中需求的最后一段停留时长截断到统计截止时间，批量导入记录应标记排除，分母为零或样本过少时只报告次数。
- 指标用于发现流转问题并推动核对，停留时长和回退受需求复杂度、排期与信息质量影响，不宜直接作为团队绩效依据。
评估目标：状态配置后要回答哪些问题
状态已经配置好，团队想确认管理是否有效，需要先把“有效”拆成几个能用数据回答的问题。停留时长和回退各自回答不同的问题，混在一起看容易得出片面结论。
- 停留时长回答：需求在某个状态平均卡了多久，哪些状态是明显的等待瓶颈。
- 回退回答：状态流转中是否频繁出现逆向变更，哪些环节容易被打回。
- 长期停滞回答：是否存在长时间无人推进的需求，状态是否只是挂着没有实际动作。
- 流转准确性回答：状态变更是否真实反映了业务动作，还是存在补录、跳步、批量改状态造成的失真。
这四类问题构成一份评估问题清单。停留时长和回退是定量指标，长期停滞和流转准确性偏向数据质量与业务核对，四者结合才能判断状态配置是否被团队真正用起来。
指标与范围：停留时长、回退率与停滞需求怎么定义
指标定义要写清公式、分子分母、时间窗和单位，否则不同人算出的结果无法对比。下表给出建议口径，团队可按自身状态体系调整，但调整后需在报告中注明。
| 指标 | 计算口径 | 单位 | 分母/范围 |
|---|---|---|---|
| 单段状态停留时长 | 离开该状态的时间点 − 进入该状态的时间点 | 小时或天 | 每一次状态区间 |
| 平均停留时长 | 某状态下所有区间时长之和 ÷ 该状态区间数 | 小时或天 | 时间窗内该状态的全部区间 |
| 中位数停留时长 | 某状态下所有区间时长排序后的中间值 | 小时或天 | 同上 |
| 回退次数 | 状态序号由大变小的事件计数 | 次 | 时间窗内全部状态变更事件 |
| 回退率 | 回退次数 ÷ 状态变更事件总数（或发生变更的需求数） | 百分比 | 需注明采用哪种分母 |
| 长期停滞需求数 | 当前停留时长超过阈值且仍在该状态的需求计数 | 个 | 统计截止时点的在途需求 |
统计范围要同时锁定三件事：需求集合（哪些需求类型、哪些项目纳入）、状态集合（哪些状态参与计算，起点和终点状态是否计入）、时间窗（按变更时间还是按需求创建时间筛选）。平均停留时长和中位数建议并列呈现，停留时长通常呈长尾分布，少数长期停滞需求会明显拉高平均值，中位数更能反映典型情况。长期停滞的阈值可以取团队历史停留时长的某个分位数，也可以约定固定天数，阈值一旦确定应保持稳定，便于跨周期对比。
数据口径与证据：状态变更记录要满足什么条件
停留时长和回退都依赖状态变更记录这一数据源，记录不完整，区间就无法配对。每条变更记录至少应包含以下字段：
- 需求标识：用于把同一需求的多次变更串成时间序列；
- 原状态与新状态：用于判断流转方向和是否构成回退；
- 变更时间：精确到小时或分钟，用于计算区间时长；
- 操作人：用于核对变更是否由真实业务动作触发。
此外需要一张状态顺序表，把每个状态映射为有序序号，作为判定前进与回退的依据。状态顺序表由团队维护，跨分支或并行的状态流转要单独约定是否计入回退。
取数后应做几项质量检查：一是检查是否存在只有新状态没有原状态的孤立记录；二是检查跨天变更的时间戳是否准确，避免按日期取整造成区间偏差；三是标记批量导入或历史迁移产生的记录，这类记录往往集中出现在同一时间点，会污染区间计算，建议排除或单独说明；四是处理时间窗边界，统计截止时仍在某状态的需求，其最后一段停留时长应截断到截止时间，而不是丢弃。
在需求集合和状态变更记录的管理上，ONES Project 支持编写需求、自定义需求状态与多种属性，并可根据实际场景自定义工作流，让需求按约定状态流转；ONES 也会自动记录和统计工作项滞留时间等过程数据，并提供可自定义数据范围和维度的报表。需要说明的是，现有资料未明确说明这些能力是否按需求状态逐段拆分停留时长、是否内置回退识别，实际取数时仍需按上述字段核对原始变更记录。
计算步骤：从变更日志到停留时长和回退率
有了字段齐全的变更日志和状态顺序表，就可以按以下步骤计算，每一步都产出可复核的中间结果。
- 按需求分组排序。把同一需求的所有状态变更事件按变更时间升序排列，形成该需求的状态时间线。
- 配对进入与离开时间。相邻两条记录之间构成一个状态区间：上一条记录的新状态即进入状态，进入时间为该条记录的变更时间，离开时间为下一条记录的变更时间。最后一条记录之后若需求仍在途，区间终点取统计截止时间。
- 计算区间时长。离开时间减进入时间得到单段停留时长，按小时或天统一单位，负值或零值需回查原始记录。
- 识别逆向变更。用状态顺序表把原状态和新状态映射为序号，新状态序号小于原状态序号记一次回退，逐条累加得到回退次数。
- 分层汇总。先按需求汇总其各状态停留时长和回退次数，再按状态汇总平均与中位数，最后按时间窗汇总回退率，三个层级的结果分别留存。
- 处理边界情况。分母为零时（时间窗内没有状态变更）不计算比率，只报告绝对次数；样本量过少时同样只呈现次数并注明样本量，避免用个位数样本判断流程好坏。
回退率的分母有两种常见选择：状态变更事件总数，或发生变更的需求数。前者反映流转动作中的回退比例，后者反映有多少需求经历过回退。两种口径不能混用，报告中必须写明采用哪一种。
例子：一个需求的状态区间与一次回退怎么算
假设某需求的状态顺序为：待评审（1）→ 评审中（2）→ 待补充（3）→ 开发中（4）。该需求在统计周期内的变更记录如下（示例数据，仅用于演示计算）：
| 变更时间 | 原状态 | 新状态 | 方向 |
|---|---|---|---|
| 3月1日 09:00 | 待评审 | 评审中 | 前进 |
| 3月2日 15:00 | 评审中 | 待补充 | 回退（2→3 若按序号递增为前进，此处按业务定义待补充为评审前环节，记为回退） |
| 3月4日 10:00 | 待补充 | 评审中 | 前进 |
| 3月5日 17:00 | 评审中 | 开发中 | 前进 |
按区间逐段计算：待评审停留 30 小时（3月1日09:00 至 3月2日15:00）；评审中第一段停留 30 小时（3月2日15:00 至 3月4日10:00）；待补充停留 43 小时（3月4日10:00 至 3月5日17:00）；评审中第二段停留 31 小时（3月5日17:00 至 3月5日17:00 之后进入开发中，按实际时间戳计算）。评审中共有两段区间，合计 61 小时，平均 30.5 小时。
回退识别：本例中从评审中回到待补充记 1 次回退。若时间窗内该需求共发生 4 次状态变更，按事件口径回退率为 1 ÷ 4 = 25%；若时间窗内共有 20 个需求发生变更、其中 5 个需求出现过回退，按需求口径回退率为 5 ÷ 20 = 25%。两种口径数值可能接近，但含义不同，报告需注明。
平均值与中位数的差异：若同一状态有 5 段停留时长分别为 10、12、15、18、200 小时，平均值为 51 小时，中位数为 15 小时。200 小时那段很可能来自长期停滞需求，只看平均值会高估典型停留时间，因此两个指标应并列呈现。
解读与限制：指标能说明什么、不能说明什么
停留时长和回退率是观察状态流转的窗口，不是流程好坏的直接结论。解读时需要把指标放回业务情境中。
- 停留时长受需求复杂度和排期影响。复杂需求在评审或开发状态停留更久属于正常现象，停留时间长也可能只是排队等待资源，不能直接推断流程低效。
- 回退可能来自信息不足而非流程失效。评审中回到待补充，往往说明需求描述不完整或验收标准不清，这是信息质量问题，需要结合回退原因记录判断。
- 样本量与时间窗影响可比性。不同时间窗、不同需求集合算出的指标不能直接对比，跨周期比较时应保持口径一致，并注明样本量。
- 结合停滞需求与流转准确性综合判断。长期停滞需求数量上升、状态变更集中在少数时间点或由少数人批量操作，都提示状态记录可能失真，此时停留时长和回退率的参考价值下降。
判断状态配置是否有效，建议把四类观察放在一起看：停留时长分布是否合理、回退是否集中在特定环节、停滞需求是否被及时识别、状态变更是否与真实业务动作对应。指标用于发现问题并推动核对，不宜直接作为团队绩效依据。团队可以在 ONES 中维护需求状态与工作流，结合系统记录的工作项滞留时间和自定义报表观察流转情况，再按本文口径补充逐段停留时长与回退统计，形成可复算的评估结果。
常见问题
状态变更记录缺失或不完整时，停留时长还能算吗？
可以算，但需要先做数据修补和范围说明。常见缺失是只有新状态没有原状态的孤立记录，这类记录无法配对区间，建议回查操作日志补齐，补不齐的从计算中排除并在报告中注明排除数量。另一种情况是历史迁移或批量导入产生的集中变更，时间戳往往不代表真实业务动作，应标记后排除，避免把批量改状态算成正常停留。若缺失比例较高，停留时长和回退率只能作为方向性参考，结论需结合人工抽查。
回退率用变更事件数还是需求数作分母，两者结果差很多怎么办？
两种口径回答的问题不同：按变更事件数作分母，反映流转动作中有多大比例是回退；按需求数作分母，反映有多少需求经历过回退。当少数需求反复回退时，事件口径的回退率会明显高于需求口径。处理办法是固定一种口径作为主指标并长期沿用，另一种作为辅助指标同时呈现，报告中写明分母定义。跨周期对比时两种口径不能混用，否则数值变化可能只是口径切换造成的。
长期停滞的阈值怎么定，定完之后可以调整吗？
阈值可以取团队历史停留时长的某个高分位数，也可以约定固定天数，例如超过两周未变更状态即列入停滞清单。阈值的作用是圈出需要人工核对的候选需求，不是判定流程失效的标准。阈值确定后建议保持稳定，便于跨周期对比；如果业务节奏或需求类型发生明显变化，可以调整，但调整时点要在报告中标注，调整前后的停滞需求数不宜直接比较。
统计结果出来后，怎么判断状态配置本身是否需要调整？
先看指标是否集中在特定环节：某个状态停留时长明显偏高且长期如此，可能是该环节人力不足，也可能是状态划分过细导致等待被单独记录。再看回退是否集中在固定路径，例如评审中频繁回到待补充，通常指向需求描述或验收标准的信息质量问题，可以通过完善提交模板解决。同时核对流转准确性，若状态变更集中在少数时间点或由少数人批量操作，说明记录可能失真，此时应先修正记录习惯，再讨论状态配置调整。
ONES 里的工作项滞留时间能直接当作状态停留时长使用吗？
需要先核对口径。ONES 会自动记录和统计工作项滞留时间等过程数据，并提供可自定义数据范围和维度的报表；现有资料未明确说明滞留时间是否按需求状态逐段拆分，也未提及内置回退识别。实际使用时建议先确认该指标的时间起点、终点和统计粒度，再与本文的逐段区间口径对照。若口径不一致，可以从状态变更记录出发自行计算，把系统报表作为交叉验证的参考。
