考核项目问题责任人的履职情况，建议围绕响应时效、解决质量、升级及时性三类指标建立口径：响应时效看首次响应时长与认领时长，解决质量看按期解决率、一次通过率与返工率，升级及时性看超期未升级比例与升级后闭环时长。每项指标都要写清起止时间点、分母范围、缺失值处理和时间窗，再结合问题难度分层解读，避免用单一指标直接评价个人绩效。
要点总览（TL;DR）
- 考核项目问题责任人履职，围绕响应时效、解决质量、升级及时性三类指标建立口径，每项指标先固定起止时间点、分母范围和时间窗。
- 响应时效看首次响应时长与认领时长；解决质量看按期解决率、一次通过率与返工率；升级及时性看超期未升级比例与升级后闭环时长。
- 取数依赖问题记录中的创建、认领、首次响应、解决、关闭时间及状态变更与升级记录，缺失值单独统计，不当作零时长拉低均值。
- 评估按定时间窗、筛范围、按责任人归集、逐项计算、分层对比、汇总结论推进，分母为零标注不适用，多指标并列呈现。
- 指标反映过程行为，需防范只挑易解决问题、拖延升级、拆分问题等失真，结合分层数据与抽样复核解读。
考核目标：先明确要回答的三个履职问题
项目问题责任人履职考核的对象，是项目推进障碍类问题的责任人，例如需求依赖未落地、跨团队协作卡点、资源不到位、决策待确认等影响项目进度的问题。产品Bug的缺陷管理、服务中断类服务事件有各自的归口流程和统计口径，不纳入这套考核。把对象限定清楚，后面的指标才有稳定的分母。
考核要回答三个问题，每个问题对应一个判断方向：
- 是否及时接手：问题创建后，责任人有没有在规定时间内响应并明确认领，判断方向是响应时效。
- 是否真正解决：问题是否在承诺时间内关闭，关闭后有没有被重新打开或返工，判断方向是解决质量。
- 是否在失控前升级：问题超出责任人可处理范围时，有没有在超过阈值前发起升级，判断方向是升级及时性。
这三个问题共同构成一份考核目标说明：响应时效回答“接没接、接得快不快”，解决质量回答“解决得实不实”，升级及时性回答“扛不住时有没有及时求助”。考核结果优先用于个人辅导和流程改进，例如发现某类问题普遍响应慢，先检查认领规则是否清晰；发现升级普遍滞后，先检查升级阈值是否合理。把单次考核结果直接与绩效等级挂钩，容易诱导责任人挑选容易的问题、拖延升级，反而破坏问题管理的真实性。
指标与范围：三类指标的定义与分母
三类指标各自解决一个判断问题，计算前必须先固定起止时间点、分子分母和时间窗。下表给出建议口径，其中时间窗统一按自然月或自然季度，以问题创建时间落入窗口为准。
| 类别 | 指标 | 计算口径 | 分子 | 分母 | 单位 |
|---|---|---|---|---|---|
| 响应时效 | 首次响应时长 | 问题创建时间至第一条有效响应记录的时间差 | 各问题首次响应时长之和（或取中位数） | 当期纳入统计的问题数 | 小时 |
| 响应时效 | 认领时长 | 问题创建时间至责任人明确认领的时间差 | 各问题认领时长之和（或取中位数） | 当期纳入统计的问题数 | 小时 |
| 解决质量 | 按期解决率 | 按期解决数 ÷ 应解决数 | 在承诺解决时间前关闭的问题数 | 当期应解决的问题数（含已到期未解决） | 百分比 |
| 解决质量 | 一次通过率 | 一次通过关闭数 ÷ 已关闭数 | 关闭后未被重新打开的问题数 | 当期已关闭的问题数 | 百分比 |
| 解决质量 | 返工率 | 返工问题数 ÷ 已关闭数 | 关闭后被重新打开或退回的问题数 | 当期已关闭的问题数 | 百分比 |
| 升级及时性 | 超期未升级比例 | 超期未升级数 ÷ 达到升级阈值数 | 超过升级阈值仍未发起升级的问题数 | 当期达到升级阈值的问题数 | 百分比 |
| 升级及时性 | 升级后闭环时长 | 升级发起时间至问题关闭的时间差 | 各升级问题闭环时长之和（或取中位数） | 当期发生升级并已闭环的问题数 | 小时 |
几个口径细节需要提前写进考核说明。首次响应时长以“第一条有效响应”为终点，自动回复、转交备注不计入，有效响应指对问题内容作出实质回应的评论或状态变更。按期解决率的分母包含已到期但尚未解决的问题，否则临近考核期末的问题会被排除在外，指标会虚高。升级阈值按问题优先级设定，例如高优先级问题超过约定时限未解决即视为达到升级阈值，具体时限由项目组在考核前确定并保持稳定。
纳入统计的问题范围建议同时满足三个条件：属于项目推进障碍类问题、创建时间落在统计窗口内、状态为已认领或已关闭。排除项包括产品Bug、服务中断事件、重复创建后被合并的问题，以及创建后经确认不属于问题范畴而被撤销的记录。范围一旦确定，考核期内不随意调整，否则前后期数据无法比较。
数据口径与证据：从问题记录中取哪些字段
指标能否复算，取决于问题记录里有没有可追溯的字段。每项指标依赖的字段如下：
- 创建时间：所有指标的时间起点，也是统计窗口的筛选依据。
- 认领时间：认领时长的终点，同时用于判断问题是否已明确责任人。
- 首次响应时间：首次响应时长的终点，取第一条有效响应记录的时间。
- 解决时间与关闭时间：按期解决率、一次通过率、返工率和升级后闭环时长的计算依据。
- 状态变更记录：判断问题是否被重新打开、是否发生退回，是返工率的主要证据。
- 升级记录：升级发起时间、升级对象，用于超期未升级比例和升级后闭环时长。
证据要求上，状态流转日志和评论记录是时效与升级判定的主要依据。口头沟通、线下会议中完成的响应和升级，应在问题记录中补一条说明，否则不计入有效响应或升级记录。这条规则要在考核前告知责任人，避免出现“做了但没记录”的争议。
常见异常需要事先约定处理方式。未认领的问题，认领时长记为缺失，不计入认领时长均值，但在认领率中计为未认领；无任何响应记录的问题，首次响应时长记为缺失，同时单独统计“零响应问题数”，不把缺失值当作零时长拉低均值。状态回退的问题，以最后一次关闭时间为准计算解决时长，回退次数计入返工次数。跨项目的问题按问题创建时所属项目归属责任人；代班场景以实际认领人为准，代班期间的问题单独标注，考核时与常规问题分开呈现，避免代班人承担不属于自己的历史积压。
这些字段和日志需要在日常问题流转中自然沉淀。以ONES为例，问题记录在系统内流转时，状态变更、评论和认领动作会形成可追溯的记录，ONES效能管理可自动收录系统内日常流转的研发数据并形成分析指标，支持多维度、精细化的自定义分析，便于按责任人、优先级和时间窗取数。预置仪表盘模板是否已覆盖上述全部指标，需要按实际配置核验后再用于考核。
计算与评估步骤：从取数到形成结论
评估流程按以下步骤执行，每一步都有明确的产物，便于复算和复核：
- 定时间窗：确定统计起止日期，按问题创建时间筛选，形成当期问题清单。
- 筛问题范围：剔除Bug、服务事件、合并问题和撤销记录，保留项目推进障碍类问题。
- 按责任人归集：以认领人为准把问题分配到个人，代班和跨项目问题按前述归属规则单独标注。
- 逐项计算指标：按指标定义表计算每项指标的分子、分母和结果，时长类指标同时给出均值和中位数。
- 按优先级或难度分层：把问题按优先级、类型分组，在组内比较，避免高难度问题多的责任人被低难度问题拉低评价。
- 汇总结论：多指标并列呈现，标注每项指标的分母和缺失情况，形成个人履职说明。
分母为零时要单独处理。某责任人当期没有纳入统计的问题，相关指标标注“不适用”，不按0%或100%计入，也不参与团队均值计算。某责任人当期没有达到升级阈值的问题，超期未升级比例同样标注不适用。这样处理可以避免“没有问题可做”被误读为“表现完美”或“表现很差”。
汇总时不建议把多项指标加权合成一个总分。响应快但返工率高、解决率高但升级滞后，这些差异恰恰是辅导的切入点，合成总分会把它们掩盖掉。更合适的做法是并列展示三类指标，配合分层数据，由项目负责人结合具体问题逐条看。
计算示例：一名责任人一个季度的指标演算
以下为演示情景，数字仅用于说明计算过程，不代表任何达标线或行业基准。
假设某责任人在一个季度内纳入统计的问题共20个，其中高优先级6个、中优先级10个、低优先级4个；已关闭16个，已到期未解决4个；关闭后被重新打开2个；达到升级阈值的问题5个，其中超期未升级1个；发生升级并已闭环的问题3个。
| 指标 | 计算过程 | 结果 |
|---|---|---|
| 首次响应时长中位数 | 20个问题的首次响应时长排序后取中间值 | 4.5小时 |
| 认领时长中位数 | 20个问题的认领时长排序后取中间值 | 6小时 |
| 按期解决率 | 14 ÷ 20 | 70% |
| 一次通过率 | 14 ÷ 16 | 87.5% |
| 返工率 | 2 ÷ 16 | 12.5% |
| 超期未升级比例 | 1 ÷ 5 | 20% |
| 升级后闭环时长中位数 | 3个升级问题闭环时长取中间值 | 36小时 |
解读时先看分层数据。按期解决率70%整体偏低，但拆开看，高优先级6个问题中5个按期解决，未按期的4个问题里有3个属于中优先级且依赖外部团队交付。这说明该责任人对高优先级问题的处理是及时的，短板集中在中优先级问题的推进节奏上，需要结合依赖方的交付情况进一步判断，不能直接归因为个人拖延。返工率12.5%对应的2个问题都是关闭后因方案调整被重新打开，属于需求变化而非解决质量问题，复核时应从返工统计中剔除或单独说明。
升级及时性方面，超期未升级的1个问题是中优先级问题，责任人当时判断可在内部消化，实际超出了阈值。这类情况适合在复盘时讨论升级阈值的合理性，而不是简单记为失职。示例中的时长中位数、分母范围和剔除规则都是假设条件，实际使用时需按本项目的字段和规则重新计算，不能直接套用这些数字。
解读与限制：指标能说明什么、不能说明什么
这些指标反映的是问题处理过程中的行为，例如响应快慢、关闭是否按期、升级是否及时。它们能帮助发现流程卡点和辅导方向，不能直接等同于个人能力评价或绩效结论。一个责任人响应时长偏长，可能是问题描述不清导致难以判断，也可能是同时承接了过多问题，需要结合上下文看。
常见的指标失真有三类，考核设计时要提前防范：
- 只挑易解决的问题：责任人优先处理简单问题以提升按期解决率，难问题被搁置。防范方式是分层看指标，单独统计高优先级和长周期问题的处理情况。
- 拖延升级：为避免“超期未升级”记录，责任人在阈值边缘反复尝试而不发起升级，实际延误了问题解决。防范方式是同时看升级后闭环时长和问题总解决时长，升级晚但闭环快的情况要单独识别。
- 拆分问题规避超期：把一个大问题拆成多个小问题分别关闭，使按期解决率虚高。防范方式是抽样复核问题粒度和关闭理由，关注同一来源的关联问题。
数据可比性也有限制。不同项目的问题难度、依赖方配合度、优先级分布差异很大，跨项目直接横向比较容易得出误导性结论。建议在项目内部按优先级分层比较，跨项目比较时只做趋势参考。使用上，多指标交叉看比单指标排名更可靠，定期抽样复核问题记录的真实性，每季度校准一次口径和升级阈值，把考核结果用于辅导沟通和流程改进，这套指标才能持续发挥作用。
常见问题
责任人当期没有纳入统计的问题，指标该怎么算？
相关指标标注“不适用”，不按 0% 或 100% 计入，也不参与团队均值计算。某责任人当期没有达到升级阈值的问题，超期未升级比例同样标注不适用。这样处理可以避免“没有问题可做”被误读为表现完美或表现很差。若需要看团队整体情况，可单独统计当期无问题记录的人数，作为数据覆盖说明的一部分。
问题关闭后因需求变化被重新打开，算不算解决质量问题？
建议在返工统计中区分原因。因方案调整、需求变化导致的重新打开，与解决不彻底导致的退回性质不同，前者不宜直接计入责任人的返工。操作上可在关闭或重新打开时标注原因，复核时把需求变化类单独列出或剔除，再计算返工率。若原因标注缺失，抽样复核时按评论记录判断，并在考核说明中写明判定规则。
跨项目问题和代班期间的问题，归属给谁？
跨项目问题按问题创建时所属项目归属责任人；代班场景以实际认领人为准，代班期间的问题单独标注，考核时与常规问题分开呈现。这样处理可以避免代班人承担不属于自己的历史积压，也避免同一问题在两个人之间重复计入或无人计入。归属规则应在考核期开始前确定并告知，考核期内保持一致。
升级阈值应该由谁定，考核期内可以调整吗？
升级阈值建议由项目组在考核前按问题优先级确定，例如高优先级问题超过约定时限未解决即视为达到升级阈值。阈值一旦确定，考核期内保持稳定，否则前后期数据无法比较。若复盘发现阈值明显不合理，可在下一考核期调整，并在调整时说明原因，同时对调整前后的数据分段呈现，避免直接混算。
这些指标可以直接用于个人绩效评级吗？
不建议直接挂钩。指标反映的是问题处理过程中的行为，响应时长偏长可能是问题描述不清或同时承接问题过多，按期解决率偏低可能与外部依赖有关。更合适的用法是并列展示三类指标，结合分层数据和具体问题逐条复核，把结果用于辅导沟通和流程改进。确需与绩效关联时，应明确指标只作为参考输入之一，并保留抽样复核和申诉环节。
