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

　　一.进度表失控的严重后果

　　进度表是项目完成所需工作的一个基本的、动态的计划表。进度表为具体工作提供计划和执行步骤，并在进行过程中设定里程碑，使我们可以将自己的进度和预先设定的完成时间相比较。因此，进度表的执行情况决定着项目的成败。

　　进度是项目开发的龙头，是一切工作的出发点。事实上，技术发展到今天，进度的重要性已经超过了技术本身。阿波罗登月成功首先是计划表的成功，其次才是技术。软件工程也是这样，系统开发技术的问题其实已经不再成为主要问题，问题在于我们能否将所有的问题或隐患考虑在内，并且一个一个地加以处理和解决。

　　(1)进度失控会扰乱规划

　　进度失控导致的直接后果是不得不推迟系统正常完成时间。这个后果会增加业主的负担，包括时间、人力、物力和财力的继续投入，严重时会造成项目停滞和搁浅。

　　(2)进度失控与质量失控相互影响

　　一般来讲，质量控制和进度控制是一对孪生兄弟，是相互起连锁反应的，进度失控可能导致质量失控;同样，质量的失控也会导致进度失控。

　　(3)进度失控会突破项目的计划成本

　　项目执行的进度拖后之后，需要投入更多的资源解决存在的问题，重新制定计划。即使工作量没有增加，时间的增加就是费用的增加，也就是投资的增加。

　　二.项目进度失控原因分析

　　为了确保项目顺利完成，进度表需要精打细算，避免项目每个任务滞后执行。然而，在项目执行时总会出现一些让人意想不到的事情，这些事情对项目的影响力是非常之大的。现在一一分析：

　　(1)任务本身估算出现偏差

　　进度出现偏差首先要考虑的工作量的估算是否合理，是否考虑了工作中存在的技术难点，是否考虑了项目成员自身的技能，是否考虑了其它应该考虑的风险。如果项目任务中存在着技术攻关或技术难点需要解决，对于这种任务往往是很难估计工作量的，而且一旦在技术问题上被卡住往往对项目进度产生致命的影响。具体表现在低估技术难度、低估协调复杂度、低估环境因素这样几个方面。

　　80-20原则在软件开发项目进度控制方面体现在：80%的项目工作可以在20%的时间内完成，而剩余的20%的项目工作需要80%的时间，但是剩余的20%左右的项目工作大部分是在后期。所以软件开发在进入编码阶段后会给人一种"进展快速"的感觉，使得产生了过于乐观的估计。当看到软件已经进行了80%，就象一块石头落地，心里想着"总算交差了"，同时又可能撤出一些被认为不必要的人力资源，这样的结果更是拖延了后期的工作。

　　(2)项目需求偏移

　　随着项目的深入，需求变更也越来越多。造成的后果是无论是删减、增加或者改变项目需求，都致使进度表发生相应的调整或滞后。例如，在需求分析前期，一方面是对于部分关键需求没有给予足够的关注，造成后期需要不断修正。另一个方面，在开发过程中总是眼光朝上，总是喜欢添加一些原先进度表规划所没有的东西，导致存在大量功能冗余，也导致进度表的失控。普遍存在的是有些项目组成员觉得反正我们都要花时间，就再增加几样东西吧，这会让我们的项目锦上添花。这样就积少成多，集腋成裘。不仅消耗了时间，而且也模糊了最初的项目需求。更严重的是，需求范围已经扩展到项目真正需要的范围之外。

　　(3)进度控制松紧不一致

　　在项目进行到一半时常常才发现时间不够用，进度表经过调整后，谁知道没过多久进度表滞后又来了。原因在于项目开始时前期太过拖沓，导致进度远远落后于进度表。

　　(4)进度落后时的"赶工"措施使进度更恶化

　　进度落后的情况下，有几种措施来弥补，如加人、加班、加激励等等，这些都是增加资源而又未必会见效的方法。这些后来参加者因为对项目不够熟悉，存在软件界一直说的"人月神话"的弊端，反而让滞后的进度表更滞后。因为对于新加入的员工来说，对项目相关背景、需求、设计的培训，对项目环境的熟悉和项目团队成员之间的沟通路径的增加，都可能会使工作效率急剧下跌。而加班造成的疲劳也会再次使工作效率降低，增加激励则会造成工作成本不断的向上攀升。这些措施并不是完全不可取，而是要考虑适度原则。

　　(5)程序员的心态因素对进度的影响

　　有两种常见的心态会对进度造成影响：一是技术完美主义、二是自尊心。技术完美主义是有些程序员做到一定程度后想到一些更好的构思，或者看到一些更好的技术介绍，或者是觉得可以更加优化，这样他们会私下或公开对软件进行调整，去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的任务并没有影响，相反可能带来不确定的隐患。这种做法不是以需求为出发点，可能对软件开发进度造成较大的影响。

