度量项目问题是否久拖不决，需要把“拖了多久”拆成可复算的时间指标：停留时长看问题在某个状态或未关闭区间内待了多久，超期天数看实际解决时间与承诺解决时间的差距，重复升级次数看同一问题被反复推动的次数。统计前先统一问题范围、状态口径、时间窗和日历，再按问题、团队、优先级分层输出，才能识别出真正需要干预的对象。
要点总览（TL;DR）
- 久拖不决要拆成三个可复算指标：状态停留时长、未关闭总时长与超期天数、重复升级次数，分别回答卡在哪一步、整体拖了多久、被反复推动了几轮。
- 停留时长按状态历史分段累计，未关闭问题以统计截止时间为区间终点；超期天数用实际解决时间（未关闭时用截止时间）减承诺解决时间，正数为超期。
- 统计前固定四项口径：问题来源、优先级、时间窗（按创建还是按关闭入池）、责任团队；同时声明按自然日还是工作日、是否暂停计时、承诺时间变更用哪个值。
- 无承诺时间的问题单列、不进超期率分母；状态历史缺失标记为不可计算并输出缺失比例，分母为零时输出“不适用”。
- 指标用于圈出需干预的问题并触发复盘，需结合优先级与影响解读，不宜直接作为个人绩效结论。
评估目标：先界定什么叫久拖不决
“久拖不决”是一个判断，不是一个原始数据。要让判断可复核，需要先把它拆成几个能取数、能计算、能对比的维度，再规定评估对象和结果用途。
建议从三个维度判定：
- 停留时长：问题在某个处理状态中停留的时间，或在未关闭状态下累计存在的时间。它回答“卡在哪一步、卡了多久”。
- 超期天数：实际解决时间（未关闭时用统计截止时间）超过承诺解决时间的部分。它回答“相对承诺晚了多少”。
- 重复升级次数：同一问题被升级、上报或跨团队协调的事件次数。它回答“这个问题被反复推动了多少轮”。
评估对象应限定为项目推进障碍类问题，例如需求依赖未确认、资源不到位、接口联调受阻、决策待拍板等。产品缺陷（Bug）和服务事件有各自的生命周期与响应时限，混入同一套口径会让停留时长和超期天数失去可比性，应分开统计。
评估结果用于识别需要干预的问题、触发复盘和调整资源，判断单位是“问题”而不是“人”。把停留时长直接挂到个人绩效上，容易让成员倾向于快速改状态而不是真正解决问题，指标就失真了。
指标与范围：三个核心指标怎么定义
三个指标各自回答不同问题，定义时要写清公式含义、单位、时间基准和统计范围，避免同名指标在不同报表里算法不一致。
| 指标 | 公式含义 | 单位 | 统计范围 |
|---|---|---|---|
| 状态停留时长 | 某状态区间结束时间 − 该区间开始时间，按状态分段后分别累计 | 小时或工作日 | 指定状态集合内的问题，按状态分别统计 |
| 未关闭总时长 | 统计截止时间（或关闭时间）− 问题创建时间 | 自然日或工作日 | 统计时间窗内处于未关闭状态的问题 |
| 超期天数 | 实际解决时间（未关闭时用统计截止时间）− 承诺解决时间 | 自然日或工作日 | 有承诺解决时间的问题；无承诺时间的单列 |
| 重复升级次数 | 统计周期内该问题的升级事件计数（去重后） | 次 | 有升级记录的问题，按问题汇总 |
统计范围需要同时固定四项：问题来源（哪些项目、哪些提出渠道）、优先级（是否只统计高优先级，还是全量分层）、时间窗（按创建时间入池还是按关闭时间入池）、责任团队（按当前责任人还是按问题所属团队归属）。时间窗口径尤其要写死：按创建时间入池，统计的是“这段时间新产生的问题后来拖了多久”；按关闭时间入池，统计的是“这段时间关闭的问题总共用了多久”。两种口径回答的问题不同，同一份报表只能选一种。
数据口径：状态时间、承诺时间与升级记录怎么取
三个指标依赖三类数据：状态变更历史、承诺解决时间、升级事件记录。取数前要确认字段存在、时间基准一致、缺失有处理规则。
| 数据项 | 取数要求 | 缺失或异常处理 |
|---|---|---|
| 状态变更历史 | 每条记录包含问题ID、原状态、新状态、变更时间、操作人 | 历史缺失的问题标记为“不可计算”，不默认按创建时间补齐 |
| 承诺解决时间 | 记录承诺时间及其设定时间、设定人，便于判断承诺是否被中途修改 | 无承诺时间的问题单列，不进入超期率分母 |
| 升级事件 | 每次升级记录问题ID、升级时间、升级对象、事件唯一标识 | 同一问题同一时刻重复录入按唯一标识去重 |
| 工作日历与时区 | 明确按自然日还是工作日计算，统一时区 | 跨时区团队统一换算到同一基准时区 |
还有两类口径要提前约定。一是暂停计时：问题处于“等待外部回复”“挂起”等状态时是否停止计时，若停止，需要状态历史支持识别暂停区间，并在公式中扣除。二是承诺时间变更：承诺时间被修改过的问题，建议保留原始承诺和最新承诺两个值，统计时声明用哪一个，否则同一问题在不同时间跑出的超期天数会对不上。
在工具层面，这些数据来自问题单的状态流转记录和字段填写。以 ONES 为例，问题可以作为工作项在项目内流转状态，状态变更、责任人、计划时间等信息随日常操作留存；ONES Performance 能自动收录系统内流转的研发数据并支持多维度、自定义分析，可作为汇总停留与超期结果的取数基础。具体是否预置“停留时长”“超期天数”这类现成指标，需要在实际环境中核验配置方式。
计算步骤：停留时长与超期天数的统计方法
计算按“先单问题、再汇总”的顺序进行，每一步都保留中间结果，便于抽查复算。
第一步：按状态分段计算停留时长。对每个问题，把状态历史按时间排序，形成若干区间 [开始时间, 结束时间)。每个区间的时长 = 结束时间 − 开始时间；未关闭问题的最后一个区间以统计截止时间为终点。若需要某状态的累计停留，把该状态的所有区间时长相加。单位统一为小时或工作日，同一报表内不混用。
第二步：计算未关闭总时长。未关闭总时长 = 统计截止时间 − 创建时间；已关闭问题用关闭时间替换统计截止时间。这个指标反映问题从提出到现在的整体跨度，适合筛查长期挂起的问题。
第三步：计算超期天数。超期天数 = 实际解决时间（未关闭时用统计截止时间）− 承诺解决时间。结果为正表示超期，为负表示提前，为零表示按期。按工作日计算时，需扣除区间内的非工作日。
第四步：统计重复升级次数。按问题ID分组，对升级事件按唯一标识去重后计数。可同时输出“升级次数”和“首次升级距创建时间”，后者能区分“一开始就推不动”和“后期反复返工”两类情况。
第五步：分层汇总。按问题、责任团队、优先级三个维度分别汇总，每个维度都给出样本数、均值和中位数。停留时长和超期天数通常右偏分布明显，均值容易被个别超长问题拉高，中位数更能代表典型情况，两者一起看。
第六步：处理边界情况。分母为零时（如某团队当期没有带承诺时间的问题），超期率输出“不适用”而不是 0%；无承诺时间的问题单独列出数量和占比，作为承诺管理质量的参考；状态历史缺失的问题标记为不可计算，并统计不可计算比例，比例过高说明数据基础不足，结论要谨慎。
算例：一个问题的停留与超期怎么算出来
以下为演示情景，用于说明计算过程，数字为假设值。
某问题于 3 月 3 日 9:00 创建，承诺解决时间为 3 月 14 日 18:00，统计截止时间为 3 月 21 日 18:00，按自然日计算。状态时间线如下：
| 状态 | 开始时间 | 结束时间 | 区间时长 |
|---|---|---|---|
| 待确认 | 3月3日 9:00 | 3月6日 9:00 | 3天 |
| 处理中 | 3月6日 9:00 | 3月12日 9:00 | 6天 |
| 等待外部回复 | 3月12日 9:00 | 3月18日 9:00 | 6天 |
| 处理中 | 3月18日 9:00 | 3月21日 18:00（截止） | 3.375天 |
停留时长：“处理中”状态累计 6 + 3.375 = 9.375 天；“待确认”3 天；“等待外部回复”6 天。未关闭总时长 = 3月21日 18:00 − 3月3日 9:00 = 18.375 天。
超期天数：问题截至统计时仍未关闭，用截止时间计算：3月21日 18:00 − 3月14日 18:00 = 7 天，即超期 7 天。
重复升级次数：假设该问题在 3 月 10 日和 3 月 17 日各有一次升级记录，其中 3 月 17 日因重复录入产生两条相同事件，按唯一标识去重后计 2 次。
结果解读：该问题未关闭总时长 18.375 天，超期 7 天，升级 2 次，且“等待外部回复”占了 6 天，说明卡点主要在外部依赖而非内部处理。这类问题应进入干预清单，推动外部依赖的确认，而不是简单催促处理人。
解读与限制：指标说明什么、不能说明什么
三个指标描述的是问题在流程中的时间分布和协调成本，它们能指出“哪里慢、慢了多久”，不能单独证明问题严重或某个人失职。
- 长停留不等于问题严重。一个低优先级问题停留 30 天可能符合预期，一个高优先级问题停留 3 天就可能需要干预。解读时要结合优先级、影响范围和涉及的业务节点。
- 超期天数受承诺时间合理性影响。承诺时间定得过紧，超期天数会普遍偏高；定得过松，指标失去预警作用。建议同时观察承诺时间的设定与变更频率，判断承诺质量。
- 重复升级反映协调成本。升级次数多说明问题需要跨层级、跨团队推动，是流程或职责边界问题的信号，不能直接当作质量差的证据；升级次数为零也可能意味着问题被搁置而无人推动。
- 数据完整性决定结论可信度。状态历史缺失、承诺时间未填、升级记录不规范，都会让计算结果偏离实际。统计时同步输出不可计算比例和缺失占比，比例高时先补数据再下结论。
- 指标用于触发复盘与干预。把停留时长、超期天数、升级次数作为筛选条件，圈出需要讨论的问题，在复盘会上分析卡点原因、调整承诺或重新分配资源。直接把这些数字作为个人绩效结论，会诱导改状态、改承诺等行为，反而破坏数据质量。
落地时，建议先在一个项目或一个团队试算一个统计周期，核对几个问题的手工计算与系统结果是否一致，确认状态口径、日历和分母规则无误后再扩大范围。ONES Performance 提供交付效率、交付质量、资源效率、完成情况等维度的效能分析，并支持自定义分析，可作为汇总这类时间指标的载体；具体指标配置需结合实际工作项字段和状态设置进行验证。
常见问题
问题在“等待外部回复”这类挂起状态的时间，算不算停留时长？
取决于统计前约定的暂停计时规则，两种做法都可行，但同一份报表只能选一种。
- 不暂停：所有状态区间都计入，停留时长反映问题从提出到关闭的真实跨度，适合评估整体拖延程度。
- 暂停：仅扣除“等待外部回复”“挂起”等约定状态区间，停留时长更聚焦内部可控时间，适合分析内部处理效率。
选择暂停口径时，需要状态历史能识别暂停区间的起止时间，并在公式中逐段扣除；同时把暂停总时长单独输出，避免外部依赖造成的延误被完全隐藏。
承诺解决时间中途被改过，超期天数按哪个时间算？
建议同时保留原始承诺和最新承诺两个值，并在报表中声明本次统计使用哪一个。
用最新承诺计算，反映当前计划下的执行偏差，适合日常跟踪；用原始承诺计算，反映最初承诺的兑现情况，适合复盘承诺质量。两种口径混用会导致同一问题在不同时间跑出的超期天数对不上。若承诺时间被频繁修改，还应单独统计变更次数和变更幅度，作为承诺管理质量的参考。
没有填写承诺解决时间的问题怎么处理？
这类问题不进入超期率的分母，单独列出数量和占比。
把无承诺时间当作“未超期”会拉低超期率，把无承诺时间当作“超期”又会高估问题严重程度，两种做法都会让指标失真。更稳妥的做法是：超期天数只对有承诺时间的问题计算，无承诺时间的问题按数量、占比和停留时长单独呈现，作为承诺管理是否到位的观察项。如果无承诺时间的占比很高，应先补承诺规则，再谈超期率。
按创建时间入池和按关闭时间入池，统计结果差别有多大？
两种口径回答的是不同问题，差别在问题集合本身。
- 按创建时间入池：统计某段时间内新产生的问题后来拖了多久。新问题尚未关闭时也能纳入，适合监控当前积压。
- 按关闭时间入池：统计某段时间内关闭的问题总共用了多久。只包含已关闭问题，适合回顾阶段性处理效率，但会漏掉仍在拖延的问题。
同一份报表只能选一种口径，并在报表说明中写清。若需要同时看积压和处理效率，可以出两张报表，分别标注口径，避免把两个数字放在一起比较。
三个指标算出来之后，怎么判断哪些问题需要优先干预？
建议用组合条件筛选，而不是单看某一个指标。
例如：高优先级且超期天数大于零的问题；未关闭总时长超过团队中位数且期间升级两次以上的问题；停留在“等待外部回复”等外部依赖状态时间占比高的问题。这几类分别对应承诺失守、协调成本高和外部卡点，干预动作不同：前者需要重排计划或调整承诺，中者需要明确责任边界，后者需要推动外部依赖确认。
筛选出清单后，在复盘会上逐条分析卡点原因，再决定调整资源、升级协调还是关闭问题。指标的作用是缩小讨论范围，结论仍要结合问题的影响范围判断。
