以下是我经历过的工时评估的几种情况
-
产品直接找到开发，让具体开发自己评估
-
leader让开发自己评估
-
leader评估
-
领导拍脑袋决定2个月完成，在2个月的deadline内评估
最后那种情况，我希望你不多见，不然我对此真的表示非常遗憾了，因为这并不科学，长此以往是会出问题的。
那么我们平时是怎么估时的呢：
-
靠经验和能力与实际需求相结合
-
根据deadline压力
-
根据产品压力
-
根据领导压力
除了第一种，我希望你没有遇到过后面三种（但你应该遇到过）。第一种相对靠谱吧，但我认为不科学，可能是我偏执，但我总认为应该有更科学的方法论。因为直觉告诉我，就算靠我自己的能力和经验这事儿也不总那么靠谱。
于是我就在工作中不断找有没有更科学的方法，幸好，我找到了：PERT
第一次看到这种方法，是在一本书上（忘记是什么书了）。
什么是PERT?
PERT(Program Evaluation and Review Technique)即计划评审技术，最早是由美国海军在计划和控制北极星导弹的研制时发展起来的。PERT技术使原先估计的、研制北极星潜艇的时间缩短了两年。
定义不重要，我们看怎么用。
我用一个例子讲清楚，先看图：
我们把一个排期的需求按模块和功能分类，然后每个功能都去评估完成它的乐观时间，标准时间和悲观时间。单位是人/天。
倒数第二列 μ （mu）为期望完成时间，
它的计算公式是：μ =(O+4N+P)/6 其中O为乐观时间，N为标准时间，P为悲观时间。
倒数第一列 σ（sigma）为标准差
它的计算公式是：σ=(P-O)/6 其中O为乐观时间，N为标准时间，P为悲观时间。
你可以把这个表格的后面两列用公式设置好，填好前面的，然后一起计算出来。
最后，我们得到的结论是：开发时间预估为期望时间的总和（sum），预估的误差是在标准差总和（sum）之内。拿上图来说就是总预估时间为43人/天，在2个标准差之内。也就是说可能在46天完成，也可能在40天完成。
我个人觉得这样就比较科学了，另外从我以往管理上的亲身实践感觉是要比自己凭经验估计的要准，而且更弹性更有说服力。