俗话说时间就是金钱，在当今快速发展的社会里，更是如此。作为一个互联网从业人员，在平时做项目中进度、成本、质量这三点常常是很难平衡的。在管理进度时，有一道绕不开的槛那就是工时评估。
传统的工时评估法就是把所有的需求收集起来，排列优先顺序后，制定需求说明书，然后根据需求说明书画一个原型图，然后根据需求说明书制成wbs，开发人员会根据wbs里的内容结合需求说明书和原型图预估自己的开发时间，然后逐层往上汇报，把整个模块汇总起来，这就是一个项目的总工时。但是这时候就会有一个问题，就是往往开发人员会多报一些工时，每一个模块可能都会多报一些，这样汇总起来，工时水分的就会多很多，那么这种问题如何解决呢？就是在总工时的情况上，挤掉水分，但是挤水分应该挤掉多少呢？一般情况如果在项目工期允许下，可以少挤一点，这样一方面可以提高一些项目质量，另一方面在减少人员的流失率上会有一定的效果；如果工期很紧张，那么就需要多挤掉一些水分，但是项目的质量可能稍稍差一些，比如在一些可以是配置项的地方写死，在可维护性上会打一些折扣。
对于一些复杂的功能，上面的工时评估效果就一般，好的方法就是对于同一个模块，让多个开发人员根据wbs里的内容结合需求说明书和原型图预估自己的开发时间，然后把多个开发人员对于同一个模块的工时评估汇总，经过专家评审或者三点估算，评估出最后的工时，这样的好处是水分很少，评估的工时相对合理一些。但是这种做法缺点就是耗时长一点，因为几个人评估一个功能点还是要把几个人的评估时间汇总起来，综合评估一下，但是总体来说时间还能接受，还有一点就是在某些相似的模块上可以用类比法来评估，这样节省了一些时间。
在一些进度很紧张的项目中，工期的规定好的，范围也是规定好的，要想满足进度要求，一种方法是从质量上牺牲掉一部分，来满足进度任务。比如说在质量的可维护性上，代码的复用性上可能就要做的差一点，这样会赶进一些进度。还有一种做法是进行外包，但是外包有一定的风险。另一种方法是好好把合同看一下，查找一些前置条件，比如网络连接，相关的对接人员已经到位等等，大多数情况下是可以找一些前置条件来推迟一些时间的，而且有一些项目往往在自己团队内不需要这些前置条件就可以开工，这样也能够找借口顺延一些工时。如果前置条件都准备好了，也没有推迟的理由了，那么只好先把主要的功能做好，假设全部做好是完美，那么做了主要的就是完成，先完成重要的的功能。
