估算假设记录把投入预估背后的前提逐条写下来，让评审者能看懂数字从哪来、错了会影响什么、什么时候能验证。本文用一个演示情景“订单中心重构”（示例，非真实客户）给出一份已填写的假设记录表，覆盖范围、人力投入、外部依赖和可用工时四类假设，并逐条解释写法与迁移方法。文中的人天与比例仅用于演示，不作为基准值。
要点总览（TL;DR）
- 估算假设记录是投入预估的说明书：每条假设写明依据、影响的工作项、不确定程度、验证方式和复核时间，评审时逐行判断是否成立。
- 演示情景“订单中心重构”给出 8 条已填假设，覆盖范围、人力投入、外部依赖、可用工时四类，人天与比例仅作写法演示。
- 写法要点：范围假设写清包含与不包含，人力假设落到角色和投入比例，外部依赖写等待时间与逾期触发条件，可用工时先扣假期再扣固定占用。
- 迁移到自己的项目时先列影响结论的假设，每条可验证并落到具体复核节点，假设与工作项建立对应关系，按项目规模增减字段与复核频次。
- 示例数据不构成基准值；需求范围尚未确定时应先做范围澄清，实际工时填报与产能分析属于另外的管理动作。
示例目标：这份假设记录要解决什么问题
演示情景设定如下：某研发团队计划对订单中心做一次重构，涉及订单创建、状态流转和查询接口三块改造，预估投入约 60 人天，计划 8 周内完成。在评审这份预估之前，负责人要求先把支撑 60 人天这个结论的前提写清楚，形成一份假设记录。这份记录不是预估本身，而是预估的“说明书”。
假设记录要回答三个问题：第一，这条假设的依据是什么，是历史数据、架构文档、外部团队的口头承诺，还是团队经验判断；第二，如果假设错了会怎样，影响哪些工作项、影响多少人天、会不会改变交付时间；第三，什么时候、用什么方式能验证它成立与否。三个问题对应表中的“依据”“影响的工作项”“验证方式与复核时间”三列。
需要划清边界：假设记录服务于投入预估，记录的是“预估成立的前提”。实际工时填报、工时审核规则、团队产出指标与产能分析属于另外的管理动作，本文不展开。假设记录写完后，工时填报才有一个可对照的基准；产能分析则要等实际数据积累后才能做。三者是先后关系，不能互相替代。
完整示例：订单中心重构的估算假设记录表
下表为演示情景下的已填写示例，共 8 条假设，覆盖范围、人力投入、外部依赖和可用工时四类。表中人天与比例均为示例数据。
| 编号 | 假设内容 | 依据 | 影响的工作项 | 不确定程度 | 验证方式 | 复核时间 | 责任人 |
|---|---|---|---|---|---|---|---|
| A1 | 本次重构包含订单创建、状态流转、查询接口三块改造；不包含支付回调改造与历史数据迁移（示例） | 需求评审纪要；架构组范围说明 | 全部 12 个工作项 | 低 | 对照需求清单逐项确认范围边界 | 迭代启动前 | 产品负责人 |
| A2 | 订单状态流转改造按 3 个状态机分支估算，每分支约 5 人天（示例） | 上一版本类似改造的实际投入记录 | 状态流转改造（5 个工作项） | 中 | 技术方案评审时拆分到接口级再核对 | 方案评审后 | 技术负责人 |
| A3 | 后端投入按 2 名开发各投入 60% 工时计算，其余时间用于线上问题支持（示例） | 团队近两个迭代的支持类工作占比 | 后端相关 7 个工作项 | 中 | 迭代排期时确认人员占用比例 | 排期确认时 | 项目经理 |
| A4 | 测试由 1 名测试工程师全程参与，联调阶段投入比例提高到 80%（示例） | 团队测试人力安排惯例 | 联调与测试类 3 个工作项 | 低 | 排期会上与测试负责人确认 | 排期确认时 | 测试负责人 |
| A5 | 依赖会员中心提供新接口，对方承诺 2 周内交付，等待期不计入本方人天（示例） | 跨团队接口排期邮件 | 查询接口改造中的 2 个工作项 | 高 | 每周跟踪对方交付进度；逾期即触发排期调整 | 每周五 | 项目经理 |
| A6 | 8 周周期内扣除 3 天法定假期与 2 天团队活动，实际可用约 35 个工作日（示例） | 团队日历与年度活动安排 | 整体排期 | 低 | 排期时对照团队日历核对 | 排期确认时 | 项目经理 |
| A7 | 每人每周约 20% 工时用于代码评审、例会与答疑，已从可用工时中扣除（示例） | 团队近一个季度的时间分布统计 | 整体排期 | 中 | 迭代中期对比计划与实际占用 | 第 4 周末 | 技术负责人 |
| A8 | 不安排专项性能压测，沿用现有压测基线（示例） | 本次改造不涉及核心链路性能变化 | 测试类 1 个工作项 | 中 | 技术方案评审时确认是否触发性能风险 | 方案评审后 | 技术负责人 |
这张表的结构可以概括为：一条假设一行，每行都能追溯到具体工作项，每行都有明确的复核时点和责任人。评审时不需要重新推导预估，只需逐行判断假设是否成立。
逐项解释：每条假设为什么这样写
A1 范围假设写清包含与不包含。范围假设最容易出问题的地方是只写“做什么”，不写“不做什么”。支付回调改造和历史数据迁移都是订单中心重构中常见的关联工作，如果不明确排除，评审时各方会按各自理解计算工作量，60 人天的结论就失去共同基础。写清排除项，等于提前锁定讨论边界。
A2 与 A3 人力投入假设要落到角色和比例。A2 把状态流转改造拆到状态机分支，是为了让“5 人天”这个数字有可对照的颗粒度；如果只写“状态流转约 15 人天”，评审时无法判断依据是否合理。A3 写投入比例而非“2 名开发全职投入”，是因为团队实际存在线上问题支持这类占用，按 60% 计算更接近真实可用投入。比例写错，整体人天会成比例偏差。
A5 外部依赖假设要写等待时间与触发条件。跨团队接口的等待期不计入本方人天，但会占用日历时间，所以必须单独记录。写法上要给出对方承诺的交付时间，并写明逾期后的动作——“逾期即触发排期调整”，这样这条假设在复核时才有可执行的判断标准，而不只是一句备注。
A6 与 A7 可用工时假设要扣除假期与支持性工作。8 周不等于 40 个工作日，法定假期和团队活动要先扣掉；扣完后还要再扣代码评审、例会这类固定占用。两层扣除都写出来，排期才经得起推敲。A7 的 20% 来自团队历史统计，比拍一个整数更有说服力。
不确定程度与验证方式要对应。不确定程度高的假设（如 A5），验证方式要更频繁、触发条件更明确；不确定程度低的假设（如 A1、A6），一次核对即可。如果一条高不确定假设配的是“项目结束时回顾”，这条假设实际上没有起到控制作用。复核时间列就是把这种对应关系固定下来。
可迁移规律：换成自己的项目怎么填
从上面的示例可以提炼出四条填写规则，适用于大多数投入预估场景。
- 先列影响结论的假设，再补细节。动笔前先问：哪些前提一旦不成立，人天结论会明显变化？范围边界、人力投入比例、关键外部依赖通常排在前列。先把这几条写清楚，再补充假期、会议占用等细节。小项目可能只需要 4 到 5 条核心假设，不必凑满整张表。
- 每条假设必须可验证，写明验证时点。验证方式要具体到动作，例如“对照需求清单逐项确认”“每周跟踪对方交付进度”，复核时间要落到具体节点，例如“方案评审后”“每周五”。无法验证的表述，例如“需求应该比较稳定”，应改写为可检查的条件。
- 假设与工作项建立对应关系。每条假设都要指向受影响的工作项。这样当某条假设被推翻时，能快速定位需要重估的范围，而不是整体推翻重来。工作项数量多时，可以按模块归组，但归组后仍要能追溯到具体条目。
- 按项目规模调整字段与复核节奏。小项目可以精简责任人列，复核合并到一次排期会；周期长、跨团队多的项目应保留完整字段，并增加复核频次，例如每两周对照一次高不确定假设。字段可以增减，但“依据、影响、验证”三要素建议保留。
假设记录需要与工作项和评审过程关联才有实际作用。以 ONES 为例，假设记录可以作为项目文档与对应工作项建立关联，评审结论记录在文档中，复核时按工作项状态逐条对照，让假设的验证动作落在具体的研发管理流程里，而不是停留在单独的表格文件中。
适用边界：哪些情况不适合用这份示例
这份示例适合需求范围相对清晰、团队有历史投入数据可参考、跨团队依赖可识别的重构或迭代类项目。以下情况需要调整做法或暂不使用。
| 情况 | 是否适用 | 说明 |
|---|---|---|
| 范围基本确定、有类似项目历史数据 | 适用 | 可直接参照示例结构填写 |
| 需求方向尚未确定、范围可能大幅变化 | 暂不适用 | 应先做范围澄清，范围稳定后再细化假设 |
| 需要评估实际工时执行情况 | 不在本文范围 | 属于工时填报与审核，需另行建立流程 |
| 需要分析团队产出与产能 | 不在本文范围 | 需基于实际数据积累后单独分析 |
| 项目周期长、外部条件持续变化 | 适用但需更新 | 假设记录要随项目推进定期复核，一次性填写会失效 |
还要强调两点：示例中的人天、比例和周期都是为说明写法而设定的演示数据，不同团队的历史数据差异很大，不能直接当作基准值套用；假设记录的价值在于持续维护，项目每进入一个新阶段，都应对照复核时间检查假设是否仍然成立，并把变化同步到预估中。
常见问题
估算假设记录和工时填报是什么关系，能不能用假设记录代替实际填报？
两者是先后关系，不能互相替代。假设记录在预估阶段写清“这个数字成立的前提”，为后续工时填报提供对照基准；工时填报记录的是实际发生的时间，用于检查假设是否成立、预估偏差在哪里。假设记录写得再细，也需要实际数据来验证。工时审核规则、填报流程属于工时管理范畴，本文不展开。
项目进行到一半，某条假设被推翻了，应该怎么处理？
先看这条假设对应哪些工作项，再判断影响范围。如果推翻的是范围类假设，需要重新确认边界并重估受影响的工作项；如果是外部依赖逾期，按记录中写好的触发条件调整排期。处理完后更新假设记录本身：把原假设标记为已失效，补写新的假设和复核时间，并同步给评审相关方。假设记录的价值在于持续维护，一次性填写会失效。
小团队项目只有三四个人，也需要这么完整的表格吗？
可以精简。小项目通常保留 4 到 5 条核心假设即可，重点是范围边界、人力投入比例和关键外部依赖。责任人列可以合并，复核动作并入一次排期会。字段可以增减，但“依据、影响、验证”三要素建议保留，否则假设在评审时无法被检验。周期长、跨团队多的项目再补全字段并提高复核频次。
假设记录里的不确定程度怎么判断，有没有统一标准？
没有统一刻度，判断依据是“这条假设错了，结论会偏多少”。依据来自历史数据或已确认文档、影响范围有限的，可标为低；依据来自经验判断或口头承诺、影响多个工作项的，标为中或高。关键是让不确定程度与验证方式对应：高不确定的假设要更频繁复核、触发条件更明确，低不确定的假设一次核对即可。团队内部保持同一套判断口径，比追求精确分级更重要。
假设记录应该由谁来写、谁来复核？
通常由负责预估的人起草，按假设类型分派责任人：范围假设由产品负责人确认，技术方案相关假设由技术负责人确认，排期与外部依赖由项目经理跟踪。复核时点写进表格，到点由责任人对照验证方式检查并记录结论。评审会上逐行过一遍高不确定假设，比整体讨论人天数字更有效率。
