资源预订规则要解决的是“谁在什么时间、以什么颗粒度、按什么优先级占用某个人的工时”。一套可执行的规则通常包含四部分：预订字段与颗粒度、提交审批变更释放四个动作、各角色职责与交付物、上线后的执行检查。本文按这个顺序给出可直接套用的字段表、流程步骤和检查清单，并说明预订规则与任务排期、负载冲突处理之间的分工。
要点总览（TL;DR）
- 资源预订规则的对象是人员投入的占用与承诺，需要回答预订什么、谁来订、怎么批、怎么变四个问题，任务排期与负载冲突裁决不在规则范围内。
- 先设计一张资源预订单，字段覆盖项目、工作项、角色、人员、投入比例或工时、起止时间、优先级、申请人、审批人与状态，再围绕这张表设计流程。
- 颗粒度按团队规模与变更频率选择：人员少、借调频繁按人预订，同类角色可互换按角色预订；时间维度按周或按迭代，投入比例与工时只选一种主口径。
- 提交、审批、变更、释放四个动作各自明确输入、做法、输出与完成标志，审批建议两个工作日内答复，项目结束后一周内释放。
- 规则上线后用预订台账和执行检查验证：字段完整率、审批时限达成、变更是否重提、释放是否及时，例外集中或冲突频发时触发复盘。
资源预订规则要管住哪几件事
预订规则的对象是人员投入的占用与承诺。它记录的是“某个人在未来一段时间内，被某个项目以多大比例占用”，让项目负责人在启动工作前先取得资源负责人的确认，让被预订人员提前知道自己的时间被谁占用。规则管的是承诺的建立、变更和解除，不管任务内部怎么拆解、先后顺序怎么排。
一份完整的预订规则需要回答四个问题：
- 预订什么：预订的对象是人还是角色，颗粒度是周还是迭代，投入用什么口径表达。
- 谁来订：由项目负责人发起，还是由资源负责人统一录入；申请人需要提供哪些信息。
- 怎么批：谁有权确认，依据什么判断，多长时间内必须给出答复。
- 怎么变：投入比例或时间调整时走什么动作，项目结束或人员离开时如何释放。
需要划清的边界有两处。任务排期解决的是工作项之间的先后与依赖，属于项目内部的执行安排；负载冲突处理解决的是多项目争抢同一人员时如何裁决，属于优先级决策。预订规则负责把占用关系记录下来并保持更新，为这两件事提供事实基础。规则本身不裁决冲突，冲突仍由资源负责人或项目集负责人按业务优先级决定。
预订字段与颗粒度：先定表格再定流程
流程要跑起来，先要有统一的载体。建议先设计一张资源预订单，把每次占用表达为一条记录，再围绕这张表设计审批动作。字段不宜多，但关键项必须必填，否则后续的冲突检查和统计都无从做起。
| 字段 | 说明 | 必填/选填 |
|---|---|---|
| 项目 | 占用工时的归属项目，用于按项目汇总投入 | 必填 |
| 任务或工作项 | 该次投入对应的主要工作内容，颗粒度到可识别的工作项即可 | 必填 |
| 角色 | 被预订人员在该项目中承担的角色，如后端开发、测试、设计 | 必填 |
| 人员 | 具体被占用的人员姓名；按角色预订时可先填角色，确认后补人员 | 必填 |
| 投入比例或工时 | 占用程度的表达，全篇统一用一种口径 | 必填 |
| 起止时间 | 占用的开始与结束日期，与颗粒度对齐 | 必填 |
| 优先级 | 该占用相对其他占用的重要程度，用于冲突时的参考 | 必填 |
| 申请人 | 发起预订的项目负责人 | 必填 |
| 审批人 | 资源负责人或团队负责人 | 必填 |
| 状态 | 待审批、已确认、已变更、已释放 | 必填 |
| 备注 | 特殊约定，如阶段性高峰、远程安排等 | 选填 |
颗粒度的选择取决于团队规模和变更频率。人员数量少、项目之间借调频繁的团队，按人预订更直接，能看清每个人的时间去向；人员多、同类角色可互换的团队，按角色预订更灵活，由资源负责人在角色池内分配具体人员。时间维度上，按周预订适合交付节奏稳定、变更较少的团队；按迭代预订适合迭代周期固定、以迭代为承诺单位的团队。两种维度可以组合，例如按迭代确认、按周跟踪。
投入比例与工时只能选一种作为主口径。用比例时，约定“100%表示该人员在该时间段内全部可用工时投入本项目”，部分投入按比例折算；用工时则直接填写人天或人时。主口径确定后，预订单、台账和检查都使用同一口径，避免出现“50%”和“每周20小时”混用导致汇总失真。若团队同时存在兼职和全职成员，可在备注中说明可用工时基数，比例仍按个人基数计算。
提交、审批、变更与释放的操作步骤
四个动作各自有明确的输入、做法、输出和完成标志，规则才算可执行。下面按动作拆解。
提交
输入：项目的工作项清单、初步排期、所需角色与人员意向。做法：项目负责人在项目启动或迭代规划阶段，按预订单字段逐项填写，一条记录对应一个人员在一段时间内的一笔占用；同一人员在不同阶段投入比例不同的，拆成多条记录。输出：状态为“待审批”的预订单。完成标志：必填字段齐全，起止时间与项目排期一致，申请人已提交给对应审批人。
审批
输入：待审批的预订单、该人员已有的占用记录、项目优先级说明。做法：审批人核对被预订人员在该时间段内的已有占用，判断新增占用后是否超出可用工时；对超出的情况，与申请人确认优先级或调整投入比例。审批时限建议按团队节奏设定，例如两个工作日内答复，超时未答复视为待定并提醒申请人跟进。输出：状态为“已确认”或“退回修改”的预订单，退回时注明原因。完成标志：审批人给出明确结论，申请人收到通知。
变更
输入：已确认的预订单、变更原因（范围调整、人员变动、优先级变化）。做法：投入比例或起止时间发生变化的，由原申请人提交变更，重新走审批；变更幅度小且不影响其他项目的，可由审批人直接确认并在台账中记录。变更确认后，通知被预订人员和其他受影响的项目负责人。输出：更新后的预订单及变更记录。完成标志：变更后的记录状态为“已确认”，相关方已收到通知。
释放
输入：项目结束通知、人员退出或转岗信息。做法：项目负责人在项目结束或人员退出时，将该人员对应的预订单状态改为“已释放”，并注明实际结束日期；提前结束的，释放剩余时间段。输出：状态为“已释放”的记录。完成标志：台账中该人员在该项目上的占用不再计入未来时间段，资源负责人可将其时间分配给新需求。
角色分工与各角色的交付物
规则停留在文档里的常见原因是没有人对具体动作负责。把每个角色的交付物和时限写清楚，规则才能进入日常节奏。
| 角色 | 主要职责 | 交付物 | 时限 |
|---|---|---|---|
| 项目负责人 | 发起预订、提交变更、项目结束时释放 | 预订单、变更申请、释放记录 | 项目启动或迭代规划时提交；变更发生后及时提交；项目结束后一周内释放 |
| 资源负责人（或团队负责人） | 审批预订、在角色池内分配人员、处理冲突 | 审批结论、人员分配结果 | 收到预订后两个工作日内答复 |
| 被预订人员 | 确认自身投入安排、反馈实际投入偏差 | 投入确认、工时或进度反馈 | 收到通知后确认；按周或按迭代反馈 |
| PMO或规则维护者 | 维护预订台账、记录例外、组织复盘 | 台账更新、例外记录、复盘纪要 | 台账按周更新；例外当次记录；按触发条件组织复盘 |
规则维护者的工作容易被忽略，但台账的准确性直接决定规则是否可信。维护者需要保证已确认的预订及时进入台账、变更和释放及时反映，并对未按流程走的例外单独记录，注明原因和处理方式。例外记录积累到一定数量，就是复盘规则的信号。
示例：一个迭代周期的预订怎么走
以下为演示情景，用于说明规则走法，不对应具体团队的真实数据。
背景：某研发团队采用两周迭代。项目A进入开发阶段，需要一名后端开发人员在后两个迭代内投入60%；项目B同期有一个测试专项，需要同一名测试人员投入50%。团队按迭代预订，投入比例以个人可用工时为基数。
填写：项目A负责人填写预订单，项目填“项目A”，工作项填“订单模块开发”，角色填“后端开发”，人员填“张工”，投入比例填“60%”，起止时间填两个迭代的起止日期，优先级填“高”，申请人填自己，审批人填后端团队负责人。项目B负责人以同样方式为测试人员提交一条50%的预订。
审批：后端团队负责人查看张工在该时间段内的已有占用，发现已有一个项目占用30%，加上本次60%合计90%，未超出可用工时，予以确认。测试人员的审批人发现其已有占用60%，加上本次50%合计110%，超出可用工时，退回项目B负责人，要求调整投入比例或错开时间。项目B负责人将投入调整为40%，重新提交后确认。
变更：迭代进行到一半，项目A的范围扩大，需要张工投入提高到80%。项目A负责人提交变更，审批人核对后确认合计达到110%，与项目A负责人和原30%占用项目的负责人协商，将原项目占用降至20%，变更完成并通知张工。
释放：第一个迭代结束时，项目B的测试专项提前完成，项目B负责人将测试人员的预订状态改为“已释放”，注明实际结束日期，释放出的时间由测试团队负责人分配给新需求。
这个示例体现的优先级判断是：审批人依据已有占用和可用工时做加总核对，超出时优先调整投入比例或错开时间，而不是直接拒绝；变更涉及多个项目时，由审批人牵头协商，协商结果落到预订单上。
预订台账与规则执行情况检查
规则上线后，需要用台账和执行检查判断它是否真的在运转。台账是全部预订单的汇总视图，建议包含：项目、工作项、角色、人员、投入比例或工时、起止时间、优先级、申请人、审批人、状态、变更记录、实际释放日期。更新频率与预订颗粒度对齐，按周或按迭代更新，变更和释放当次记录。
执行检查建议每月或每迭代做一次，检查项与通过标准如下：
| 检查项 | 通过标准 | 不通过时的处置 |
|---|---|---|
| 字段完整率 | 已确认预订的必填字段完整率达到约定比例，例如95%以上 | 退回补填；连续不达标的项目在例会上说明 |
| 审批时限达成 | 约定时限内给出结论的预订占比达到约定比例 | 提醒审批人；积压较多的调整审批分工 |
| 变更是否重提 | 投入比例或时间调整的预订均有变更记录 | 补录变更；对未走变更的占用在台账中标注 |
| 释放是否及时 | 项目结束或人员退出后，预订在约定时限内释放 | 由维护者代为释放并通知原申请人 |
| 例外记录 | 未按流程走的占用均有例外记录和原因 | 补充记录；例外集中的环节纳入复盘 |
规则复盘的触发条件可以设为：例外记录连续两个周期超过约定数量、多个项目频繁因资源冲突延期、团队规模或项目结构发生明显变化。复盘时重点看颗粒度是否合适、审批时限是否现实、字段是否有冗余，据此调整规则本身，而不是只追责执行。
在工具承载上，预订台账和审批状态可以放在统一的项目协作平台中管理。ONES 资源管理提供资源规划视图，管理者可以按业务优先级安排和计划团队资源；支持通过工作数量和工时规模了解成员排期，支持筛选与分组掌握成员在不同项目的投入比重，并可实时查看成员每日投入饱和明细、通过资源报表反馈项目投入情况。团队可以把预订单作为工作项或记录纳入同一平台，让预订状态与项目进度放在一起查看，减少台账与项目信息脱节的情况。具体到预订单据和审批流的配置方式，建议在选型时结合团队现有流程核验。
常见问题
团队规模很小，还需要正式的预订审批流程吗？
规模小的团队可以简化流程，但建议保留两个动作：预订记录和释放。审批环节可以由资源负责人口头确认后由申请人补录记录，只要台账能反映谁在什么时间段被哪个项目占用多少比例即可。简化的是审批层级和时限，预订记录本身不宜省略，否则人员投入无法追溯，后续出现冲突时缺少事实依据。
按角色预订后，具体人员什么时候确定？
按角色预订时，预订单先记录角色、投入比例和起止时间，人员字段可以留待资源负责人在角色池内分配后补填。补填的时点建议不晚于占用开始前一个规划周期，例如按迭代预订的团队在迭代开始前确认到人。人员确定后需要通知被预订人员本人，并同步更新台账，避免出现角色已被占用但无人知晓的情况。
预订已经确认，但实际投入和预订偏差很大，怎么处理？
偏差处理分两步。第一步是记录：被预订人员按周或按迭代反馈实际投入，维护者在台账中标注偏差。第二步是判断原因：如果偏差来自项目范围变化，走变更流程重新确认投入比例；如果偏差来自个人效率或任务拆分问题，属于项目内部执行管理，由项目负责人处理。偏差持续出现且集中在同一环节时，应纳入规则复盘，检查颗粒度或投入口径是否合适。
预订规则和任务排期、负载冲突处理怎么衔接？
三者分工不同。预订规则记录人员投入的占用关系，任务排期安排工作项之间的先后与依赖，负载冲突处理决定多项目争抢同一人员时谁优先。衔接点在数据：预订台账提供每个人在各时间段的占用事实，任务排期据此安排工作项时间，冲突发生时由资源负责人依据台账和业务优先级裁决，裁决结果再回到预订单上更新。规则本身不承担裁决职责。
预订台账用什么工具承载比较合适？
台账的核心要求是能按人员和时间段汇总占用、能反映状态变化、能与项目信息对照查看。表格工具可以起步，但项目增多后容易出现台账与项目进度脱节。ONES 资源管理提供资源规划视图，管理者可以按业务优先级安排和计划团队资源；支持通过工作数量和工时规模了解成员排期，支持筛选与分组掌握成员在不同项目的投入比重，并可实时查看成员每日投入饱和明细、通过资源报表反馈项目投入情况。预订单据和审批流的具体配置方式，建议结合团队现有流程在选型时核验。
