园子里面出了篇文章，感同身受，特此记录。
英文原文：How long would this project take?
这个问题是我最常碰到的一个，也是我最难回答的一个。对这种问题最好的回答方式是用全职员工来推算天数。这非常容易，你只需要找出有多少个不重叠的功能特征，然后每个人负责一个。一旦各个功能块被分成了不能再分的任务，你计算需要多少人天，这就是你的答案。你无论如何都不可能用比这更少的时间开发完这个项目。
“一个女人生一个孩子要 10 个月，不论你再增加多少个女人来做这事，都不会缩短这个时间”
“只有当一个任务的完成可以分配多人，并且不需要他们之间相互交流合作的情况下能完成时，人和月才能互相替换。”
“往一个已经延迟的项目里添加程序员只会使项目进一步延迟”(因为项目中现有的人需要培训新来的人)
不幸的是，大部分人只想知道一个项目需要多少时间完成。这实际是个伪命题，因为 90% 软件成本的产生是发生在软件发布之后。这些费用会产生于修复 bug、增加欠缺的功能、性能的改进、对新平台进行支持(安卓就是一个大债主)或重写质量差的老代码来减少技术债务。即使是项目发布前，对于如何合适的处理每一种报错情况，这也是无法预先估计全的。从某种程度上，你就是被别人问了这样一个问题：“我有一个问题，我想解决它，但我无法说清问题是什么。请问解决这个问题需要多少时间？”
尽管预估很难，但程序员最终要找到一种预估的方法。虽然无法知道一个确切的答案，但我有 3 种方法能大致估计出一个软件项目要花多少时间：
- 想要搞清楚一个事情需要多少时间完成，这最好的方法是找一个程序员已经完成的、相似的项目。对一些简单的网站和应用来说非常有效，或者那些使用标准 CRUD 的项目也是适用。当项目小且简单时这种方法最好用。这种方法可以用在软件 1.0 版本时，但以后的版本就不行了，因为这时你跟相参照的项目开始慢慢的产生差异，这时写的代码是你以前没有写过的。
- 我的好朋友、并且是以前的同事 John Walker (不是这个 John Walker)喜欢用这种方法。把项目拆解成最小的任务。然后记录完成每个任务你认为可能需要多少小时、天、周、月。遵循这种原则，如果一个任务需要几小时，就是算成一天，如果需要数天，就是算成一周，如果是数周，就算成一月。如果超过一个月，那你就无法知道需要多少时间了，或你根本不知道要做什么。
- 我有自己的预估方法，但事实上跟 John 的把任务拆分成最小的子任务的方法非常相似。我是以最坏的情况下每个最小单元需要的完成时间为标准。汇总，然后乘以4。再向上取舍到最近的素数，就算是对我的这种没谱的方法的讽刺吧。
对于大型的、独特的项目，程序员几乎无法知道它需要多少时间开发。它就是像在问“需要花多少时间能找到治疗癌症的方法？”然而，大部分的管理部门都拒绝接受这种答案，于是，程序员只好玩一些花招，先弄清楚老板们希望听到的时间，然后加入一些余地。还能有什么办法？通常都是超近路，这都是因为要去追赶那个本不应该设置的最后期限。你需要明白，预估是困难的，需要运行计划上的变更。除非你的程序员能将任务拆分小于一个月的子任务，千万不要在软件发布时间上做任何市场活动计划。
这最后一件需要注意的事是，当你在一个现有的软件(比如 2.0 版，3.0 版….)上增加新功能时，你需要追加 20% 用来对现有代码进行重写的时间(程序员称之为重构)。这是为了偿还技术债务，或为未来的行动铺路。人们以为 Google 是拿出 20% 的时间用来创新，但我敢打赌，其实这大部分是来偿还技术债务的。
估计一件事情要花多少事情是非常难的，通常也是不可能的。虽然你曾在一些小项目上有成功的预测，但随着项目的发展你会感觉到越来越难。一个好的方法是给程序员留足额外的时间。很多年轻的程序员通常没有这方面的经验，所以，项目经理必须把他们估计出的时间乘以4。