假设有1000块砖头，它们的大小和重量一样，每名工人每天能搬100块砖头，于是我们可以估算到需要10人日来搬完。10人日的意思是1名工人需要10天完成，而10名工人只需要1天就搞定了。
这个1000块代表了工作的规模，而生产率就是100块/日，这样就可以推算出工作量为10人日。建筑工程可以得到土石方量、混凝土量、钢筋量等代表工作规模的数据，这样就比较容易推算出完成这些工作需要的工作量。
功能点法和代码行法有比较长的历史，也有很多详细资料，大家可以去查阅一下。这方法理论上很理想，但实践效果很差，我还没有见到一家能成熟应用并且取得比较好效果的公司。功能点法和代码行法有这样的一些难以解决的问题：
2、我们绝大部分项目是需求不明确、设计不明确，并且工期很赶的，这两个方法都无法适应这样的现实条件。需求不明确基本上无法得到软件规模，建筑工程为什么能做到，是因为需求和设计都十分明确了。
普遍认为各专家的经验与知识水平会严重影响结果的准确性，而我的实践经验是：应该让项目组每个人自己来估算，也就是让大家来当专家，在这个基础上可以再增加一两名来自项目组外部的专家。
有时候觉得估算这个问题搞得太复杂了，各式各样的方法是不是太夸张了？其实最简单的方法就是让负责该项工作的人自己来估计工作量，微软的由底而上的估算方法就是这样做的，可谓返璞归真啊！
微软由底而上的估算方法大致是这样的：对项目各项工作进行分解后（即俗称的wbs：work breakdown structure，工作分解结构），每个任务落实负责人，由负责人对自己的任务进行估计。这个办法有以下好处：
1、最终该任务是由这个人来完成的，他估计多少时间才能做完，这个时间才是最接近实际的。
2、负责该任务的人进行估算的时候，肯定需要认真思考这个任务的风险，需要做哪些具体的工作，这样更容易在未开始工作之前就发现更多的潜在问题。相反如果由项目经理来分配时间，这个人就可能不会去思考这个任务了。
3、做这个任务的人会有被重视和尊重的感觉，他会很重视自己承诺的完成时间，并且想法设法按时间完成。这样会减少很多项目管理时间，因为每个任务负责人都会主动地跟踪好自己的工作。
其实微软这个方法根本就没有什么特别，所有正常人都可以想到这个方法，但仍然有很多人去追求那些不太靠谱的估算方法。
这个方法还是有这样的一些问题的：
1、有人会估算偏小，比方他说需要5天，但往往10天还完不成。
2、有人估算过于保守。
3、项目的进度要求就是很紧，基本上你必须在指定时间内完成，估算显得毫无价值。
第一个问题是比较常见的，但我们要这样想：估不准也比不估算好，估算偏差哪怕超过100%，也比不估算好，至少有个谱。
大家是会进步的，估不准往往是对任务和自己能力认识不到位，要让大家不害怕估算，只要敢于估算，问题才会暴露出来，才能持续进步。
第二个问题分两种情况，有些人是确实是过分保守的对自己信心不太足，项目经理可以多多来指导他的工作，看看他具体的进展，让他更加充分地了解任务，更加充分了解自己的能力，增强他的信心，这样他就能持续进步了。而另外一种情况就比较恶劣，少数人会故意增大时间，这样他平时工作不必全力以赴，可以比较悠闲，甚至可以利用工作时间干私事。如果发现这样的情况，就应该严肃处理了，不要做烂好人，这样的人在团队中存在是对团队的极大伤害。
第三个问题往往是各项目经理心中的痛楚，他们会觉得：实在无奈啊！做项目就是在有限时间有限资源内做不可能完成的任务，在这样的情况下，你就不要跟我扯估算了！
我们的项目大部分情况都是非常大压力的，应对这样大的压力越需要冷静。实际上大部分项目尽管是有压力，但只要发挥团队的聪明才智，还是可以高效地做好工作的，不需要加班或者少加班。本文稍后会介绍这个问题的应对办法。
介绍了这么多种估算方法，每种都有很多问题，那到底怎样才能做好项目估算呢？
软件项目的特点就是项目签订时，价钱是死的，工期是死的，而需求和设计是不明确的。
我的经验告诉我，功能点法、代码行法这些方法基本上是不靠谱的，我在实际项目中会综合使用Dephi法和由底而上的估算方法，并予以改良，下面介绍一下我的一些心得体会。
1、项目估算与其说是估出来，还不如说是做出来的。
假设某项目是这样的情况：
1）合同签署的金额是100万，工期是3个月。
2）需求只是大致写了，并不明确。
3）老板要赚50万，给你的预算只有50万。
我们很多项目都是这样的情况，不是等你估算出比较靠谱的数字，然后才去报价签合同的，我们经常要在老板指定的预算下完成项目。
你现在要负责这个项目，你会如何做估算呢？
你需要做好两个事情，才能保证项目实际成本控制在预算内。
第一个事情，控制好需求。需求不明确，这既是不利因素也是有利因素，应尽量往有利的方向控制。不明确的好处就是你有控制需求的空间，抓住客户的关键需求，简化不必要的花销的需求，能极大地降低项目工作量。
第二个事情：想尽办法降低开发工作量。不要因为进度紧就不认真思考软件的设计，应尽量采用简单的成熟的设计方案，简化工作。
2、估算应该持续进行，持续细化。
项目初期很难对项目做完整估算，但能估计的部分应先估计出来，并且针对不明确的部分安排计划去搞清楚。
3、估算是项目各种工作估算的总和。
估算并不是只是得到一个项目估算的总体数字，项目的估算总数其实是由项目各种工作的估算组成的。
前文介绍了项目的各种工作，每一种工作都需要认真估算。如果估算发生偏差，要能定位到具体是哪部分的估算出问题了，否则估算没有指导项目工作的价值。功能点法、代码行法的估算办法，只能得到一个项目估算的总数，而不能定位到具体的哪一部分工作，这样得到的估算结果难以用来指导项目工作。
4、估算依赖项目组的整体实力。
如果你没有软件开发相关经验，只懂理论上的估算，你是不可能做好估算工作的。
项目组由项目管理、软件设计、编码、测试、实施等各类专业人才组成，每个人在自己方面都是专家，每个人都是整个项目组中最有资格对自己专业方面的工作进行估算。前文列出了的项目各方面的工作，应该由相应的项目成员为主进行估算。
5、项目组应该不断学习、总结、进步，提高整体水平。
需求不明确、设计不确定这是项目的特点，我们需要不断地学习来提高水平，将这些不明确的因素逐步明确。
没有什么妙方能解决这些不明确的因素，靠的还是我们的知识和能力。项目组每个人都应该通过持续估算来发现自己的不足并提高水平。
6、公司应该定期组织项目资深人士制定估算指南并持续更新。
我们公司有一份估算模板，里面汇集了以前的估算经验，列出了所有需要考虑的估算内容以及详细的说明。
我们以前没有估算模板时，估算偏差会达到50%以上，总结经验发现偏差的主要原因是估漏！使用估算模板会帮助我们发现遗漏，后来我们的估算偏差基本可以控制在20%以内。
前文的“估算要估啥”小节，我列出了项目通常要考虑的各种工作，也列出了容易估漏和估计不足的地方，大家可在此基础上根据自己公司实际情况，修改和扩充这些内容，写出自己公司的估算模板或估算指南。
先得到项目规模，再由规模导出工作量，这是一个很美好的想法，问题就是和我们的实际情况相去甚远了。
将工作分解，直到分解到可以估计工作量的程度，这个可能是最土最有效的方法了。但你可能会问，这样的估算方法，项目之间就无法横向比较了？
项目估算第一目标是用来指导项目工作，如果这个目标都达不到，那么就不需要考虑项目之间的横向比较了。
另外我要反问：为什么非要用这样的方式来作项目之间的横向比较？有什么好处？国外优秀的软件开发工作室就不会做这样无聊的事情，软件开发可能是人类最厉害的智力活动，你觉得一定能量化度量吗？
要从本质上提升估算水平，你不太可能用几天时间去突击学习某种估算办法就能胜任项目实际的估算工作。
提高估算能力靠你长期的积累，你的实力、你的项目团队的综合实力，还有你们公司的综合实力，决定了估算的水平！
估算是为项目服务的，后文你会看到如何利用估算来管理项目，又如何因应项目实际情况来更新估算。
下面开始，我们将讲述估算与计划的关系、计划及计划跟踪。 计划有什么内容？