文章探讨了软件开发中估算工作的矛盾性：开发者常因不确定性而厌恶估算，认为难以准确预测；而产品负责人则依赖估算进行短期和长期的产品规划。作者试图弥合双方认知差异，既让开发者理解估算对产品管理的重要性，也帮助产品负责人明白开发者抵触估算的原因。

标题：估算——必要的恶？

主要内容：

这篇文章探讨了软件开发中估算（estimates）的必要性及其引发的矛盾。作者从开发者和产品负责人（PO）的双重角度出发，分析了估算的价值与困境。

1. 产品负责人为何需要估算？
PO负责根据市场需求和用户反馈确定产品功能的优先级。由于待开发的需求总是多于团队能实现的速度，PO需要通过估算来权衡：
- 若优先开发大功能但未按时完成，可能导致发布失败；
- 若选择小功能则风险更低，但收益有限。
估算帮助PO在资源有限的情况下，平衡风险与回报，避免开发团队投入低价值功能。

2. 开发者为何厌恶估算？
- 不确定性：开发过程中常遇到技术债务（如陈年代码、隐藏依赖），导致实际耗时远超预期。例如，一个预计2天的任务可能因重构演变为2周的工作。
- 估算变 deadline：开发者提供的估算常被误解为硬性截止时间，迫使他们刻意夸大缓冲时间，失去信任。

3. 冲突根源与可能的解决方案
根本问题在于组织将估算等同于承诺，而外部压力（如预先公布的发布日期）加剧了矛盾。理想情况下，应减少提前承诺功能与期限，但现实商业需求（如税务软件的年度窗口）使完全避免估算不切实际。

4. DevOps 的启示
通过提升开发流程的“流动性”（Flow），例如持续交付和减少技术债务，可降低估算误差的风险，但无法完全消除估算需求。

结论
估算本身无错，但被误用为施压工具时会损害团队心理安全。建议开发者透明更新进度，PO则需理解技术复杂性，双方协作而非对立。

（注：原文中关于具体技术案例和DevOps推广的内容已精简，保留核心论点。）

以下是评论内容的总结：

主要观点与论据

1. 估计的困难性

   • 软件开发中的不确定性使估计变得困难（评论3、9、10）。
     "In my experience, most of the time estimates are difficult because prerequisites and constraints are not clear or not fully known."
     "The unique thing about estimates in software engineering is that if you do it right, projects should be impossible to estimate!"

2. 估计的价值与局限性

   • 估计是必要的，但应视为模型而非精确承诺（评论14、24）。
     "Models of any kind in whatever domain are necessarily always something less than reality."
     "When you discover more work hidden under that 'simple' pile of code, you absolutely HAVE to update your estimate."

3. 管理层的角色与问题

   • 管理层常将估计转化为硬性承诺，导致压力和不合理期望（评论5、11、22）。
     "Management doesn't want Kanban, because they want to promise things to customers."
     "The thing that sucks is that when I avoid giving estimates, I'm not trying to be difficult, I'm being honest about the unknowns."

4. 改进估计的方法

   • 使用无单位的复杂度估计（如斐波那契数列）和团队投票（评论15）。
     "The team reads [the task] together, thinks about it privately, and then votes on its complexity."
   • 采用历史数据和调整因子（评论16、19）。
     "Multiply any time estimate by 1.57... ime it should be multiplied by 7.85."

5. 行业对比与反思

   • 软件行业可借鉴其他行业的估计方法（评论21）。
     "Maybe software industry should learn from other industries where people don't see estimates as something unthinkable?"

不同观点的平衡

• 支持估计的论点：
  估计是项目规划和客户沟通的基础（评论7、28）。
  "When you order something on Amazon, would like an estimate on when the item would be delivered to you?"

• 反对估计的论点：
  估计常被滥用，且忽视不确定性（评论11、18）。
  "Garbage in, garbage out. Inaccurate estimates, unreasonable timelines, stressed devs and upset PMs."

关键引用保留

1. 评论9（yen223）：
   "The unique thing about estimates in software engineering is that if you do it right, projects should be impossible to estimate!"
   "But if the predictable tasks take 0 time, how long a project takes will be dominated by the novel, unpredictable parts."

2. 评论15（rendall）：
   "The PM and team lead write a description of a task, and the whole team reads it together... votes on its complexity."
   "It’s important that the scores be unitless estimates of complexity, not time."

3. 评论28（jackfranklyn）：
   "You say 'probably 2-3 weeks' to your manager, who tells the PM 'about 2 weeks', who tells sales 'mid-month', who tells the customer 'the 15th'."
   "Always giving estimates in writing with explicit confidence levels."

总结：评论普遍认为软件项目估计困难且常被误用，但通过改进方法（如团队投票、历史数据）和明确沟通可部分缓解问题。管理层与开发者的期望差异是冲突的核心。