研发资源预订是把“谁在什么时间段投入哪个项目、投入多少”提前约定下来，并让约定可查、可改、可追溯的一套动作。它解决的是跨项目争抢同一批研发人员时，投入安排靠口头沟通、事后才发现冲突的问题。本文聚焦人员投入的预订，任务排期与负载冲突仲裁不在展开范围；ONES 可作为预订记录与偏差核对的承载工具之一。
要点总览（TL;DR）
- 研发资源预订的对象是人员投入，约定谁在什么时间段为哪个项目投入多少比例；任务拆分与依赖关系属于任务排期，不在预订范围内。
- 流程按申请、审批、确认、变更四个环节推进：项目负责人提交需求，资源负责人核对同期预订与负载后给出结论，执行人确认知悉，变更走统一通道并记录原因。
- 三类角色各有交付物：项目负责人提交预订申请，资源负责人输出审批结论与冲突协调记录，执行人确认安排并回填实际投入。
- 台账至少保留人员、项目、起止时间、投入比例和状态五项字段；状态区分申请中、已确认、已变更、已结束，统计投入时只计入已确认和已变更的记录。
- 机制可用与否看四点：字段与流程已书面定义、角色指定到人、首个周期跑通一轮完整流程、偏差核对形成固定节奏。
研发资源预订要解决什么问题，边界在哪里
研发资源预订的对象是人员的投入安排，具体到某个人或某个角色，在某个时间段内为某个项目投入多少比例。任务本身拆成几步、先后依赖如何，属于任务排期的工作；预订只回答“这段时间这个人归谁用、用多少”。把两者分开，预订台账才能保持稳定，不会因为任务拆分调整而频繁重写。
时间粒度决定预订的可操作程度。常见选择有三种：按周预订，适合人员流动快、项目切换频繁的团队；按双周预订，与多数团队的迭代节奏对齐；按迭代预订，适合迭代长度固定且跨团队协作较多的组织。粒度一旦确定，应在一个周期内保持一致，否则同一时段的记录无法横向比较。粒度也不宜过细，按天预订会带来大量维护成本，实际执行中很难坚持。
预订与任务排期、负载冲突管理有明确分工。预订负责形成投入约定，任务排期负责把工作拆解到可执行单元，负载冲突管理负责在超载发生时做取舍和仲裁。三者顺序是：先有预订形成投入基线，排期在基线内安排任务，冲突处理在基线被突破时介入。预订环节不承担仲裁职责，遇到两个项目同时要一个人，应由资源负责人按优先级协调，而不是在预订表里反复改数字。
预订不等于锁定。预订记录表达的是当前周期内的投入约定，遇到项目优先级变化、人员变动或紧急插入任务，应当走变更通道更新记录，并留下变更原因和影响范围。保留变更通道的目的，是让台账始终反映真实约定，而不是把预订做成一份签完就没人再看的表格。
预订流程的四个环节：申请、审批、确认、变更
把预订拆成申请、审批、确认、变更四个环节，每个环节都有明确的输入、动作、输出和完成标志，执行时按顺序推进即可。下表给出四个环节的执行口径。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 申请 | 项目名称、所需人员或角色、起止时间、投入比例、需求优先级、申请理由 | 项目负责人填写预订申请，注明是否已有口头约定 | 一条状态为“申请中”的预订记录 | 必填字段完整，资源负责人已收到申请 |
| 审批 | 申请记录、该人员同期已有预订、当前负载情况 | 资源负责人核对可投入量，判断是否与其他项目冲突，给出同意、调整比例或驳回的结论 | 审批结论及理由 | 记录状态变为“已确认”或退回申请 |
| 确认 | 已审批通过的预订记录 | 通知执行人，执行人确认接受安排；有异议的在此时提出 | 执行人确认结果 | 执行人已知悉项目、时间段与投入比例 |
| 变更 | 变更原因、影响范围、新的时间或比例 | 由提出方发起变更，资源负责人重新判断冲突，执行人知悉调整 | 更新后的记录及变更历史 | 变更原因与影响范围已记录，相关方已知悉 |
申请环节的字段设计直接影响后续统计。除基本信息外，建议要求填写需求优先级和申请理由，前者用于审批时排序，后者在变更和复盘时提供依据。申请提交后，记录进入“申请中”状态，此时不应被当作已确定的投入对外承诺。
审批依据主要是该人员同期已有预订和当前负载。资源负责人需要看两件事：同一时间段内该人员的预订比例合计是否超过可用投入，以及新申请与已有预订的优先级关系。审批结论有三种：按申请通过、调整比例后通过、驳回并说明原因。审批人应是掌握团队人员调配权的人，通常是资源负责人或研发经理，而不是项目负责人自己。
确认环节容易被省略，但它是预订真正生效的标志。审批通过只代表资源侧同意，执行人是否知悉、是否有异议，需要在确认环节解决。通知方式可以是预订记录中@执行人，也可以是周会同步，关键是留下执行人已知悉的痕迹。执行人提出异议时，回到审批环节重新判断，而不是在确认环节私下调整。
变更与取消的触发条件包括：项目优先级调整、人员离职或转岗、紧急任务插入、原估算投入明显偏离。变更时记录三件事：变更原因、影响的项目范围、调整后的时间或比例。取消同样走变更通道，记录状态改为“已结束”并注明取消原因，保留历史记录以便后续追溯。
角色分工与各自交付物
预订涉及三类角色，各自在流程中承担不同职责，交付物也不同。角色指定到人，是预订机制能运转的前提。
| 角色 | 主要职责 | 交付物 | 变更时的责任 |
|---|---|---|---|
| 项目负责人 | 提出人员需求，说明优先级和投入时段，对需求合理性负责 | 预订申请记录 | 发起变更申请，说明变更原因和影响范围 |
| 资源负责人 | 判断可投入量与冲突，做出审批结论，维护整体投入平衡 | 审批结论、冲突协调记录 | 重新评估冲突，确认调整方案 |
| 执行人 | 确认接受安排，按周期反馈实际投入 | 确认结果、实际投入回填 | 知悉调整并反馈执行影响 |
项目负责人的核心动作是把需求说清楚：要谁、什么时候要、投入多少、为什么这个优先级。需求描述模糊会导致审批反复，常见问题是只写“需要前端支持”而不写具体时段和比例。项目负责人还应对需求做内部排序，同一项目提多个人员需求时，标明哪些是必须、哪些可以延后。
资源负责人是预订机制的关键节点。其职责不是简单盖章，而是掌握团队整体投入情况，在多个项目之间做平衡。审批时需要有可查的同期预订视图，否则判断只能凭印象。资源负责人还应定期检查预订与实际的偏差，发现系统性超载时推动调整，而不是等到项目延期才处理。
执行人的职责常被低估。确认接受安排，意味着执行人知悉自己在某段时间的投入归属；按周期回填实际投入，是偏差核对的数据来源。执行人反馈的实际投入与预订值不一致时，应说明原因，例如被临时抽调、任务估算偏差或请假，这些信息是下一周期调整预订的依据。
变更时三类角色各有责任：项目负责人发起并说明原因，资源负责人重新判断冲突并确认方案，执行人知悉调整并反馈执行影响。三方都留下记录，变更才可追溯。
资源预订台账的字段设计
台账是预订机制的记录载体，字段设计决定了记录能否统计和核对。下表给出建议字段及必填、选填划分，团队可按规模调整。
| 字段 | 说明 | 必填/选填 |
|---|---|---|
| 预订编号 | 唯一标识，便于引用和追溯 | 必填 |
| 人员或角色 | 预订单元，明确到人或角色 | 必填 |
| 所属团队 | 便于按团队汇总 | 选填 |
| 项目 | 投入归属的项目 | 必填 |
| 开始时间 | 预订起始日期 | 必填 |
| 结束时间 | 预订截止日期 | 必填 |
| 投入比例 | 该时段内投入的百分比或人天 | 必填 |
| 优先级 | 需求优先级，用于冲突排序 | 必填 |
| 状态 | 申请中/已确认/已变更/已结束 | 必填 |
| 申请人 | 项目负责人 | 必填 |
| 审批人 | 资源负责人 | 必填 |
| 实际投入 | 周期末回填的实际投入值 | 选填，核对时填写 |
| 偏差说明 | 实际与预订不一致的原因 | 选填，有偏差时填写 |
| 变更记录 | 变更时间、原因、影响范围 | 选填，发生变更时填写 |
状态字段是台账的核心。四个状态覆盖预订的完整生命周期：申请中表示尚未生效，已确认表示约定成立，已变更表示原约定被调整，已结束表示该时段投入已完成或取消。统计投入时只计入已确认和已变更的记录，申请中的记录不纳入，避免把未定事项当作既定投入。
实际投入回填字段让台账具备核对能力。回填时点与预订粒度对齐，按周预订就在周末回填，按迭代预订就在迭代末回填。偏差说明不是必填项，但出现明显偏差时应填写，否则下一周期无法判断是估算问题还是执行问题。
小团队可以精简字段，保留人员、项目、起止时间、投入比例和状态五项即可运转。跨项目多、人员共享频繁的组织，建议保留优先级、审批人和变更记录，否则冲突判断和追溯会缺少依据。
一个完整示例：两周迭代的预订过程
以下为演示情景，用于说明各环节如何衔接。某研发团队采用双周迭代，成员包括前端工程师小李、项目负责人张经理、资源负责人王主管。张经理负责的项目 A 在下一迭代需要小李投入 60% 的时间，用于支付模块改造。
申请环节：张经理在台账中新增一条记录，填写人员为小李、项目为项目 A、起止时间为迭代起止日期、投入比例 60%、优先级为高，申请理由注明支付模块改造为季度目标的关键路径。记录状态为申请中。
审批环节：王主管查看小李同期已有预订，发现项目 B 已预订 50% 投入。两个项目合计 110%，超出可用投入。王主管与张经理沟通后，确认项目 A 优先级更高，将项目 B 的预订调整为 40%，项目 A 按 60% 通过。审批结论记录在案，项目 B 的记录状态改为已变更并注明原因。
确认环节：张经理在记录中通知小李，小李确认接受，并在迭代计划会上知悉具体任务安排。此时项目 A 的记录状态为已确认。
执行与核对：迭代进行中，小李因一次线上故障处理占用了约两天，实际投入约为 50%。迭代末回填实际投入，偏差说明记录为故障支持占用。王主管在偏差核对时看到这一情况，判断属于偶发事件，不调整下一迭代预订，但在风险记录中标注支付模块存在延期可能。
这个示例说明三个要点：审批环节需要看到同期全部预订才能判断冲突；变更要记录原因，项目 B 的调整才有据可查；偏差核对的价值在于区分偶发偏差和系统性问题，前者记录即可，后者需要调整预订。
用ONES承载预订记录与核对
预订台账落地到工具时，需要解决三件事：记录存在哪里、状态如何流转、预订与实际如何对照。ONES 的资源管理能力可以承接其中部分环节，具体配置需结合团队流程确定。
记录承载方面，预订记录可以作为工作项或文档中的结构化条目管理，每条记录对应一个人员在一个时间段内对一个项目的投入约定。ONES Resource 支持通过工作数量和工时规模了解成员排期，并支持筛选与分组，查看成员在不同项目的投入比重，这与台账中按人员、按项目汇总的需求对应。排期规划可通过甘特视图完成，支持拖拉拽调整项目排期，便于在预订确认后做整体排布。
状态流转与变更留痕方面，预订记录的状态可以借助工作项状态或文档中的状态字段表达，变更时保留修改记录。需要说明的是，ONES 资源管理中是否有独立的预订对象和预订状态流转，现有资料未明确，落地时应先确认承载方式，再决定是用工作项类型还是文档表格来管理预订记录。
预订与实际的对照方面，ONES Resource 支持实时查看成员每日投入饱和明细，识别规划风险；提供多种资源报表反馈项目投入情况，并支持一键导出工时日志。资源和工时管理方案支持多维度掌握项目和成员的投入情况，可查询和导出工时登记日志明细。这些能力可用于周期末的偏差核对：以预订记录为基线，用工时和饱和度数据对照实际投入。预订值与实际值的直接对照视图是否可生成，需在实际配置中确认，必要时通过导出数据后比对完成。
上线前的完成检查
预订机制是否可运行，可以用以下清单逐项核对。每项都应有明确结论，而不是停留在“计划中”。
- 预订单元已确定：明确到人、角色还是团队，并在团队内统一口径。
- 时间粒度已确定：按周、双周还是迭代，且与团队现有节奏一致。
- 四个环节的输入输出已定义：申请字段、审批依据、确认方式、变更记录方式均有书面说明。
- 台账字段已确定：必填与选填划分清楚，状态字段的四个取值已约定含义。
- 三类角色已指定到人：项目负责人、资源负责人、执行人均有明确人选，不出现角色空缺。
- 首个周期已完成试运行：至少走完一轮申请、审批、确认、回填的完整流程。
- 偏差核对已形成固定节奏：核对时点、参与人、偏差处理方式已确定并执行过一次。
- 变更通道已验证：至少发生过一次变更，记录完整可追溯。
清单中任何一项未完成，机制在上线后都容易出现记录不全或核对断档。试运行阶段可以缩小范围，选择一个项目和一个迭代先跑通，再逐步扩大。偏差核对形成固定节奏是最后一项，也是判断机制是否真正运转的标志：如果连续两个周期都没有核对记录，说明预订还停留在填表阶段。
常见问题
预订粒度选按周还是按迭代，中途可以改吗？
粒度选择取决于团队节奏：人员流动快、项目切换频繁的团队适合按周；迭代长度固定、跨团队协作多的组织适合按迭代。粒度一旦确定，应在一个周期内保持一致，否则同一时段的记录无法横向比较。中途调整粒度会打断偏差核对的连续性，建议在周期结束时统一评估是否调整，并把调整原因记录下来。
执行人对预订安排有异议，应该在哪一步提出？
异议应在确认环节提出。审批通过只代表资源侧同意投入，执行人是否知悉、是否有执行上的困难，需要在确认环节解决。执行人提出异议后，回到审批环节由资源负责人重新判断冲突和比例，而不是在确认环节私下调整。这样处理的好处是，台账上的记录始终与审批结论一致，后续核对有据可查。
小团队人少，能不能精简台账字段？
可以。小团队保留人员、项目、起止时间、投入比例和状态五项即可运转。跨项目多、人员共享频繁的组织，建议保留优先级、审批人和变更记录，否则冲突判断和追溯会缺少依据。精简的前提是状态字段的四个取值含义清楚，否则统计投入时容易把未定事项算成既定投入。
偏差核对发现实际投入长期低于预订值，该怎么处理？
先区分偶发偏差和系统性偏差。偶发偏差（如临时故障支持、短期请假）记录原因即可，不调整下一周期预订；连续两个周期以上出现同方向偏差，说明预订估算或人员安排存在问题，应在下一周期调整预订比例，并检查是否有个别项目长期占用超出其优先级应得的投入。核对时点建议与预订粒度对齐，按周预订就在周末核对，按迭代预订就在迭代末核对。
预订记录放在工具里，需要先确认哪些事情？
落地到工具前先确认三件事：记录用什么承载（工作项类型还是文档表格）、状态如何流转并留痕、预订值与实际投入如何对照。以 ONES 为例，ONES Resource 支持通过工作数量和工时规模了解成员排期，支持筛选与分组查看成员在不同项目的投入比重，也支持实时查看成员每日投入饱和明细并导出工时日志，可用于周期末的偏差核对。预订对象与状态流转的具体实现方式，现有资料未明确，建议先小范围试配置再推广。
