做完，这个时间才是最接近实际的。
2. 负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
3. 做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。
其实微软这个方法根本就没有什么特别，所有正常人都可以想到这个方法，但仍然有很多人去追求那些不太靠谱的估算方法。
这个方法还是有这样的一些问题的：
1.有人会估算偏小，比方他说需要5天，但往往10天还完不成。
2.有人估算过于保守。
3.项目的进度要求就是很紧，基本上你必须在指定时间内完成，估算显得毫无价值。
第一个问题是比较常见的，但我们要这样想：估不准也比不估算好，估算偏差哪怕超过100%，也比不估算好，至少有个谱。
大家是会进步的，估不准往往是对任务和自己能力认识不到位，要让大家不害怕估算，只要敢于估算，问题才会暴露出来，才能持续进步。
第二个问题分两种情况，有些人是确实是过分保守的对自己信心不太足，项目经理可以多多来指导他的工作，看看他具体的进展，让他更加充分地了解任务，更加充分了解自己的能力，增强他的信心，这样他就能持续进步了。而另外一种情况就比较恶劣，少数人会故意增大时间，这样他平时工作不必全力以赴，可以比较悠闲，甚至可以利用工作时间干私事。如果发现这样的情况，就应该严肃处理了，不要做烂好人，这样的人在团队中存在是对团队的极大伤害。
第三个问题往往是各项目经理心中的痛楚，他们会觉得：实在无奈啊!做项目就是在有限时间有限资源内做不可能完成的任务，在这样的情况下，你就不要跟我扯估算了!
我们的项目大部分情况都是非常大压力的，应对这样大的压力越需要冷静。实际上大部分项目尽管是有压力，但只要发挥团队的聪明才智，还是可以高效地做好工作的，不需要加班或者少加班。本文稍后会介绍这个问题的应对办法。
介绍了这么多种估算方法，每种都有很多问题，那到底怎样才能做好项目估算呢?
软件项目的特点就是项目签订时，价钱是死的，工期是死的，而需求和设计是不明确的。
我的经验告诉我，功能点法、代码行法这些方法基本上是不靠谱的，我在实际项目中会综合使用Dephi法和由底而上的估算方法，并予以改良，下面介绍一下我的一些心得体会。
1.项目估算与其说是估出来，还不如说是做出来的。
假设某项目是这样的情况：
1)合同签署的金额是100万，工期是3个月。
2)需求只是大致写了，并不明确。
3)老板要赚50万，给你的预算只有50万。
我们很多项目都是这样的情况，不是等你估算出比较靠谱的数字，然后才去报价签合同的，我们经常要在老板指定的预算下完成项目。
你现在要负责这个项目，你会如何做估算呢?
你需要做好两个事情，才能保证项目实际成本控制在预算内。
第一个事情，控制好需求。需求不明确，这既是不利因素也是有利因素，应尽量往有利的方向控制。不明确的好处就是你有控制需求的空间，抓住客户的关键需求，简化不必要的花销的需求，能极大地降低项目工作量。
第二个事情：想尽办法降低开发工作量。不要因为进度紧就不认真思考软件的设计，应尽量采用简单的成熟的设计方案，简化工作。
2.估算应该持续进行，持续细化。
项目初期很难对项目做完整估算，但能估计的部分应先估计出来，并且针对不明确的部分安排计划去搞清楚。
3.估算是项目各种工作估算的总和。
估