客户交付时间与研发容量冲突，常见原因是双方口径不同：客户看的是验收日期，研发看的是可用人天和技能结构。本文给出一套排期方法：先把交付时间拆成可承诺的节点，再量化真实容量，用“承诺—弹性—待定”三档完成匹配，并说明角色分工、取舍示例和按周复核机制。
要点总览（TL;DR）
- 冲突多数来自口径不一致：客户看验收日期，研发看可用人天和技能结构，先把两者放到同一张表上再谈取舍。
- 排期分三步：把客户交付时间拆成可独立承诺的里程碑与验收节点，按可用人天和技能结构量化容量，再用承诺、弹性、待定三档完成匹配。
- 客户对接人确认交付时间，产品负责人拆范围定优先级，研发负责人核算容量，项目经理维护排期表，对外承诺须经审批人确认。
- 范围无法全部满足时优先保障硬约束和验收必选项，对依赖有风险的部分给出主方案与备选方案，容量确实不足的部分与客户重新约定时间。
- 排期后按周复核容量占用与节点偏差，出现承诺档延期超缓冲、关键人员变动、外部依赖延期或范围变更时启动重排期。
冲突的本质：把交付时间与容量放到同一张表上
排期冲突的核心判断是：客户要求的交付时间与研发容量并非天然对立，多数冲突来自两边没有使用同一套计量口径。客户说“月底必须上线”，指的是验收通过的时间；研发说“做不完”，指的是当前可用人天不足以完成全部需求。把这两个口径放到同一张表上，冲突才会从模糊的“时间紧”变成可计算、可取舍的差距。
排期的基本思路分三步：拆时间、量容量、做匹配。三步的输入、动作和输出如下。
第一步：把客户交付时间拆成里程碑与验收节点
输入是客户合同、订单或书面确认中的交付要求。动作是把一个总日期拆成若干可独立承诺的节点，例如需求确认完成、方案评审通过、首批功能可试用、全量功能交付、客户验收通过。每个节点写明交付物和判定标准。输出是一张交付节点表，每个节点都有日期、交付物和验收方式。完成标志是客户对这些节点书面确认，双方对“什么时候交付什么”没有歧义。
拆节点时要注意区分硬约束和软约束。合同约定的验收日期通常是硬约束；内部演示、培训安排等时间可以协商。把硬约束单独标出，后续取舍时优先保障。
第二步：按可用人天、技能与在途需求量化研发容量
输入是团队人员、排班日历、在途需求清单和历史投入数据。动作分三层核算：
- 名义人天：排期内团队总人数乘以工作日数。
- 可用人天：扣除休假、培训、公共事务、线上支持等非项目投入，再扣除在途需求已占用的部分，剩下的才是可分配给新交付的时间。
- 技能结构：把可用人天按前端、后端、测试、特定领域经验等维度拆分，避免出现总人天够、关键角色不够的情况。
输出是一张容量表，按技能维度列出排期内每个时间段可投入的人天。完成标志是容量数字能对应到具体的人和具体的时间段，而不是一个笼统的总量。
第三步：用三档排期完成匹配
把交付节点与容量表逐项比对，将需求分入三档：
| 档位 | 划分规则 | 资源处理 | 对客户的表达 |
|---|---|---|---|
| 承诺档 | 容量可覆盖、技能匹配、依赖已就绪的需求 | 锁定资源，排期内不随意抽调 | 明确承诺交付节点和交付物 |
| 弹性档 | 容量存在缺口，但通过裁剪范围、分批交付或调整内部优先级可以满足 | 预留缓冲，明确触发条件 | 给出主方案和备选交付范围 |
| 待定档 | 容量确实不足，或关键依赖未就绪 | 不占用承诺资源 | 与客户重新约定时间或范围 |
三档划分的完成标志是：每条需求都有档位、负责人、交付节点和容量占用记录。排期结论落到需求条目上，后续才能按周核对偏差。对于需求明确、交付周期固定的客户项目，可以用项目制方式管理，围绕里程碑和交付物组织排期；持续演进的产品需求则适合按产品制管理，聚焦路线图与迭代节奏。ONES 支持项目制与产品制并行管理，排期结论可以落到统一的需求池中，业务团队可随时跟踪需求和缺陷处理进度，便于在冲突场景下保持对客户的透明沟通。
排期中的角色分工与交付物
排期不是某一个人的判断，而是几个角色各出一份输入、共同形成一个结论。分工不清时，最常见的后果是客户时间没人正式确认、容量数字没人负责、承诺随口给出。以下按角色说明职责和交付物。
| 角色 | 主要职责 | 关键交付物 |
|---|---|---|
| 客户对接人（销售/客户经理/交付经理） | 收集并确认客户交付时间，区分硬约束与可协商时间，传递客户验收标准 | 客户交付节点确认单、硬约束清单 |
| 产品负责人 | 拆解需求范围，确定优先级，提出范围裁剪和分批交付方案 | 需求清单及优先级、分批交付方案 |
| 研发负责人/技术负责人 | 核算可用人天与技能结构，评估技术依赖和风险，给出容量结论 | 容量核算表、技术风险清单 |
| 项目经理/排期负责人 | 组织排期会议，汇总三档分类，维护排期表，跟踪偏差 | 三档排期表、周度偏差报告 |
| 承诺审批人（业务负责人或交付负责人） | 审批对外承诺，裁定承诺档与弹性档的边界，处理跨项目资源冲突 | 承诺审批记录、资源冲突裁定结论 |
分工落地时有两条规则值得明确。第一，客户交付时间必须由客户对接人以书面形式确认，口头转述的时间不进入排期表。第二，对外承诺必须经过审批人确认后才能发出，研发负责人给出的容量结论是承诺审批的必要输入。这两条规则把“谁收集、谁核算、谁拍板”分开，避免排期结论在执行中被随意推翻。
各角色的交付物最终汇入同一份排期表：需求条目、档位、负责人、交付节点、容量占用、依赖和风险。这份表既是内部执行依据，也是与客户沟通的底稿。
一个冲突排期的示例
以下为演示情景，用于说明方法如何落地，不代表真实项目数据。
某客户要求 6 月 30 日前完成一套订单管理功能的验收。客户对接人确认该日期为合同硬约束，验收标准包括订单创建、审批流、对账报表三项功能可用。产品负责人拆出 12 条需求，研发负责人核算后发现：排期内团队可用人天为 180 人天，其中后端可用 70 人天、前端 55 人天、测试 40 人天、特定领域经验人员仅 15 人天；在途需求已占用约 60 人天。按全部 12 条需求估算需要约 210 人天，且审批流模块依赖外部接口联调，存在两周的不确定期。
差距呈现清楚后，取舍按以下顺序进行：
- 先保硬约束：订单创建和对账报表是验收必选项，进入承诺档，锁定对应前后端和测试资源。
- 再处理有依赖风险的部分：审批流拆成两批，基础审批流进入弹性档，主方案在 6 月 20 日前可试用，备选方案是复杂审批分支延至验收后两周交付，并提前与客户确认验收范围是否接受。
- 最后处理容量确实不足的部分：报表的定制导出等三条增强需求进入待定档，与客户另行约定时间。
排期结果是：承诺档 7 条需求，对应 6 月 30 日验收；弹性档 2 条需求，带主方案和备选方案；待定档 3 条需求，给出重新约定的时间窗口。与客户沟通的结论以书面形式发出，内容包括验收范围内的功能清单、分批交付的时间点、待定需求的后续安排，以及变更时的通知方式。客户确认后，这份结论成为后续跟踪的基准。
这个示例可迁移的要点是：先量化差距再谈取舍，取舍时优先保障硬约束和验收必选项，对存在依赖风险的部分给出备选方案而不是简单承诺或简单拒绝。
排期后的跟踪与完成检查
排期表发出后，执行偏差会持续出现，跟踪机制的作用是让偏差在影响客户之前被发现。建议以周为单位复核三项内容：各需求的实际投入与计划容量占用的偏差、交付节点的完成情况、依赖和风险状态的变化。复核的输出是一份周度偏差记录，写明偏差条目、原因和拟采取的动作。
偏差触发重排期的条件
并非所有偏差都需要重排。出现以下情况时，应启动重排期并与客户沟通：承诺档需求的预计完成时间晚于节点超过约定缓冲；关键角色人员发生不可替代的变动；外部依赖延期导致弹性档的主方案不可行；客户提出范围变更且影响承诺档资源。重排期时沿用三档分类重新匹配，而不是在原表上简单顺延日期。
排期完成检查清单
- 每条需求都有档位、负责人、交付节点和容量占用记录。
- 客户交付节点已经客户书面确认，硬约束单独标识。
- 容量核算包含可用人天和技能结构两个维度，并扣除了在途需求占用。
- 弹性档需求都有主方案和备选方案，触发条件写明。
- 待定档需求已与客户约定后续沟通时间。
- 对外承诺经过审批人确认，审批记录可查。
- 周度偏差记录连续留存，重排期有对应的沟通记录。
需要留存的证据包括：客户交付节点确认单、容量核算表、三档排期表、承诺审批记录、周度偏差记录和重排期沟通记录。这些材料既支撑内部复盘，也能在客户对交付时间提出异议时说明排期依据。
排期结论落到需求条目后，执行期的跟踪需要工具承载。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务团队可随时跟踪需求和缺陷处理进度；在采用 Scrum 的团队中，产品负责人可按优先级将需求规划至对应迭代，团队借助敏捷看板和燃尽图对齐进度与风险。这些能力适合承接本文的排期表与周度复核动作，具体功能范围以实际开通模块和版本为准。
常见问题
客户交付时间本身可以协商，还需要走三档排期吗？
可以先走范围与时间的联合谈判，再决定是否启用三档分类。如果客户对验收日期没有合同级硬约束，谈判空间通常更大，此时把可调整的时间窗口、可裁剪的范围和分批交付方案一起摆出来，往往能直接达成一致。
当谈判后仍存在部分需求无法在客户期望时间内完成，再用承诺、弹性、待定三档把剩余差距固定下来，避免口头约定在执行中反复变化。
容量核算时，在途需求占用的时间怎么估算才不至于失真？
建议以历史投入数据为基础，按需求条目估算剩余工作量，而不是按人数乘以剩余天数倒推。对已经进入开发或测试的在途需求，取团队近几个周期同类工作的实际投入作为参考；对尚未开始的需求，按技能维度分别估算。
核算结果保留一个明确的缓冲比例，并在排期表中写明缓冲的用途和动用条件。缓冲被提前消耗时，应视为偏差信号进入周度复核，而不是临时压缩其他承诺档需求的资源。
弹性档的主方案和备选方案，应该什么时候告诉客户？
建议在排期结论对外发出时一并告知，而不是等主方案出现风险后再提。客户提前知道备选交付范围和时间点，才能在自身业务安排上做预案；等到临近节点才说明，容易把交付问题变成信任问题。
告知内容至少包括：主方案覆盖的功能与时间、备选方案覆盖的功能与时间、触发切换到备选方案的条件，以及切换时的通知方式。客户确认后，这份内容与承诺档一起作为后续跟踪的基准。
重排期时，原排期表上的日期可以直接顺延吗？
不建议直接顺延。直接顺延会把原来的容量假设原样带到新周期，而偏差往往说明容量假设或依赖判断已经失效。重排期应重新核算可用人天与技能结构，重新比对交付节点，再按三档分类重新匹配。
重排期后需要同步更新对客户的表达：哪些需求仍在承诺档、哪些转入弹性档或待定档、新的时间窗口是什么。重排期的沟通记录与新的排期表一并留存，作为后续复盘的依据。
排期结论落到需求条目后，用什么方式承载跟踪比较合适？
关键是让需求条目、档位、负责人、交付节点和容量占用在同一处可查，并能按周导出偏差。ONES 通过统一的业务需求池、产品需求池与工单系统联动业务反馈与产品开发，业务团队可随时跟踪需求和缺陷处理进度；采用 Scrum 的团队中，产品负责人可按优先级将需求规划至对应迭代，团队借助敏捷看板和燃尽图对齐进度与风险。
具体功能范围以实际开通模块和版本为准。若团队规模较小或交付项目数量有限，用共享的排期表加周度例会也能满足复核要求，工具选择应服从已有的协作习惯。
