对如何估算时间的一点想法

这是我对知乎上题为“一个产品经理怎么跟工程师沟通时间进度问题？”的问题给出的回答。原帖在这里 http://zhi.hu/d6Nj

我对如何估算分配给我的任务需要花多长时间一直心存疑虑，每次我的经理问我这个问题的时候我都没法自信满满给出一个让我觉得有把握又不浪费的时间。

我在目前的公司做开发9年了，几乎没出现过延迟交付，很少需要靠加班来避免延迟。但是我还是对准确估算时间这件事感到困惑，因为我感觉能够达到上面效果的一大因素是，我们公司并不是一个节奏很快，压力很大的公司。在这样的气氛下允许开发人员给出一个相对安全的估算时间，相对的我觉得付出的代价就是开发效率有些低下。下面说一些我认为对准确估算时间有帮助的建议吧。
第一先达成前提再开始估算。我觉得开始进行时间估算的前提有两项，一明确需求，二明确采取的方案。明确做什么和怎么做之后才能谈花多少时间的问题。对于技术人员来说有过相关经验的任务可能很快就能确定技术方案。但是对于缺乏相关经验的全新任务提出可能的技术方案，验证可行性本身就是一个耗时的过程。这个时候一个选择是交给更有经验的人来确定技术方案。另一个选择是先别忙着估计时间，先安排一个调研任务吧。给出一个限定的时间，1周，2周，1个月。如果在限定时间之后对于怎么完成预期的目标还没有什么靠谱的想法的话，放弃这个这个项目不见得是什么坏事。
第二，谁去干活就交给谁去估计，不同开发人员之间的效率可能相差几十倍。
第三，大任务分解成小任务进行估算，但是要为把小任务集成起来预留时间。我觉得任务的粒度分解到1至2天比较合适。
第四，工作效率是有弹性的，压力大一点，可能效率能高一点。但是效率不可能随着压力无限提高。压力下的完成时间不见得是个准确的时间，这次完成了，下次不一定能完成。这次完成了，过程很痛苦，下一次也许就不愿意完成。对效率的追求应该是整个团队的价值观层面的事情，通过让团队成员分享高效率带来的成果，让团队成员自发主动的在估算的时候给出一个尽量准确的时间，而不是一个尽量“安全”的时间。