工作量估算要落到可执行的动作上：先把估算对象限定为人的投入量，再拆出可判断的任务清单，由执行者给出乐观、最可能、悲观三档取值，汇总成区间并记录假设，最后用实际投入回填校准。本文按六个步骤说明每一步的输入、动作、输出和完成标志，并给出三点估算算例、角色分工表、估算记录字段和完成检查清单。
要点总览（TL;DR）
- 估算前先锁定三项口径：对象是人的投入量（人时/人日）、单位与取整规则、任务拆解颗粒度，否则各人报出的数字无法汇总比较。
- 按六步执行：建任务清单、定方法与单位、执行者独立出三档、汇总为区间、交叉校验、记录假设并设复盘时点，每步都有输入、动作、输出和完成标志。
- 三点估算用期望值=(乐观+4×最可能+悲观)/6、标准差=(悲观-乐观)/6 计算，结果以区间呈现，承诺时向上取整并写明缓冲覆盖的不确定项。
- 执行者先独立出数、技术负责人校验、项目经理汇总记录、需求方确认范围，顺序不能颠倒，范围变更时按变更部分重走流程。
- 估算记录必须包含任务、单位、三档取值、期望值、假设、依赖、估算人、日期；无假设记录、单点承诺、执行者未参与属于阻断项。
工作量估算先定口径：估什么、用什么单位、估到多细
估算开始前先锁定三项口径，否则后面各人报出的数字无法汇总，也无法与历史数据比较。口径说明建议写成一页纸，在估算启动会上确认，后续所有取值都按这一页执行。
估算对象：人的投入量
工作量估算的对象是完成任务所需的人的投入量，常用单位是人时或人日。它回答“这件事需要多少人的工作时间”，与工期（日历上要花多少天）、成本（折算成金额）、产出指标（交付了多少功能或需求）是不同口径。三者混用是估算失真的常见原因：把工期当工作量，会忽略并行投入的人数；把成本当工作量，会把采购、外部服务等非人力费用算进来。口径说明中应明确写出“本次估算只统计人力投入，不含等待、审批、外部依赖占用的日历时间”。
单位与换算规则
单位要统一到可汇总的程度，并提前约定换算与取整规则：
- 以人日为主单位时，明确一个人日对应多少有效工作小时（例如按团队作息约定为 6 或 8 小时），全篇一致。
- 小于半天的任务按半天计，避免出现 0.3 人日这类无法核对的数字；大于 5 人日的任务应继续拆分。
- 汇总时先按原始精度相加，再在最终结果上取整，避免逐项取整造成累积偏差。
- 会议、评审、沟通、返工等协作性投入单独列项或按比例预留，不隐含在开发任务里。
拆解颗粒度
任务拆到执行者能直接判断“大概要多久”的规模即可，通常单个任务控制在 0.5 至 3 人日之间。颗粒度过粗（如“完成后端开发”）只能靠猜；过细（如“写一个接口的注释”）会让估算成本超过估算收益。判断标准是：任务有明确的完成状态、有可识别的负责人、不依赖尚未确定的技术方案。对于方案未定的探索性任务，单独标注为高不确定性条目，给出更宽的区间。
精度随阶段变化
早期阶段（需求刚明确、方案未定）用区间估算，允许上下浮动较大，用于判断量级和排优先级；进入开发前，任务清单细化到可执行颗粒度，再给出较窄的区间用于排期和承诺。口径说明中应写明当前处于哪个阶段、本次估算的用途是排序、排期还是对外承诺，用途不同，取值的保守程度也不同。
六步操作流程：从任务清单到可用的估算区间
以下六步按顺序执行，每一步都有明确的输入、动作、输出和完成标志。流程可以在一到两次会议内走完，规模较大的需求可拆成多轮，每轮针对一组任务。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 建立任务清单 | 需求说明、范围边界、验收标准 | 按交付物拆出任务条目，标注负责人和依赖 | 任务清单（含颗粒度检查） | 范围内每项工作都有对应条目，无“其他”兜底项 |
| 2. 确定方法与单位 | 口径说明、历史数据可得性 | 按任务性质选择类比、三点估算或专家判断，统一单位 | 方法选择说明 | 每个任务都标注了所用方法和单位 |
| 3. 执行者独立出数 | 任务清单、任务说明 | 执行者各自给出三档取值和依据，不先看总数 | 各任务的三档取值 | 每个任务都有执行者本人的取值和一句依据 |
| 4. 汇总为区间 | 三档取值 | 按公式计算期望值，汇总总量并标注不确定性来源 | 总量区间与不确定性清单 | 结果以区间呈现，且列出主要不确定项 |
| 5. 评审与交叉校验 | 汇总结果、历史数据、同类任务记录 | 技术负责人检查遗漏任务与假设，与历史同类任务比对 | 评审意见与修订后的区间 | 偏差有解释，遗漏任务已补入清单 |
| 6. 记录假设并设定复盘时点 | 修订后的估算、假设清单 | 填写估算记录，约定复盘时间和偏差阈值 | 估算记录、复盘计划 | 记录字段完整，复盘时点和责任人已确定 |
第一步：建立任务清单
从需求说明和范围边界出发，按交付物而不是按角色拆任务。一个交付物可能同时涉及前端、后端和测试，拆成“某功能的后端接口”“同一功能的前端页面”“该功能的测试用例与验证”三条，比按“前端组工作”“后端组工作”拆更容易判断投入。清单完成后做一次颗粒度检查：超过 5 人日的条目继续拆，无法判断完成状态的条目补充验收标准。
第二步：确定估算方法与单位
三种常用方法的适用条件不同：
- 类比估算：有高度相似的历史任务和可信的实际投入数据时使用，直接参照历史值并按差异调整。适合重复性高、变化小的任务。
- 三点估算：任务有一定不确定性但边界清楚时使用，通过乐观、最可能、悲观三档取值得到期望值和区间。适合大多数研发任务。
- 专家判断：任务新颖、无历史参照，或需要跨领域经验时使用，由熟悉该领域的执行者或技术负责人直接给出区间，并写明判断依据。
同一份清单里可以混用不同方法，但每个任务都要标注所用方法，便于评审时判断取值的可靠性。
第三步：由执行者独立出数
让实际做这件事的人给出三档取值，而不是由项目经理先报一个总数再往下分摊。先报总数会让执行者围绕这个数字调整，失去独立判断。操作上可以要求每人先独立填写，再集中讨论差异大的条目；讨论聚焦“为什么你认为是 3 天而我认为是 6 天”，把分歧转化为对假设和依赖的澄清。每个取值附一句依据，例如“参照上个版本同类接口，含联调约 2 人日”。
第四步：汇总为区间并标注不确定性
按任务逐项计算期望值后相加，得到总量期望值；同时汇总悲观值与乐观值，形成总量区间。不确定性来源要单独列出，常见的有：技术方案未验证、依赖外部团队交付、需求边界可能变化、执行人经验不足。每一项注明影响的任务和大致影响幅度，供决策者判断是否需要先做技术验证或调整范围。
第五步：评审与交叉校验
评审由技术负责人主持，重点检查三类问题：任务清单是否漏项（如部署、数据迁移、文档、回归测试）；假设是否成立（如“复用现有组件”是否真的可复用）；结果与历史数据是否偏离过大。与同类任务的历史实际投入比对时，偏差超过约定阈值（例如 30%）的条目要给出解释，解释不成立的重新取值。评审后的区间才是可用于排期的版本。
第六步：记录假设并设定复盘时点
把估算记录写入团队共用的位置，与任务清单放在一起，确保执行过程中随时可查。同时约定复盘时点，例如任务完成后的下一次迭代回顾，以及偏差阈值（单项偏差超过 50% 或总量偏差超过 30% 时触发分析）。复盘的目的不是追责，而是把“当时为什么估成这样”和“实际发生了什么”对照，沉淀为下一次类比估算的依据。
任务清单和估算记录需要有稳定的承载位置，否则三档取值、假设和复盘结论容易散落在聊天记录里。ONES 的资源与工时管理方案支持查看项目和团队的资源利用率与负荷度，也支持多维度掌握项目和成员的资源投入情况；在估算阶段，团队可以把任务条目和估算字段放在同一工作项下管理，执行后产生的工时登记数据再用于与估算值对照。具体字段配置方式需结合团队实际使用的工作项类型确认。
三点估算怎么算：公式、示例与取整处理
三点估算用三个取值刻画不确定性，计算过程可以直接复算。公式为：期望值 =（乐观 + 4 × 最可能 + 悲观）÷ 6，标准差 =（悲观 − 乐观）÷ 6。期望值用于汇总，标准差用于判断区间宽度。
一个完整算例
假设要估算“用户权限模块改造”，拆成三个任务，由执行者给出三档取值（单位：人日）：
| 任务 | 乐观 | 最可能 | 悲观 | 期望值 | 标准差 |
|---|---|---|---|---|---|
| 权限模型设计与评审 | 1 | 2 | 4 | (1+8+4)/6 = 2.17 | (4−1)/6 = 0.50 |
| 接口改造与联调 | 3 | 5 | 9 | (3+20+9)/6 = 5.33 | (9−3)/6 = 1.00 |
| 回归测试与上线验证 | 1 | 2 | 3 | (1+8+3)/6 = 2.00 | (3−1)/6 = 0.33 |
总量期望值为 2.17 + 5.33 + 2.00 = 9.5 人日。总量区间可用两种方式表达：一是直接汇总各任务的乐观值与悲观值，得到 5 至 16 人日的宽区间；二是用期望值加减合并标准差（各任务标准差平方和开方，约 1.17），得到约 8.3 至 10.7 人日的窄区间。前者适合向需求方说明不确定性范围，后者适合内部排期参考。
取整与转为承诺口径
汇总结果按口径说明的规则取整。上例中 9.5 人日可按半天取整为 9.5 人日，或按人日取整为 10 人日。转为对外承诺时，通常取期望值向上取整并附加缓冲，例如承诺 11 至 12 人日，同时在记录中写明缓冲覆盖的是哪些不确定项。承诺口径应说明是“投入量”而非“交付日期”，交付日期还要结合人员可用性和并行任务另行排定。
何时改用其他方法
当任务与历史任务高度相似且历史实际投入数据可靠时，类比估算更快且往往更准；当任务涉及未验证的技术方案、三档取值本身难以判断时，先安排技术验证（时间盒控制在半天到一天），验证后再估算，比强行给出三档更有意义；当任务极小（半天以内）时，直接由执行者给出单值并注明即可，不必套用公式。
角色与交付物：谁出数、谁汇总、谁确认
估算由多方共同完成，每个角色有明确的交付物和交接时点，避免估算变成单人拍数或无人负责。
| 角色 | 职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 任务执行者 | 按任务给出三档取值和依据，说明技术假设 | 各任务的三档取值与依据说明 | 估算会议前独立提交 |
| 技术负责人/评审人 | 校验假设、检查遗漏任务、主持交叉校验 | 评审意见、补充任务清单、修订后的取值 | 评审会上及会后一个工作日内 |
| 项目经理 | 汇总区间、记录假设、跟踪实际偏差 | 估算记录、区间汇总、复盘报告 | 评审后当日归档，复盘时更新 |
| 需求方 | 确认范围边界与优先级，确认承诺口径 | 范围确认意见、优先级排序 | 估算启动前确认范围，评审后确认承诺 |
交接的关键在于顺序：需求方先确认范围，执行者再出数，技术负责人校验，项目经理汇总。任何一环缺失都会让后面的数字失去依据。范围在估算后发生变更时，按变更部分重新走一遍出数与校验，不在原区间上直接加减。
估算记录怎么写：必填字段与填写示例
估算记录是复盘校准的唯一依据，字段要能支撑“当时怎么想的”和“实际差在哪”两个问题。
| 字段 | 必填/选填 | 填写要求 |
|---|---|---|
| 任务 | 必填 | 与任务清单条目一致，含唯一编号 |
| 单位 | 必填 | 人时或人日，注明换算规则 |
| 乐观/最可能/悲观 | 必填 | 三档取值，注明所用方法 |
| 期望值 | 必填 | 按公式计算，保留计算过程 |
| 假设 | 必填 | 取值成立所依赖的前提，逐条写 |
| 依赖 | 必填 | 外部团队、环境、数据等前置条件 |
| 估算人 | 必填 | 实际出数的执行者 |
| 日期 | 必填 | 出数日期与修订日期分开记录 |
| 历史参考 | 选填 | 参照的历史任务及实际投入 |
| 风险备注 | 选填 | 可能显著影响投入的风险项 |
| 置信度 | 选填 | 高/中/低，说明判断理由 |
一条填写示例
任务：权限模块接口改造与联调（编号 AUTH-02）；单位：人日；乐观 3、最可能 5、悲观 9；期望值 5.33；假设：现有鉴权中间件可复用、测试环境与生产环境配置一致；依赖：网关团队在第二周前完成路由配置；估算人：后端负责人；日期：出数 3 月 4 日，评审修订 3 月 6 日；历史参考：上个版本同类接口改造实际投入 4.5 人日；风险备注：若中间件需重写，悲观值可能上浮至 12 人日；置信度：中。
记录与任务清单存放在同一位置，任务状态变化时同步更新实际投入；每次修订保留原值，不覆盖历史版本，便于复盘时对照。复盘时把实际投入填入记录，与期望值和区间比较，偏差原因写在同一行，形成可检索的经验库。
完成检查：估算结果可用前的核对项
估算提交排期或对外承诺前，逐项核对以下清单。全部通过才算完成；出现阻断项时先修正再使用结果。
- 任务清单覆盖了范围边界内的全部工作，包括部署、数据迁移、文档和回归测试。
- 每个任务的单位一致，换算规则与取整规则已在口径说明中写明。
- 每个任务都有执行者本人的三档取值和一句依据，取值在集中讨论前独立完成。
- 结果以区间呈现，总量期望值有计算过程，主要不确定性来源已列出。
- 经过技术负责人交叉校验，与历史同类任务的偏差有解释。
- 假设与依赖逐条显式记录，包括外部团队交付时点。
- 已设定复盘时点和偏差阈值，并指定跟踪责任人。
- 承诺口径写明是投入量还是交付日期，缓冲覆盖的不确定项已说明。
阻断项有三类：估算记录中没有假设与依赖，结果无法复盘；以单点数字对外承诺，没有区间和缓冲；执行者未参与出数，取值缺乏依据。出现任一项时，估算结果只能作为内部参考，不用于排期承诺。
常见问题
需求范围在估算后发生变更，原来的区间还能直接用吗？
不能直接在原区间上加减。范围变更后，把变更部分拆成新的任务条目，重新走一遍出数与校验，再把新增任务的期望值并入原区间。原区间中未受影响的任务保持不变，并在估算记录里保留原值，注明修订日期和变更原因，便于复盘时区分“估算偏差”和“范围变化”两类原因。
团队没有可靠的历史投入数据，还能用类比估算吗？
类比估算依赖可信的历史实际投入，没有这类数据时，优先用三点估算或专家判断，并在记录中标注置信度为低。可以先从当前项目开始积累：每次任务完成后把实际投入回填到估算记录，几个迭代之后就有了可参照的样本。在数据积累起来之前，向需求方说明区间较宽的原因，避免把早期估算当作精确承诺。
三点估算算出的期望值可以直接作为对外承诺的数字吗？
期望值是汇总和比较用的中间结果，对外承诺通常取期望值向上取整并附加缓冲，同时在记录中写明缓冲覆盖哪些不确定项。承诺口径还要说明是投入量还是交付日期：投入量是人的工作时间，交付日期还需结合人员可用性、并行任务和等待时间另行排定，两者不能混为一谈。
估算记录放在哪里，才能在执行过程中真正用起来？
关键是让记录和任务清单在同一处，执行时随手可查，任务状态变化时能同步更新实际投入。ONES 的资源与工时管理方案支持查看项目和团队的资源利用率与负荷度，也支持多维度掌握项目和成员的资源投入情况；团队可以把任务条目和估算字段放在同一工作项下管理，执行后产生的工时登记数据再用于与估算值对照。具体字段配置方式需结合团队实际使用的工作项类型确认。
复盘时发现偏差很大，应该先查什么？
先区分偏差来源：是任务清单漏项（如部署、数据迁移、回归测试未列入），是假设不成立（如“复用现有组件”实际需要重写），还是执行过程中的外部等待。对照估算记录里的假设与依赖逐条核对，把实际发生的情况写在同一行。偏差原因归类之后，下一轮估算才能在对应环节调整取值或补充任务条目，而不是笼统地把所有数字上调。
