“这个网站相当简单，所有你需要做的就是完成X，Y，Z。你看起来应该是技术很好，所以，我相信，你不需要花费太多时间就能把它搭建起来。”

我时时时的就会收到这样的Email。写这些邮件的人几乎都是跟技术不沾边的人，或正在研究他们的第一个产品。起初，当听到人们这样的话，我总是十分的愤怒。他们在跟谁冲突软件开发所需要的时间？但后来我意识到，即使我本身对本身的项目预测要花去几多开发时间,我也是一筹莫展。如果连我本身都做欠好，我何必对那些人愤怒呢？

真正让我郁闷的不是他们预估的错误。问题在于他们竟然认为本身可以做出正确的预计。作为开发人员，我们经常会发明，在软件开发的问题上，一个外行人会很自然的把庞大的工作预计的很简单。

这并不是为我们的愤慨找借口。但这引起了此外一个有趣的问题：为什么我们天生的预测庞大性的能力在遇到编程问题时会掉灵？

为了回答这个问题，让我们来认识一下我们的大脑如何预计工作的。有些工作对付一些没有经验的人也很容易预估正确，但有些工作则不然。

我们来想想不雅观看一小我私家弹吉他。即使你从来没有弹过吉他，在不雅观看了一场弹奏《玛丽有只小羊羔(Mary had a Little Lamb)》的吉他演出后，你也能概略猜测出这很简单，一小我私家不需要太高的技术就能吹奏出来。同样，当不雅观看了有人吹奏D大调的《卡农(Pachabel’s Canon)》后，你也很容易猜测出，这很庞大，需要很永劫间的操练才华吹奏的出来。

为什么我们能够很迅速准确的预估这两首曲子的庞大性呢？这是跟我们用来判断一个工作简单和还是庞大的要领有关的。我们的大脑有一些现成的模式 来完成这些工作，首先一个就是按照速度。这种情况下，大脑会鉴别每秒钟吹奏的对象。按照每秒钟吹奏了几多对象，我们很容易有一个直不雅观的判断曲子的庞大度。因为用吉他吹奏一首歌是一种物理过程，一种感官上的勾当，我们的大脑很容易依此来猜测速度，继而转换成庞大度。

我们还有此外一个天生的猜测依据：体积。想想把一个帐篷和一栋公寓放在一起比拟。即使一小我私家从来没有学过建筑学，他也能报告你凡是设计和建造一个帐篷会比设计和建造一栋公寓要简单。为什么？因为我们天生的会使用物理体积作为事物庞大性的一个指标。

固然。上面说的这两种逻辑分析并不是总是100%的有效。但大大都情况下，人们就是这样干，而且很告成。大大都情况中，我们在对物理过程评估时，我们的大脑会对物理事物进行有效的关联，不需要依赖之前的经验。

此刻让我们来谈谈软件。当一个不懂技术的人试图对软件开发时间进行评估时，有两个很根基的直不雅观指标在帮助他们：以体积为指标的庞大度和以速度为指标的庞大度。但他们没有意识到，软件跟他们想象的不一样。软件素质上不是有形物质。没有体积和速度。它的极小的构成部分可能会时时时的在电脑屏幕上闪现。正因为如此，对面对开发一个web应用时(或任何类型的软件)，我们的根基直不雅观觉得掉效了。

这第一点，速度，很显然根柢不成能被外行人拿来对软件进行评估。于是很自然的，他们倾向于使用体积指标进行评估。要么是按照描述文档的页数，要么是按照软件的成果用例数或特征数。

有时候，这种评估手段确实有效！对面对一个静态网站，没有特另外设计要求，外行人很容易用这种要领预计出开发时间。但是，凡是情况下，对付软件开发，体积并不能真实有效的反应庞大度。

不幸的是，对付软件的庞大度，独一有效的猜测要领是依据经验。而且还不是不时都好用。作为一个措施员，我知道，按照我之前开发过的相似的成果特征，我可以预计呈此刻的这些成果特征各自要几多开发时间。然后，我把总时间加起来，这就得到了完成整个项目需要的大抵时间。然而，事实情况中，每个项目在开发过程中都遇到二、三个瓶颈。这些瓶颈会肆意的消耗措施员的大量时间，你在遇到它们之前根柢不会有所预见。它们会拖住整个项目，致使工期延后数周甚至数月。

这些是没有经验的人在评估庞大度时不会理解的。他们不大白在其他工作上都很灵的要领，为什么放到软件开发上就不灵了。所以，下一次当你听到有人说“我想你几天时间就能把它开发出来”时，不管是谁说的，都不要烦恼。深呼吸一下，报告他这篇文章的地点，本身该干什么还干什么。