(2)项目需求偏移随着项目的深入,需求变更也越来越多。造成的后果是无论是删减、增加或者改变项目需求,都致使进度表发生相应的调整或滞后。例如,在需求分析前期,一方面是对于部分关键需求没有给予足够的关注,造成后期需要不断修正。另一个方面,在开发过程中总是眼光朝上,总是喜欢添加一些原先进度表规划所没有的东西,导致存在大量功能冗余,也导致进度表的失控。普遍存在的是有些项目组成员觉得反正我们都要花时间,就再增加几样东西吧,这会让我们的项目锦上添花。这样就积少成多,集腋成裘。不仅消耗了时间,而且也模糊了最初的项目需求。更严重的是,需求范围已经扩展到项目真正需要的范围之外。
(3)进度控制松紧不一致在项目进行到一半时常常才发现时间不够用,进度表经过调整后,谁知道没过多久进度表滞后又来了。原因在于项目开始时前期太过拖沓,导致进度远远落后于进度表。
(4)进度落后时的“赶工”措施使进度更恶化进度落后的情况下,有几种措施来弥补,如加人、加班、加激励等等,这些都是增加资源而又未必会见效的方法。这些后来参加者因为对项目不够熟悉,存在软件界一直说的“人月神话”的弊端,反而让滞后的进度表更滞后。因为对于新加入的员工来说,对项目相关背景、需求、设计的培训,对项目环境的熟悉和项目团队成员之间的沟通路径的增加,都可能会使工作效率急剧下跌。而加班造成的疲劳也会再次使工作效率降低,增加激励则会造成工作成本不断的向上攀升。这些措施并不是完全不可取,而是要考虑适度原则。
(5)程序员的心态因素对进度的影响有两种常见的心态会对进度造成影响:一是技术完美主义、二是自尊心。技术完美主义是有些程序员做到一定程度后想到一些更好的构思,或者看到一些更好的技术介绍,或者是觉得可以更加优化,这样他们会私下或公开对软件进行调整,去尝试一下新的技术。而是否使用这些新的技术对完成项目本身的任务并没有影响,相反可能带来不确定的隐患。这种做法不是以需求为出发点,可能对软件开发进度造成较大的影响。
另一方面,自尊心是有些程序员在遇到一些自己无法解决的问题时,倾向于靠自己摸索,而不愿去问周围那些经验更为丰富的人。有些人也许会通过聊天室或论坛等方式匿名地向别人求教,运气好会很快地解决,否则要花很多时间去实践摸索。而向周围的人求教,可能摸索几天的问题别人早就曾经解决过。
三,避免进度表滞后的几点措施
最现实、最合理的进度表在项目进行中还是可能遇到麻烦。例如由于有一些事情的优先等级提高了,另一个本来进行得很顺利的任务现在却可能被放到了不重要的位置。一般来说,可以有好几个办法让进度表滞后的项目再回到正常轨道上来。因此,进度表滞后并不是不可以避免的。哪么,如何避免进度表滞后,保证项目如期完成?