资源预订规则用来约定谁在什么时间、以多少投入参与哪项工作，由谁批准，以及变更和释放怎么处理。本文给出一份已填写的示例规则表，覆盖预订对象、投入比例、时间窗、审批角色、变更与释放条件，并逐项解释填写理由，帮助读者改造成本团队可用的规则。
要点总览（TL;DR）
- 资源预订规则要写清四件事：预订什么、订多少、订多久、谁批准，示例用8条规则覆盖开发、测试、管理、维护、跨部门协作和新人培养场景。
- 投入比例与预订单位取决于工作可分割程度：开发按人天、测试按半天、管理职责按百分比并按周更新，最小单位不宜细于半天。
- 审批遵循“谁掌握资源谁审批、谁使用资源谁确认”，变更与释放条件要量化到触发值和操作时限，避免预订长期挂账。
- 改造时先定预订粒度再定审批层级，规则条目控制在5到10条，例外场景单列并写明审批人与有效期。
- 示例假设约30人、双周迭代、内部人员为主；团队规模、项目周期、外包与跨部门比例变化时，提前期、审批层级和投入上限需要相应调整。
这份资源预订规则示例要解决什么问题
资源预订规则约束的是“人员投入”这件事，它要回答四类问题：预订什么（人员、角色或具体的人）、订多少（人天、投入百分比或半天粒度）、订多久（起止时间与提前多久提出）、谁批准（直属主管、项目负责人还是资源池负责人）。把这四个问题写清楚，团队在抽调人员参与项目时就有共同依据，减少口头承诺和临时插队。
本文的示例情景为虚构设定，仅用于演示填写方式：某研发团队约30人，分为前端、后端、测试三个职能小组，同时推进两个产品项目和一个维护项目；角色包括项目负责人、职能组长、资源协调人和普通研发成员。示例中的姓名、项目名和数字均为演示数据，不代表真实客户或实测结果。
需要说明本文的边界：规则只处理“人员投入的预订与释放”，任务本身的排期方法、依赖关系管理，以及资源负载冲突的识别与处置流程，属于相邻主题，本文不展开。预订规则是排期和负载管理的前置输入，它保证排期时拿到的投入承诺是可追溯的，但不替代排期本身。
完整示例：一张已填写的资源预订规则表
下表是一份已填写的规则示例，共8条，按角色和工作类型分别设定。字段包括规则编号、适用对象、预订单位、投入上限、时间窗、审批角色、变更条件和释放条件。读者可以把它当作填写模板，替换成自己团队的角色与项目名称。
| 规则编号 | 适用对象 | 预订单位 | 投入上限 | 时间窗 | 审批角色 | 变更条件 | 释放条件 |
|---|---|---|---|---|---|---|---|
| R01 | 后端研发成员参与产品项目 | 人天，最小0.5天 | 单项目不超过本人可用工时的60% | 提前5个工作日提交，覆盖未来4周 | 职能组长审批，项目负责人确认 | 变更超过2人天需重新审批 | 任务完成或项目阶段结束后3个工作日内释放 |
| R02 | 前端研发成员参与产品项目 | 人天，最小0.5天 | 单项目不超过本人可用工时的50% | 提前5个工作日提交，覆盖未来4周 | 职能组长审批，项目负责人确认 | 变更超过2人天需重新审批 | 任务完成或项目阶段结束后3个工作日内释放 |
| R03 | 测试成员参与版本验证 | 半天 | 单版本不超过本人可用工时的70% | 版本提测前3个工作日提交 | 测试组长审批 | 提测延期超过2天需重新确认 | 版本发布后2个工作日内释放 |
| R04 | 项目负责人投入 | 投入百分比，按周更新 | 同时负责项目不超过2个，合计不超过80% | 项目立项时登记，每周一更新 | 研发经理审批 | 新增负责项目需重新审批 | 项目结项后释放 |
| R05 | 职能组长兼任项目接口人 | 投入百分比，按周更新 | 接口事务不超过本人可用工时的20% | 项目启动时登记 | 研发经理审批 | 接口范围扩大需重新评估 | 项目结项或接口人更换时释放 |
| R06 | 维护项目紧急支持 | 人天，最小0.5天 | 单人每周不超过2人天 | 当天可提交，次日生效 | 维护项目负责人审批，事后报职能组长 | 连续两周超限需升级审批 | 故障关闭后1个工作日内释放 |
| R07 | 跨部门协作人员 | 人天，最小1天 | 单次预订不超过10人天 | 提前10个工作日提交 | 双方部门负责人共同审批 | 超过10人天需拆分或升级审批 | 协作任务验收后5个工作日内释放 |
| R08 | 新人培养期参与项目 | 人天，最小1天 | 不超过本人可用工时的30%，需配导师 | 提前5个工作日提交 | 职能组长审批 | 导师变更需重新登记 | 培养期结束或转正后释放 |
示例中的人员投入与项目对象的对应关系是：R01、R02对应两个产品项目的开发任务，预订时须写明项目名和需求编号；R03对应版本验证，须写明版本号；R04、R05对应项目管理职责，按项目登记；R06对应维护项目的故障单；R07对应跨部门协作事项；R08对应新人所在项目。每条预订都能追溯到具体工作对象，避免出现“某人被订走了但不知道为谁做事”的情况。
逐项解释：每条规则为什么这样填
投入比例与预订单位的选择，取决于这项工作的可分割程度。开发任务通常按人天预订，最小0.5天，因为半天是多数团队能说清楚的最小投入单位；测试验证按半天预订，因为一轮验证往往以半天为周期；管理职责按投入百分比并按周更新，因为管理投入是持续性的，按人天拆反而失真。如果团队任务颗粒度较粗，可以把最小单位放大到1天；如果任务切换频繁，可以细化到0.5天，但不宜再细，否则填写成本会超过规则带来的收益。
时间窗与提前期的设定，要与团队的排期节奏匹配。示例中开发预订提前5个工作日、覆盖未来4周，是因为该团队按双周迭代排期，提前一周提交能留出协调时间。跨部门协作提前10个工作日，是因为跨部门沟通链条更长。紧急支持允许当天提交、次日生效，是为故障场景留的例外通道，同时用“连续两周超限需升级审批”防止例外变成常态。提前期填得太短，审批流于形式；填得太长，又会让临时需求全部走例外。
审批角色与授权层级的设计，遵循“谁掌握资源谁审批、谁使用资源谁确认”的分工。职能组长掌握本组人员的时间，所以由组长审批投入上限；项目负责人使用这些投入，所以由负责人确认预订是否与实际任务匹配。跨部门协作需要双方负责人共同审批，因为涉及两个部门的资源让渡。紧急支持采用“先审批后报备”，把审批权下放给维护项目负责人，同时保留事后知情。常见填错方式是把所有规则都写成“项目经理审批”，结果是项目经理既不了解各职能组的实际负荷，也无法对超限投入负责。
变更、延期与释放条件的写法要具体到触发值和动作。示例中“变更超过2人天需重新审批”，给出了明确的阈值；“提测延期超过2天需重新确认”，把延期与测试资源挂钩；“任务完成或项目阶段结束后3个工作日内释放”，给出了释放的时限。常见错误是只写“变更需审批”而不写什么算变更，或者只写“项目结束后释放”而不写由谁在几天内操作，导致预订长期挂账、资源被虚占。修正写法是把触发条件量化，并指定释放动作的责任人。
从示例到自用：可迁移的填写规律
把示例改造成本团队规则，建议按以下步骤推进，顺序本身也是规律的一部分：
- 先定预订粒度。统计团队过去一个季度的任务切换频率，确定最小预订单位是人天、半天还是投入百分比。粒度定不下来，后面的审批层级就没有依据。
- 再定审批层级。按“资源归属”划分审批权：本组人员由组长审批，跨组由双方负责人审批，管理职责由上一级审批。审批层级应比预订粒度粗一级，避免每笔预订都要高层签字。
- 把规则条目绑定到角色和工作项类型。示例中R01绑定“后端成员+开发任务”，R03绑定“测试成员+版本验证”。绑定方式让规则可被检索和复用，而不是散落在文档里靠记忆执行。
- 控制规则数量。示例用8条覆盖主要场景，经验上规则条目控制在5到10条较为可操作；超过这个范围，说明团队在试图用规则覆盖所有例外，应改为“通用规则+例外清单”的结构。
- 处理例外条款。为紧急支持、跨部门协作等场景单列规则，并写明例外的审批人和有效期，防止例外条款被日常使用。
规则最终要落到协作工具里才能被持续执行。以ONES为例，可以把“预订单位、投入上限、时间窗、审批角色”配置为工作项的自定义字段，把“待审批、已预订、已释放”设为状态流转，让每次预订都对应一条工作项记录，审批和释放留下操作痕迹。这样规则从文档变成工作项字段和状态约束，资源协调人查看字段汇总就能知道谁在什么时间被订给了哪个项目。工具承载的是管理动作，规则本身仍需团队先定义清楚。
适用边界：这些规则在什么情况下要调整
示例假设团队规模约30人、以双周迭代推进、以内部研发人员为主。团队规模明显扩大时，审批层级需要增加或改为按资源池管理；项目周期很短（如一周以内的活动型项目）时，提前5个工作日的预订窗口会失效，应缩短提前期并简化审批；外包人员参与时，预订规则要与合同工时和结算口径对齐，投入上限的写法需要调整；跨部门协作比例高时，应把R07这类规则从例外提升为常规条目。
规则过细的代价是填写和审批成本上升，成员把时间花在维护预订记录上；规则过粗的代价是预订失去约束力，超限投入无法及时发现。判断标准是：如果一条规则连续一个季度没有被触发过变更或审批，可以考虑合并；如果例外条款的使用频率超过常规条款，说明规则需要重写。
资源预订规则与任务排期、负载冲突管理的分工是：预订规则负责“承诺”，排期负责“安排”，负载冲突管理负责“调整”。预订确认后，排期在此基础上安排任务顺序；出现负载冲突时，按预订记录判断哪些承诺可以协商调整，而不是重新口头协调。三者衔接顺畅的前提是预订记录可查、可追溯。
建议每季度复审一次规则，复审内容包括：例外条款的使用次数、超限审批的发生频率、释放是否及时。规则变更时保留版本号和生效日期，旧版本归档，避免成员按不同版本执行。规则数量、审批层级和提前期是复审时最常调整的三项，调整前先用一个迭代的数据做验证，再全量推行。
常见问题
团队刚开始用资源预订规则，应该先定几条？
建议从覆盖主要工作类型的3到5条起步，例如开发投入、测试验证、项目管理职责各一条，先跑一个迭代。运行中记录哪些预订走了例外、哪些规则从未触发，再决定补充或合并。规则数量控制在5到10条较为可操作，超过这个范围通常说明团队在试图用规则覆盖所有例外，应改为“通用规则+例外清单”的结构。
预订了但任务推迟，投入记录怎么处理？
在规则里预先写明延期条件，例如“提测延期超过2天需重新确认”，让延期触发一次重新审批而不是自动顺延。释放动作要指定责任人，例如由项目负责人在阶段结束后3个工作日内操作释放。如果延期频繁发生，说明提前期或排期节奏需要复审，可以先用一个迭代的数据验证调整方案。
紧急需求插队时，预订规则要不要留通道？
需要留，但要把通道写成有边界的例外条款。示例中维护项目的紧急支持允许当天提交、次日生效，审批权下放给维护项目负责人并事后报备职能组长，同时规定“连续两周超限需升级审批”。这样既保证故障响应，又防止例外条款被日常使用。例外条款应写明审批人、有效期和升级条件。
预订规则和排期、负载冲突处理怎么衔接？
三者分工是：预订规则负责“承诺”，排期负责“安排”，负载冲突管理负责“调整”。预订确认后，排期在此基础上安排任务顺序；出现负载冲突时，按预订记录判断哪些承诺可以协商调整，避免重新口头协调。衔接顺畅的前提是预订记录可查、可追溯，因此规则落地时要保证每条预订都能对应到具体工作对象和状态。
规则多久复审一次，复审看什么？
建议每季度复审一次，重点看三项数据：例外条款的使用次数、超限审批的发生频率、预订释放是否及时。如果一条规则连续一个季度没有被触发过变更或审批，可以考虑合并；如果例外条款使用频率超过常规条款，说明规则需要重写。规则变更时保留版本号和生效日期，旧版本归档，避免成员按不同版本执行。
