研发人员排期要解决的问题，是把已确认的任务落到具体的人和具体的周次，形成一份执行人认可、可以跟踪和调整的投入承诺。制定时先划定范围与周期，再盘点可用工时，把任务拆到可估算并标注技能要求，然后按优先级和依赖初排、与执行人确认，最后留出缓冲并设定复查节奏。下面按这八个环节展开，每一步都说明输入、做法和产出。
要点总览（TL;DR）
- 研发人员排期先定范围、周期与颗粒度，再把名义人力折算成按角色分组的可用人天，避免用虚高的总量做承诺。
- 任务拆到半天到三天、一人可独立完成，并标注技能要求与前置依赖，让分配有据可依。
- 初排按优先级和依赖排序、按技能匹配人员，逐人与执行人确认后才算当期承诺。
- 缓冲按历史估算偏差确定，固定复查加异常触发复查，变更记录内容、原因和影响范围。
- 用范围、工时、任务、人员、机制五类检查项核对，存在未拆解任务或未确认承诺时先返工。
排期前先定清范围、周期与颗粒度
排期最常见的返工来源，是范围没定就开工：一会儿补进别的项目，一会儿把季度目标塞进两周表。启动前先把三个前提写成一页说明，后续所有讨论都以此为边界。
覆盖哪些团队与项目
明确本次排期纳入的团队、项目及其优先级顺序。跨团队协作的任务，只把本团队承担的部分纳入，对方交付作为前置条件标注。范围说明中列出纳入项和明确排除项，排除项要写清由谁另行安排，避免出现无人认领的空白。
周期长度与滚动方式
周期长度与团队的交付节奏匹配：需求变化快、反馈周期短的团队适合两周一个周期；以版本交付为主、联调周期长的团队可以用四周。无论选哪种，都约定滚动方式，例如每周期结束前三天完成下一周期初排，未完成项按规则带入或退回待办，而不是默认顺延。
任务拆到何种颗粒度才可排
可排的颗粒度满足三条：一个人能独立完成；工作量在半天到三天之间；完成标准可以用一句话描述。超过三天的任务继续拆，小于半天的任务合并到同一工作项或作为子项处理。颗粒度标准写进范围说明，拆解时按同一把尺子执行。
本节产出：一份排期范围说明，包含团队与项目清单、周期长度与滚动规则、颗粒度标准与排除项。
盘点人员可用工时：把人力折算成可承诺的人天
名义人力和可承诺人力差距很大。一个五人团队按每人每周期十天计算是五十人天，扣除休假、会议、值班和技术支持后，实际可投入可能只有三十多人天。排期必须用后者，否则承诺从第一天起就是虚的。
从名义工时扣到可用工时
按周期逐项扣减：法定假日与已批准休假按实际天数扣；固定会议（站会、评审、周会）按人均每周小时数折算；值班、线上问题处理、技术支持等支持类事务，参考近几个周期的实际占比预留；培训、面试等临时事务单独列出。扣减后的结果才是可分配工时。
按角色或技能分组统计
把可用工时按角色或技能分组，例如后端、前端、测试、数据，因为任务需要匹配技能，总量够不代表结构够。分组后能直接看出哪类角色是瓶颈，为后续分配提供依据。
口径与更新频率
统一口径：一人天按多少小时计、会议折算是否含在扣减内、支持类事务按固定比例还是按历史均值，都要写清楚。可用工时表在每个排期周期启动时更新一次，周期内出现长假、人员变动或支持量突增时即时修订，并注明修订原因。
| 角色 | 人数 | 名义人天 | 休假与会议扣减 | 支持类预留 | 可用人天 |
|---|---|---|---|---|---|
| 后端 | 3 | 30 | 4 | 3 | 23 |
| 前端 | 2 | 20 | 3 | 2 | 15 |
| 测试 | 2 | 20 | 2 | 3 | 15 |
表中数字为演示情景，实际填写时以团队真实数据替换。本节产出：按角色分组的可用工时表，附口径说明与更新记录。
把任务拆到可估算并标注技能要求
任务清单是排期的原料。原料不合格，后面排序和分配都会失真。这一环节要做三件事：拆到可估算、标出技能要求、写清依赖。
拆解粒度与估算方式
按上一节确定的颗粒度拆解，每个任务给出估算人天。估算由执行该任务的人或熟悉该类工作的工程师给出，管理者负责校准口径而不是代替估算。估算时把联调、自测、文档等收尾工作计入任务本身，避免排期时只算编码时间。对不确定性高的任务，给出乐观与保守两个值，排期取保守值。
标注所需技能与熟练度
每个任务标注所需技能和熟练度要求，例如“熟悉该模块的后端工程师”“能独立完成前端组件开发”。熟练度分档不必过细，能区分“可独立完成”和“需指导完成”即可。标注的作用是让分配时有据可依，也让培养型安排显性化——把需要指导的任务交给新人时，要同时安排带教时间。
识别依赖与前置条件
列出任务之间的先后关系，以及外部前置条件，例如接口文档就绪、测试环境可用、第三方账号开通。依赖只记录影响开始时间的关键项，不追求画全图。前置条件未满足的任务，在排期表中标注为“待条件”，不占用当期工时承诺。
本节产出：带估算值、技能标签和依赖说明的任务清单。
初排与人员确认：按优先级和依赖落到人
有了可用工时和任务清单，就可以做初排。初排的目标不是排满，而是排出一份执行人认可、风险可见的计划。
按优先级与依赖确定先后顺序
先按业务优先级排序，再在优先级内部按依赖关系调整：被多个任务依赖的前置任务提前，依赖外部条件的任务排在其条件满足之后。排序结果形成一条时间线，明确每个任务的计划开始与结束周次。
按技能匹配与负载均衡分配人员
逐个任务匹配具备相应技能的人员，同时检查每人当期分配总量不超过其可用工时。分配时保留一定余量给临时插入的高优先级事项，具体比例在下一节说明。同一人承担多个任务时，确认切换成本可接受，避免一天内频繁上下文切换。
与执行人确认并记录承诺与风险
初排结果必须与执行人逐一确认，确认内容包括任务理解、估算是否认可、时间是否可行、依赖是否清楚。执行人提出的风险写入排期表的风险列，例如“依赖接口未定稿，可能延后两天”。确认后的排期表即为当期承诺，变更走记录流程。
| 任务 | 负责人 | 技能要求 | 估算人天 | 计划起止 | 依赖 | 风险 |
|---|---|---|---|---|---|---|
| 订单查询接口改造 | 后端A | 熟悉订单模块 | 3 | 第1周周一至周三 | 无 | — |
| 查询页前端联调 | 前端B | 可独立开发组件 | 2 | 第1周周四至周五 | 接口改造完成 | 接口延期则顺延 |
本节产出：人员排期表，字段包括任务、人员、起止时间、依赖与风险。
留缓冲与设定复查节奏
没有缓冲的排期等于把全部风险转嫁给执行人；没有复查节奏的排期，第一周之后就失去参考价值。两者要一起约定。
缓冲比例的确定依据
缓冲按团队历史数据确定：统计过去几个周期实际用时与估算的偏差，偏差稳定在百分之十左右就留百分之十到十五；需求变动频繁、外部依赖多的团队适当提高。缓冲可以集中放在周期末尾作为团队缓冲，也可以按任务预留，两种方式选一种并保持一致。缓冲不是可随意消耗的余量，动用时要记录原因。
复查频率与触发条件
固定复查放在每周固定时间，检查任务进度、剩余工时和风险变化。触发式复查用于异常情况：关键任务延期超过一天、人员临时缺勤、外部依赖未按期到位、插入高优先级需求。触发后由项目负责人组织小范围调整，不等到周会。
变更的记录与同步
排期变更记录三要素：变更内容、原因、影响范围。变更后同步给受影响的执行人和相关方，并更新排期表版本。周期结束时做一次简短复盘，把估算偏差和缓冲消耗情况带入下一周期。
本节产出：缓冲规则与复查节奏约定，附变更记录模板。
角色分工与各环节交付物
排期不是一个人的工作。把职责和交接物定清楚，能减少“以为对方在跟”的空档。
| 角色 | 主要职责 | 输入 | 输出 |
|---|---|---|---|
| 项目负责人 | 确定范围与周期，组织初排与复查，维护排期表 | 项目目标、需求优先级 | 范围说明、排期表、变更记录 |
| 技术负责人 | 校准拆解粒度与估算口径，识别技术依赖与风险 | 任务清单、技术方案 | 估算校准意见、依赖与风险清单 |
| 执行人 | 拆解并估算本人任务，确认承诺，报告进度与风险 | 任务背景、可用工时 | 估算值、确认记录、进度更新 |
| 资源管理者 | 提供可用工时，协调跨团队人员投入 | 人员名册、休假与支持安排 | 可用工时表、人员协调结论 |
确认与审批节点设两个：初排完成后由技术负责人校准、执行人确认，形成当期承诺；周期内重大变更（影响交付日期或跨团队协作）由项目负责人与资源管理者共同确认后生效。日常小调整由项目负责人记录即可。
一个两周排期的填写示例
以下为演示情景，团队与数据均为假设，用于说明填写方式。
背景与假设：某研发小组共五人，后端三人、前端两人，排期周期两周。本周期后端可用二十三人天、前端十五人天。周期内有一名后端工程师休假两天，已从工时中扣除。团队约定缓冲为百分之十五，放在周期末尾。
填写过程：任务清单共八项，按优先级排序后，前四项为本周期承诺，其余为待条件或下期候选。分配时后端A承担订单接口改造三天，后端B承担权限校验两天并支援接口联调一天，前端B承担查询页开发两天、联调两天。依赖关系在表中标注，接口改造完成是前端联调的前置条件。
| 任务 | 负责人 | 估算人天 | 计划起止 | 依赖 | 状态 |
|---|---|---|---|---|---|
| 订单查询接口改造 | 后端A | 3 | 第1周周一至周三 | 无 | 进行中 |
| 权限校验逻辑调整 | 后端B | 2 | 第1周周一至周二 | 无 | 进行中 |
| 查询页组件开发 | 前端B | 2 | 第1周周一至周二 | 无 | 进行中 |
| 查询页联调 | 前端B、后端A | 2 | 第1周周四至周五 | 接口改造完成 | 待开始 |
| 回归测试 | 测试C | 2 | 第2周周一至周二 | 联调完成 | 待开始 |
缓冲与复查处理：周期末尾预留约五人天作为团队缓冲，用于吸收联调延期和临时插入事项。每周三下午固定复查一次，重点看接口改造是否按期完成；若周三仍未完成，触发调整，把联调顺延并评估对回归测试的影响，变更记入记录表。周期结束复盘时，对比估算与实际用时，作为下期缓冲比例的参考。
排期完成检查清单
排期表填完后，用下面四类检查项逐条核对。全部通过才进入执行；出现阻断项先返工，不带着问题开工。
| 类别 | 检查项 | 通过标准与证据 | 阻断项 |
|---|---|---|---|
| 范围 | 团队、项目、周期、颗粒度标准是否写明 | 范围说明文档存在且相关方已知悉 | 范围未定或存在未归属项目 |
| 工时 | 可用工时是否按角色分组并扣除休假、会议、支持事务 | 可用工时表附口径说明与更新日期 | 直接使用名义人力排期 |
| 任务 | 任务是否拆到可估算粒度，是否标注技能与依赖 | 任务清单每项有估算值、技能标签、依赖说明 | 存在超过三天未拆解的任务 |
| 人员 | 每项任务是否落到具体人并经本人确认，负载是否在可用工时内 | 排期表有负责人与确认记录，无超配 | 存在未确认的承诺或明显超配 |
| 机制 | 缓冲规则与复查节奏是否约定并告知全员 | 缓冲比例有依据，复查时间与触发条件已同步 | 无缓冲或无复查安排 |
检查通过后，排期表进入执行状态。执行过程中，任务状态、工时消耗和人员分配需要持续更新，否则复查就失去依据。这类工作项与工时的记录、按人员查看投入分布，可以在ONES中承载：任务作为工作项关联负责人和计划时间，工时按人记录，排期表与变更记录作为文档随周期更新，让承诺、进度和调整留在同一处可查。
常见问题
团队第一次做人员排期，没有历史估算偏差数据，缓冲比例怎么定？
没有历史数据时，可以先按经验设一个初始值，例如百分之十五，并在前两三个周期记录每项任务的估算与实际用时。周期复盘时对比偏差，偏差持续偏大就上调，偏差很小再逐步下调。关键是让缓冲比例有记录可查，而不是每期凭感觉调整。需求变动频繁或外部依赖多的团队，初始值可以适当提高。
排期表已经和執行团队确认，周期中途插入高优先级需求怎么办？
插入需求时先判断它是否影响当期承诺。若影响，由项目负责人评估需要挪动哪些任务、是否动用缓冲，并与受影响的执行人确认调整后的时间。调整结果记入变更记录，写明变更内容、原因和影响范围，同步给相关方。若插入需求超出当期可用余量，应明确哪些原任务顺延到下期，避免用加班消化全部增量。
跨团队协作的任务，人员排期应该怎么处理？
只把本团队承担的部分纳入排期，对方团队的交付作为前置条件标注在依赖列。前置条件的计划到位时间要向对方确认，并写进排期表。若对方交付延期，按触发式复查处理，评估对本团队任务开始时间的影响。跨团队的资源协调由资源管理者负责，排期表本身不替对方做承诺。
执行人不认可估算或时间安排时，排期如何推进？
先区分分歧来源：是任务理解不一致、估算口径不同，还是可用工时被其他事务占用。任务理解问题由技术负责人澄清范围与完成标准；估算口径问题回到统一的估算规则上校准；工时问题则核对可用工时表是否漏扣了支持类事务。分歧未解决前不把该任务写成确定承诺，可以标注为待定并约定解决时间。
两周周期和四周周期，复查节奏需要区别设置吗？
需要。两周周期通常每周固定复查一次，并在周期中段重点检查关键路径任务；四周周期可以在每周固定复查之外，增加一次中段整体复核，检查前半程估算偏差是否影响后半程安排。两种周期都应保留异常触发复查，例如关键任务延期超过一天或人员临时缺勤，不必等到固定复查时间。
