统计研发人员被会议和临时支持打断的情况，需要先把“打断”拆成两类可采集的事件：会议占用和临时支持，再固定统计单位与时间窗，分别计算会议占用率、临时支持频次、被打断工作日占比和上下文恢复时间。数据来自日历、工单或即时通讯求助记录、任务系统状态变更，结果用于观察团队协作负载与干扰分布。ONES 可在工作项与工时记录中登记临时支持和会议占用，作为数据来源之一。
要点总览（TL;DR）
- 把打断拆成会议占用和临时支持两类事件分别采集，固定时间窗（一周或两周）与统计单位（人-日、人-周），结果才可跨团队、跨周期比较。
- 四项核心指标：会议占用率=实际参会时长÷可用工作时长；临时支持频次=事件数÷统计人数或人日；被打断工作日占比=有打断的工作日数÷总工作日数；上下文恢复时间作为估计值单独标注。
- 临时支持按“非计划内、非本人发起、需即时响应”三条同时满足来判定；缺失与未登记事件显式标注为未采集，不按零处理，分母为零记不适用。
- 计算后按团队、角色、时段分组，并用连续两到三个时间窗看趋势；抽样核对原始记录与计算结果，先修口径再出结论。
- 指标反映协作负载与干扰分布，用于调整会议安排和支持值班，不用于个人绩效评价或心理状态判断。
评估目标：要回答哪些打断问题
打断统计要回答的是协作负载问题：研发人员的时间有多少被会议占走，有多少被临时支持切碎，这些干扰集中在哪些人、哪些角色、哪些时段。明确这一点，才能决定采集哪些事件、按什么粒度汇总。
两类事件需要分开处理。会议打断指日历上已安排或临时召集的会议占用，特征是时间块相对完整、参与人明确；临时支持打断指同事通过工单、即时通讯或当面提出的求助，特征是发起时间不可预期、需要即时响应。两类事件的判定规则和数据来源不同，合并成一个笼统的“打断次数”会掩盖问题来源。
评估目标清单可以写成三句话：
- 看清会议时间在可用工作时间中的占比，以及会议集中在哪些角色和时段。
- 看清临时支持的发生频次、单次时长和分布，判断支持请求是否过度集中在少数人身上。
- 为调整会议安排、建立支持值班或分流机制提供依据，观察调整前后的变化。
边界同样要写清楚：这套统计不用于个人绩效评价，打断多不等于个人效率低；也不用于心理状态诊断或压力评估，恢复时间是行为层面的估计值，不构成对个人状态的判断。
指标与范围：四个核心指标及统计单位
四个指标分别刻画打断的“量”和“碎片化程度”。每个指标都要写明分子、分母、单位和时间窗，否则跨团队、跨周期的数字无法比较。建议先固定时间窗为一周或两周，统计单位取人-日和人-周两种。
| 指标 | 公式 | 分子 | 分母 | 单位 | 时间窗 |
|---|---|---|---|---|---|
| 会议占用率 | 会议时长 ÷ 可用工作时长 | 时间窗内实际参会时长合计 | 同一时间窗内可用工作时长（扣除法定休息与已确认休假） | 百分比 | 人-周 |
| 临时支持频次 | 临时支持事件数 ÷ 统计人数或人日 | 时间窗内判定为临时支持的事件数 | 统计人数（人-周口径）或总人日（人-日口径） | 次/人·周 或 次/人日 | 人-周或人-日 |
| 被打断工作日占比 | 有打断事件的工作日数 ÷ 总工作日数 | 至少发生一次会议或临时支持的工作日数 | 时间窗内总工作日数 | 百分比 | 人-周 |
| 上下文恢复时间 | 打断后回到原任务的估计时长之和 ÷ 打断次数 | 各次打断的恢复时长估计值合计 | 纳入统计的打断次数 | 分钟/次 | 人-周 |
会议占用率的分母要用“可用工作时长”，即合同工时扣除休息、休假和已确认的培训等非工作时段，直接用自然日时长做分母会低估占用程度。临时支持频次有两种口径：按人-周算适合看个体负载分布，按人日算适合看每天被打断的概率，同一份报告里只选一种，避免混用。
上下文恢复时间是估计值，来源可以是打断后重新进入任务的实际间隔（通过任务系统状态变更时间推断），也可以是研发人员自报的典型恢复时长。无论哪种来源，都要在报告中标注“估计”，并与前三项基于记录计数的指标区分开。
数据口径与证据：从哪里取数、怎么判定一次打断
数据源分三块：日历提供会议事件，工单与即时通讯记录提供临时支持，任务系统提供任务状态变更用于推断恢复时间。三块数据的字段和判定规则要写成对照表，保证不同团队按同一口径登记。
| 事件类型 | 数据源 | 关键字段 | 判定规则 |
|---|---|---|---|
| 会议 | 日历事件 | 参会人、开始与结束时间、实际参会状态 | 取实际参会时长，不取邀请时长；未实际参加的会议不计入 |
| 临时支持 | 工单、即时通讯求助记录、口头请求登记 | 发起人、接收人、发起时间、处理时长、事由 | 同时满足非计划内、非本人发起、需即时响应三条才计入 |
| 恢复时间 | 任务系统状态变更、自报记录 | 打断结束时间、原任务恢复时间 | 取两次状态变更之间的间隔，超过阈值需人工确认 |
临时支持的判定是口径难点。计划内的代码评审、排期内的答疑属于正常工作安排，不计入；同事临时找你排查线上问题、口头请求协助调试，属于典型打断。建议在登记表里设置“是否计划内”“是否本人发起”“是否需即时响应”三个勾选项，三项同时为是才计入，减少事后争议。
缺失值要显式标注。日历缺失、求助未登记、恢复时间无法推断的情况，记为“未采集”，不能按零处理，否则会系统性低估打断程度。报告中同时给出采集覆盖率，例如“本周临时支持登记覆盖率约七成”，让读者知道数字的完整程度。
数据只统计团队聚合结果，个人明细仅用于核对和本人查看，对外分享的仪表盘做脱敏处理，避免把打断统计变成对个人的监视。
在工具承载上，ONES 效能管理自动收录系统内日常流转的研发数据并形成分析指标，支持多维度、精细化、自定义的分析，也提供场景化卡片与仪表盘模板。临时支持若通过工作项登记、会议占用若通过工时记录填报，就可以在系统内汇总；日历与外部即时通讯记录通常产生于系统外，需要额外登记或导入，具体字段与接入方式以产品实际配置为准。
计算与评估步骤：从原始记录到可比结果
从原始记录到可比结果，按以下步骤执行，每一步都留下可复核的中间产物。
- 按人-日汇总事件。把会议和临时支持记录归到具体的人和日期，同一时段重叠的事件（例如同时参加两个会议、会议期间收到求助）在汇总时去重，只计一次占用。
- 按公式计算四项指标，保留分母。每个指标同时输出分子、分母和结果，分母为零时标记“不适用”，不写零。
- 按团队、角色、时段分组对比。同一指标在不同角色（如核心模块负责人与一般开发）之间差异往往比团队平均值更有信息量；按上午、下午、晚间分时段统计，可以看出打断集中在哪个时间段。
- 用连续两到三个时间窗观察趋势。单周数据受发版、故障等偶发因素影响大，连续观察才能区分常态负载和短期波动。
- 抽样核对。随机抽取若干条原始记录，与计算结果逐条比对，确认判定规则执行一致、去重逻辑正确、缺失标注到位。
核对时重点看三类偏差：会议实际参会与邀请名单不一致导致的高估，临时支持未登记导致的低估，重叠事件去重规则不统一导致的跨团队不可比。发现偏差先修口径，再出结论。
例子：一个两周时间窗的算例
以下为演示情景，数字为假设值，用于说明公式代入方式。
某小组 6 名研发人员，两周共 10 个工作日，每人每日可用工作 8 小时，小组可用工作时长合计 6 × 10 × 8 = 480 小时。两周内日历记录的实际参会时长合计 96 小时；登记在案的临时支持事件 42 次，合计处理时长 31 小时；10 个工作日中有 9 天至少发生一次打断；抽样估计每次打断后平均需要 12 分钟恢复。
| 指标 | 代入 | 结果 |
|---|---|---|
| 会议占用率 | 96 ÷ 480 | 20% |
| 临时支持频次（人-周） | 42 ÷ 6 ÷ 2 | 3.5 次/人·周 |
| 被打断工作日占比 | 9 ÷ 10 | 90% |
| 上下文恢复时间 | 12 分钟 × 42 次 ÷ 42 次 | 12 分钟/次（估计） |
解读这组数字时，会议占用率 20% 说明会议时间占可用工时的五分之一；临时支持每人每周 3.5 次，配合 90% 的工作日都被打断，说明碎片化程度较高；按 12 分钟恢复估计，42 次打断累计约 8.4 小时的恢复成本，相当于一名研发人员一天多的有效工作时间。
分母为零或数据缺失时这样处理：某成员当周全部休假，可用工作时长为零，会议占用率记为“不适用”；某周临时支持登记覆盖率明显偏低，该周频次标注“数据不完整”，不与其他周直接比较。
解读与限制：指标能说明什么、不能说明什么
这组指标说明的是协作负载和干扰分布，不能直接推出效率结论。打断频次高，可能因为该成员负责核心模块、是团队内主要的技术支持入口，也可能因为支持流程缺少分流；同样频次在不同任务类型下影响差别很大，深度开发任务被打断的代价明显高于例行维护。
会议和临时支持都有合理部分。排期会、评审会、故障协同属于必要协作，不能一律视为干扰。解读时要把“必要协作”和“可优化干扰”分开：前者看总量是否合理，后者看是否有替代方式，例如把重复性答疑沉淀为文档、把支持请求改为值班轮换。
样本量小、登记不全时结论不可比。人数少的团队单周数据波动大，临时支持靠人工登记容易漏记，这两类情况下只适合看趋势方向，不适合做团队间排名。跨团队比较前，先确认时间窗、可用工时口径、判定规则三者一致。
指标的用途是调整会议安排和支持值班：例如把会议集中到固定时段、为高频支持模块设置轮值接口人、观察调整后两到三个时间窗内指标是否变化。它不适合作为个人考核依据，也不适合用来推断个人状态。ONES 效能管理提供交付效率、交付质量、资源效率、完成情况四个维度的度量体系，并支持仪表盘共享与权限控制，可以把打断相关指标与交付类指标放在同一视图中对照观察，具体指标配置以产品实际能力为准。
常见问题
临时支持靠人工登记容易漏记，统计结果还能用吗？
可以用，但要把登记覆盖率一起报出来。做法是每周统计临时支持登记覆盖率，例如通过工单或求助记录登记的事件数占实际发生数的估计比例，并在报告中标注“数据不完整”的周次。漏记会导致频次系统性偏低，因此这类周次只适合看趋势方向，不与其他周或团队直接比较。降低漏记的可行方式是简化登记入口，把求助统一走工单或固定表单，减少口头请求无记录的情况。
会议占用率的分母应该用合同工时还是实际出勤工时？
建议用可用工作时长，即合同工时扣除法定休息、已确认休假和培训等非工作时段。用自然日时长做分母会把休假和休息时间算进可工作范围，低估会议占用程度；用实际出勤工时会随请假波动，跨周比较时口径不稳定。无论选哪种，同一份报告和跨团队比较中必须保持一致，并在指标说明里写明扣除项。
统计出打断频次偏高，下一步应该先做什么？
先区分必要协作和可优化干扰，再决定动作。排期会、评审会、故障协同属于必要协作，看总量是否合理；重复性答疑、缺少分流的临时求助属于可优化干扰，可以考虑沉淀文档、设置值班轮换或指定接口人。调整后继续用同一时间窗和同一口径观察两到三个周期，确认指标变化来自调整本身，而非发版或故障等偶发因素。
人数少的团队做这套统计，结论可靠吗？
人数少的团队单周数据波动大，一两次故障或集中发版就能明显改变频次和占比，因此更适合看连续多个时间窗的趋势，不适合做团队间排名或单点结论。样本量小的时候，可以把时间窗拉长到一个月，或把统计单位从人-周放宽到团队-周，减少个别事件的影响。跨团队比较前，先确认时间窗、可用工时口径和打断判定规则三者一致。
用ONES做这类统计，哪些数据能自动汇总，哪些需要额外登记？
ONES 效能管理自动收录系统内日常流转的研发数据并形成分析指标，支持多维度、自定义分析，也提供场景化卡片与仪表盘模板，并支持仪表盘共享与权限控制。临时支持若通过工作项登记、会议占用若通过工时记录填报，可以在系统内汇总；日历和外部即时通讯记录通常产生于系统外，需要额外登记或导入。工时记录的具体字段和外部数据接入方式以产品实际配置为准。
