制定研发资源分配与排期，核心做法是先按角色和技能盘点可用容量，再把已确认的任务按优先级与依赖排入时间窗，形成“人—任务—时间”可核对的排期表，并配套每周滚动复核与变更记录。本文给出一套可直接落地的四步流程和三张表，聚焦人员投入与排期表产出，帮助研发负责人或项目经理从零建立机制。
要点总览（TL;DR）
- 资源分配与排期要交付三张表：角色容量表、任务排期表、变更记录表，分别回答人有多少可用投入、任务由谁在何时交付、调整如何追溯。
- 容量盘点按角色与技能分组，从名义工作日中扣除会议、支持、休假，折算净可用工时，避免按人头平均造成隐性超载。
- 任务按必须做、应该做、可延后三级排序，先排必须做任务，再填剩余容量，依赖关系只作为排期约束使用。
- 排期落地靠固定分工与节奏：研发负责人确认优先级，技术负责人确认工作量与依赖，项目经理编制排期并组织周复核。
- 每周滚动复核实际投入与容量偏差，变更按需求变化、容量变化、依赖延期三类触发并登记回写，完成检查逐项核对。
先定口径：资源分配与排期要产出哪三张表
资源分配与排期最终要交付三张可核对的表：角色容量表、任务排期表、变更记录表。三张表分别回答“人有多少可用投入”“任务排在什么时间、由谁交付”“排期调整后如何追溯”。把它们分开维护，可以避免把容量、任务和变更混在一张表里，导致超载看不见、调整说不清。
| 表名 | 输入来源 | 负责人 | 更新频率 | 核心字段 |
|---|---|---|---|---|
| 角色容量表 | 人员名单、角色与技能、休假与会议安排、支持类工作占比 | 研发负责人或项目经理 | 每迭代或每月更新一次，周复核时微调 | 人员、角色、技能、可用天数、投入比例、时间窗 |
| 任务排期表 | 已确认的需求与任务清单、优先级、依赖关系、容量表 | 项目经理 | 每周滚动更新 | 任务、优先级、负责人、起止时间、交付物、前置依赖 |
| 变更记录表 | 排期调整申请、超载预警、需求变更 | 项目经理记录，研发负责人确认 | 发生即记录 | 变更日期、变更对象、触发原因、影响范围、回写结果 |
三张表的边界需要提前说清：容量表只解决“人有多少可用投入”，不判断任务该不该做；排期表解决“任务如何匹配容量”，依赖关系只作为排期约束使用；变更记录表解决“调整如何留痕”，负载冲突的具体协调方式不在本文展开，另行处理。三张表串起来，才构成完整的分配与排期依据。
第一步：按角色与技能盘点可用容量
容量盘点的关键动作是把人员投入折算成可分配工时，并按角色与技能分组，避免按人头平均分配。同样五个人，前端、后端、测试的可用投入差异很大，按人头平均会让某些角色隐性超载。
具体做法分三步。第一，列出参与本时间窗的全部人员，标注角色与主要技能，例如后端—订单服务、前端—管理后台、测试—接口自动化。第二，从名义工作日中扣除会议、日常支持、休假、培训等非项目投入，得到净可用天数。第三，按投入比例折算为可分配工时，例如某后端工程师两周名义10个工作日，扣除会议与支持后净可用7天，投入比例80%，可分配约5.6人天。
| 人员 | 角色 | 技能 | 可用天数 | 投入比例 | 时间窗 |
|---|---|---|---|---|---|
| 张工 | 后端 | 订单服务、支付接口 | 7 | 80% | 第1—2周 |
| 李工 | 前端 | 管理后台、组件库 | 8 | 90% | 第1—2周 |
| 王工 | 测试 | 接口自动化、回归测试 | 6 | 70% | 第1—2周 |
填写时注意两点：可用天数要写净可用，不写名义工作日；投入比例要说明剩余部分去了哪里，例如支持线上问题或参与跨团队评审。容量表完成后由研发负责人确认，作为排期的唯一投入依据。
第二步：把任务按优先级和依赖排入时间窗
任务排入时间窗的动作，是把已确认的任务按优先级排序，再逐条匹配到具体人员和周次。优先级建议分三级：必须做、应该做、可延后。必须做指本时间窗内不完成会影响交付或线上稳定；应该做指有价值但可小幅调整时间；可延后指资源紧张时优先让出容量。
填充规则如下：
- 先排必须做任务，按依赖顺序确定起止周次，前置任务未完成的后续任务不提前占用容量。
- 再排应该做任务，填入剩余容量，标注负责人、起止时间、交付物。
- 可延后任务只登记不占容量，待周复核时根据释放的容量决定是否排入。
- 每条任务必须有一个负责人和一个可验收的交付物，例如接口文档、测试报告、可演示版本。
- 依赖关系写在“前置依赖”列，作为排期约束；依赖本身的管理方法不在本文展开。
| 任务 | 优先级 | 负责人 | 起止 | 交付物 | 前置依赖 |
|---|---|---|---|---|---|
| 订单查询接口改造 | 必须做 | 张工 | 第1周 | 接口文档与联调通过 | 无 |
| 订单列表页改版 | 必须做 | 李工 | 第1—2周 | 可演示页面 | 订单查询接口改造 |
| 支付回归测试 | 应该做 | 王工 | 第2周 | 回归测试报告 | 订单列表页改版 |
| 报表导出优化 | 可延后 | 待定 | 未排 | 方案说明 | 无 |
排完后逐人核对：每个人在各周的分配工时不超过容量表中的可分配工时。超出即标记超载，回到优先级判断，把可延后任务移出或调整起止时间，而不是直接压缩工期。
第三步：角色分工与交付物责任
三张表能否持续维护，取决于每个角色是否清楚自己的输入、动作和交付物。常见分工如下：
| 角色 | 输入 | 动作 | 交付物 | 交接时点 |
|---|---|---|---|---|
| 研发负责人 | 业务目标、团队人员与技能情况 | 确认容量口径与优先级排序 | 确认后的容量表与优先级清单 | 排期评审前 |
| 项目经理 | 容量表、任务清单、依赖关系 | 编制排期表、记录变更、组织周复核 | 任务排期表、变更记录表 | 每周复核后 |
| 技术负责人 | 技术方案、任务拆分结果 | 评估任务工作量与依赖合理性 | 任务工作量与依赖确认意见 | 排期编制阶段 |
| 团队成员 | 个人任务与可用时间 | 确认分配、反馈实际投入与风险 | 任务确认与实际工时反馈 | 周复核时 |
评审与确认节奏建议固定：每个迭代开始前召开一次排期评审，研发负责人确认优先级，技术负责人确认工作量和依赖，项目经理输出排期表；迭代内每周一次短会复核容量与进度，成员反馈实际投入偏差。确认动作要留痕，避免口头调整后无人知晓。
示例：一个迭代周期的资源分配与排期落地
以下为演示情景，用于说明三张表如何串联。某研发小组共5人，本迭代两周，容量盘点结果为：后端2人合计可分配11人天，前端2人合计可分配13人天，测试1人可分配6人天。扣除会议、支持和一人三天休假后，净可用容量比名义容量少约两成。
任务排入后，排期表片段如下：
| 任务 | 优先级 | 负责人 | 起止 | 交付物 | 前置依赖 |
|---|---|---|---|---|---|
| 订单查询接口改造 | 必须做 | 张工 | 第1周 | 接口文档与联调通过 | 无 |
| 订单列表页改版 | 必须做 | 李工 | 第1—2周 | 可演示页面 | 订单查询接口改造 |
| 支付回归测试 | 应该做 | 王工 | 第2周 | 回归测试报告 | 订单列表页改版 |
第1周周复核时发现，张工因线上问题支持实际投入比计划少1.5人天，订单查询接口改造无法在第1周完成。项目经理在变更记录表中登记：变更日期第1周周五，变更对象为订单查询接口改造，触发原因为线上支持占用，影响范围为订单列表页改版顺延两天，回写结果为两项任务起止时间调整、支付回归测试保持第2周后半段。调整后重新核对容量，张工当周分配未超载，李工第2周容量仍有余量，可延后任务继续不排入。
这个示例说明：容量表提供投入上限，排期表承载任务与时间，变更记录表保证每次调整都有原因、影响和回写结果，三者缺一不可。
第四步：滚动复核、变更规则与完成检查
排期制定后需要每周滚动复核，检查项包括：本周实际投入与容量表偏差是否超过约定阈值；必须做任务是否按计划推进；是否有任务因依赖未满足而空转；超载标记是否已处理；变更记录是否已回写排期表。复核由项目经理组织，研发负责人确认优先级调整，成员反馈实际投入。
变更触发条件建议明确为三类：需求新增或优先级变化、人员可用容量变化、前置依赖延期。触发后由项目经理在变更记录表中登记原因与影响范围，研发负责人确认是否调整优先级，确认结果回写排期表并同步相关成员。未经记录的调整不进入排期表，保证表内信息可追溯。
完成检查清单可按以下条目逐项核对：
- 容量表已扣除会议、支持、休假，净可用工时与投入比例填写完整。
- 每条已排任务都有负责人、起止时间和可验收交付物。
- 依赖关系已标注，前置任务未完成的后续任务未提前占用容量。
- 逐人核对后无未标记的超载，超载项已通过调整优先级或时间处理。
- 变更记录表包含触发原因、影响范围和回写结果，且与排期表一致。
- 本周复核已完成，下周容量与任务安排已更新。
当团队需要在多个项目间同时掌握成员投入时，可以把容量表与排期表放到同一套工作项和工时记录中维护。ONES Resource 支持通过工作数量和工时规模了解成员排期，并支持筛选与分组查看成员在不同项目中的投入比重；其甘特视图可用于项目资源规划与进度跟踪，拖拉拽完成排期调整，成员每日投入饱和明细可辅助识别超载风险。将工作项负责人、起止时间和工时登记对应到本文的排期表字段，周复核时直接核对实际投入与计划偏差，变更记录也可作为工作项备注留存，减少表格来回同步的成本。
常见问题
容量表按人头平均分配有什么问题，什么情况下可以简化？
按人头平均分配会掩盖角色之间的投入差异。同样五个人，前端、后端、测试的可用投入并不相同，平均分配容易让某些角色隐性超载，而另一些角色容量闲置。
当团队规模很小、成员技能高度重叠、任务可以互相接手时，可以适当简化到按人盘点；只要任务对角色有明确要求，就应按角色与技能分组盘点，再折算净可用工时。
排期表里任务超出容量时，应该先压缩工期还是先调整优先级？
建议先回到优先级判断。把可延后任务移出当前时间窗，或调整应该做任务的起止时间，让分配工时回到容量上限以内。直接压缩工期会把容量问题转成进度风险，后续复核时往往还要再调整一次。
如果必须做任务本身就超出容量，说明容量与目标不匹配，需要在排期评审阶段由研发负责人确认取舍，而不是由项目经理在表内消化。
每周复核时，实际投入与计划偏差多大需要触发变更记录？
偏差阈值由团队自行约定，常见做法是偏差影响到任务能否按原起止时间交付时就登记变更，而不只看工时数字。例如某成员因线上支持少投入1.5人天，导致后续任务顺延，就应记录原因、影响范围和回写结果。
偏差未影响交付时间时，可在复核会上口头同步并更新实际投入，不必每次登记，保持记录表聚焦真正改变排期的调整。
多个项目同时占用同一批成员时，容量表怎么维护？
容量表仍以人员为单位维护，在投入比例中拆分各项目占比，例如某后端工程师本时间窗可分配5.6人天，其中项目A占3人天、项目B占2.6人天。排期表按项目分别编制，但逐人核对时要跨项目合并计算，确保合计不超过容量上限。
当团队需要在多个项目间同时掌握成员投入时，可以把容量表与排期表放到同一套工作项和工时记录中维护。ONES Resource 支持筛选与分组查看成员在不同项目中的投入比重，并可通过工作数量和工时规模了解成员排期，便于跨项目核对合计投入。
变更记录表和排期表如何保持一致，避免两套信息对不上？
把变更记录表定位为调整的依据，排期表定位为调整后的结果。每次变更先登记触发原因、影响范围和拟调整内容，经研发负责人确认后再回写排期表，回写结果同步填入变更记录表。
周复核时增加一项核对：变更记录表中已确认的调整是否都体现在排期表里。未经记录的调整不进入排期表，这条规则能减少口头调整造成的两表不一致。
