资源负载图是一张按“人员×时间周期”排布的表格，单元格填写该人在该周期内已分配的工作量，再与可用工时对比，标出超载、空闲和冲突。本文提供可直接复制的空白表格、逐字段填写口径、必填与选填规则、一份完整的双周填写示例，以及后续调整维护方法，拿到即可用于团队第一版资源盘点。
要点总览（TL;DR）
- 资源负载图按“人员×时间周期”排布，每格填已分配工时，与可用工时对比后算出负载率，据此标出超载、正常和空闲。
- 空白模板包含人员基础信息、周期子列、汇总列和冲突协调列，复制后按人数增删行、按规划跨度增删周期列即可使用。
- 姓名、周期起止、已分配工时、可用工时是必填项；状态异常时冲突说明、协调动作和协调人必须填写，冲突才能闭环。
- 示例采用双周视图，演示了单周峰值与两周汇总的差异判断，以及超载、空闲两种情形的备注与协调写法。
- 模板需按周或双周固定更新，人员变动保留历史行，排期变更当天同步，并与项目排期和工时记录保持同一口径。
可复制空白资源负载图模板
下表为空白模板，可直接复制到 Excel、在线表格或文档中。表格按“人员基础信息 + 时间周期列 + 汇总与判断列”横向展开，每个周期列内再分“已分配工时”和“可用工时”两个子列。复制后按团队人数增删行，按规划跨度增删周期列即可。
| 姓名 | 角色 | 技能标签 | 所属团队 | 第1周（月/日–月/日） | 第2周（月/日–月/日） | 周期总已分配 | 周期总可用 | 负载率 | 状态 | 冲突说明 | 协调动作 | 协调人 | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 已分配工时 | 可用工时 | 已分配工时 | 可用工时 | |||||||||||
使用说明：周期列的数量按规划跨度增减，例如做月度视图就展开4–5个周列；人员行按参与项目的人员逐行添加。若团队习惯以人天计量，把“工时”统一替换为“人天”，全表口径保持一致即可。表格下方可另加一行“团队合计”，用于观察整体负载分布。
每个字段填什么：字段说明
模板中的字段分为人员维度、时间维度、负载数值和判断结论四组。填写时先固定人员与周期，再逐格填数值，最后根据数值计算负载率并给出状态。下表给出每个字段的含义与填写口径，示例值与第四节的双周示例保持一致。
| 字段 | 含义 | 填写口径 | 示例值 |
|---|---|---|---|
| 姓名 | 承担任务的成员 | 填写真实姓名或工号，一人一行，不合并单元格 | 李敏 |
| 角色 | 该成员在当前周期的主要职责 | 填一个主角色，如后端开发、测试、产品经理；兼任时填主角色并在技能标签体现 | 后端开发 |
| 技能标签 | 可用于匹配任务的技能关键词 | 用逗号分隔，2–4个为宜，便于判断任务能否转派 | Java, 接口设计 |
| 所属团队 | 成员归属的小组或职能线 | 填团队名称，跨团队借调时填实际归属团队 | 交易平台组 |
| 周期起止 | 每个时间列覆盖的日期范围 | 写在列标题中，格式统一为“月/日–月/日” | 3/4–3/10 |
| 周期粒度 | 一个列代表多长时间 | 全表统一为周、双周或月，不与其它粒度混用 | 周 |
| 已分配工时 | 该成员在该周期内已承诺的任务工作量 | 按任务预估或排期折算，单位与全表一致；只计已排入计划的工作 | 32 |
| 可用工时 | 该成员在该周期内真正可投入工作的时间 | 扣除休假、会议、值班、培训等非项目时间后的净值 | 40 |
| 负载率 | 已分配工时占可用工时的比例 | 已分配工时 ÷ 可用工时，按周期或按汇总计算，保留整数百分比 | 80% |
| 状态 | 对该周期负载的结论 | 按第三节的判断规则填写超载、正常或空闲 | 正常 |
| 冲突说明 | 负载异常的原因或资源争用情况 | 写清涉及的项目、任务和冲突对象，一句话说明 | 与支付改造项目争用同一人 |
| 协调动作 | 针对冲突拟采取的处理方式 | 写具体动作，如顺延任务、转派、加班或缩减范围 | 将报表任务顺延一周 |
| 协调人 | 负责跟进该冲突处理的人 | 填项目经理或资源负责人姓名 | 王强 |
必填与选填：哪些字段不能空
必填字段决定这张表能否支撑判断。姓名、周期起止、已分配工时、可用工时四项缺失时，负载率无法计算，整行数据失去意义，因此必须填写。角色、所属团队影响资源归属判断，也建议作为必填项固定下来。
| 字段 | 必填/选填 | 留空的影响与处理 |
|---|---|---|
| 姓名 | 必填 | 无法定位责任人，整行无效 |
| 角色 | 必填 | 难以判断任务是否可转派，建议固定填写 |
| 所属团队 | 必填 | 跨团队协调时无法确认归属 |
| 周期起止 | 必填 | 数值失去时间参照，无法与排期对齐 |
| 已分配工时 | 必填 | 无法计算负载率；确实无任务时填0，不空格 |
| 可用工时 | 必填 | 无法计算负载率；未填时按标准工时扣除已知非项目时间估算，并在备注注明估算依据 |
| 技能标签 | 选填 | 不影响负载计算，但影响冲突时的转派判断，建议填写 |
| 负载率 | 由公式得出 | 不手工填写，用已分配工时除以可用工时自动计算 |
| 状态 | 由规则得出 | 按负载率区间判断，避免主观填写 |
| 冲突说明 | 状态异常时必填 | 超载或空闲行必须写明原因，正常行可留空 |
| 协调动作、协调人 | 状态异常时必填 | 有冲突就必须有处理动作和跟进人，否则冲突无人闭环 |
状态判断建议采用统一区间：负载率超过100%记为超载，70%–100%记为正常，低于70%记为空闲。区间可按团队实际调整，例如把正常下限设为80%，但同一张表内必须使用同一套阈值，并在表头或备注中写明，避免不同人按不同标准解读。可用工时未填时，默认按团队标准周工时扣除已知休假和固定会议估算，估算值需标注，后续拿到准确数据再替换。
填写示例：一个双周资源负载图
以下示例为演示情景：某交易平台组共4人，规划周期为两周（3月4日至3月17日），按周展开两个周期列，负载率阈值采用超载100%以上、正常70%–100%、空闲70%以下。示例数据用于说明填写方法，不代表真实项目数据。
| 姓名 | 角色 | 技能标签 | 所属团队 | 第1周已分配 | 第1周可用 | 第2周已分配 | 第2周可用 | 总已分配 | 总可用 | 负载率 | 状态 | 冲突说明 | 协调动作 | 协调人 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 李敏 | 后端开发 | Java, 接口设计 | 交易平台组 | 44 | 40 | 36 | 40 | 80 | 80 | 100% | 正常 | 第1周承接支付改造联调，工时偏高 | 联调任务第2周减半 | 王强 |
| 赵磊 | 后端开发 | Java, 报表 | 交易平台组 | 48 | 40 | 48 | 40 | 96 | 80 | 120% | 超载 | 同时承担报表开发与支付改造两个项目 | 报表任务顺延一周，转派部分接口给李敏 | 王强 |
| 陈晓 | 测试 | 接口测试, 自动化 | 交易平台组 | 20 | 40 | 24 | 40 | 44 | 80 | 55% | 空闲 | 测试用例依赖开发提测，前期可投入时间不足 | 安排其补充自动化脚本，并支援支付改造回归 | 王强 |
| 周婷 | 产品经理 | 需求分析, 原型 | 交易平台组 | 32 | 40 | 36 | 40 | 68 | 80 | 85% | 正常 |
识别过程：赵磊两周合计已分配96小时、可用80小时，负载率120%，超过100%阈值，判为超载，冲突说明写明两个项目争用同一人，协调动作给出顺延与转派两条具体措施。陈晓负载率55%，低于70%阈值，判为空闲，原因是用例依赖提测，协调动作把空余时间导向自动化脚本和回归支援。李敏第1周单周已分配44小时、可用40小时，单周看略超，但两周合计负载率100%，整体判为正常，冲突说明中记录单周偏高的事实并给出第2周减半的安排，避免只看汇总掩盖单周峰值。
冲突备注的写法建议包含三要素：涉及的项目或任务、冲突的具体表现、影响范围。协调动作则要写成可执行、可验收的动作，例如“顺延一周”“转派某模块”“缩减某需求范围”，并指定协调人，便于下次更新时核对是否落地。
模板的调整与维护方法
模板首次填完后，需要随团队和项目节奏持续维护，否则负载图很快与实际脱节。以下清单覆盖周期粒度、人员变化、数据来源、版本留存和与排期的衔接。
- 周期粒度调整：项目节奏快、任务切换频繁时用周视图；迭代以双周为单位的团队用双周视图；做季度资源规划时改用月视图。切换粒度时保持单位一致，历史数据不混填在同一张表里。
- 人员增减与角色变化：新人加入时新增行并补齐基础信息；成员离场或转岗时保留历史行并标注离场日期，不直接删除，避免历史对比失真；角色变化时更新角色列，技能标签同步调整。
- 数据来源与更新频率：已分配工时来自项目排期和任务预估，可用工时来自考勤、休假和固定会议安排。建议每周固定时间更新一次，双周视图在每周中途做一次轻量核对，重点检查超载和空闲行。
- 版本管理与历史留存：每次更新另存版本，文件名包含周期范围，例如“资源负载图_3月第1-2周”；保留最近若干版本用于回溯，重要节点的版本单独归档。
- 与项目排期、工时记录的衔接：排期变更后当天同步负载图对应单元格；实际工时与预估偏差较大时，在冲突说明中记录偏差原因，作为下次估算的参考。
当团队使用 ONES 承载项目任务与工时数据时，资源负载图可以从工作项和工时记录中取数：任务排期提供已分配工时的来源，成员工时填报反映实际投入，资源负责人据此更新负载图并跟踪冲突协调动作的落地状态。这样负载图与项目执行数据保持同一口径，减少手工重复录入。是否引入工具承载取决于团队已有的任务管理方式，规模较小、项目数量有限的团队用表格维护同样可行。
常见问题
团队刚开始用资源负载图，周期粒度选周还是双周？
看任务切换频率和迭代节奏。任务切换频繁、排期常在一周内调整的团队，用周视图能更早发现单周峰值；以双周为迭代单位的团队，用双周视图与迭代对齐，更新负担也更小。做季度层面的人员规划时可以改用月视图。无论选哪种，同一张表内保持一种粒度，切换时另建新表，避免历史数据混填。
可用工时算不准，负载率还有参考价值吗？
有，但需要标注估算依据。可用工时未填时，可以按团队标准周工时扣除已知休假、固定会议和值班时间估算，并在备注中写明估算口径。负载率的用途是发现相对偏高或偏低的格子，估算值足以支撑这一判断。后续拿到考勤或工时填报的准确数据，替换数值并复核状态即可，不必等数据齐全才开始使用模板。
一个人同时参与多个项目，冲突说明怎么写才便于后续协调？
建议写清三件事：涉及哪些项目或任务、冲突的具体表现、影响范围。例如“同时承担报表开发与支付改造两个项目，第2周两边的联调时间重叠”。协调动作要写成可执行、可验收的动作，如顺延某任务一周、转派某模块、缩减某需求范围，并指定协调人。下次更新时对照协调动作核对是否落地，冲突才有闭环。
单周超载但两周汇总正常，应该判超载还是正常？
汇总状态按汇总负载率判断，同时要在冲突说明中记录单周峰值的事实和应对安排。示例中李敏第1周已分配44小时、可用40小时，两周合计负载率100%，整体判为正常，但备注写明了第1周承接联调导致工时偏高，并给出第2周任务减半的安排。只看汇总容易掩盖短期峰值，建议在更新时额外扫一遍各周期列，对明显偏高的单周格子单独标注。
成员离场或转岗后，原来的行要删除吗？
保留历史行并标注离场或转岗日期，不直接删除。删除会让历史周期的负载对比失真，也无法回溯当时的资源分布。新人加入时新增行并补齐基础信息；角色变化时更新角色列，技能标签同步调整。需要看当前团队负载时，用筛选或另建当期视图即可，历史表继续留存。
