"正确"的方式为客户或经理提供软件估算的实际检查

Question

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

客户或经理向我提出任务并要求估算.我估计说24小时.他们还问一位商业分析师,据我所知,他们的经历主要是非技术性的.他们估计说16个小时.最后,他们会考虑分析师给出的价值,即使除了提供我的估计之外,我还向他们解释了技术方面任务的可行性.他们将分析师的估计视为"生活中的事实",尽管它只是一种估计,真正的价值在于实际任务本身.更糟糕的是,我看到一种模式,与任务的可行性相比,他们倾向于选择较低的价值(比如我提出的分析值低于分析师,他们很快就会考虑它).如果您已经阅读过Peopleware,那么他们就是那些给予一系列工作时间会做任何事情的人,尽管实际上并不存在,但他们有权缩短一切.

你有没有具体的谈判技巧和战术,以避免这种情况？

Answer 1

如果我可以帮助它,我几乎不会给出像"24小时"这样的数字.这样做会产生几个隐含的假设:

1. 估计精确到一小时之内.
2. 数字中的所有数字都是重要数字.
3. 估算对您在估算时间与工作完成时间之间可能出现的情况不敏感.

在大多数情况下,这些都是明显错误的.为避免陷入(1)所构成的陷阱,引用范围反映了您对估计准确性的不确定性:"3周,正负3天".这也照顾(2).

为了弥补(3)的漏洞,请明确说明您的假设:"3周,加上或分钟3天,假设Alice和Bob完成了Frozzbozz组件".

IMO以这种方式明确表达您的假设,将比分析师的POV表现出更深刻的思考.我更倾向于关注那些比刚刚从空中拉出一个号码的人更加强烈地思考这个问题的人,而这肯定会在你谈判中加分.

Answer 2

您是否没有可以验证估算的工作分解结构？

如果您的经理/客户不相信您的估计,您应该能够轻松地证明它超出分析师的能力.

没有任何东西可以使你的估计本质上比他的超出明显更好的估计.像这样的东西例如:

Gather Feature Requirements      (2 hours)
Design Feature                   (4 hours)
Build Feature
  1 easy form                    (4 hours)
  1 easy business component      (4 hours)
  1 easy stored procedure        (2 hours)
Test Feature
  3 easy unit tests              (4 hours)
  1 regression test              (4 hours)
Deploy Feature
  1 easy deployment              (4 hours)
                                ==========
                                (28 hours)

然后你说"好吧,我想出了28个小时,告诉我我错在哪里.告诉我你怎么能在16岁时做到这一点."