language-agnostic - "Proper"让客户或经理对软件估计进行现实检查的方法

Question

回顾我过去的项目，我经常遇到这个:

一位客户或经理向我提出一项任务并要求进行估算。我估计说 24 小时。他们还询问了业务分析师，据我所知，他们的经验大多是非技术性的。他们给出的估计是 16 小时。最后，他们会考虑分析师给出的值(value)，尽管除了我这边提供的估计之外，我已经在技术方面向他们解释了这项任务的可行性。他们将分析师的估计视为“生活中的事实”，即使它只是一个估计，真正的值(value)在于实际任务本身。更糟糕的是，我看到一种模式，即与任务的可行性相比，他们倾向于选择较低的值(value)(假设我提出的值(value)估计低于分析师，他们很快就会考虑)。如果您读过 Peopleware，就会知道他们是那种给定一组工作时间的人，他们会竭尽所能缩短工作时间，即使这实际上是不可能的。

您之前是否使用过特定的谈判技巧和策略来避免这种情况？

Answer 1

如果可以的话，我几乎不会给出“24 小时”这样的数字。这样做会做出几个隐含的假设:

1. 估算准确到一小时以内。
2. 数字中的所有数字都是 significant figures .
3. 估算对您给出估算和工作完成之间可能出现的情况不敏感。

在大多数情况下，这些显然是错误的。为避免落入 (1) 所造成的陷阱，请在报价范围内反射(reflect)您对估算准确性的不确定程度:“3 周，正负 3 天”。这也适用于 (2)。

要填补 (3) 的漏洞，请明确说明您的假设:“3 周，再加上 3 天，假设 Alice 和 Bob 完成了 Frozzbozz 组件”。

IMO，以这种方式明确你的假设将显示出比分析师的 POV 更深入的思想。我宁愿关注对此事有更深入思考的人，也不愿关注只是凭空得出数字的人，这肯定会在谈判中为你方加分。