资源负载图的设计顺序是先定口径、再画图：明确统计对象、时间粒度、负载单位和容量基准，再按数据采集、容量计算、负载计算、冲突标记、评审调整五步形成一张可每周更新的表。图上要能看出谁在哪个时间段超出容量、超出多少、由哪些任务造成，并配套冲突处置清单，把调整动作落到任务、负责人和完成时间。
要点总览（TL;DR）
- 先定四个口径：统计对象（人、角色或团队）、时间粒度（周或双周）、负载单位（计划工时或容量占比）、容量基准（名义工时扣除假期、例会、培训等非项目占用），口径写进定义表后再画图。
- 按数据采集、工时摊分、负载率计算与分档着色、超载标记回溯任务、评审调整回写五步制作，每步都有输入、输出和完成标志。
- 项目经理提供任务与工时估算，资源经理确认容量并提出调配，成员确认自身分配，评审主持人组织逐条处置，决策人对顺延、换人等调整拍板。
- 发现超载后拆解到具体任务与时间重叠原因，用顺延、拆分、换人或缩减范围处理，并在下一版图中验证负载率变化。
- 投入前按口径一致性、数据完整性、更新频率、冲突标记、处置闭环和可追溯性逐项检查，不通过先修正再发布。
先定四个口径：负载图能不能用取决于这一步
同一批任务数据，换一种口径就会得出不同的超载结论。设计前先把四个口径写进一张定义表，后续所有计算和评审都以这张表为准，避免会上争论“这个百分比是怎么算出来的”。
| 口径 | 可选方式 | 适用场景 | 取值来源 |
|---|---|---|---|
| 统计对象 | 个人 / 角色 / 团队 | 个人适合执行层排期；角色适合人员可互换的团队；团队适合早期粗粒度规划 | 组织架构与项目成员名单 |
| 时间粒度 | 周 / 双周 | 周粒度适合任务切换频繁的团队；双周适合迭代节奏稳定、任务周期较长的团队 | 团队迭代周期或排期习惯 |
| 负载单位 | 计划工时 / 容量占比 | 计划工时便于与任务估算直接对应；容量占比便于跨岗位横向比较 | 任务工时估算、成员可用容量 |
| 容量基准 | 可用工时 = 名义工时 − 假期 − 例会 − 培训等非项目占用 | 所有场景均需扣除，否则负载率会被系统性低估 | 考勤日历、例会安排、培训计划 |
统计对象的选择直接影响图的用途。按人统计能直接落到具体排期调整，但人员变动时维护成本高；按角色统计便于在同类人员之间调配，代价是看不到个体层面的冲突；按团队统计适合判断整体人力是否够用，难以定位到任务。多数团队可以先按人统计，再按角色或团队汇总，两个层级共用一套数据。
时间粒度按周展开的理由是：多数任务的估算精度在半天到两天之间，周粒度既能摊平估算误差，又足以暴露连续超载。任务周期普遍超过两周、切换成本高的团队可以改用双周，但要在口径表中注明，避免与周度数据混用。
容量基准是最容易被忽略的一项。名义工时按每人每周5天计算只是起点，必须扣除法定假期、团队例会、培训、值班等非项目占用，得到真正可用于项目的可用工时。扣除项要列明清单和取值来源，每季度复核一次，否则负载率的分母会随季节失真。
从数据采集到冲突标记：五步画出负载图
口径确定后，按以下五步制作第一版负载图。每一步都明确输入、动作、输出和完成标志，做完一步再进入下一步。
第一步：采集任务分配与工时估算
输入是当前周期内所有已分配任务的清单。需要采集的字段包括：任务名称、所属项目、负责人、计划开始与结束时间、工时估算、任务状态。数据来源是项目管理工具中的任务记录或排期表。输出是一张按负责人归集的任务明细表。完成标志是每条任务都有负责人和工时估算，缺失估算的任务单独列出并限期补齐。
第二步：把任务工时摊到每个周期
按任务的起止时间，把工时估算分摊到它跨越的每个周或双周。跨周期任务按工作日比例拆分，例如一项16小时、跨越两周的任务，每周摊入8小时。输出是“人 × 周期”的工时矩阵。完成标志是矩阵中每个单元格都能回溯到具体任务，没有来源不明的工时。
第三步：计算负载率并分档着色
负载率 = 该周期计划工时 ÷ 该周期可用容量。按阈值分档，例如低于70%为偏闲、70%至90%为正常、90%至100%为接近饱和、超过100%为超载，分别用不同颜色标注。阈值由团队根据任务波动情况确定并写入口径表。输出是一张带颜色的负载图。完成标志是每个单元格都有负载率和颜色，且计算过程可复算。
第四步：标记超载并回溯到任务
对超过阈值的单元格逐一标记，并列出造成超载的任务清单，注明每项任务的工时和占用时段。重点看时间重叠：多个任务在同一周集中交付，往往是超载的直接原因。输出是超载清单，每条包含人员、周期、超出工时和关联任务。完成标志是每个超载单元格都有对应的任务解释，不存在“不知道为什么超”的条目。
第五步：评审调整并回写下一版
在评审会上逐条处理超载清单，确定顺延、拆分、换人或缩减范围等调整动作，记录负责人和完成时间。调整结果回写到任务记录中，重新计算负载率，形成下一版图。输出是更新后的负载图和冲突处置记录。完成标志是每条超载都有处置结论，且下一版图中对应单元格的负载率已发生变化。
角色分工与交付物：谁维护、谁评审、谁决策
负载图做完没人用，通常是因为维护、评审和决策的责任没有落到具体角色。下表给出一种常见分工，团队可按规模调整。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 提供任务清单与工时估算，确保任务起止时间和负责人准确 | 任务明细表、工时估算 |
| 资源经理或职能负责人 | 确认成员可用容量，提出调配方案 | 容量基准表、调配建议 |
| 成员本人 | 确认自身分配是否准确，反馈遗漏或冲突 | 分配确认记录 |
| 评审主持人 | 组织评审会，逐条处理超载清单 | 会议记录、处置结论 |
| 决策人 | 对顺延、换人等影响交付的调整做最终决定 | 调整决定及生效时间 |
项目经理对任务数据的准确性负责，这是负载图可信的前提；资源经理掌握人员可用情况，负责容量口径和调配建议；成员本人确认分配，能发现系统里未登记的工作；评审主持人负责让每条超载都有结论；决策人对跨项目的优先级冲突拍板。规模较小的团队可以由一人兼任多个角色，但职责要在口径表中写明。
一个两周示例：从超载标记到调整落地
以下为演示情景，用于说明识别与调整过程，数据为假设值，不代表任何真实项目。
假设某研发小组有三名成员，按周统计，每人每周可用容量为32小时（已扣除例会和培训）。第一版负载图显示，成员A在第1周和第2周的负载率分别为118%和112%，连续两周超过100%。回溯任务发现：第1周有一项接口开发任务估算20小时，同时有一项线上问题排查任务估算18小时；第2周接口联调任务估算24小时，与测试支持任务12小时重叠。
冲突原因拆解为两点：一是两项任务交付时间重叠，二是线上问题排查的工时在排期时未计入。评审会上确定调整方案：线上问题排查改为由成员B承接，因其当周负载率为65%；接口联调任务顺延两天开始，避开测试支持的高峰；成员A第2周的计划工时降至26小时。调整结果回写到任务记录，重新计算后成员A两周负载率分别为94%和81%，成员B第1周升至92%，仍在阈值内。
下一版图中验证两点：成员A的负载率是否稳定在阈值以下，成员B承接新任务后是否出现新的超载。若成员B接近饱和，则需在再下一版中提前安排分流。
完成检查：这张负载图是否可以投入使用
投入使用前，按以下清单逐项核对，全部通过再进入例行更新。
- 口径一致性：统计对象、时间粒度、负载单位和容量基准已写入定义表，图中所有单元格按同一口径计算。
- 数据完整性：每条任务都有负责人和工时估算，缺失项已列出并有补齐期限；容量基准中的扣除项有来源。
- 更新频率：明确每周或每双周的更新时间和维护人，最近一版图的日期在约定周期内。
- 冲突标记：每个超载单元格都能回溯到具体任务和时间重叠原因，没有无法解释的条目。
- 处置闭环：每条超载都有处置结论、负责人和完成时间，下一版图中能看到负载率变化。
- 可追溯性：负载图版本与评审记录一一对应，调整决定可查到作出人和生效时间。
任何一项不通过，先修正再发布，避免把口径不一致或数据缺失的图带到评审会上消耗讨论时间。
把负载图接入日常协作：数据与评审的承载方式
负载图依赖任务分配和工时数据，这些数据如果散落在表格和聊天记录里，每周更新都会变成重复劳动。把任务、工时和容量登记在同一个协作工具中，负载视图才能随任务变化及时反映。
在ONES中，任务分配与工时字段可以作为负载图的数据源：通过工作数量和工时规模了解成员排期，支持筛选与分组，掌握成员在不同项目的投入比重；资源管理支持实时查看成员每日投入饱和明细，帮助识别规划风险；多种资源报表可实时反馈项目投入情况，并支持一键导出工时日志。这些数据对应到本文第二步的工时矩阵和第三步的负载率计算，减少手工汇总。
评审衔接上，可以把评审结论回写到对应任务的状态或备注中，使调整动作与任务记录保持关联；资源规划视图可帮助管理者按业务优先级安排团队资源，在可用资源与需求之间做平衡。下一版负载图直接从更新后的任务数据生成，形成“任务登记—负载查看—评审调整—回写任务”的循环。具体字段配置和视图形态以实际产品配置为准。
常见问题
团队规模小、人员身兼多职时，负载图还需要按角色分开统计吗？
可以先用个人口径统计，再按角色汇总，两个层级共用一套任务数据。人员身兼多职时，按角色统计容易掩盖个体层面的冲突，建议以个人负载率作为排期调整依据，角色汇总只用于判断整体人力是否够用。角色划分和兼任情况写进口径表，评审时按同一口径讨论。
任务工时估算普遍不准，负载图还有参考价值吗？
有参考价值，但要先把估算精度作为已知条件管理。可以在负载图中标注估算来源（历史均值、经验值或待确认），对缺失估算的任务单独列出并限期补齐；周粒度本身能摊平部分估算误差。评审时优先处理连续多周超载或接近饱和的条目，单周小幅波动不必逐条调整。估算偏差持续偏大的团队，可先积累几轮实际工时与估算的对比，再修正估算习惯。
成员临时承接线上问题、支援等未登记的工作，负载图怎么反映？
这类工作需要在任务记录中登记为独立任务并给出工时估算，否则负载率会被系统性低估。可以在每周更新前留出固定时间，由成员本人核对自身分配，补充遗漏任务；容量基准中也可为值班、支援类工作预留一定比例的非项目占用。评审会上把未登记工作作为数据完整性问题单独处理，而不是等到超载发生后再追溯。
负载率阈值定多少合适，需要统一标准吗？
阈值由团队根据任务波动情况确定并写入口径表，不同岗位可以不同。常见做法是低于70%为偏闲、70%至90%为正常、90%至100%为接近饱和、超过100%为超载。阈值的作用是触发讨论，不是考核指标；同一团队内保持口径一致，跨团队比较时注明各自阈值，避免把不同标准的百分比直接对比。
负载图的数据放在协作工具里，和放在表格里相比要注意什么？
放在协作工具里的关键是任务分配与工时字段成为唯一数据源，负载视图随任务变化更新，减少每周手工汇总。以ONES为例，任务分配与工时字段可作为负载图的数据源，资源管理支持查看成员每日投入饱和明细、按工作数量和工时规模了解排期，并提供资源报表与工时日志导出（具体字段配置和视图形态以实际产品配置为准）。无论用哪种载体，都要明确更新频率、维护人和评审结论的回写位置，保证下一版图能追溯到调整记录。
负载图发现超载后，调整动作怎么验证是否有效？
调整结果回写到任务记录后重新计算负载率，在下一版图中对比调整前后的数值。验证两点：原超载人员的负载率是否回到阈值以内，承接任务的人员是否出现新的超载。若承接方接近饱和，需要在再下一版中提前安排分流。每条超载的处置结论、负责人和完成时间记入冲突处置记录，与负载图版本一一对应，便于后续追溯。
