“‘两周，我保证’：我们对客户和自己撒的谎”

Source: Dev.to

如果你是一名开发者，“估算”可能是你最不喜欢的词。那是你不再是工程师而开始充当“预言家”的时刻——通常预言得很差。

在我的岗位上，我既是提供时间估算的人，也是必须完成工作的那个人。你可能会认为这会让我成为完美的估算者，对吗？错了。这只意味着当我在周六凌晨 3 点仍在调试时，唯一可以指责的只能是我自己。

下面是真相——为什么估算是一场噩梦，以及我们该如何止血。

第1部分：问题（“期望 vs. 现实”差距）

1. “我看到就知道”型客户

为没有明确需求的客户进行估算，就像为只说“想吃好吃的”的人去买菜。你猜测、购买，然后他们告诉你他们对你挑选的所有东西都过敏。

• 现实情况： 没有规格说明时，一个“简单的登录页面”很快就会变成“带社交登录、双因素认证、通过信鸽发送的‘忘记密码’流程以及暗黑模式的登录页面”。

2. “理想世界”谬误

我们在估算时好像是生活在真空中的机器人。我们假设：

• API 文档实际上是正确的（其实从来不是）。
• 网络永远不会掉线。
• 我们不会因为缺少一个分号而花上六个小时。
• 我们的大脑认为自己是电影里那种 10 倍效率的开发者，但实际生产力却受猫跳到键盘次数的支配。

3. “生活会发生”因素

你为一个项目估算了 40 小时。但你忘记了：

• 为其他项目参加的“快速”会议耗费的 10 小时。
• 为之前的客户紧急修复的 bug，整整占用了一个下午。
• 你实际上需要睡觉、吃饭，并偶尔和家人聊天，让他们记得你的长相。

Source: …

第2部分：解决方案（如何生存）

1. “模糊税”

如果需求不明确，价格就会上涨。就这么简单。

• 解决办法： 如果客户说“我想要一个搜索功能”，但没有提供细节，就在你的估算上加 50 %。这就是你的“我必须弄清你到底想要什么”税。如果他们想要更便宜的报价，就必须说得更清楚。

2. “缓冲”是你最好的朋友

我过去会因为添加缓冲而感到内疚，觉得自己在“撒谎”。现在我明白，不加缓冲才是谎言。

• 规则： 1.5× 倍数。把你最真实、最诚实的估算乘以 1.5。如果你认为需要 10 天，就告诉他们 15 天。
• 专业做法：
  • 12 天完成 → 你是英雄。
  • 14 天完成 → 你仍然提前。
  • 10 天完成 → 你是神。

3. 使用“悲观”公式

不要只给出一个数字。使用 PERT（项目评估与审查技术）公式。它会迫使你考虑“悲观”情景。

其中：

• O = 乐观（Optimistic）： “一切第一次就成功”的奇迹（10 %）。
• M = 最可能（Most Likely）： 现实的中间值（70 %）。
• P = 悲观（Pessimistic）： “一切都坏了，我没有网络”的灾难（20 %）。

当你真的写下如果一切出错需要多长时间时，最终得到的数值（E）会更加贴合现实。

4. 管理“时钟时间”与“深度工作”

不要再用 8 小时工作日来思考。没有人能连续编码 8 小时。

• 真实数学： 你每天大概只有 4 小时的高质量“深度工作”。其余时间被邮件、Slack 消息和个人生活吃掉。
• 解决办法： 如果一个项目需要 40 小时的工作，那它是一个两周的项目，而不是五天的项目。

估算最难的不是数学，而是有勇气告诉客户他们的“简单”想法其实是一个复杂的项目。与其在项目结束后为迟交而进行绝望的对话，不如在项目开始前就就时间线进行一次硬核的沟通。

下次你想说“只要一周就行”时，先深呼吸，想想你的猫，然后说“三周”。你的未来的自己会感谢你的。