文章指出软件行业普遍存在一种礼貌的虚构：认为有经验的团队能准确预估项目耗时。但事实上，软件项目根本无法精确预估，这导致各种奇怪现象，如用T恤尺码代替时间估算，或采用"初始估算翻倍再加20%"等经验法则。作者质疑科技公司是否应该放弃这种徒劳的预估尝试。

标题：资深软件工程师的工作评估之道

在软件行业存在一种心照不宣的假象：虽然估算项目耗时非常困难，但训练有素的工程师团队通过努力可以预测交付时间，从而帮助企业制定商业计划。然而事实是，准确预估软件项目根本不可能。这种认知矛盾导致科技公司出现各种奇怪现象。

常见现象包括： 1. 工程师用T恤尺码（XS/S/M/L）而非具体时间估算，但管理层仍会将其转换为具体工时 2. 采用"初始估算×2+20%"等经验法则，本质上等同于放弃精确估算

为什么估算不可行？ - 仅适用于范围明确的小型任务（如修改链接文本可准确预估45分钟） - 大多数工作涉及复杂系统的研究探索，存在大量未知因素 - 传统"先规划后执行"模式已过时，现代开发需要工程师自主决策

估算的政治属性： - 本质是管理层的政治工具，用于决定项目优先级和资源分配 - 工程师的估算常被要求调整以符合上级预期 - 只有在技术不可行时，估算才能发挥警示作用

逆向工作法： 实际流程是"给定时间框架→设计可行方案"，而非"确定需求→计算耗时"。例如开发PDF聊天功能： - 6个月方案：完整的文件上传、分块嵌入、图像提取系统 - 1天方案：客户端文本转换+直接输入LLM上下文

作者的估算方法： 1. 首先收集政治背景：项目压力级别、管理层预期 2. 带着预设时间框架评估技术方案 3. 重点关注未知风险而非已知工作 4. 提供带风险评估的多套方案而非单一估算

争议回应： - 拒绝估算等于将决策权交给非技术人员 - 与管理者合作寻找折中方案≠背叛工程原则 - 压力较小的团队可能难以理解高压环境

核心结论： 1. 软件估算本质是政治协商工具，而非技术预测 2. 有效方法是先了解时间预期，再设计可行技术方案 3. 应提供带风险说明的多种选择，而非单一时间数字 4. 建立信任才能在对不可行项目说"不"时被采信

（注：原文中关于订阅推广、脚注说明等非核心内容已省略，保留主要技术观点和论证逻辑）

以下是评论内容的总结，涵盖主要观点和论据，并保持不同观点的平衡性：

1. 估算的传统经验与幽默观点

• 老程序员常开玩笑说将原始估算乘以π（3.14）更接近实际耗时。
  • 引用：
    "The old guys in the 80's and 90's would say kiddingly multiply your original estimate time pi (3.14)."
    "To make good estimates... take that number and multiply by 2. Then double that number."

2. 估算的政治与管理意义

• 估算更多是管理政治需求的工具，而非技术精确性问题。
  • 引用：
    "The more I work in engineering, the more I agree... that a large part of the job is managing politics."
    "Estimates are not by or for engineering teams."

3. 估算的可行性与技能争议

• 支持估算可行：认为估算是一种可通过练习提升的技能，失败源于方法不当。
  • 引用：
    "Estimation can be done. It's a skillset issue... experienced devs have built versions of them before."
• 反对估算可行：认为软件开发的未知因素（如未知问题）使精确估算不可能。
  • 引用：
    "It is not possible to accurately estimate software projects."

4. AI在估算中的新角色

• 部分评论者提到使用AI（如CLI代理或Cursor）生成估算，认为其能快速发现潜在问题，但结果可能偏保守。
  • 引用：
    "AI estimates much better & faster than us... a great tool for estimation."
    "First impressions... they give really long estimates."

5. 时间与范围的权衡

• 提出“时间-质量-功能”三选二的经典权衡，并强调主动调整范围比单纯延长时间更有效。
  • 引用：
    "Features : Quality : Timeline. Choose 2."
    "Padding time doesn’t work. Padding scope does."

6. 跨部门协作与估算的现实挑战

• 销售、市场等部门依赖估算日期，但工程师常因突发问题（如关键漏洞）无法兑现。
  • 引用：
    "Sales would rather confidently repeat a date... and blame engineering later."
    "Delays usually came from unexpected sources... collaboration is key."

7. 替代估算的方法

• 部分建议用“承诺交付日期”或“工作小时”替代传统估算，或通过拆分任务缩小不确定性。
  • 引用：
    "Think in terms of deliverables and commitments."
    "The only reasonable way to estimate is in work hours."

关键分歧点：

• 估算本质：是政治工具（如管理优先级）还是技术工具（如资源规划）？
• 可行性：是否可通过经验、AI或流程改进实现精准估算？
• 责任归属：估算失败应归咎于工程师能力，还是管理层的错误预期？

（总结保留原始评论的多样性与核心论据，压缩至约600字。）