研发资源分配要先把“人”当作可预订的投入单位管理起来：以项目优先级和阶段人力需求为输入，确定每个人的投入比例与起止时间，形成可维护的资源分配表，再按周滚动确认跨项目排期。本文按“统一口径—五步流程—表格设计—角色分工—兼职与外包安排—示例—完成检查”的顺序展开，帮助团队把分配从口头协调变成一套每周运转的机制。
要点总览（TL;DR）
- 先统一计量口径：以投入比例（FTE）为主口径记录持续投入，人天用于短期专项，人数只做汇总展示，并同时保留计划投入与实际投入两个字段。
- 按五步流程执行：收集阶段人力需求、按优先级初步匹配、确定投入比例形成预订、项目负责人与人员本人双方确认、按周滚动更新并记录变更原因。
- 资源分配表的关键字段包括人员、角色/技能、所属项目、投入比例、起止时间、来源类型、确认状态，变更采用追加记录而非覆盖原值。
- 项目负责人提需求、资源负责人拍板、人员本人确认、PMO或指定维护人维护表格，四个角色缺一不可。
- 兼职共享人员约定固定时段与占比上限，外包约定投入周期、交付节点与对接人，并在表中单独标注来源类型。
先定分配口径：按人、按比例还是按人天
资源分配最常见的失败原因，是各部门用不同单位描述同一件事：项目负责人说“这个月需要两名后端”，研发经理理解成“两个人全职投入”，实际到岗却是每人一半时间。跨项目比较和预订只有在计量单位统一后才成立，因此动手做表之前，先确定用哪种口径记录投入。
研发人员投入通常有三种计量方式。人数最直观，适合向管理层汇报“某项目占用几个人”，但无法表达兼职和共享情况。投入比例（FTE，全职当量）把一个人满负荷记为1.0，投入一半记为0.5，适合描述持续数周以上的稳定投入，也便于把多个项目的占用加总校验。人天或人时适合短期专项、临时支援和按交付节点结算的场景，颗粒度细，但维护成本高，不适合作为长期排期的唯一单位。
| 计量单位 | 适用场景 | 记录字段 | 注意事项 |
|---|---|---|---|
| 人数 | 向管理层汇报总量、粗略估算团队规模 | 项目、角色、人数 | 不能反映兼职与共享，不能直接用于冲突判断 |
| 投入比例（FTE） | 持续数周以上的稳定投入、跨项目排期 | 人员、项目、投入比例、起止时间 | 同一人员同一时段的比例合计应有上限约定 |
| 人天/人时 | 短期专项、临时支援、按节点结算 | 人员、项目、人天数、使用日期 | 颗粒度细，需明确折算规则，避免与比例混用 |
实际操作中，建议以投入比例作为主口径，人天作为短期补充，人数只用于汇总展示。无论选哪种口径，分配表都应同时保留“计划投入”和“实际投入”两个字段：计划投入来自预订，实际投入来自人员反馈或工时记录，两者之间的偏差才是复盘和调整的依据。只记计划不记实际，分配表会逐渐变成一张无人核对的愿望清单。
核心操作步骤：从需求收集到资源预订落地
资源分配可以拆成五个动作，每个动作都有明确的输入、输出和完成标志。流程按周或按双周滚动执行，而不是一次性排完整年。
第一步：收集各项目的阶段人力需求
输入是项目计划、里程碑和所需角色。项目负责人按阶段列出未来一段时间需要哪些角色、需要多少投入、从什么时候开始。需求要写到角色和技能层面，例如“后端开发，熟悉支付链路，投入0.5”，而不是笼统的“需要研发支持”。输出是一份按项目归集的需求清单，完成标志是每个在研项目都提交了本周期需求，且需求能对应到具体阶段。
第二步：按优先级排序并做初步匹配
输入是需求清单、人员技能和可用容量。资源负责人或研发经理依据项目优先级对需求排序，再对照现有人员的技能与剩余容量做初步匹配。这一步的产出是“哪些需求可以满足、哪些存在缺口、哪些需要调整时间”的判断，完成标志是每个需求都有初步归属或明确的缺口说明。
第三步：确定投入比例并形成资源预订记录
在初步匹配基础上，与项目负责人确认每项投入的比例和起止时间，写入资源分配表。输出是一张包含人员、项目、投入比例、时间段的预订记录。完成标志是分配表中不再有“待定”的投入项，或待定项已标注原因和预计确认时间。
第四步：与项目负责人和人员本人确认预订
预订需要双方确认才生效：项目负责人确认投入满足交付需要，人员本人确认时间安排可执行。输出是确认状态字段被更新为“已确认”。完成标志是本周新增和变更的预订全部完成确认，未确认项进入下周跟进清单。
第五步：按周滚动更新，记录变更原因
每周固定时间核对计划投入与实际投入，处理新增需求、人员请假、项目延期等变化，更新分配表并记录调整原因、调整时间和确认人。完成标志是本周分配表已更新、变更记录完整，且下一周期的预订已初步确认。
资源分配表怎么设计：字段与填写规则
资源分配表是整套机制的核心产物，设计目标是让任何人在需要时都能查到“谁在什么时间、以多少投入、参与哪个项目、由谁确认”。字段不必多，但关键字段必须齐全且规则清晰。
| 字段 | 必填 | 填写规则 |
|---|---|---|
| 人员 | 是 | 填写真实姓名，一人一行或一人多行（按项目拆分） |
| 角色/技能 | 是 | 写项目中的实际角色，必要时补充关键技能，便于匹配 |
| 所属项目 | 是 | 一个预订对应一个项目；跨项目支援需分行记录 |
| 投入比例 | 是 | 以FTE记录，0.5表示投入一半；短期专项可另附人天 |
| 起止时间 | 是 | 精确到日期，避免只写“本月”“下阶段” |
| 来源类型 | 是 | 专职、兼职共享、外包三选一，便于分类统计 |
| 确认状态 | 是 | 待确认、已确认、已变更；变更后需重新确认 |
| 计划投入 | 是 | 预订时填入，作为后续偏差对比的基准 |
| 实际投入 | 选填 | 按周或按双周由人员本人反馈后填入 |
| 调整时间、调整原因、确认人 | 变更时必填 | 每次修改预订都追加一条记录，不覆盖原值 |
填写规则中最容易出问题的是同一人员同一时段的投入比例合计。建议在表中设置校验列或汇总视图，把一个人在同一时间段内所有项目的投入比例加总，超过约定上限（例如专职人员合计不超过1.0）时标红提示，由资源负责人判断是调整比例还是调整时间。变更记录采用追加方式而非直接改数，这样在复盘时能看清每次调整的来龙去脉，也便于回答“这个预订为什么从0.8降到0.5”。
角色与交付物：谁提需求、谁拍板、谁维护
分配表无人维护，通常是因为职责没有落到具体角色。资源分配涉及四类角色，各自有明确的交付物和交接时点。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目负责人 | 提出人力需求，对需求合理性负责 | 阶段人力需求清单（角色、投入、时间） | 每周确认会前提交 |
| 资源负责人/研发经理 | 做优先级判断与最终分配决策 | 优先级排序结果、分配决策与缺口说明 | 确认会上给出结论 |
| 人员本人 | 确认投入安排，反馈实际投入 | 预订确认、实际投入反馈 | 收到预订后确认，每周反馈实际 |
| PMO或指定维护人 | 维护分配表，组织每周确认 | 更新后的分配表、变更记录、待办清单 | 会后一个工作日内完成更新 |
分工的关键在于把“提需求”和“拍板”分开：项目负责人最了解交付需要，但容易高估所需投入；资源负责人掌握全局容量，负责在多个项目之间做取舍。人员本人的确认环节常被省略，结果是预订看起来完整、执行时却频繁冲突，因此确认状态字段必须由本人确认后才能置为“已确认”。维护人可以是PMO，也可以是研发经理指定的助理，但必须是固定的人，而不是“大家共同维护”。
当团队使用项目管理工具承载这套机制时，资源预订和投入比例可以直接记录在系统中，减少表格来回传递。ONES Resource 支持通过甘特视图进行项目资源规划与进度跟踪，并支持筛选与分组查看成员在不同项目的投入比重；ONES 资源和工时管理解决方案提供资源规划视图，可按业务优先级安排团队资源，并支持多维度查看项目和成员的资源投入情况。对于需要每周核对计划与实际投入的团队，这类视图可以作为确认会的共同依据，具体功能范围以实际使用的版本为准。
兼职共享人员与外包的投入安排
专职人员的分配相对简单，真正容易失控的是兼职共享人员和外包。前者被多个项目同时按满额预订，后者缺少明确的对接和交接约定，都会让分配表上的数字失去意义。
对兼职共享人员，做法是明确固定投入时段和占比上限。例如约定某位测试人员每周一、三、五投入A项目，周二、四投入B项目，合计不超过0.6，剩余时间保留给临时支援和事务性工作。固定时段比只写比例更可执行，因为比例无法回答“周三下午到底去哪个项目”。在分配表中，这类人员单独标注来源类型为“兼职共享”，便于统计其被占用的总比例。
对外包人员，需要约定投入周期、交付节点和对接人。投入周期说明外包从何时到何时参与、以什么节奏交付；交付节点与项目里程碑对齐；对接人负责日常沟通和验收，避免多头指挥。外包的投入记录同样进入分配表，来源类型标注为“外包”，实际投入可按交付节点或工时反馈。
共享人员的交接与信息同步要有固定动作：每周确认会上同步本周时段安排，人员变动或项目优先级调整时，由维护人当天更新分配表并通知相关项目负责人。来源类型字段的价值正在于此——按类型筛选后，可以快速看出兼职和外包占用了多少容量，为下一周期的分配决策提供依据。
示例：一个双项目共用三名研发的分配过程
以下为演示情景，用于说明填写过程，不代表真实项目数据。
某团队同时推进A项目（客户定制交付）和B项目（平台版本迭代），共有三名研发：小张（后端，专职）、小李（前端，专职）、小王（测试，同时支持两个项目，兼职共享）。本周期为四周。
需求收集阶段，A项目负责人提出：第1至3周需要后端0.5、前端0.5、测试0.3；B项目负责人提出：第1至4周需要后端0.5、前端0.5、测试0.3。优先级判断上，A项目有合同交付节点，排在前；B项目为内部迭代，可接受部分延后。
初步匹配发现：小张和小李的投入比例在两个项目各0.5，合计1.0，处于上限；小王的测试需求合计0.6，尚有余量。据此形成预订：小张第1至3周投入A项目0.5、第1至4周投入B项目0.5；小李同样分配；小王第1至4周投入A项目0.3、B项目0.3，来源类型标注为兼职共享。三项预订经项目负责人和小王本人确认后，状态置为“已确认”。
第二周确认时发现偏差：A项目第2周出现联调高峰，小张实际投入达到0.8，B项目相应延后。调整动作是：将小张第2周A项目投入改为0.8、B项目改为0.2，在变更记录中写明原因“联调高峰”、调整时间和确认人，并通知B项目负责人顺延对应任务。这次调整不覆盖原记录，而是追加一行，复盘时可以清楚看到偏差发生在哪一周、由什么引起。
完成检查：分配机制是否真正运转
机制是否落地，不看表格做得多漂亮，而看它是否每周被使用、被确认、被修正。可以按以下清单逐项核对：
- 分配表覆盖全部在研项目和参与人员，没有“表外人员”在项目间临时流动。
- 每项预订都有确认人和确认状态，待确认项有明确的跟进时间。
- 分配表按周更新，每次变更都记录了调整时间、原因和确认人。
- 计划投入与实际投入有偏差对比，偏差较大的项目或人员有对应的调整动作。
- 兼职共享人员和外包人员在表中有明确的来源类型标注和投入约定，包括固定时段、占比上限或交付节点。
- 同一人员同一时段的投入比例合计经过校验，超出上限的情况有处理结论。
- 每周确认会有固定参与人和固定输出，会后一个工作日内完成表格更新。
如果以上条目大部分可以勾选，说明资源分配已经从个人协调转变为可查、可确认、可调整的机制；若仍有条目长期空缺，优先补上确认状态和变更记录两项，它们决定了分配表能否在下一周期继续被信任和使用。
常见问题
团队规模很小，是否也需要做资源分配表？
小团队同样会遇到人员被多个事项同时占用的情况，只是复杂度低一些。可以简化表格字段，保留人员、项目、投入比例、起止时间和确认状态这几项，每周花十几分钟核对一次即可。判断是否需要正式表格的标准是：是否出现过“以为某人在做A，实际在做B”的情况。出现过，就值得把投入安排写下来并确认。
投入比例和工时记录应该以哪个为准？
两者用途不同。投入比例是预订，回答“计划让这个人投入多少”，在分配时确定；工时记录是实际发生，回答“这个人实际投入了多少”。复盘时看的是两者之间的偏差，而不是用其中一个替代另一个。如果团队已有工时登记习惯，可以把实际投入按周汇总后填入分配表，与计划投入并列对比；没有工时记录时，也可以由人员本人每周简要反馈实际投入情况。
项目优先级由谁定，出现争议怎么办？
优先级判断通常由资源负责人或研发经理牵头，依据交付节点、合同约束和业务价值做取舍，项目负责人提供需求合理性说明。出现争议时，把争议落到具体时段和具体人员上讨论，例如“第2周小张的0.3投入给A还是给B”，比笼统争论“哪个项目更重要”更容易形成结论。结论写入分配表并记录确认人，下一周期如需调整再走变更流程。
兼职共享人员的投入时段确定后，临时支援需求怎么处理？
建议在约定占比上限时预留一部分余量，例如合计不超过0.6，剩余时间用于临时支援和事务性工作。临时需求进入每周确认会统一处理，由资源负责人判断是否占用余量、是否调整固定时段，并当天更新分配表通知相关项目负责人。避免由需求方直接找人员本人协调，否则固定时段会逐渐失效。
用表格管理资源分配，和用项目管理工具承载有什么区别？
表格上手快、字段可自由设计，适合机制建立初期；工具的优势在于预订记录、投入比重和工时数据在同一处维护，减少多份表格来回传递和版本不一致。团队使用 ONES 时，资源预订和投入比例可以记录在系统中，ONES Resource 支持通过甘特视图进行项目资源规划与进度跟踪，并支持筛选与分组查看成员在不同项目的投入比重，可作为每周确认会的共同依据，具体功能范围以实际使用的版本为准。
