估算假设记录要保留四类信息：假设本身（内容、类型、影响对象）、依据与来源（数据出处、参考项目、判断理由）、量化影响（对应的工作量区间、置信度、敏感度）、责任与时效（提出人、确认人、复核时间、失效条件）。记录按“一条假设一行”维护，并与估算版本绑定；估算变更时同步更新状态，后续复核才能追溯每个数字背后的前提。本文给出可直接套用的字段清单、维护流程、角色分工和填写示例。
要点总览（TL;DR）
- 估算假设记录按“一条假设一行”维护，至少保留四类信息：假设内容与类型、依据与来源、量化影响与置信度、责任人与复核时效。
- 记录要与估算版本绑定，估算变更时同步更新状态（有效、已失效、已替换），保证每个估算数字都能回溯到当时的前提。
- 维护按五步走：估算前登记、标注影响工作项、评审逐条确认、变更时更新状态、结束后归档并保留版本关联。
- 提出假设的人与确认假设的人尽量分开；影响大且置信度低的假设要指定验证责任人和完成时间。
- 提交评审前用检查清单核对可追溯性、依据充分性、量化区间、失效条件与版本同步，阻断项未通过不进入下一环节。
一份估算假设记录至少包含哪些字段
假设记录的作用，是让读估算的人不必追问“这个数字怎么来的”，就能看到前提、依据和影响范围。字段设计围绕这条主线展开：先写清假设是什么，再写为什么这样假设，接着写假设对工作量影响多少，最后写谁负责、什么时候需要重新看。
下表是一份可直接建表的字段清单。必填字段缺失时，该条假设不能进入估算评审；选填字段按估算对象复杂度决定是否启用。
| 字段 | 填写要求 | 是否必填 |
|---|---|---|
| 假设编号 | 按“估算版本号-序号”编制，如 EST-02-A03，保证全表唯一、可被其他文档引用 | 必填 |
| 假设内容 | 用一句可判断真假的陈述句描述，避免“情况比较复杂”这类无法验证的表述 | 必填 |
| 假设类型 | 从范围、技术、资源、外部依赖等类型中选择，便于分类复核 | 必填 |
| 影响对象 | 写明受影响的工作项、模块或交付物编号，一条假设可对应多个对象 | 必填 |
| 依据与数据来源 | 写清数据出处、参考项目、历史数据或判断理由；引用历史项目时注明项目与时间段 | 必填 |
| 量化影响 | 给出该假设成立与不成立时的工作量区间，单位与估算口径一致（人天或人时） | 必填 |
| 置信度 | 用高、中、低三档标注对该假设的判断把握，并简述理由 | 必填 |
| 敏感度 | 标注假设变化对总估算的影响程度，用于决定复核优先级 | 选填 |
| 提出人与提出时间 | 记录最初提出该假设的人与日期 | 必填 |
| 确认人与确认时间 | 记录在评审中确认该假设成立的人与日期 | 必填 |
| 失效条件 | 写明什么情况下该假设不再成立，如接口方案变更、人员调整、需求范围扩大 | 必填 |
| 复核节点 | 指定下次复核的时间点或触发事件，如需求评审后、开发启动前 | 必填 |
| 状态 | 标注有效、已失效、已替换，并与估算版本关联 | 必填 |
| 备注 | 记录讨论中的分歧、待补充信息等 | 选填 |
字段之间有两处容易写空。一是“依据与数据来源”，只写“根据经验”等于没有依据，应落到具体项目、历史工时或技术验证结论。二是“量化影响”，只写“影响较大”无法支撑复核，应给出区间，例如“若复用现有组件，约 3 人天；若需自研，约 8 至 10 人天”。
按步骤建立并维护假设记录
字段定义清楚后，记录能否发挥作用取决于维护动作。建议按五步执行，每一步都有明确的输入、动作、输出和完成标志，避免记录建完就搁置。
第一步：估算前识别并登记假设
输入是需求说明、技术方案初稿和历史估算数据。估算负责人组织参与估算的人员逐项讨论“哪些前提不确认就无法给出数字”，把每条前提登记为一行记录，填写假设内容、类型和初步依据。完成标志是：所有参与估算的人都认可当前假设清单覆盖了影响估算的主要不确定项。
第二步：标注影响的工作项或模块
输入是已登记假设和工作分解结构。由模块负责人把每条假设对应到具体工作项或模块编号，并补充量化影响区间。完成标志是：每条假设至少关联一个工作项，且没有工作项在无假设说明的情况下单独承载大额估算。
第三步：估算评审时逐条确认假设
输入是完整假设清单和估算结果。评审会上逐条过假设，由评审参与者提出质疑，确认人判断假设是否成立，并在记录中填写确认人、确认时间和置信度。对争议较大的假设，当场约定验证方式与验证时间。完成标志是：每条假设都有确认结论，未确认的假设被标记并说明处理方式。
第四步：估算变更时更新假设状态
输入是变更请求、需求调整或技术方案更新。估算负责人检查受影响的假设，把不再成立的条目标记为已失效，需要替换的标记为已替换并新建记录，同时更新量化影响和估算版本号。完成标志是：估算版本变更后，假设清单中不存在状态与实际情况不符的条目。
第五步：估算结束后归档并保留版本关联
输入是定稿的估算结果和假设清单。将假设记录与对应估算版本一并归档，保留历史版本以便回溯。完成标志是：任一历史估算数字都能通过版本号找到当时的假设记录。
在工具承载上，假设记录需要与工作项和评审过程保持关联。ONES 支持通过工作数量和工时规模了解成员排期，并支持筛选与分组掌握成员在不同项目的投入比重；其资源管理可实时查看成员每日投入饱和明细，识别规划风险，并提供多种资源报表、一键导出工时日志。这些能力适合在假设确认后核对资源投入是否与估算前提一致。假设记录本身的模板与字段配置，需以实际产品配置为准。
角色分工与各角色交付物
假设记录流于形式，常见原因是没人对“写什么、确认什么、维护什么”负责。把职责落到角色和交付物上，记录才有稳定的维护机制。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 估算负责人 | 组织假设识别与登记，汇总假设清单，维护编号规则和版本关联，跟踪复核节点 | 假设记录总表、复核计划 |
| 模块负责人或技术骨干 | 提供技术类假设及其依据，给出量化影响区间，参与验证争议假设 | 技术假设条目、验证结论 |
| 项目经理 | 确认范围类与资源类假设，判断假设失效对交付计划的影响 | 范围与资源假设的确认意见 |
| 评审参与者 | 在评审中对假设提出质疑，核对依据是否充分，确认后签字 | 评审意见、确认记录 |
分工中有一条实用原则：提出假设的人与确认假设的人尽量分开。提出人负责把依据写足，确认人负责判断依据是否支撑结论，两者分离能减少“自己提、自己批”带来的盲区。对于影响大且置信度低的假设，还应指定验证责任人和验证完成时间。
填写示例：一个需求估算的假设记录
以下为演示情景，用于说明字段如何填写，不对应真实项目数据。
背景：某业务系统需要新增报表导出功能，估算对象为“报表导出模块”，估算版本 EST-02，初步估算工作量 15 人天。估算过程中识别出三条主要假设。
| 字段 | 假设 A01 | 假设 A02 | 假设 A03 |
|---|---|---|---|
| 假设内容 | 导出功能复用现有报表组件的导出接口，无需新建导出服务 | 导出文件格式仅需支持 Excel，不包含 PDF 与打印模板 | 测试环境在开发启动前可提供与生产一致的数据量级 |
| 假设类型 | 技术 | 范围 | 资源 |
| 影响对象 | 报表导出模块-服务层 | 报表导出模块-前端与模板 | 报表导出模块-联调测试 |
| 依据与数据来源 | 现有报表组件已具备导出接口，参考上一版本同类需求的实现记录 | 需求说明第 3 节列出的交付范围 | 与测试负责人沟通确认的环境排期 |
| 量化影响 | 成立约 3 人天；不成立需新建服务，约 8 至 10 人天 | 成立约 2 人天；增加 PDF 与打印模板约增加 4 人天 | 成立不影响估算；不成立联调测试增加约 3 人天 |
| 置信度 | 高，接口已在其他模块验证可用 | 中，需求方尚未最终确认格式清单 | 低，环境排期存在不确定性 |
| 敏感度 | 高，直接影响总估算约 5 至 7 人天 | 中 | 中 |
| 提出人/时间 | 模块负责人，估算启动日 | 估算负责人，估算启动日 | 测试负责人，估算启动日 |
| 确认人/时间 | 技术评审人，评审当日确认 | 项目经理，评审当日标记待需求方确认 | 项目经理，评审当日确认排期风险 |
| 失效条件 | 报表组件接口变更或下线 | 需求方新增导出格式要求 | 测试环境排期延后或数据量级不足 |
| 复核节点 | 开发启动前 | 需求评审后 | 联调测试开始前一周 |
| 状态 | 有效 | 有效，待确认 | 有效 |
这份示例体现了几个填写要点。量化影响写成区间而非单点，便于评审判断风险敞口；置信度附简短理由，避免只标档位；失效条件写成可观察的事件，复核时能直接判断是否触发；状态与估算版本 EST-02 绑定，后续版本变更时按条目更新。
完成检查：假设记录是否可用
假设记录提交评审或归档前，按下表逐项核对。标注为阻断项的条目未通过时，记录不应进入下一环节。
| 检查项 | 通过标准 | 是否阻断 |
|---|---|---|
| 可追溯性 | 每条假设都能关联到具体工作项或模块编号 | 是 |
| 依据充分性 | 依据写明数据出处、参考项目或判断理由，不出现仅凭经验的笼统表述 | 是 |
| 量化影响 | 给出成立与不成立两种情形的工作量区间，单位与估算口径一致 | 是 |
| 置信度 | 每条假设标注置信度并附理由 | 否 |
| 责任与时效 | 指定确认人与复核时间或触发事件 | 是 |
| 失效条件 | 写明可观察的失效事件，而非“情况变化时”这类模糊表述 | 是 |
| 版本同步 | 估算版本变更后，假设状态已更新，无状态与实际不符的条目 | 是 |
| 覆盖完整性 | 影响估算的主要不确定项均已登记，无遗漏的大额假设 | 否 |
检查通过后，假设记录与估算版本一并归档。后续复核时，先看状态与失效条件是否触发，再核对量化影响是否仍与当前估算一致，这样每个估算数字都能回到它成立的前提上。
常见问题
假设记录和估算文档放在一起，还是单独建一份表？
两种做法都可行，判断标准是复核时能否快速定位。假设条目较多、需要按类型或状态筛选时，单独建表更便于维护，估算文档中引用假设编号即可；条目少且只服务一次估算时，作为估算文档的附表也能用。无论哪种方式，都要保证假设编号唯一，并与估算版本号对应，避免估算更新后找不到对应的假设记录。
评审时对某条假设无法达成一致，记录该怎么写？
把分歧本身记录下来，不要为了凑出结论而强行确认。可以在备注中写明各方观点，状态标为“待确认”，同时指定验证方式、验证责任人和验证完成时间。该假设对应的估算数字在验证前按较保守的区间取值，并在估算结果中标注这一不确定性。验证完成后回填结论，再更新状态和量化影响。
估算版本更新后，旧版本的假设记录需要保留吗？
需要保留。旧版本记录是解释历史估算数字的依据，删除后就无法回答“当时为什么估这个数”。建议按版本归档，旧版本条目标记为已失效或已替换，并注明被哪条新记录替代。这样在复盘估算偏差时，可以对比前后两版假设的变化，判断偏差来自前提变化还是估算方法本身。
假设记录需要覆盖到什么颗粒度，会不会记录量过大？
颗粒度按影响程度取舍：对总估算影响大、置信度低的假设逐条登记；影响很小且容易验证的前提可以合并成一条概括性记录。判断标准是这条假设失效后，估算是否需要重新讨论。如果答案是否定的，就不必单独成行。记录量随估算对象复杂度增长，但应保持在评审时能逐条过完的规模。
假设确认后，怎么和资源排期核对是否一致？
假设确认后，把量化影响区间与资源排期对照，看排期是否落在假设成立所要求的人力与时间范围内。ONES 资源管理支持通过工作数量和工时规模了解成员排期，支持筛选与分组掌握成员在不同项目的投入比重，并可实时查看成员每日投入饱和明细、识别规划风险，还提供多种资源报表与工时日志导出（依据 F3、F4）。这些能力可用于核对资源投入是否与估算前提一致；假设记录本身的模板与字段配置以实际产品配置为准。
