任务截止日期由工作量估算、可用时间、依赖关系和风险缓冲共同推导，再经执行人确认形成承诺。本文按“先算净工期、再排最早开始时间、加缓冲、落库确认”的顺序给出可执行步骤，并说明谁负责估算与确认、如何用带依赖的示例推算日期，以及承诺前应逐项检查什么。
要点总览（TL;DR）
- 任务截止日期由四类输入推导：净工期估算、可用时间、依赖关系与风险缓冲，最后经执行人确认形成承诺。
- 净工期按任务熟悉程度选择历史类比、三点估算或专家判断，并记录估算依据，便于偏差出现后复盘校准。
- 依赖关系决定最早可开始时间，截止日期等于最早可开始时间加净工期再加缓冲；关键路径上的任务应优先跟踪。
- 分工上执行人负责估算与承诺确认，技术负责人负责依赖与顺序，排期协调人负责缓冲与整体校准，日期变更需记录并通知下游。
- 日期落库前用五项检查核对：估算有依据、依赖已记录、缓冲覆盖风险、执行人明确确认、变更有触发条件。
截止日期的四个输入：先算净工期再定日期
截止日期不是从期望日期倒推出来的，而是从任务本身推导出来的。推导顺序固定为四步：估算净工期、核算可用时间、按依赖推算最早可开始时间、叠加风险缓冲。四类输入缺一项，日期就缺少依据。
输入一：净工期估算
净工期指任务在无人打扰、依赖齐备的情况下需要的工作时间。常用三种方法，按任务熟悉程度选择：
- 历史类比：找同类任务的实际耗时作为参照。适用于团队做过类似工作、有记录可查的情况。使用时注意参照任务的范围和复杂度是否接近，必要时按比例调整。
- 三点估算：分别给出乐观值、最可能值、悲观值，按（乐观＋4×最可能＋悲观）÷6 计算期望工期。适用于不确定性较高、又需要给出量化区间的任务。
- 专家判断：由做过同类工作的资深人员给出区间估计。适用于缺少历史数据的新类型任务。使用时要求给出区间而非单点，并说明区间上下限对应的假设。
估算结果应记录方法和依据，例如“参照上个季度同类接口改造实际耗时2.5人日，本次范围相近，估2.5人日”。有依据的估算在偏差出现时才能复盘校准。
输入二：可用时间
净工期是工作量，可用时间是执行人真正能投入的时间，两者不能直接等同。核算可用时间要扣除会议、休假、培训以及其他并行任务占用。例如执行人未来两周有8个工作日，扣除会议和已排任务后实际可投入约5个工作日，那么净工期超过5人日的任务就无法在这两周内完成。
输入三：依赖关系
依赖关系决定任务最早什么时候可以开始，不直接决定截止日期。前置任务未完成，后续任务即使人已空闲也无法启动。因此排期时先按依赖顺序排出每项任务的最早可开始时间，再用“最早可开始时间＋净工期”得到最早可完成时间。依赖链上耗时最长的一条路径即关键路径，关键路径上的任务延迟会直接推迟整体交付，应优先识别并重点跟踪。
输入四：风险缓冲
缓冲用于吸收估算偏差和依赖波动，按风险高低设置：依赖多、技术不确定性高、执行人同时承担多项任务的工作项，缓冲比例应更高；流程成熟、历史数据充分的任务可以少留。缓冲要明确归属，是加在单个任务上还是加在阶段末尾，避免同一份风险在任务级和阶段级重复叠加。一个常见做法是任务级只留小幅缓冲，阶段级统一留一段集中缓冲，由排期协调人管理。
| 步骤 | 输入 | 输出 |
|---|---|---|
| 1. 估算净工期 | 历史数据、三点值或专家区间 | 每项任务的净工期及估算依据 |
| 2. 核算可用时间 | 工作日历、会议、休假、并行任务 | 执行人可投入的工作日数 |
| 3. 排依赖顺序 | 任务间前置关系 | 每项任务的最早可开始时间、关键路径 |
| 4. 叠加缓冲 | 风险等级、缓冲归属规则 | 建议截止日期 |
操作步骤：从工作项拆解到日期落库
以下五步把上面的推导变成可执行动作。每一步都说明输入、动作、输出和完成标志，做完一步再进入下一步。
第一步：拆解工作项到可估算粒度
输入：需求说明或任务描述。动作：把任务拆成单个工作项，建议每项不超过3人日；超过的继续拆分，直到每项都能被一个人清楚估算。输出：工作项清单，每项有明确的范围和验收标准。完成标志：清单中不存在“完成开发”这类无法判断结束的笼统条目，每项都能说清做完是什么样。
第二步：逐项估算净工期并记录依据
输入：工作项清单、历史数据或专家意见。动作：对每项选择历史类比、三点估算或专家判断，给出工期数值并写明依据和假设。输出：每项工作项的净工期与估算说明。完成标志：任意一项被问“为什么是这个数”时，能指出参照对象或计算过程。
第三步：按依赖排出顺序，识别关键路径
输入：工作项清单及其前置关系。动作：标出每项的前置任务，按依赖排出执行顺序，计算每项的最早可开始时间，找出耗时最长的依赖链。输出：带依赖关系的排期顺序和关键路径标注。完成标志：每项工作项都能回答“它在等谁完成”，关键路径上的任务已被单独标出。
第四步：加缓冲后确定建议截止日期
输入：最早可开始时间、净工期、风险等级。动作：按“最早可开始时间＋净工期＋缓冲”计算建议截止日期；缓冲按任务风险设置并明确归属，避免重复叠加。输出：每项工作项的建议截止日期。完成标志：每个日期都能拆解为开始时间、工期和缓冲三部分。
第五步：与执行人确认并写入工作项
输入：建议截止日期、执行人。动作：把日期、估算依据、依赖关系和验收标准交给执行人确认；执行人认可后写入工作项的截止日期字段，依赖关系同步记录在系统中。输出：已确认并落库的截止日期。完成标志：执行人明确表示可以承诺，工作项上能看到日期、依赖和验收标准三项信息。
在ONES中，这些信息可以承载在工作项上：截止日期作为工作项字段记录，依赖关系通过工作项之间的关联体现，估算依据和验收标准写在描述或自定义字段中。日期调整时，变更记录保留在工作项历史里，便于后续复盘估算偏差。具体字段名称和配置方式以团队实际使用的ONES版本为准。
角色分工与交付物：谁估算、谁确认、谁维护
截止日期由单方拍定，往往在执行阶段暴露问题。合理的分工是：估算由最接近工作的人做，顺序由懂技术依赖的人排，缓冲由看整体的人定，承诺由执行人给出。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 执行人 | 拆解自己负责的工作项，给出净工期估算和依据，确认是否接受截止日期 | 工作项估算说明、承诺确认 |
| 任务负责人或技术负责人 | 识别任务间依赖，安排执行顺序，标出关键路径 | 依赖关系清单、排期顺序 |
| 项目经理或排期协调人 | 设置缓冲规则与归属，汇总各项日期做整体校准，处理冲突 | 缓冲设置说明、整体排期表 |
| 日期变更发起人 | 在依赖变化或偏差超出缓冲时提出调整，记录原因并通知相关方 | 变更记录、通知记录 |
日期变更的责任需要提前约定：谁发现偏差谁发起，变更原因、影响范围和新的截止日期都要记录，并通知下游依赖方。变更不是失败，缺少记录和通知才是问题——下游任务按旧日期排期，会在无人察觉的情况下整体后移。
示例：一个带依赖的任务如何定出截止日期
以下为演示情景，用于说明推导过程，数字为示意值。
任务背景：为订单模块增加批量导出功能，涉及后端接口、前端页面和测试三个环节，执行人分别为后端工程师A、前端工程师B、测试工程师C。
拆解与估算
- 后端导出接口：A估算2人日（参照上个季度同类导出接口实际耗时，范围相近）。
- 前端导出页面与进度提示：B估算1.5人日（三点估算：乐观1人日、最可能1.5人日、悲观3人日，加权约1.6人日，取1.5人日）。
- 联调与测试：C估算2人日（专家判断，含回归测试）。
依赖与最早可开始时间
依赖关系为：前端页面依赖后端接口的字段定义确定后才能定稿；联调测试依赖前后端都完成。假设三项任务都从周一（第1个工作日）具备启动条件：后端接口第1天开始，第2天结束；前端页面在第1天可先做静态部分，字段定稿后完成剩余工作，第3天结束；联调测试最早第4天开始，第5天结束。关键路径为“后端接口→联调测试”，总净工期5个工作日。
缓冲与最终日期
该任务依赖外部字段确认，且C同时承担其他项目测试，风险中等，在阶段末尾统一加1个工作日缓冲。建议截止日期为第6个工作日结束。缓冲归属阶段级，不在单个任务上重复加。
确认与落库
排期协调人把建议日期分别发给A、B、C确认。C提出第4天有其他项目的测试窗口冲突，经协调将联调测试调整为第5天开始，截止日期顺延至第7个工作日。三人确认后，日期写入各自工作项的截止日期字段，依赖关系记录为“前端页面依赖后端接口”“联调测试依赖前端页面与后端接口”，验收标准写明导出字段范围、单次导出条数上限和进度提示要求。变更原因同步记录在工作项历史中。
完成检查：截止日期是否可承诺
日期写入工作项之前，用下面五项逐条核对。任何一项不通过，日期都应退回调整，而不是先写进去再说。
| 检查项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 估算是否有依据 | 每项工作项能指出历史参照、三点计算或专家区间及假设 | 补充依据或重新估算 |
| 依赖是否已识别并记录 | 每项工作项能说明在等谁，依赖关系已写入系统 | 补全依赖清单后再排日期 |
| 缓冲是否覆盖主要风险 | 高风险项有对应缓冲，缓冲归属明确且未重复叠加 | 调整缓冲比例或归属 |
| 执行人是否明确确认 | 执行人对日期有明确承诺，而非默认接受 | 与执行人重新沟通可用时间 |
| 变更是否有触发条件与处理方式 | 约定了偏差超出缓冲时的发起人、记录方式和通知对象 | 补充变更规则后再落库 |
五项全部通过，截止日期才具备承诺的基础。此后依赖变化或估算偏差超出缓冲时，按约定的触发条件重新校准，记录变更原因并通知下游依赖方，让日期始终反映当前可兑现的承诺。
常见问题
任务拆到多细才适合估算截止日期？
建议拆到单个工作项不超过3人日的粒度。超过这个量级的工作项，估算误差会明显放大，执行过程中也难以判断进度是否正常。拆解完成的标志是每项都能说清做完是什么样，避免出现“完成开发”这类无法判断结束的笼统条目。如果一项任务涉及多个角色或多个交付物，按角色或交付物继续拆分，再分别估算。
执行人不认可建议截止日期时怎么处理？
先区分不认可的原因。如果是可用时间不足，核对工作日历、会议、休假和并行任务占用，看是否漏算了实际可投入时间；如果是估算依据不足，补充历史参照或专家区间后重新估算；如果是依赖关系未理清，回到依赖清单确认前置任务。调整后仍无法达成一致时，由排期协调人在缓冲和整体顺序上做取舍，并把调整原因记录下来。执行人明确确认之前，日期不写入工作项。
依赖关系在执行中发生变化，截止日期要不要立刻改？
不必每次变化都立即调整，先判断影响是否超出缓冲。前置任务延迟但仍在缓冲范围内，可以保持原日期并持续跟踪；延迟超出缓冲、或关键路径上的任务发生变动，就应触发重新校准。重新校准时更新受影响工作项的截止日期，记录变更原因和影响范围，并通知下游依赖方。下游任务按旧日期排期却无人知晓变化，是日期失效最常见的原因。
缓冲加在单个任务上还是加在阶段末尾更好？
两种方式各有适用条件。任务级缓冲适合风险集中在个别工作项的情况，比如某项任务依赖外部团队交付；阶段级缓冲适合风险分散、需要统一管理的场景，由排期协调人集中掌握。常见做法是任务级只留小幅缓冲，阶段末尾统一留一段集中缓冲，避免同一份风险在两级重复叠加。无论选哪种，缓冲归属都要提前写明，让每个人知道哪部分时间可以动用。
估算偏差反复出现，怎么校准？
把每次实际耗时与估算值对照记录，按任务类型归类，看偏差集中在哪类工作上。偏差稳定的类型可以调整估算系数，偏差波动大的类型说明不确定性高，应提高缓冲比例或进一步拆分工作项。复盘时关注估算依据是否成立，比如参照的历史任务范围是否真的相近，而不只是比较数字大小。持续记录几轮之后，估算区间会逐步收敛。
