资源预订规则要解决的问题，是把“谁在什么时间以多大比例投入哪个项目”变成一条可提交、可审批、可查询的记录，让项目排期和人员投入有共同依据。制定时依次确定预订对象与粒度、必填字段与填写口径、提交与审批流程、角色分工，再用一个试运行周期验证规则能否执行。预订台账和审批流转可以放在项目管理工具中承载，下文按落地顺序展开。
要点总览（TL;DR）
- 资源预订规则先划定管理范围：预订到具体人员、角色池还是团队，时间按周、按迭代还是按项目阶段切分，粒度要与团队规模和项目节奏匹配。
- 预订单的必填字段包括项目、角色、人员、起止时间、投入比例、优先级和申请人，投入比例统一用百分比表达，跨项目合计不超过100%。
- 提交时限对齐计划节奏，审批链按“谁掌握资源谁确认”分工，变更与释放走单独路径，超订在预订环节只做识别和升级交接。
- 规则发布前试运行一个完整迭代或2至4周，观察预订覆盖率、变更次数和审批时长，再按检查清单逐项核对后定稿。
- 预订台账落到具体角色维护，定期与工时记录核对，并按季度回顾字段、时限和审批链是否仍匹配团队节奏。
先定预订对象与粒度：规则要管到什么程度
资源预订规则的第一步是划定管理范围：预订的是具体人员、角色池还是整个团队，时间按周、按迭代还是按项目阶段切分。范围定得过大，规则会变成粗线条的部门承诺，无法指导排期；定得过细，填写成本高，团队很快会绕过规则。判断依据是团队规模、项目并行数量和计划节奏。
| 预订对象 | 适用条件 | 优点 | 需要注意 |
|---|---|---|---|
| 具体人员 | 团队规模较小、人员技能可替代性低、项目对特定人员依赖强 | 投入记录精确，可直接对应到个人排期 | 人员请假或调岗时需及时变更预订 |
| 角色池（如后端、前端、测试） | 同一角色有多名成员可互相调配，项目按角色提出需求 | 填写负担小，便于资源负责人在池内分配 | 需在预订生效前落实到具体人员 |
| 团队 | 以团队为单位整体投入项目，团队内部不再细分 | 规则简单，适合长期稳定的团队配置 | 难以反映团队内部成员的投入差异 |
时间粒度同样需要取舍。按周预订适合节奏稳定、以周为计划单位的团队；按迭代预订适合采用固定迭代周期的研发团队，预订单与迭代规划会同步产生；按项目阶段预订适合周期长、阶段边界清晰的项目，但阶段内的人员变化需要靠变更单补充。团队规模在十人左右、项目数量不多时，按人按周预订通常足够；多项目并行、共享人员频繁的团队，按角色池加迭代粒度更容易维护。
投入比例建议统一用百分比表达，例如某成员在某项目投入 50%。百分比便于跨项目相加判断是否超过 100%，也便于与工时记录对照。若团队习惯用人天，需要在规则中写明换算口径，例如按每周 5 个工作日计，50% 对应每周 2.5 人天，且同一张预订单只使用一种口径。
预订单必填字段与填写口径
字段设计的目的是让预订单脱离填写人也能被读懂和核对。以下字段表可直接作为预订单模板，其中“填写口径”一列是规则能否执行的关键，需要在发布前与提交人确认一致。
| 字段 | 填写口径 | 必填/选填 | 示例 |
|---|---|---|---|
| 项目 | 填写项目全称或系统内项目编号，一个项目一张单 | 必填 | 订单中心重构 |
| 角色 | 按团队约定的角色名称填写，与角色池口径一致 | 必填 | 后端开发 |
| 人员 | 预订到人时填写姓名；预订到角色池时填写池名称，生效前补充具体人员 | 必填 | 张明 / 后端池 |
| 起止时间 | 填写预订生效与结束日期，与所选时间粒度对齐 | 必填 | 3 月 4 日至 3 月 15 日 |
| 投入比例 | 用百分比表示该时间段内的平均投入，跨项目合计不超过 100% | 必填 | 50% |
| 优先级 | 按项目优先级填写高、中、低，冲突时作为排序依据 | 必填 | 高 |
| 申请人 | 填写提出预订的项目侧人员，负责后续变更沟通 | 必填 | 李华（项目经理） |
| 备注 | 说明特殊安排，如仅参与某阶段、需特定技能 | 选填 | 仅参与联调阶段 |
投入比例与工时口径的换算要在规则中固定下来，避免同一成员在不同预订单上出现百分比和人天混用。常见做法是以百分比为唯一录入口径，工时记录作为事后核对依据；若团队以人天做计划，则在预订单备注中注明换算结果，由审批人核对一致性。
优先级字段的作用是冲突时的排序依据，而不是装饰。规则应写明：同一人员在重叠时间段被多个项目预订且合计超过 100% 时，按项目优先级排序，优先级相同则按提交时间先后，仍无法判断时提交资源负责人裁定。这样冲突在预订环节就有明确的处理入口。
提交时限、审批链与变更释放规则
流程节点决定预订单从提交到生效需要经过谁、在什么时间之前完成。时限设置应与团队的计划节奏对齐：按周预订的团队可规定每周固定日期前提交下周预订；按迭代预订的团队要求在迭代规划会前完成提交，确保规划会上讨论的是已提交的预订而非口头承诺。
| 节点 | 责任人 | 时限 | 输出 |
|---|---|---|---|
| 提交预订单 | 申请人（项目侧） | 每周固定截止日或迭代规划会前 | 填写完整的预订单 |
| 人员可用性确认 | 直属负责人 | 提交后 1 个工作日内 | 确认或提出调整意见 |
| 投入平衡确认 | 资源负责人 | 提交后 2 个工作日内 | 批准、调整比例或退回 |
| 优先级与比例确认 | 项目负责人 | 与投入平衡确认同步 | 确认项目侧投入安排 |
| 台账登记生效 | 台账维护人 | 审批完成后当日 | 生效的预订记录 |
审批链遵循“谁掌握资源谁确认”的原则：直属负责人确认人员在该时间段是否可用，资源负责人确认跨项目投入是否平衡，项目负责人确认本项目优先级与投入比例是否匹配计划。三个确认可以并行，避免串行等待拉长审批时长。
变更与释放需要单独规定路径。取消预订由申请人发起并说明原因，经原审批人确认后从台账中关闭；缩减投入比例视为变更，需重新确认合计投入是否仍不超过 100%；延期则修改起止时间并重新走确认。规则中应明确变更的提交时限，例如人员变动发生后 1 个工作日内提交变更单，避免台账与实际投入脱节。
当预订环节识别出同一人员合计投入超过 100% 时，规则只负责识别和升级：由资源负责人接手，按优先级排序后与相关项目负责人交接调整方案。具体的负载冲突处理办法属于相邻主题，本规则不展开，但需要写明升级的触发条件和接收人。
角色分工与各环节交付物
规则能否持续运行，取决于每个角色是否清楚自己在哪个环节做什么、交出什么。下表把职责落到具体动作和产物上，可直接作为团队内的规则附件。
| 角色 | 提交环节 | 审批环节 | 变更环节 | 复盘环节 |
|---|---|---|---|---|
| 申请人（项目侧） | 按模板填写预订单并按时提交 | 回应审批人提出的调整意见 | 发起取消、缩减或延期申请 | 核对本项目预订与实际投入差异 |
| 直属负责人 | — | 确认人员可用性，提出替代人员建议 | 确认人员变动对预订的影响 | 反馈人员实际投入情况 |
| 资源负责人 | — | 确认跨项目投入平衡，裁定优先级冲突 | 审批影响投入平衡的变更 | 汇总预订覆盖率与变更次数 |
| 项目负责人 | — | 确认本项目优先级与投入比例 | 确认变更后项目计划是否需调整 | 评估预订对项目进度的影响 |
| 台账维护人 | — | 登记生效预订 | 更新台账状态 | 定期与工时记录核对，输出差异清单 |
预订台账的维护责任应落到具体角色，通常由资源负责人或项目管理办公室承担，负责登记生效记录、更新变更状态、定期与工时记录核对。规则解释与例外审批的归属也要写明：日常口径解释由资源负责人负责，超出规则范围的例外（如临时紧急投入）由资源负责人会同项目负责人共同审批，并记录例外原因，作为后续修订规则的输入。
当预订记录需要被持续查询和核对时，可以借助项目管理工具承载台账与流转。ONES 资源管理支持通过工作数量和工时规模了解成员排期，并支持筛选与分组查看成员在不同项目的投入比重；资源报表可实时反馈项目投入情况，工时登记日志支持查询和导出。这些能力适合承接预订生效后的投入查看与核对环节，预订单的提交与审批方式则需结合团队实际配置确认。
示例：一个迭代周期的资源预订走一遍
以下为演示情景，用于说明规则如何从提交走到生效。背景：某研发团队采用两周迭代，开发人员张明同时支持订单中心重构和支付网关升级两个项目，团队按迭代粒度、预订到人的方式管理资源。
迭代规划会前三天，订单中心重构的项目经理李华提交预订单：项目为订单中心重构，角色为后端开发，人员张明，起止时间为 3 月 4 日至 3 月 15 日，投入比例 60%，优先级高，申请人为李华，备注写明需参与接口联调。同日，支付网关升级的项目经理王强提交预订单：人员同为张明，同一时间段，投入比例 50%，优先级中。
两张预订单进入审批。直属负责人确认张明在该时间段无请假安排，人员可用；资源负责人在核对时发现合计投入为 110%，超过 100%，触发升级。资源负责人按优先级排序，与王强沟通后将支付网关升级的预订比例调整为 40%，王强确认后重新提交变更。项目负责人分别确认两个项目的投入比例与计划匹配，审批完成。
台账维护人当日登记两条生效记录：张明在 3 月 4 日至 3 月 15 日投入订单中心重构 60%、支付网关升级 40%，合计 100%。迭代进行到第二周，支付网关升级因联调提前结束，王强提交缩减变更，将剩余时间的投入比例调整为 20%，经资源负责人确认后台账同步更新。迭代结束后复盘时，台账维护人将预订记录与工时登记对照，发现订单中心重构实际投入略高于预订，作为下个迭代调整比例的依据。
试运行与完成检查
规则发布前建议先试运行一个完整迭代或 2 至 4 周，用实际填写和审批情况检验规则是否可执行。试运行期间重点观察三项指标：预订覆盖率，即实际投入项目的人员中提交了预订单的比例；变更次数，反映初始预订的准确程度；审批时长，反映流程节点是否过重。三项指标不需要设定统一阈值，由团队根据试运行结果判断规则是否需要简化或补充。
试运行结束后，按以下清单逐项核对，全部满足即可定稿：
- 预订对象与时间粒度已明确，团队成员能说清自己按什么粒度提交。
- 字段表中每个必填字段都有填写口径和示例，试运行中未出现同一字段两种填法。
- 提交时限与团队计划节奏对齐，试运行期间无因时限不合理导致的集中补交。
- 审批链各节点责任人和时限明确，审批未出现无人认领的环节。
- 变更与释放路径已被实际使用至少一次，台账状态与变更记录一致。
- 超订识别与升级交接的触发条件和接收人已写明。
- 台账维护人已确定，且完成过一次与工时记录的核对。
试运行中常见的填写偏差包括：投入比例按人天填写导致跨单无法相加、起止时间与迭代周期不对齐、预订到角色池后长期不落实到人、变更只在口头沟通而未更新台账。对应修正方式是在字段口径中补充示例、在提交时限中明确对齐规则、在审批环节增加落实到人的确认动作、把变更单作为台账更新的唯一入口。
规则定稿后保留固定的维护节奏，例如每季度回顾一次字段、时限和审批链是否仍匹配团队的项目节奏和人员规模；每次例外审批记录积累到一定数量时，评估是否将例外情形纳入正式规则。预订台账持续维护并与工时记录定期核对，规则才能长期支撑资源分配与排期决策。
常见问题
团队规模很小，还需要按角色池预订吗？
团队规模小、人员技能可替代性低时，按具体人员预订通常更直接，投入记录能对应到个人排期。角色池的价值在于同一角色有多名成员可互相调配，如果团队里每个角色只有一两个人，池内调配空间有限，按角色池预订反而多一道落实到人的环节。可以先按人预订，等团队扩编或出现多项目共享同一角色时，再评估是否改为角色池粒度。
预订比例和实际工时对不上，规则该怎么调整？
先区分是填写口径问题还是计划偏差。如果同一成员在不同预订单上出现百分比和人天混用，属于口径问题，应在字段规则中固定单一录入口径并补充换算示例。如果口径一致但实际投入持续偏离预订，说明预订比例本身估得不准，可在复盘时把差异作为下个周期调整比例的依据，而不必立即修改规则。连续几个周期偏差集中在某类项目上时，再考虑调整该类项目的预订习惯或审批要求。
临时紧急投入来不及走预订流程怎么办？
规则中应预留例外路径：由资源负责人会同项目负责人共同审批临时投入，记录例外原因和实际投入时间，事后补登台账。例外记录积累到一定数量时，评估是否把这类情形纳入正式规则，例如为紧急需求设置固定的预留比例。例外审批的关键是留下记录，否则台账会与实际投入脱节，后续核对和复盘都失去依据。
预订到角色池后长期不落实到人，怎么处理？
这是试运行中的常见偏差。可以在审批环节增加一个确认动作：角色池预订在生效前由直属负责人补充具体人员，未补充的预订单不进入台账。另一种做法是在提交时限上区分，角色池预订允许提前提交，但落实到人的截止时间设在迭代规划会前。两种方式都要求台账维护人核对角色池预订的落实状态，避免池内预订长期悬空。
预订台账用什么承载比较合适？
台账需要满足可查询、可更新状态、能与工时记录对照三个条件。表格工具可以起步，但变更状态和跨项目投入合计需要人工维护，人员规模扩大后容易出错。项目管理工具可以承载预订记录与投入查看，例如 ONES 资源管理支持筛选与分组查看成员在不同项目的投入比重，资源报表可实时反馈项目投入情况，工时登记日志支持查询和导出。预订单的提交与审批方式需结合团队实际配置确认。
