资源利用率偏低，先别急着把工时填满。更常见的情况是：任务本身有，但被频繁切换、等待依赖和返工切碎了。改进要从投入端入手，先建立任务分配与项目切换的现状基线，分清损耗类型，再按减少并行、成块分配、明确交接、按能力派活的顺序小范围调整，最后用同一口径的数据对照验证。ONES 的工作项与迭代视图可以承载任务分配、依赖和切换记录，方便把改进动作落到日常协作中。
要点总览（TL;DR）
- 利用率偏低先固定统计口径，再把“低”拆成空闲、切换、等待、返工、能力错配五类损耗，分别设定可观测目标。
- 判断主因看两个比例：跨项目切换次数占比高，优先处理切换；依赖等待时长占比高，优先处理任务分配与依赖排期。
- 改进按顺序推进：限制并行与在手上限、任务拆到可交接粒度、切换设缓冲与交接清单、按能力与负载派活、用周度排期会替代临时插单。
- 限制并行可能推迟个别项目启动，交接与排期会增加管理动作，小团队或需求高峰需按周期调整上限并设恢复条件。
- 验证沿用改进前口径，同时观察切换次数、等待时长和返工率，以试点小组对比未改小组，排除任务总量变化的影响。
先看清现状：利用率偏低是哪种低
利用率偏低是一个结果指标，单看数字无法判断该改什么。第一步是把统计口径固定下来：按人、按团队还是按周期统计，分子分母分别包含哪些工作项，是否计入会议、支持、返工和等待时间。口径不统一，改进前后的对比就失去意义。建议选定一个统计周期（例如连续四周），覆盖一个完整的小迭代，避免用单周数据下结论。
口径确定后，把“低”拆成可观察的投入端现象。常见的有五类：一是无任务可派，人员处于空闲；二是任务被切碎，一个人同时挂着多个项目，每天在上下文之间来回；三是等待依赖，上游未交付或评审未排期，工作项停在原地；四是返工重做，完成定义不清导致反复修改；五是能力错配，任务分配与人员技能不匹配，做起来慢且质量不稳。这五类的改进动作完全不同，混在一起谈“提升利用率”容易开错药。
改进目标应设为提升有效投入时间占比，而不是单纯拉高工时。有效投入指推进工作项向完成状态移动的时间。目标值可以按损耗类型分别设定，例如把切换损耗从当前水平压缩到某个比例，把等待时长控制在一个迭代内的可接受范围。目标要写成可观测的形式，便于后续验证。
| 统计口径 | 统计范围 | 周期 | 主要损耗类型（初步占比） | 目标值 |
|---|---|---|---|---|
| 按人/按团队 | 参与项目的工作项 | 连续四周 | 切换、等待、返工、错配、空闲 | 有效投入占比提升至约定水平 |
| 按项目 | 项目内全部任务 | 一个迭代 | 同上，按项目归集 | 等待与返工时长下降 |
这张基线表的作用是给后续改进提供参照系。占比可以先做粗略估算，例如通过工作项状态停留时间、切换记录和返工次数推算，不必追求精确到分钟。关键是同一口径贯穿始终。
任务分配与项目切换中的常见损耗
利用率被消耗，往往不是某个人不努力，而是分配方式和切换节奏在制造空转。理解机制，才能判断问题出在任务分配还是项目切换。
一人同时挂多个项目导致频繁切换。当一个人手上同时有三个以上活跃项目，每天要在不同上下文之间切换，每次切换都需要重新加载背景、确认进度、找回思路。切换次数越多，真正推进工作的时间越少。可观测信号是：同一人当日工作项跨多个项目、状态变更频繁但完成量低。
任务颗粒度过大或过小。颗粒度过大，一个任务挂一周没有中间交付，依赖方只能干等；颗粒度过小，任务碎成大量待办，协调和交接成本超过执行本身。两种极端都会制造等待和返工。可观测信号是：任务平均停留时间过长，或任务数量激增而单个任务耗时极短。
交接不清、依赖未排期。上游完成后没有明确交接物，下游不知道从哪接；依赖关系没有进入排期，等到要用时才发现前置未做。这类损耗表现为工作项长时间停在“等待”状态。可观测信号是：阻塞标记频繁出现，且阻塞原因集中在少数几个依赖点。
按人头平均派活而非按能力与负载派活。把任务平均分给每个人，看似公平，实际让擅长的人做不熟的事、让已经满负荷的人继续接单。结果是部分人加班、部分人闲置，整体利用率被拉低。可观测信号是：同类任务在不同人身上的耗时差异明显，且与技能标签不对应。
| 损耗类型 | 典型现象 | 影响环节 | 可观测信号 |
|---|---|---|---|
| 频繁切换 | 一人多项目并行 | 执行与上下文重建 | 跨项目工作项多、完成量低 |
| 颗粒度失当 | 任务过大或过碎 | 等待与协调 | 停留时间长或任务数激增 |
| 交接与依赖 | 阻塞、返工 | 上下游衔接 | 阻塞标记集中、等待时长高 |
| 能力错配 | 耗时差异大 | 执行质量与速度 | 同类任务耗时与技能不对应 |
判断问题偏向任务分配还是项目切换，可以看两个比例：跨项目切换次数占总工作项变更的比例，以及因依赖等待损失的时长占总投入的比例。前者高，说明切换是主因；后者高，说明分配与依赖排期是主因。两者都高时，先处理切换，因为切换会放大等待的感知。
优先改进动作：从分配与切换入手
改进动作按顺序推进，先做约束并行，再做分配细化，最后固化节奏。每一步都对应前面识别出的损耗类型。
限制并行项目数，设定每人同时在手任务上限。给每个人设定一个“在手”上限，例如同时推进的活跃任务不超过两到三个，超出部分进入待办队列而不是立即开工。上限的作用是强制排序，让真正优先的工作先获得完整注意力。责任角色是团队负责人或项目负责人，生效范围先从试点小组开始。
把任务拆到可交接的粒度，明确负责人、依赖与完成定义。每个工作项写清三件事：谁负责、依赖谁、什么算完成。粒度以“一个迭代内可交付、可被下游接手”为准。完成定义写具体，例如包含评审通过或测试通过，减少“做完了但不算完”的返工。这一步直接压缩等待和返工两类损耗。
项目切换设缓冲与交接清单。当人员确实需要在项目间切换时，规定切换前填写交接清单：当前进度、下一步、未决问题、相关文档位置。切换后留出短暂缓冲用于上下文重建，而不是立刻进入新任务的高强度输出。交接清单让接手方少走弯路，也减少原负责人被反复追问的打断。
按能力标签与当前负载派活，先匹配再平衡。给人员维护能力标签，派活时先看技能匹配，再看当前在手任务量。匹配优先能减少错配带来的低效执行，负载平衡在此基础上做微调。派活动作由项目负责人执行，依据是工作项上的标签与在手数量。
用周度排期会替代临时插单。把临时插入的任务集中到每周固定排期会上处理，会上确认优先级、调整在手任务、更新依赖。临时插单减少后，切换次数随之下降，团队对本周投入有稳定预期。
| 改进动作 | 责任角色 | 生效范围 | 预期影响的损耗类型 |
|---|---|---|---|
| 限制并行与在手上限 | 团队/项目负责人 | 试点小组 | 频繁切换 |
| 任务拆到可交接粒度 | 任务负责人 | 全部工作项 | 等待、返工 |
| 切换缓冲与交接清单 | 切换当事人 | 跨项目人员 | 切换、等待 |
| 按能力与负载派活 | 项目负责人 | 派活环节 | 能力错配 |
| 周度排期会 | 团队负责人 | 团队节奏 | 切换、临时插单 |
这些动作在 ONES 中可以这样落地：工作项承载负责人、依赖、完成定义和状态，迭代视图呈现每个人当前在手的任务数量，阻塞标记和状态停留时间帮助识别等待与返工。改进动作产生的分配调整和切换记录留在同一套工作项里，后续验证时可以直接取数，不必另建台账。
适用前提与代价
上述改进成立有前提，也需要付出成本，盲目套用可能适得其反。
前提之一是任务来源相对稳定、工作项可记录。如果大量工作靠口头安排、没有进入统一的工作项管理，切换次数和等待时长就无法观测，改进也缺少依据。前提之二是团队对优先级有共识，否则限制并行时会出现“我的任务都重要”的僵局。前提之三是管理层愿意接受短期的节奏调整，而不是一边限制并行一边继续临时加急。
代价方面，限制并行可能延长个别项目的周期。当资源从多项目摊薄转为集中投入，某些项目的启动会推迟，这需要与交付优先级协调，把推迟的项目明确告知相关方。交接与排期会增加管理动作，周度排期会和交接清单都要占用少量管理时间，这部分投入应从减少返工和等待中回收。团队规模小或业务波动大时，固定的在手上限需要调整，例如在需求高峰临时放宽，但放宽要有明确期限和恢复条件。
| 条件/代价 | 具体表现 | 应对方式 |
|---|---|---|
| 任务可记录 | 工作项进入统一管理 | 先补齐记录再谈改进 |
| 周期延长 | 部分项目启动推迟 | 与交付优先级协调并提前沟通 |
| 管理动作增加 | 排期会与交接清单占时 | 控制会议时长，模板化交接 |
| 规模与波动 | 小团队或需求高峰 | 上限按周期调整并设恢复条件 |
效果验证：用同一口径对照改进前后
验证的核心是沿用改进前的利用率口径与统计周期，避免换算法得出“变好了”的错觉。改进前按人、按团队、按周期怎么算，改进后仍怎么算，统计范围保持一致。
除利用率本身，同时观察过程指标：切换次数（跨项目工作项变更频次）、等待时长（阻塞状态停留时间）、返工率（因未达完成定义而重新打开的比例）。这些指标直接对应改进动作，能解释利用率变化来自哪里。如果利用率上升但返工率也上升，说明只是把工作压得更紧，并未改善投入结构。
设置对照周期，排除任务量整体变化的影响。例如改进前后各取四周，并记录同期任务总量和紧急插单数量。若任务总量本身下降，利用率变化可能来自外部波动而非改进动作。更稳妥的做法是以试点小组对比未改小组：两组任务类型相近，一组执行新规则，一组维持原做法，观察同一周期内的指标差异，再决定是否推广。
| 验证指标 | 口径 | 对照方式 | 观察周期 | 判定标准 |
|---|---|---|---|---|
| 有效投入占比 | 与改进前一致 | 试点组 vs 未改小组 | 前后各四周 | 试点组提升且未改小组平稳 |
| 切换次数 | 跨项目变更频次 | 同上 | 同上 | 试点组下降 |
| 等待时长 | 阻塞停留时间 | 同上 | 同上 | 试点组缩短 |
| 返工率 | 重新打开比例 | 同上 | 同上 | 不上升或下降 |
判定时把相关性当因果是常见误区。利用率提升如果与任务总量下降同时发生，就不能全部归功于改进动作。试点对照的价值在于提供一个同期参照，让改进效果与外部波动分开观察。验证通过后再逐步推广，推广时保留同一口径，持续观察一到两个周期，确认效果稳定。
常见问题
利用率偏低时，怎么判断问题主要出在任务分配还是项目切换？
看两个比例即可初步判断。跨项目工作项变更次数占总变更的比例高，说明切换是主因，人员在不同项目间来回，上下文重建消耗了大量时间。因依赖等待损失的时长占总投入的比例高，说明任务分配与依赖排期是主因，工作项停在阻塞状态等上游。两者都高时先处理切换，因为频繁切换会放大等待带来的感知，让团队误以为处处都在卡。
限制并行项目数后，个别项目周期变长怎么办？
这是限制并行的正常代价，需要提前与交付优先级协调。做法是把推迟启动的项目明确列出，告知相关方新的启动时间，而不是让项目悄悄延后。同时给在手上限设恢复条件：需求高峰可临时放宽，但写明放宽期限和回到原上限的时间点。若多个项目都不可推迟，说明资源总量与承诺范围不匹配，应先调整范围再谈利用率。
团队规模小、任务来源不稳定时，这套改进还适用吗？
适用，但动作要简化。小团队可以先只做两件事：把任务拆到可交接粒度并写清完成定义，以及用固定排期会收拢临时插单。在手上限可以设得宽松一些，按周调整。任务来源不稳定时，切换和等待的观测数据本身波动大，建议拉长观察周期，用两个以上周期对照，避免用单周数据下结论。
改进后利用率上升，但返工也变多，说明什么？
说明工作被压得更紧，投入结构并未改善。返工率上升通常对应完成定义不清或任务颗粒度过细，执行者为了尽快推进而跳过评审或测试。此时应回看完成定义是否写具体，以及任务拆分是否把验收环节切掉了。利用率与返工率要一起看，只升利用率不看返工，容易把返工成本转移到下游。
验证改进效果时，试点组和未改小组任务类型不同怎么办？
先尽量让两组任务类型相近，例如选择同一产品线或同类需求。若无法完全对齐，就在对比时记录任务复杂度、紧急插单数量等差异因素，判定时把这些因素纳入解释，不把全部变化归因于改进动作。对照的价值是提供同期参照，差异因素越多，结论越要保守，推广节奏也应放慢。
