该帖子同步发自：(yanglinux的博客  访问该博客)

       Schedule，是个酒。酒能怡情，也最能伤人。罪不在酒本身，而在于不同的人！根据我多个项目的经历，资源严重不足（或人员离职）是最头疼的问题，需求蔓延和进度表超出100%-300%甚至更多是最常见的问题。

而项目进度表是任何可能出错事件的替罪羊。如果有人胡乱评估，弄错需求，或者有项目组成员生病了、离职了，这都是进度表的责任。

       但是，项目进度表又必不可少。它至少有三个作用：第一，是一个承诺，是对什么时候完成任务的承诺。进度表在参与者之间提供了一份合同，确定每个人在一个特定的时间内要提供什么；第二，是提供了一种能够追踪项目和把工作分成若干个易于管理的小块的工具，把工作分成小的任务，能够帮助团队更好地理解他们到底需要做些什么；第三，是鼓励每个人把自己的工作看做整体的一部分，并且全力把自己的工作和他人的工作结合起来。只是在实际工作中，我们很容易发现进度表的第一、第二个作用，我重点说说第三个作用。如果没有一个进度表来说明在某个特定的时间和日期内必须要完成某些任务，就不可能让大家相互团结和依靠起来。没有进度表，每个人只会关注他自己的任务，而不去考虑他的工作是否会影响别人。在进度表中，有一种心理上的力量，因为它对众宣布了某人要履行的承诺。

       要制作进度表，就必须做估算，而估算是相当困难的，这里面既有技术方面的原因，更有很多不可预测或我们无法左右的因素在里面。Schedule必不可少，而制作它又有很大的问题，一对极度的矛盾体。

       如果一个团队在开始一个项目的时候，就充分了解进度表可能出现问题的原因，并且采取措施去减少这些出错的风险，那么这个进度表就为成为开发过程中更加有用和精准的工具。要弄清进度表为什么总做不准，就必须找出最本质的原因。

       原因一，倒推法本身就有很大的问题。客户、市场部门甚至是我们自己在项目前期荒废了大量时间，而到了后面，眼看着做不完了，就用倒推法来处理。同样是甲方，有没有哪个病人对牙医说，我下午赶飞机，你两个小时之内把我的牙齿修好。牙医不把他骂翻才怪！ 思路都出了问题，结果能不出问题么？

       原因二，我们的估算过程有问题。是该先出需求、概要设计还是该先出计划？实际工作中，我们总是在项目还没有签合同（快要签了）就将计划按照用户方、监理方的要求做好并发给他们，当然这个计划是包括了工期和大的进度计划（总体）的。然后是进场做需求调研，再做设计。搞得我总是怀疑自己的智商只有60-70，不怪这个世界变化太快，而该反省我反应太慢。

       原因三，我们的估算方法有问题。经常是项目经理一个人拍脑袋后的一份文档，有时候半天就提供出来了。没有经过集体的研究，没有采用科学的方法，如PERT、三点估算法，参数估算法等等。总之，一切显得那么的草率，依据这样的结果做出的进度表误导了好些人，起到的副作用是显然的。我们处于一个躁动、功利和狂热的大环境中。

       原因四，我们喜欢按照固定思维来考虑问题。比如1人1天100行代码，那么3个人100天自然就是30000（100*100*3=30000）行代码，打个7折，也有21000行代码。你看，够低调了吧，其实早期我也经常犯这类错误。有考虑到夏天热或春节附近工作效率会低很多么？有将用户新需求蔓延的风险计划在内么？有设想到关键员工生个小病请假么？有应对员工离职的风险策略么？如果这些常见的都没有考虑，项目延期也是活该！

       当然，办法总是比问题多。既然可以提出问题，就有解决问题的方法。

首先，必须不要盲目的屈从“政治”的压力，假使技术团队足够强势，情况会是这个样子么？这个问题够大够广，还是从技术层面谈点实际的。

估算应该根据以前的生产率。

估算依赖于程序员、技术人员对项目目标的理解。

项目经理、程序员应该受到信任。

可以多个人从不同角度来进行估算。

规格说明书或设计质量应该达到做良好估算所需的程度。