先定义交付物，再估工时
仅凭“网站”“活动”“集成”或“改版”这样的模糊名词，无法做出有依据的估算。先描述可观察的结果：页面、状态、格式、集成、设备、客户提供的内容、审批流程和验收标准。
为每个交付物写一条简短的完成定义。如果两个理性的人仍可能争论工作是否已经完成，那么范围还不够具体，无法可靠估算。现在把它说清楚，比预算耗尽后再争论便宜得多。
- 最终交付什么，以及使用什么格式
- 客户需要提供什么，以及何时提供
- 需要支持哪些设备、浏览器或平台
- 包含多少概念方案、变体和修改轮次
- 明确排除在估算之外的内容
把工作拆成足够小、可以被质疑的任务
把交付物拆成通常需要1到8小时的任务。一个叫“开发应用，60小时”的任务隐藏了太多假设。认证、账户状态、表单验证、响应式布局、分析和部署都可以单独估算和复核。
把可重复工作与不确定工作分开。使用现有组件库构建页面，与缺少文档的第三方集成并不是同一种风险。把它们塞进一个数字，会让熟悉的工作替未知工作补贴成本。
对不确定任务使用三点估算
对于存在明显不确定性的任务，记录乐观、最可能和悲观三个时长。一个实用的加权公式是：预计工时 =（乐观 + 4 × 最可能 + 悲观）÷ 6。
假设某个集成在文档和权限都正确时需要4小时，最可能需要8小时，如果API表现很差则需要20小时。加权结果是9.3小时。这个公式不会让不确定性消失，但会阻止乐观场景悄悄变成正式计划。
如果悲观场景足以让项目失控，不要把它藏在一个百分比里。可以先做付费探索、按小时阶段，或者在承诺固定总价之前设置决策节点。
把隐藏工作和客户依赖也算进去
制作时间只是交付的一部分。需求探索、会议、状态更新、文件准备、反馈审阅、测试、无障碍检查、交接和部署都会消耗产能。如果项目需要这些工作，它们就属于估算。
依赖项需要负责人和截止时间。等待权限或内容可能不产生可计费工时，但会推迟交付并造成昂贵的上下文切换。应明确输入延迟时会发生什么，而不是假装时间表不受现实影响。
- 需求探索、研究和需求澄清
- 项目管理和集中式客户沟通
- 内容准备、迁移或数据清理
- 质量保证、无障碍和设备测试
- 包含的修改、部署和交接
- 直接费用和专业分包
实际案例：一个小型网站更新
一个五页网站刷新需要4小时做探索和结构，10小时设计，22小时实现，8小时录入内容和质量检查，5小时沟通和交接，另加5小时用于包含的一轮修改。已定义工作合计54小时。
CRM集成仍然不确定。三点估算为4、8和20小时，对应9.3小时期望值。只对这个不确定任务增加20%的固定价缓冲，即1.9小时。规划总量约为65小时，而不是54小时，也不是随手凑成70小时。
内部保留任务级估算。在客户提案中展示交付物、假设、包含的修改、价格和时间表。工时是你做决定的证据，不必变成每份报价后附的一份审判记录。
把每个已完成项目变成更好的估算数据
用与估算相同的任务分类记录实际时间。交付后，记下偏差来自哪里：需求不清、客户延迟、技术意外、返工，或者只是估得太乐观。
做过几个项目后，用自己的区间替代通用缓冲。你可能会发现实现很可预测，而内容准备和审批并不稳定。这是有价值的运营数据，比上网问“做一个网站需要多久”有用得多。
- 按任务比较预计和实际工时，而不只比较项目总量
- 记录每个重要偏差的原因
- 交付后更新可复用任务模板
- 重大估算在承诺前让另一位专业人士复核
把方法变成真实报价
把工作拆成任务，加入时间和费率，然后生成清晰的客户报价。
打开免费计算器常见问题
项目估算应该加多少缓冲？
没有通用百分比。先指出具体的不确定任务，再为这些风险增加时间或成本。如果不确定性主导整个项目，应使用付费探索或按小时计费，而不是用一个巨大的缓冲把它藏起来。
如果我没有历史项目数据怎么办？
从详细任务拆分开始，对未知工作使用三点估算，让同行挑战你的假设；如果区间太宽，就把探索和交付分开。
要向客户展示每一小时的估算吗？
不一定。详细工时可以内部保留，客户需要看到的是清晰的交付物、假设、边界、里程碑、价格和变更流程。