　　另一方面，自尊心是有些程序员在遇到一些自己无法解决的问题时，倾向于靠自己摸索，而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室或论坛等方式匿名地向别人求教，运气好会很快地解决，否则要花很多时间去实践摸索。而向周围的人求教，可能摸索几天的问题别人早就曾经解决过。

　　三.避免进度表滞后的几点措施

　　最现实、最合理的进度表在项目进行中还是可能遇到麻烦。例如由于有一些事情的优先等级提高了，另一个本来进行得很顺利的任务现在却可能被放到了不重要的位置。一般来说，可以有好几个办法让进度表滞后的项目再回到正常轨道上来。因此，进度表滞后并不是不可以避免的。哪么，如何避免进度表滞后，保证项目如期完成?

　　(1)锁定需求，避免无休止的变更。

　　每一个项目都需要在开展之前锁定需求，不这样做必将会导致项目失败。在项目开发的过程中，多多少少都会发生一些范围变更，一定要严格控制这些变更，对这些变更有一个应对方案，把变更范围控制在可控范围内，不然便会出现很多并发症，导致进度表滞后和成本的增加。

　　例如明确项目需求变更的根本原则，避免将需求范围扩大化，将不确定和复杂多变的需求排除在开发策略之外。把需求定义为"必须的需求"、"应当具备的需求"和"锦上添花的需求"，严格坚守核心功能，并一直不断跟踪以控制在进度表范围之内。事实证明，只有做到了需求明确才能避免进度表不断滞后的恶果。

　　(2)重新检查进度表

　　项目进度表的一个很重要的前提是项目估算，项目估算最大的基础是基于经验值，而软件工程的经验值反映的只是业界的常规实践，并不能够反映每一个团队。因此，在项目估算时应该以自己团队历史经验值为基础，让项目团队中的每一个成员参与估算，这样才能够保证项目计划的可行性，从而避免出现系统设计与编码实现都超出进度表的计划估算。

　　同时，项目进度表不是一成不变的，而是应该根据项目的进展对一些新的需求、新的变化做出响应，动态的更新项目计划。例如，面对动态变化的环境，可采用迭代式的生命周期模型使项目开发团队更好地适应变化。如果进度严重滞后，看看能否在进度表中增加一到两个缓冲区，如果已经用光了所有的缓冲区，看看能不能缩短某个任务的时间或加快进行。同时，仔细检查进度表里有没有这样的步骤：他们可以锦上添花，但并不是项目成功的关键任务。现在就需要删除这些内容，可能最后的结果没那么精细，但去掉一些装饰物可以帮助项目走回正轨。

　　(3)有效的进度表检查工具

　　糟糕的执行会给项目带来在成本和时间两方面上的失败，这会最终导致整个项目的失败。很多失败的项目开发的教训揭示了能够充分地描述项目进度的检查工具简直太重要了。我得到的最宝贵的经验是要抓住项目开发过程中的关键环节，密切注意进展情况，一旦出现问题，应该马上能拿出切实可行的措施。当出现可能严重影响进度表滞后时，就应该根据现阶段状况重新评价需求分析结果、工数估算、设计结果等。切勿匆忙采取头痛医头、脚痛医脚的措施，致使进度表滞后更严重。

　　例如，根据里程碑完成情况编写项目进度报告时赋予里程碑标识进度值的功能。简单地说，就是让每个里程碑带上一个百分比，告诉团队通过这个里程碑说明项目完成了多少，这样项目进度报告上的完成百分比将显得更加真实和有意义。

　　(4)在各种项目目标中进行平衡

　　进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目进度、质量和成本构成一个相互制约的三角关系，需要去平衡。如果经过评估确定项目进度确实已无法控制，就应当下定决心以牺牲软件功能范围、工作成果范围、成本预算、进度计划或软件质量中的某一项目标为代价，来保住项目最重要的目标达成，最终确定一个最合适的解决方案。指望不采取纠正和干预措施，进度失控会自行消失的想法是不现实的。因此，如果这些项目参数超出项目目标的限制范围，就必须马上采取纠正措施;如果发现这些项目参数有超出项目目标的限制范围的趋势，就必须马上采取预防措施。

　　(5)奖罚制度的制定项目经理圈子

　　进度表的执行还必须有相应的控制措施来保证。例如可以制定一些奖惩制度，奖励是主要，惩罚是辅助手段，调动起所有人员的积极性。通过订立相应的评估指标，把项目执行作为项目人员的重要业绩进行考核监督，避免因为少部分人不配合工作导致项目整体延误，从制度上保障任务的顺利完成。