Wherever possible, go one meta-level up: give an estimate of when you can give reasonably accurate estimate.
"I don't know enough about Foo to give an accurate estimate, but I will know enough about Foo by Thursday week."
I acknowledge it often isn't possible, but I try to make it an option when I am project managing.
You can even go up another meta-level, in large projects.
"I don't know how long it will take for us to get a expert in to give us an estimate. I will talk with my colleagues, and give you an estimate on Friday of how long it will take to get an expert estimate."
This can be combined with large error margins, diminishing rapidly. "It will take 1 year, +/- 9 months. I'll give you another estimate with an error range +/- 3 months by June 30."
You cannot estimate these, you can only guess. The difference, to me, is that an estimate is based on knowledge & experience, and you have neither for the unknown.
You have to constantly reevaluate where you started, where you stand, and your guess on what's left. You could probably break down your problem into steps but your biggest issue will be in the "footnotes" of what you're learning.
The example that comes to mind was my first C# interop with Word. It was entirely unknown and I didn't have the foggiest clue what it would take to generate a 1000 page formatted document based on database information. It, in itself, is pretty straight-forward: open Word, format page, and insert data. There are all kinds of issues that cropped up that you couldn't fathom and that easily doubles your guess.
Ask people who are familar with the concepts how long it would have taken them back when they first learnt the technique (including how long to learn). Average the results and adjust based on your capability to learn.
Then guess anyway and triple the quote. Doubling is for chumps.
MinMaxLikely is the method I use. The minimum for the case where everything goes well, the maximum for everything going pear-shaped, and the likely somewhere in between.
Of course, management only ever looks at the minimum figure but, by the time they start complaining about cost over-runs and missed deliverables, you've already got them locked in and you have been (hopefully) keeping the fully appraised of any problems you've encountered and the effect those problems are having (pushing the actuals away from Min and closer to Max).
聘请培根烧烤专家 等等 - 您可以为每一个分配一些 est. 并放置一个 ? 接近实际烹饪。 称之为概念验证（你能烧烤培根吗？）、研究和开发，等等——但是当你开始一个项目时，有些事情你不知道，但你可以制定一个计划来更好地了解这些领域，一旦你这样做了重新审视该计划并添加调查结果。 通过这样做，你可以向团队、赞助商等传达你所知道的、你不知道但有计划去了解的领域，以及对已识别的未知数的粗略估计。
Know what you Know AND Know what you don't Know and you'll be successful. Use a work breakdown structure (WBS) to get the sub parts of the project/application/whatever. You can provide an est. (to a degree) of the effort to get the knowns complete, as with any project there are the unknowns - identifying them is the first big step. The best next step is to add to the WBS steps to better know those unknowns, for example, if the task is to go BBQ a cheese burger with strips of bacon and you've never BBQ'd bacon before - then you break the job down to getting the ingredients, getting the BBQ, starting the BBQ, etc. and the one thing you don't know - getting/cooking bacon you add some sub-components like:
call butcher
research bacon cooking
hire bacon BBQ'er expert etc. - each of those you can assign some est. to and put a ? near the actual cooking. Call it a proof of concept (can you bbq bacon?), research and development, whatever - but there are somethings when you start a project you don't know, but you can devise a plan to better know those areas AND once you do revisit the plan and add the findings. By doing this you're communicating out to the team, sponsors, etc. what you know, those areas you don't know but have a plan to get to know, and a rough est. with the unknowns identified.
It's hard. Actually, it is not possible to give an accurate estimate of something that is not known. But that doesn't stop people from needing to know.
Write down a list of all functional components or aspects that you are aware of.
Be as vague as necessary to cover everything.
Now, you have a list of components. For each component, do your best to get the business and/or functional requirements of that part. Why is it there? What is it supposed to do? Why? How? Drill down to more detail, add as many items to your list as possible (nested, components, sub-components).
The more items you have the easier it is to estimate each one.
Then double it!
I think it is very reasonable to walk the stakeholders through some level of design in order to provide an estimate. Otherwise, it's like walking up to a construction company and saying "I want a house, how much will it cost?"
And keep in mind -- it is an estimate :)
Oh, one last thing... Be clear about what it is that you are estimating. If it is "a, b, c" and they later ask for "d", it will be easy to point out that your estimate did not cover "d"... your new estimate is ...
发布评论
评论（7）
只要有可能，就提高一个元级别：估计何时可以给出相当准确的估计。
“我对 Foo 的了解还不够，无法给出准确的估计，但到周四，我就会对 Foo 有了足够的了解。”
我承认这通常是不可能的，但我在项目管理时尝试将其作为一种选择。
在大型项目中，您甚至可以提升到另一个元级别。
“我不知道我们需要多长时间才能请专家给我们一个估计。我会和我的同事们谈谈，并在周五给你们一个估计，需要多长时间才能得到专家的估计。 ”
这可能与较大的误差幅度相结合，并迅速减小。 “这需要 1 年 +/- 9 个月的时间。到 6 月 30 日，我将给你另一个估计，误差范围为 +/- 3 个月。”
Wherever possible, go one meta-level up: give an estimate of when you can give reasonably accurate estimate.
"I don't know enough about Foo to give an accurate estimate, but I will know enough about Foo by Thursday week."
I acknowledge it often isn't possible, but I try to make it an option when I am project managing.
You can even go up another meta-level, in large projects.
"I don't know how long it will take for us to get a expert in to give us an estimate. I will talk with my colleagues, and give you an estimate on Friday of how long it will take to get an expert estimate."
This can be combined with large error margins, diminishing rapidly. "It will take 1 year, +/- 9 months. I'll give you another estimate with an error range +/- 3 months by June 30."
您尝试过规划扑克吗？
这些SO问题可能是相关的：
如何估计a的长度编程任务
处理糟糕的估计
最重大的项目管理错误
你练习规划游戏吗？
Have you tried planning poker?
These SO questions might be relevant:
How to estimate the length of a programming task
Dealing with awful estimates
The most significant project management mistakes
Do you practice the planning game?
你无法估计这些，你只能猜测。 对我来说，不同之处在于估计是基于知识和经验的。 经验，而对于未知的事物，你两者都没有。
你必须不断地重新评估你的起点、你的立场以及你对剩下的事情的猜测。 您可能可以将问题分解为多个步骤，但最大的问题将出现在您所学内容的“脚注”中。
我想到的例子是我的第一个 C# 与 Word 的互操作。 这是完全未知的，我完全不知道如何根据数据库信息生成 1000 页的格式化文档。 它本身非常简单：打开 Word、设置页面格式并插入数据。 各种各样的问题突然出现，你无法理解，很容易使你的猜测加倍。
You cannot estimate these, you can only guess. The difference, to me, is that an estimate is based on knowledge & experience, and you have neither for the unknown.
You have to constantly reevaluate where you started, where you stand, and your guess on what's left. You could probably break down your problem into steps but your biggest issue will be in the "footnotes" of what you're learning.
The example that comes to mind was my first C# interop with Word. It was entirely unknown and I didn't have the foggiest clue what it would take to generate a 1000 page formatted document based on database information. It, in itself, is pretty straight-forward: open Word, format page, and insert data. There are all kinds of issues that cropped up that you couldn't fathom and that easily doubles your guess.
询问熟悉这些概念的人，当他们第一次学习该技术时需要多长时间（包括学习多长时间）。 平均结果并根据您的学习能力进行调整。
然后无论如何猜测并将报价增加三倍。 加倍是给笨蛋的。
Ask people who are familar with the concepts how long it would have taken them back when they first learnt the technique (including how long to learn). Average the results and adjust based on your capability to learn.
Then guess anyway and triple the quote. Doubling is for chumps.
MinMaxlikely 是我使用的方法。 一切顺利的情况下的最小值，一切进展顺利的情况下的最大值，以及可能介于两者之间的情况。
当然，管理层只关注最低数字，但是当他们开始抱怨成本超支和错过交付成果时，您已经将他们锁定，并且您（希望）一直对任何问题进行全面评估您遇到过的问题以及这些问题所产生的影响（使实际值远离最小值并接近最大值）。
MinMaxLikely is the method I use. The minimum for the case where everything goes well, the maximum for everything going pear-shaped, and the likely somewhere in between.
Of course, management only ever looks at the minimum figure but, by the time they start complaining about cost over-runs and missed deliverables, you've already got them locked in and you have been (hopefully) keeping the fully appraised of any problems you've encountered and the effect those problems are having (pushing the actuals away from Min and closer to Max).
知道你知道什么，知道你不知道什么，你就会成功。
使用工作分解结构（WBS）来获取项目/应用程序/其他内容的子部分。 您可以提供估计（在某种程度上）的努力来完成已知的工作，就像任何项目都存在未知数一样 - 识别它们是第一步。 最好的下一步是添加到 WBS 步骤中，以更好地了解这些未知因素，例如，如果任务是用培根条烧烤芝士汉堡，而您以前从未烧烤过培根 - 那么您就破坏了工作到获取原料、获取烧烤、开始烧烤等，还有一件事你不知道 - 获取/烹饪培根，你添加一些子组件，例如：
等等 - 您可以为每一个分配一些 est. 并放置一个 ? 接近实际烹饪。 称之为概念验证（你能烧烤培根吗？）、研究和开发，等等——但是当你开始一个项目时，有些事情你不知道，但你可以制定一个计划来更好地了解这些领域，一旦你这样做了重新审视该计划并添加调查结果。 通过这样做，你可以向团队、赞助商等传达你所知道的、你不知道但有计划去了解的领域，以及对已识别的未知数的粗略估计。
Know what you Know AND Know what you don't Know and you'll be successful.
Use a work breakdown structure (WBS) to get the sub parts of the project/application/whatever. You can provide an est. (to a degree) of the effort to get the knowns complete, as with any project there are the unknowns - identifying them is the first big step. The best next step is to add to the WBS steps to better know those unknowns, for example, if the task is to go BBQ a cheese burger with strips of bacon and you've never BBQ'd bacon before - then you break the job down to getting the ingredients, getting the BBQ, starting the BBQ, etc. and the one thing you don't know - getting/cooking bacon you add some sub-components like:
etc. - each of those you can assign some est. to and put a ? near the actual cooking. Call it a proof of concept (can you bbq bacon?), research and development, whatever - but there are somethings when you start a project you don't know, but you can devise a plan to better know those areas AND once you do revisit the plan and add the findings. By doing this you're communicating out to the team, sponsors, etc. what you know, those areas you don't know but have a plan to get to know, and a rough est. with the unknowns identified.
不是认真的...
好吧，好吧...
这很难。 实际上，不可能对未知的事物做出准确的估计。 但这并不能阻止人们需要知道。
现在，您有了一个组件列表。 对于每个组件，尽最大努力获得该部分的业务和/或功能需求。 为什么它在那里？ 它应该做什么？ 为什么？ 如何？ 深入了解更多详细信息，向列表中添加尽可能多的项目（嵌套、组件、子组件）。
您拥有的项目越多，就越容易估算每一项。
然后加倍！
我认为引导利益相关者完成一定程度的设计以提供估计是非常合理的。 否则，这就像走到一家建筑公司说“我想要一套房子，要花多少钱？”
并记住 - 这是一个估计:)
哦，最后一件事。 .. 清楚你所估计的是什么。 如果是“a、b、c”，而他们后来要求“d”，则很容易指出您的估计没有涵盖“d”...您的新估计是 。 ..
Not Serious...
Ok, ok...
It's hard. Actually, it is not possible to give an accurate estimate of something that is not known. But that doesn't stop people from needing to know.
Now, you have a list of components. For each component, do your best to get the business and/or functional requirements of that part. Why is it there? What is it supposed to do? Why? How? Drill down to more detail, add as many items to your list as possible (nested, components, sub-components).
The more items you have the easier it is to estimate each one.
Then double it!
I think it is very reasonable to walk the stakeholders through some level of design in order to provide an estimate. Otherwise, it's like walking up to a construction company and saying "I want a house, how much will it cost?"
And keep in mind -- it is an estimate :)
Oh, one last thing... Be clear about what it is that you are estimating. If it is "a, b, c" and they later ask for "d", it will be easy to point out that your estimate did not cover "d"... your new estimate is ...