要判断项目问题是否久拖不决，需要把“拖”拆成可复算的时间量：问题在某个状态停留了多久、超过承诺解决日期多少天、被重复升级了几次。本文给出停留时长、超期天数和升级次数的统计口径、取数字段与计算步骤，并说明未关闭问题、分母为零和样本过少时如何处理，便于团队按同一口径复核结果。
要点总览（TL;DR）
- 判断项目问题是否久拖不决，可拆成三个可复算的时间量：状态停留时长、超期天数、重复升级次数，分别对应流程停滞、承诺失守和协调失灵。
- 停留时长按“离开状态时间−进入状态时间”计算，未关闭用统计截止日代替；超期天数按“关闭日期−承诺解决日期”计算，未关闭同样用截止日，并单独标注“进行中超期”。
- 统计前统一状态口径、时间窗和分母，分组输出中位数、P90、超期率与平均升级次数，平均值只作辅助。
- 样本过少或分母为零时标注“样本不足”或“无数据”，不输出比率；指标用于定位卡点与验证改进，不直接作为个人绩效唯一依据。
评估目标：把“久拖不决”拆成可统计的判断
“久拖不决”是一种主观感受，落到度量上要回答三个具体问题：这个问题在当前环节停了多久、是否已经超过承诺的解决时间、是否被反复升级或退回。三个维度分别对应流程停滞、承诺失守和协调失灵，单独看任何一个都容易误判。
停留时长反映问题在某个状态或整体未关闭期间的持续时间，适合发现流程卡点；超期天数反映承诺日期与实际关闭日期的差距，适合判断对外承诺的兑现情况；重复升级次数反映问题是否在团队之间反复流转，适合识别责任不清或依赖未解的协调问题。三者结合，才能区分“处理慢”和“卡在某个环节”。
这套指标主要服务三类用途：一是识别卡点，找出停留时间最长的状态或团队；二是排序处置优先级，把超期最久、升级最多的问题排在前面；三是验证改进效果，在调整流程或补充资源后对比观察周期内的变化。指标本身不评价个人，也不替代对问题复杂度的判断。
统计范围需要先划清。本文讨论的是项目推进过程中阻碍交付的问题，例如需求不清、依赖未就绪、资源冲突、外部等待。产品缺陷的严重度与修复周期、线上服务事件的响应与恢复，属于另外的度量体系，不纳入本文的停留时长与超期天数统计，否则分母和口径会混在一起。
指标与范围：停留时长、超期天数与升级次数怎么定义
三个指标需要统一名称、公式、单位和统计对象，否则不同人算出的结果无法比较。下表给出建议定义，团队可按自身状态体系调整状态名称，但公式结构保持一致。
| 指标 | 公式 | 单位 | 时间窗 | 分母/统计对象 |
|---|---|---|---|---|
| 状态停留时长 | 离开该状态的时间戳 − 进入该状态的时间戳；仍在其中则用统计截止日 − 进入时间 | 小时或天 | 按观察周期统计，如近30天、近一个迭代 | 在该状态内有记录的问题 |
| 整体未关闭时长 | 关闭时间 − 创建时间；未关闭用统计截止日 − 创建时间 | 天 | 同上 | 纳入统计的全部问题 |
| 超期天数 | 实际关闭日期 − 承诺解决日期；未关闭用统计截止日 − 承诺解决日期 | 天 | 同上 | 设有承诺解决日期的问题 |
| 超期率 | 超期问题数 ÷ 纳入统计问题数 | 百分比 | 同上 | 分母需明确是在办问题数还是已关闭问题数 |
| 重复升级次数 | 同一问题被再次升级或退回的累计次数 | 次 | 同上 | 有升级记录的问题 |
停留时长有两种用法：按状态统计用于定位卡点，按整体未关闭统计用于衡量问题从提出到关闭的总周期。两者不要混用，报告中应分别标注。超期天数允许为负值，表示提前关闭；统计超期率时只把大于零的记录计为超期。
统计范围要写明四件事：纳入哪些问题类型、覆盖哪些项目、观察周期从哪天到哪天、排除哪些记录。常见排除项包括测试数据、重复提交后合并的问题、明确挂起且不计入考核的等待类问题。排除规则一旦确定，前后对比时保持一致，否则改进效果无法归因。
数据口径与证据：时间戳、状态与承诺日期从哪里取
停留时长和超期天数都依赖时间字段，取数前要确认每个字段的来源和含义。所需字段包括：问题创建时间、每次状态变更的时间和变更前后状态、承诺解决日期、实际关闭时间、升级或退回记录。字段缺失或口径不一致，计算结果就无法复核。
状态口径需要统一。先列出全部状态，明确哪些算“在办”、哪些算“关闭”、哪些算“挂起等待”。状态回退要单独处理：问题从待验证退回处理中，应视为重新进入在办状态，停留时长从回退时间重新起算，并在明细中保留回退记录。跨状态跳转，例如从新建直接关闭，按实际时间戳计算，不做插值。
缺失值和异常值要有明确规则。没有承诺解决日期的问题不进入超期天数计算，但在报告中单列数量，避免超期率被少数有承诺日期的问题放大。承诺日期早于创建时间、关闭时间早于进入时间等异常记录，应回到原始记录核对，确认是录入错误还是流程倒挂，修正后再纳入统计。
证据留存要求保留明细数据，包括问题编号、各时间戳、承诺日期、状态序列和升级记录。汇总结果旁边附上明细导出，任何人按同一公式都能复算出相同数字。观察周期、排除规则和统计截止日也应记录在报告首页，便于跨期对比。
计算与评估步骤：从明细到分组统计
计算过程分为五步，每一步都产出可检查的中间结果，便于发现口径问题。
第一步，清洗明细。按统计范围筛选问题，补齐创建时间、状态变更序列、承诺日期和关闭时间，标记缺失字段和异常记录。输出一张每个问题一行的明细表，包含起止时间和状态路径。
第二步，逐条计算。按状态计算每次停留的起止时间，累加得到整体未关闭时长；用关闭日期或统计截止日减去承诺日期得到超期天数；统计升级记录条数得到重复升级次数。计算时统一单位，小时和天不要混用，跨天按自然日还是工作日需提前约定并写入口径。
第三步，分组。按问题类型、优先级、责任团队三个维度分别汇总，也可以交叉分组，例如“高优先级 × 责任团队”。分组维度不宜过多，否则每组样本过少，结论不稳定。
第四步，计算分布指标。每组输出中位数、P90、超期率和平均升级次数。中位数反映典型水平，P90反映尾部拖长的情况，两者一起看能区分“普遍偏慢”和“个别长期挂起”。平均值容易受极端值影响，可作为辅助但不单独使用。
第五步，设定观察周期并对比。以月或迭代为周期，比较调整前后的中位数、P90和超期率变化。对比时保持分组维度、排除规则和统计截止口径一致，样本量明显变化的组要单独说明。
当问题状态流转和时间字段已经在协作工具中记录，上述明细可以直接从系统导出，减少手工整理。ONES Performance 可自动收录 ONES 系统内日常流转的研发数据并形成分析指标，支持多维度、自定义的分析；问题本身的状态变更与承诺日期记录在 ONES Project 的工作项中，Performance 能同步其中的业务数据。具体到停留时长、超期天数是否有现成指标模板，以及状态变更历史和承诺日期字段的可用性，需要在选型或配置时按实际版本核验。
算例：一个问题的停留时长与超期天数
以下为演示情景，数字用于说明公式，不代表任何真实项目。
某问题于3月1日创建，3月2日进入“处理中”，3月10日退回“待分派”，3月12日再次进入“处理中”，3月25日关闭。承诺解决日期为3月20日。统计截止日为3月31日。
- 整体未关闭时长：3月25日减3月1日，共24天。
- “处理中”停留时长：第一次3月2日至3月10日共8天，第二次3月12日至3月25日共13天，合计21天；中间退回待分派的2天不计入处理中停留。
- 超期天数：3月25日减3月20日，超期5天。
- 重复升级次数：若退回待分派后重新分派算一次退回，则计1次；普通状态流转不计入。
若该问题到统计截止日仍未关闭，则整体未关闭时长为3月31日减3月1日共30天，超期天数为3月31日减3月20日共11天，并在结果中标注“进行中超期”，与已关闭问题的超期天数分开汇总。
分母处理同样需要说明。若某责任团队在观察周期内只有2个设有承诺日期的问题，其中1个超期，超期率为50%，但样本过少，应标注“样本不足”，不据此判断该团队整体表现。若某组纳入统计的问题数为零，不输出比率，显示“无数据”。
解读与限制：指标能说明什么、不能说明什么
停留时长长不等于处理不力。问题可能依赖外部供应商、等待架构评审或受制于其他团队排期，这些信息不在时间戳里。解读时应回到明细，看停留最长的状态集中在哪个环节，再结合问题描述判断是流程等待还是处理能力不足。
超期率受承诺日期设定质量影响很大。承诺日期定得过松，超期率自然低，但问题实际周期可能仍然很长；定得过紧，超期率上升却未必代表改进空间大。因此超期率要与整体未关闭时长的中位数和P90一起看，并定期检查承诺日期的设定依据。
样本量和时间窗影响可比性。观察周期太短，问题数量少，中位数和P90波动大；跨期对比时如果问题类型构成发生变化，例如新增了一类长周期依赖问题，整体指标会被拉高，需要分组对比而不是只看总数。
这套指标适合定位卡点、排序处置优先级和验证流程调整的效果，不适合直接作为个人绩效的唯一依据。合理做法是把指标用于团队层面的流程改进，个人评价结合问题复杂度、协作记录和实际产出综合判断。指标反映的是时间分布，因果解释仍需结合具体问题和过程记录。
常见问题
问题没有设置承诺解决日期，超期天数怎么处理？
没有承诺解决日期的问题不进入超期天数计算，但要在报告中单列这类问题的数量，说明超期率的分母只覆盖设有承诺日期的问题。若这类问题占比很高，超期率会因样本缩小而波动，解读时应同时看整体未关闭时长的中位数和P90，避免只凭超期率判断整体拖延程度。
问题状态回退后，停留时长从哪一刻重新起算？
状态回退视为重新进入在办状态，停留时长从回退时间重新起算，并在明细中保留回退记录。例如从待验证退回处理中，处理中的停留时长按第二次进入的时间重新累计，中间在待验证的时间不计入处理中停留。回退动作本身若属于升级或退回，可同时计入重复升级次数，但需在口径中事先写明哪些动作算一次。
观察周期内问题数量很少，还能算超期率吗？
可以计算，但要在结果旁标注“样本不足”，不据此判断团队整体表现。样本过少时中位数和P90波动大，单看比率容易误导。更稳妥的做法是拉长观察周期、合并相近分组，或改为看具体问题明细，等样本积累到一定数量后再做分组对比。
停留时长和超期天数能否直接从协作工具导出？
当问题的状态变更时间和承诺日期已在协作工具中记录，明细可以从系统导出，减少手工整理。ONES Performance 可自动收录 ONES 系统内日常流转的研发数据并形成分析指标，支持多维度、自定义的分析；问题本身的状态变更与承诺日期记录在 ONES Project 的工作项中，Performance 能同步其中的业务数据。停留时长、超期天数是否有现成指标模板，以及状态变更历史和承诺日期字段的可用性，需在选型或配置时按实际版本核验。
指标显示某团队停留时长最长，是否说明该团队处理不力？
不能直接下这个结论。停留时长长可能来自外部依赖、等待评审或其他团队排期，这些信息不在时间戳里。解读时应回到明细，看停留最长的状态集中在哪个环节，再结合问题描述判断是流程等待还是处理能力不足。指标适合定位卡点和排序处置优先级，因果解释仍需结合具体问题和过程记录。
