最近换了家新公司，接了新的工作项目，有了新的项目经理（FSK工作过10年以上）。新项目是为一学校做业务系统，采用B/S结构，.NET开发。经过前期的需求调研之后，一起做出了数据表的物理模型。涉及到业务的大表和子表大概有40多个。两位老员工负责报表开发，我和另一个老员工负责除报表外的所有开发工作。应项目经理的要求，我的这位搭档根据表单数量估算了大概的工作量，平均下来大概每个表单估算了三到四个工作日，并制作成WBS，关键路径一出来，开发大概需要两个多月。

　　看着这个估算，我菊花一紧：“TMD这公司都是牛人啊？”  结果还没等到我开口说话，经理开始发话了：“这肯定不行的，一个表单又没什么难度，还要三四个工作日，这在FSK会被DIAO死的。要抓紧进度，两个月内必须完成，过年前必须结束这个项目。多加点班早点做完”。 我不敢说话了，TMD一山还比一山高，看来FSK的程序员都是大神啊。我就不好意思说在上个公司开发个表单至少要求一个星期了。

　　在深深佩服这些牛人的同时，我也在想千千万万像我这样普通的码农该怎么样来估算自己的工作时间，不然以后经理问起来，估太多了吧，说你小子工作效率真这么低下还是想偷懒；估太少了吧，自己加班加点做不完，还不被人理解。我开始上网查找同行们的估算方法，也研究了一些进度管理方面的知识。总的感觉，粒度还是太大了，一个工作包三个人/日，我们领导只会觉得这么简单的一个功能为什么要这么久，而不会去关心码农们实现这功能需要做的具体工作量。于是我决定做一个粒度精确到小时的表单估时模板，用来告诉领导为什么需要这么多天，每天都做了哪些事情，做这些事情需要CODE几个小时。我相信有了这个模板，就算得不到领导认同，至少也表明了自己还是有在做事的。

　　我选择了一个有10个字段的比较有代表性的业务表单，从开始到结束，精确统计了每个步骤需要的消耗的工时数。采用四舍五入法最终制作了如下的工时估算表：

　　因每个人员技术水平，经验的差距，所以表中的数据不能一概而论。相信有很多牛人会大大高于这个效率。但这绝对是我养精蓄锐后才能达到的效率了，我期望的工时应该是在这基础上*（1+100%）。

　　说了这么多，其实我也不太确定这样的工时估算是否准确。很想知道各位同行平时是怎么估算自己的工时的，或者项目经理是怎么给员工估算工时的。有没有更好的办法可以更准确地估算出整个项目的开发周期。