研发资源预订是把“谁在什么时间段投入哪个项目、投入多少”提前登记并获得确认的管理动作。落地时先统一预订对象与计量单位，再走申请、评估、确认入账、变更与释放的流程，最终形成一份可追溯的预订台账。本文聚焦人员投入的登记与确认，任务排期与负载冲突处置不在展开范围。ONES 的资源规划与工时能力可作为台账与确认结果的承载方式之一。
要点总览（TL;DR）
- 先统一预订口径：确定预订对象（人员、角色或小组）、计量单位（人天、人周或投入百分比）和时间窗口（季度、月度或迭代），并与后续工时统计口径保持一致。
- 核心流程分五步：提交申请、评估余量、确认入账、变更处理、释放；每步都要有明确的输入、输出和完成标志，口头同意不算确认。
- 台账按标识、资源、时间与量、状态、关联五组字段建立，状态至少覆盖待确认、已确认、已变更、已释放，变更保留原值以便追溯。
- 项目负责人提出申请并对投入量负责，资源负责人确认与调整，PMO或资源管理员维护台账与口径，执行成员按确认结果投入并反馈偏差。
- 用覆盖率、确认及时性、台账一致性、释放及时性四项检查判断机制是否跑起来，按短板调整对应环节。
先定预订对象与粒度：预订什么、按什么单位记
预订机制跑不起来，常见原因不是流程复杂，而是口径不统一：有人按人天报，有人按百分比报；有人预订到具体人，有人只写“后端一名”。这些记录汇总后无法比较，也无法与工时数据核对。因此在发出第一张申请表之前，先把三件事定下来，并写成一份简短的预订口径说明，发给所有项目负责人和团队主管。
预订对象：人员、角色还是小组
预订对象的选择取决于团队管理成熟度。人员级预订精确到具体成员，适合成员技能差异大、可替代性低的团队，比如核心中间件、算法或特定业务模块的负责人；代价是每次人员变动都要改台账。角色级预订写“高级后端工程师 1 人”，适合同类角色可互换的团队，排期灵活但确认时需要资源负责人指定具体人选。小组级预订以团队为单位登记投入，适合外包团队或按整组交付的场景，粒度最粗，通常只用于季度级规划。
实际操作中常见混合做法：季度规划用角色或小组级，迭代内执行用人员级。无论选哪种，同一时间窗口内应保持一种主口径，避免同一份台账里两种粒度混用。
计量单位：人天、人周还是投入百分比
投入粒度要与后续工时统计口径一致，否则台账和实际投入永远对不上。人天适合按月或按迭代预订，与每日工时登记直接对应；人周适合季度规划，减少申请频次；投入百分比适合一人同时服务多个项目的场景，便于横向比较各项目占用。选择时问自己一个问题：月底核对实际投入时，你打算拿什么数据来比？如果团队按工时登记，就用人天或百分比；如果只做粗粒度规划，人周即可。
时间窗口：季度、月度还是迭代
时间窗口决定申请频次和台账更新节奏。季度窗口适合年度规划与预算对齐，但离执行越远越容易失真；迭代窗口最贴近实际，但两周一次的申请对项目负责人是不小的负担；月度窗口是多数团队折中的选择。可以分层设置：季度做总量预订，月度或迭代做滚动确认，确认时只调整变化部分。
完成标志：形成一页纸的口径说明，写明对象类型、计量单位、时间窗口，以及由谁审批这份口径的变更。
核心操作步骤：从提交申请到确认入账
口径确定后，预订流程本身应尽量短。一个可执行的流程包含提交、评估、确认入账、变更、释放五个动作，每个动作都要有明确的输入、输出和完成标志，否则流程会退化成“发个消息说一声”。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 提交申请 | 项目计划、所需角色与技能、时间段、投入量 | 需求方在统一入口填写预订申请，说明项目背景与不可调整的约束 | 一条待确认的预订申请 | 申请进入待确认状态并通知到资源负责人 | 项目负责人 |
| 2. 评估余量 | 申请、现有台账、成员当前排期 | 资源负责人查看目标人员在申请时间段内的已确认投入，计算剩余可用量，对照项目优先级判断能否满足 | 评估结论：可满足、部分满足或冲突 | 给出明确结论及理由，冲突时提出替代方案 | 资源负责人/团队主管 |
| 3. 确认入账 | 评估结论、双方协商结果 | 确认投入量、起止时间与具体人员，写入预订台账，同步到排期或工时计划 | 状态为“已确认”的台账记录 | 台账更新且相关方收到确认通知 | 资源负责人 |
| 4. 变更处理 | 变更请求、偏差说明 | 按变更规则提交调整，记录原值、新值与原因，重新确认 | 状态为“已变更”的记录及变更历史 | 变更后的投入量在台账与排期中一致 | 项目负责人发起，资源负责人确认 |
| 5. 释放 | 项目结束或阶段完成通知 | 核对实际投入，将剩余预订量释放，记录释放时间 | 状态为“已释放”的记录 | 该成员在后续时间段的可用量恢复 | 项目负责人发起，资源管理员核对 |
几个容易出问题的环节值得单独说明。评估环节要基于台账而不是印象，资源负责人应能看到目标人员在申请时间段内所有已确认的预订，而不是只凭记忆判断“他应该有空”。确认环节的结论必须落到可查询的地方，口头同意不算确认，因为后续核对时无从追溯。变更环节要保留原记录，直接覆盖会让偏差分析失去依据。释放环节最容易被忽略：项目结束后预订不释放，台账上的占用会持续累积，下一次评估时可用量被低估，新项目申请被误判为冲突。
完成标志：团队内任意一条预订都能在台账中查到完整的状态流转记录，且每个状态变化都有对应的确认人或操作记录。
预订台账该有哪些字段
台账是整套机制的载体，字段设计决定了它能回答哪些问题。字段太少，无法支撑评估和核对；字段太多，填写成本高，记录很快荒废。建议按五组组织，先保证必填字段完整，再按需扩展。
| 字段名 | 类型 | 是否必填 | 说明 |
|---|---|---|---|
| 预订编号 | 文本/自动编号 | 必填 | 唯一标识，便于在沟通和变更中引用 |
| 项目名称 | 文本/关联项目 | 必填 | 预订归属的项目 |
| 提出人 | 人员 | 必填 | 通常为项目负责人 |
| 提出时间 | 日期 | 必填 | 用于统计申请到确认的周期 |
| 人员或角色 | 人员/文本 | 必填 | 按口径说明填写具体人员或角色 |
| 所属团队 | 文本/关联组织 | 必填 | 用于按团队汇总投入 |
| 技能标签 | 多选 | 选填 | 角色级预订时用于匹配具体人选 |
| 开始日期 | 日期 | 必填 | 预订投入的起始日 |
| 结束日期 | 日期 | 必填 | 预订投入的截止日 |
| 投入量 | 数值 | 必填 | 与计量单位配套，如 10 人天、50% |
| 计量单位 | 单选 | 必填 | 人天、人周或投入百分比 |
| 状态 | 单选 | 必填 | 待确认、已确认、已变更、已释放 |
| 关联需求或任务 | 关联记录 | 选填 | 便于从预订追溯到具体工作内容 |
| 确认人 | 人员 | 必填 | 资源负责人或团队主管 |
| 变更原因 | 文本 | 条件必填 | 状态变为已变更时填写 |
| 备注 | 文本 | 选填 | 约束条件、替代方案等补充信息 |
状态字段是台账的核心。待确认表示申请已提交但未获资源方同意，此时不应计入可用量扣减；已确认才代表占用生效；已变更保留原记录并记录新值；已释放表示占用结束。如果团队希望区分“部分满足”的情况，可以在投入量旁增加“已确认投入量”字段，与申请投入量分开记录。
台账建立后，建议按项目、按团队、按时间段三个维度提供查询视图。项目负责人关心自己项目的预订是否齐全，团队主管关心本团队成员的占用情况，资源管理员关心整体确认及时率。这三个视图不需要额外数据，只需要台账字段完整。
角色与交付物分工
预订无人认账，通常是因为“谁确认、谁维护”没有写清楚。以下分工适用于多数研发团队，可根据规模合并角色，但职责本身不宜省略。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目负责人（需求方） | 根据项目计划提出预订申请，对投入量的合理性负责；项目结束或阶段完成时发起释放；投入出现偏差时发起变更 | 预订申请、变更请求、释放申请 |
| 资源负责人/团队主管 | 评估申请时间段内的可用余量，按项目优先级给出确认、部分确认或冲突反馈；指定角色级预订的具体人选 | 确认结论、冲突说明与替代方案 |
| PMO 或资源管理员 | 维护台账结构与口径说明，定期核对台账与排期、工时数据的一致性，统计确认及时率与预订覆盖率 | 台账、口径说明、周期性核对记录 |
| 执行成员 | 按确认结果投入工作，如实登记工时；发现实际投入与预订偏差时及时反馈 | 工时记录、偏差反馈 |
一个常见的职责错位是让项目负责人自己确认自己项目的预订。确认动作的本质是资源方对占用做出承诺，必须由掌握资源的人完成。另一个错位是资源管理员替团队主管做确认决定，管理员负责台账和口径，不负责判断优先级。规模较小的团队可以由一人兼任资源负责人和资源管理员，但确认记录上仍应体现确认动作由谁做出。
当预订记录需要与排期、工时数据对照时，ONES 资源管理提供了可衔接的承载方式：通过甘特视图完成项目资源规划与进度跟踪，借助工作数量和工时规模了解成员排期，并支持筛选与分组查看成员在不同项目的投入比重。这意味着确认后的预订可以落到排期视图中，与工时记录形成对照，减少台账与实际情况脱节的情况。具体视图能力以实际使用版本为准。
示例：一个迭代周期的预订怎么走完
以下为演示情景，用于说明流程走法，不代表真实项目数据。
背景：某研发团队采用两周迭代。项目 A（订单系统重构）和项目 B（支付渠道接入）在同一迭代内都需要后端工程师小李，小李的技能标签为“Java、支付域”。迭代开始前一周，两个项目的负责人分别提交预订申请。
- 项目 A 申请：小李，迭代全程 10 个工作日，投入 100%，即 10 人天，理由是重构任务涉及核心交易链路，需要连续投入。
- 项目 B 申请：小李，迭代第 1 至第 6 个工作日，投入 60%，约 3.6 人天，理由是支付渠道联调需要熟悉支付域的人参与。
资源负责人查看台账，发现该迭代内小李尚无其他已确认预订，总可用量为 10 人天。两项申请合计 13.6 人天，超出可用量。按项目优先级（项目 B 有对外交付节点），资源负责人给出结论：项目 B 的申请全额确认；项目 A 调整为迭代第 7 至第 10 个工作日投入 100%，前 6 个工作日投入 40%，合计约 6.4 人天，并建议项目 A 将非支付相关的重构任务分配给同组另一名后端工程师。
两个项目负责人接受调整后，资源负责人将两条记录写入台账，状态置为“已确认”，并同步到排期视图。台账中项目 A 的记录备注栏写明“前 6 个工作日 40%，后 4 个工作日 100%，经与项目 B 协调”。
迭代执行到第 4 个工作日，项目 B 的联调因外部渠道延迟，实际只需小李投入 2 人天。项目 B 负责人提交变更请求，将投入量从 3.6 人天调整为 2 人天，变更原因记为“外部渠道联调延期”。资源负责人确认后，台账中该记录状态变为“已变更”，原值保留在变更历史中，释放出的 1.6 人天由资源负责人通知项目 A，用于补充前段重构任务。
迭代结束，两个项目负责人分别发起释放。资源管理员核对工时记录：项目 A 实际投入约 7.2 人天，与确认值 6.4 人天偏差 0.8 人天，偏差原因记为“补充变更释放量”；项目 B 实际投入 2 人天，与变更后确认值一致。两条记录状态置为“已释放”，小李在下一迭代的可用量恢复为全额。
这条记录的状态流转为：待确认（项目 A 提交）→ 已确认（调整后入账）→ 已变更（项目 B 变更释放量后，项目 A 补充确认）→ 已释放。每一步都有确认人和时间戳，事后可以完整还原当时的决策依据。
完成检查：预订机制是否真的跑起来了
机制建立后，用以下清单做一次核对。检查频率建议为每月一次，由资源管理员执行，结果同步给项目负责人和团队主管。
| 检查项 | 通过标准 | 证据来源 |
|---|---|---|
| 预订覆盖率 | 在研项目均有预订记录，无“先干后补”的项目 | 项目清单与台账比对 |
| 确认及时性 | 申请到确认的平均周期在约定时限内，超时申请有说明 | 台账中提出时间与确认时间之差 |
| 台账一致性 | 预订与实际投入的偏差被记录并说明原因，无静默覆盖 | 台账变更历史与工时记录对照 |
| 释放及时性 | 结束项目在约定天数内完成释放，无长期挂账的占用 | 项目结束时间与释放时间之差 |
| 口径统一 | 台账中计量单位与对象类型符合口径说明，无混用 | 台账字段抽查 |
四项检查中，覆盖率反映机制是否被真正使用，及时性反映流程是否顺畅，一致性反映记录是否可信，释放及时性反映台账是否保持准确。如果覆盖率达标但一致性差，说明确认后的执行跟踪缺失；如果及时性差但一致性尚可，说明评估环节的余量信息不透明，资源负责人难以快速判断。针对不同短板调整对应环节，比整体重做流程更有效。
当预订量增长到人工核对吃力时，可以把台账与排期、工时数据放到同一套系统中对照。ONES 资源管理支持实时查看成员每日投入饱和明细，帮助识别规划风险；资源规划视图可按业务优先级安排团队资源，在可用资源与需求之间做平衡。这些能力用于支撑预订后的跟踪与核对，预订口径和确认规则仍需团队自己定义。
常见问题
团队规模很小，还需要单独设资源管理员吗？
可以合并角色，但职责不宜省略。小团队常见做法是由团队主管兼任资源负责人和台账维护，确认动作仍要留痕，写明谁在什么时间确认了哪条预订。随着预订量增长，再把台账维护和口径统一交给专人，避免确认与记录混在一起导致无法追溯。
预订提交后资源负责人迟迟不确认，怎么处理？
先约定确认时限，并在台账中记录提出时间与确认时间，把超时申请纳入月度检查。超时通常说明评估环节缺少可用信息，资源负责人难以快速判断余量。可以让资源负责人直接查看台账中目标人员在申请时间段内的已确认投入，减少来回询问。对临近执行仍未确认的申请，由项目负责人升级到双方共同上级按优先级裁定。
预订和实际投入对不上，应该改台账还是改计划？
两者都要动，但顺序是先记录偏差再调整。实际投入偏离确认值时，由项目负责人提交变更请求，写明原值、新值和原因，资源负责人确认后更新台账，同时同步到排期或工时计划，保证两处一致。直接覆盖原记录会让偏差分析失去依据，也无法还原当时的决策过程。
项目结束后忘记释放预订会有什么影响？
台账上的占用会持续累积，下一次评估时目标人员的可用量被低估，新项目申请容易被误判为冲突，资源负责人也可能因此做出错误的调配决定。建议在项目结束或阶段完成的检查项中加入释放动作，由资源管理员定期核对项目结束时间与释放时间之差，清理长期挂账的占用。
预订粒度选人员级还是角色级，能中途切换吗？
可以分层使用：季度规划用角色或小组级，迭代内执行用人员级，但同一时间窗口内应保持一种主口径，避免同一份台账里两种粒度混用导致无法汇总比较。切换粒度时，对已有记录做一次口径转换并注明转换规则，而不是新旧记录并存各说各话。
