“这个网站相当简单，所有你需要做的就是完成X，Y，Z。你看起来应该是技术很好，所以，我相信，你不需要花费太多时间就能把它搭建起来。”
我时不时的就会收到这样的 Email。写这些邮件的人几乎都是跟技术不沾边的人，或正在研究他们的第一个产品。起初，当听到人们这样的话，我总是十分的恼怒。他们在跟谁辩论软件开发所需要的时间？但后来我意识到，即使我自己对自己的项目预测要花去多少开发时间，我也是一筹莫展。如果连我自己都做不好，我何必对那些人恼怒呢？
真正让我郁闷的不是他们预估的错误。问题在于他们竟然认为自己可以做出正确的估计。作为开发人员，我们经常会发现，在软件开发的问题上，一个外行人会很自然的把复杂的事情估计的很简单。
这并不是为我们的愤怒找借口。但这引起了另外一个有趣的问题：为什么我们天生的预测复杂性的能力在遇到编程问题时会失灵？
为了回答这个问题，让我们来认识一下我们的大脑如何估计事情的。有些事情对于一些没有经验的人也很容易预估正确，但有些事情则不然。
我们来想想观看一个人弹吉他。即使你从来没有弹过吉他，在观看了一场弹奏《玛丽有只小羊羔(Mary had a Little Lamb)》的吉他表演后，你也能大概推测出这很简单，一个人不需要太高的技术就能演奏出来。同样，当观看了有人演奏D大调的《卡农(Pachabel’s Canon)》后，你也很容易推测出，这很复杂，需要很长时间的练习才能演奏的出来。
为什么我们能够很迅速准确的预估这两首曲子的复杂性呢？这是跟我们用来判断一个事情简单和还是复杂的方法有关的。我们的大脑有一些现成的模式来完成这些事情，首先一个就是根据速度。这种情况下，大脑会辨别每秒钟演奏的东西。根据每秒钟演奏了多少东西，我们很容易有一个直观的判断曲子的复杂度。因为用吉他演奏一首歌是一种物理过程，一种感官上的活动，我们的大脑很容易依此来推测速度，继而转换成复杂度。
我们还有另外一个天生的推测依据：体积。想想把一个帐篷和一栋公寓放在一起对比。即使一个人从来没有学过建筑学，他也能告诉你通常设计和建造一个帐篷会比设计和建造一栋公寓要简单。为什么？因为我们天生的会使用物理体积作为事物复杂性的一个指标。
当然。上面说的这两种逻辑分析并不是总是 100% 的有效。但大多数情况下，人们就是这样干，而且很成功。大多数情况中，我们在对物理过程评估时，我们的大脑会对物理事物进行有效的关联，不需要依赖之前的经验。
现在让我们来谈谈软件。当一个不懂技术的人试图对软件开发时间进行评估时，有两个很基本的直观指标在辅助他们：以体积为指标的复杂度和以速度为指标的复杂度。但他们没有意识到，软件跟他们想象的不一样。软件本质上不是有形物质。没有体积和速度。它的极小的组成部分可能会时不时的在电脑屏幕上闪现。正因为如此，当面对开发一个 web 应用时(或任何类型的软件)，我们的基本直观感觉失效了。
这第一点，速度，很显然根本不可能被外行人拿来对软件进行评估。于是很自然的，他们倾向于使用体积指标进行评估。要么是根据描述文档的页数，要么是根据软件的功能用例数或特征数。
有时候，这种评估手段确实有效！当面对一个静态网站，没有特别的设计要求，外行人很容易用这种方法估计出开发时间。但是，通常情况下，对于软件开发，体积并不能真实有效的反映复杂度。
不幸的是，对于软件的复杂度，唯一有效的推测方法是依据经验。而且还不是时时都好用。作为一个程序员，我知道，根据我之前开发过的相似的功能特征，我可以估计出现在的这些功能特征各自要多少开发时间。然后，我把总时间加起来，这就得到了完成整个项目需要的大致时间。然而，事实情况中，每个项目在开发过程中都遇到二、三个瓶颈。这些瓶颈会肆意的消耗程序员的大量时间，你在遇到它们之前根本不会有所预见。它们会拖住整个项目，致使工期延后数周甚至数月。
这些是没有经验的人在评估复杂度时不会理解的。他们不明白在其他事情上都很灵的方法，为什么放到软件开发上就不灵了。所以，下一次当你听到有人说“我想你几天时间就能把它开发出来”时，不管是谁说的，都不要懊恼。深呼吸一下，告诉他这篇文章的地址，自己该干什么还干什么。
阅读总结：
一、为什么老板问软件开发的员工，你大概几天能弄好。有时候下面的人没法给个明确的时间确定？因为：对于软件的复杂度，唯一有效的推测方法是依据经验，假如我以前开发过相似的功能，那么我完全知道大致多长时间能够完成。假如，我没做过这个功能。我不知道在做的过程中会遇到哪些技术障碍点，或者困难。所以我怎么预估呢？
这就像：创业的老板们，如果你没做过这项生意，那么就意味着你没有类似的经验，你能预估你多长时间赚到x万吗？你永远无法。你也是心里想：我试一试吧。我不知道其中会遇到哪些障碍。实际情况是，有些老板做一项生意，可能因为一个细节没把握好，全盘就输了。如果你做过a行业，在此方面拥有丰富的操作经验，你当然能够提前只会存在哪些困难，提醒自己哪些方面不犯错。
我理解是，不管怎么样。去做，去尝试就对了。就能把事情前进一步。
二、虽然作为外行，去判断内行东西是否复杂，我们的大脑常常是根据两项指：速度和体积。软件是抽象的东西。与能摸得着的建筑相比，不能用体积去判断是否复杂，实现时间多长。评价复杂度，评价时间是依据经验。解决问题的经验，知识应用的经验。
三、为什么，有时候一个功能暂时做不出来，老板逼也做不出来(是可以做出来，先糊弄一下给你看看过关，以后扩展性暂时不给你考虑了)。这是依据经验和知识来的。所以逼也没用。逼只会让老板你自己吃亏，程序被逼着为完成任务优先，细节办法替你考虑太多了。
看京东的技术架构：http://www.zhihu.com/question/19818863，里面分析，有一点是非常符合程序员的心里，原文如下：
京东的系统的问题，明显是自己架构和管理的问题。这个东西不能说得太细，不然就泄露机密了。 呵呵。
1）首当其冲是管理者的问题。不觉得技术重要，不听技术人员的建议，急功近糙，超，快，猛。
2）其次是开发团队的人的问题，乱来。当然，有客观条件和上级逼着他们不得不乱来。
//////////////////////////////////////////////////////////////////////////////////////////////////
四、为什么老板看a网站有这功能，然后要求手下的技术，你也实现这个功能。结果技术给出答复是：实现不了。或者很难实现。于是一些老板就心里很纳闷：为什么别的网站能够实现，我们网站就是实现不了。或者：别的网站一天就实现了，你们怎么改、调整3-5天，可能还没搞定，神马原因啊？？
一个原因是，第三点说到的，之前一直逼技术，为了赶速度啊，然后程写着就先凑合，应付一下(没办法，做技术同行都懂的)。没必要责备。老板你不懂，就要尊重技术。瞎干涉只能这样了。
应付一下之后，后面要修改，增加一个新功能肯定没那么容易。这就是专业上说的：可扩展性。
架构不同，修改和实现起来的成本当然是不同的。
很像现实中的：a栋房子与b栋房子，建造和设计结构不同。你要想修改，必须适应房子的整体结构去修改，因为要适应现有结构，当然就出现了，不是你想做成什么样就什么样。当然可以完全按照自己思路做。那就重构一下。专业术语中的重构，我觉得对应到房子建造就是-推倒房子重新建造。这个可以做。如果当前的系统，简单的修改，增加新功能已经变成一种负担，甚至无法实现；改来改去，都跳不出原来的圈子，被原来固有的结构限死发挥。就推倒重来吧。
五、没做过技术的老板还是有必要去了解各种岗位的东西，不说熟悉，熟悉没那么多的时间，了解有助于沟通和管理。不了解也没事，那就要足够的尊重。你只要告诉技术，我要这样的效果，这样的功能。然后让技术根据当前系统的情况，实现起来时间成本要多少。时间成本是否在你可接受以内。因为往往，一个功能实际上可能只会用到20%，用处不大，浪费了大量的开发成本。
其实，只要做过任何技术工种，比如平面设计，程序，家电维修，医生等，大家在沟通的时候，就有种知己的感觉。因为技术工种是相通性的。思维模式往往是不被外行理解。
比如，我知道医生，他也是人，他只是掌握了医学知识，但掌握医学知识与诊病是两码事，诊病是靠丰富的实际经验。哪怕你是医学博士，只是表示你理论知识多少。诊病是一种复杂的判断，在实际情况中情况复杂的多。知识只是有助于你判断。有些家传的民间医生，他们虽然没足够的医学知识。但是诊断一些病掌握了实战经验，仍然能诊断。
