关于项目进度计划延期的分析

关于项目进度计划延期的分析

在我个人看来，在众多公司的项目中，项目的进度估计虽然具有一定的依据，也参照了一定的依据，包括经验，也遵循了一定的流程，但是还是存在许多不足之处。除了用户方的原因(在此不做讨论)，在我看来主要问题出于以下几点：

1 软件开发计划制定中的几个问题

1.1 详细设计不彻底

详细设计的不彻底，导致开发计划制定后执行的空洞，从而无法真正实现计划的实现和监控，大多的情况是在不断的弥补，或者进度的追赶，从导致代码的质量无法保证，甚至亦无法保证功能的实现。

1.1.1 详细的设计的不足

很多开发人员在接到开发任务后，担心不能及时完成任务，在匆忙做完了概要设计(其实此时的概要设计可能根本不能满足需要)，以没有时间为借口，直接进入到编码阶段，没有对软件系统进行更为详细的设计，从而导致了对开发中出现的问题没有做出相应的应对措施。而且在出现问题后，对问题认识的不足(包括担心问题的出现会使自己的技能被别人否定等)，和解决方法的缺乏，从而导致了问题的堆积和时间的流失，到最后使得项目的进度不得不发生了延迟。众多公司的项目和产品中普遍存在这个问题。

1.1.2 详细设计应该达到的地步

详细设计应该能够达到一个这样的地步，比如，在一个模块所需要实现的功能基础上，对此模块再次进行的详细设计，以至不可再分，甚至可以细化到可以实现的某一个具体的函数、类、属性等之上。而且不遗漏细节! 比如页面设计可以以页面为单位进行详细设计，从而细化到每个页面大概需要实现的基本要素，包括多少个按钮、列表框、输入框等，以及每个页面中的功能点，包括需要连接的数据库等。这样每个页面的具体时间就能准确的确定，并被执行。且需要做出一个网页的设计图样，共项目评审使用。比如图形制作可以以每幅

图为单位进行详细设计，从而可以细化到每个可能需要实现的基本要素，包括道路等各项图形要素，以及功能点等。这样每副图形制作的具体时间就能准确的确定，并被执行。亦可以做评审使用。

1.1.3 重物的称量

试想，我们需要称量一个重物，如果没有磅秤，只有弹簧称，那么我们只能将此重物进行分割，方能知道此重物的重量，而且需要保证在分割的过程中没有损耗。否则就需要进行一个定量的、适度的估算，比如百分比等，以弥补分割过程的损耗。

在这个比喻中，我们把重物看成是个项目，分割重物的人是项目经理或系统分析人员，称量的人则是实施开发的人员，分割过程则是项目开发过程。

如果在分割重物的人，没有具备分割的能力，重物的重量将会远远偏离其实际目标。

如果称量重物的人，没有具备称量的能力，重物的重量也会偏离其实际目标，只不过相对于分割重物的人的不称职，离目标可能会近些。项目管理者联盟文章，深入探讨。

1.1.4 西瓜籽的计算

有时候我们开发项目的过程也像一个计算西瓜籽的过程。

看下面的过程，根据西瓜向阳一面多籽的特性，确立西瓜的中心线，然后将西瓜籽分解成阳面、阴面的两部分，再根据中心线与阳面、阴面的距离，将西瓜进行多次分块，直到我们能够较容易得数出西瓜中的西瓜籽。这样我们可以对所有的西瓜块进行分类，这样就能够很快的得出西瓜籽的数量。如果我们对西瓜的结构很是了解，那么即使有些误差，但也会相差无几。

在这里，西瓜是我们需要建立的系统，西瓜籽是我们所需要实现的功能，西瓜籽的数目则是我们的时间，对西瓜的分块和分类则是我们的进度安排。而我们只有采用科学的方法，才能快捷的获得一个较为准确的项目进度计划。

另外，还有一个含义，就是如果想要知道西瓜籽的数量，我们必须切开西瓜，才能知道。

而且分得越细越准确。具体所需要分的块数也取决于西瓜的大小和切西瓜的人的经验。

1.2 开发技能的估计不足

开发技能的不足也经常阻止了计划的顺利执行。

1.2.1 非项目小组成员

在很多项目进行开发之前，项目组成员采纳项目评审小组意见的时候，非项目小组成员并非真正、彻底的了解该项目的实际内容，或者了解不彻底，因此他们的经验和意见使得项目组在决定项目将要使用到的开发工具和技术的时候容易估计不足，也可能导致项目的进度延期。

1.2.2 掌握的新技术和技能

在项目中，项目组成员如果不能满足对工具的熟练程度，那么项目的开发计划是需要及时跟进的。如果进度不能如期进行，或者开发人员在额定的时间内，掌握的新技术和技能不能满足要求，需要重新且及时的进行分析。

1.2.3 开发人员技能汇报

如果不及时跟进开发人员技能的掌握程度，而且直接开发人员也不及时进行汇报，将会导致项目进度延期的无法抗拒。

不仅仅技能不满足要求时沟通不够，也有其他方面的沟通不足，也会导致项目的进度也可能受到影响。

1.3 关键技术分析不透彻

在一个项目中，如果对关键技术分析不够透彻，用一种模糊的观点，抱着试试看的心态，也可能导致项目计划执行难度较大。

这个与“详细设计不彻底”有些相通之处，但不完全相同。

比如，yyyyy项目，它就存在一个对关键技术分析不透彻的问题，也存在“详细设计不彻底”的问题。因此，拟定的计划是模糊的，不可执行的。开发人员凭着自己的经验和智慧，解决开发当中遇到的问题。

1.4 开发经验总结不足

对于同样的一个项目，同样的一个功能，在进行多次的复用后，其技术应该已经较为成熟，其功能的实现也应该较为容易，出错率也应该较低，我们进度应该比较有把握，但事实情况并非如此!

那我想，也许是我们对开发的经验总结不够!

我们是否可以做一个这样的统计：

在一个我们现有的项目开发过程中，我们进行了多长时间的编码工作，其中没有任何修改操作的时间为多长，因为用户需求的更改而导致的代码修改时间为多长，因为设计的修改而导致的代码修改时间为多长，因为功能实现的错误而进行的代码修改时间为多长。

所有时间的综合在没有进行修改的情况下项目所花费的时间引起代码修改的原因用户需求更改的情况下项目所花费的时间设计发生修改的情况下项目所花费的时间功能实现的错误的情况下项目所花费的时间测试发现错误的情况下项目所花费的时间花费的时间也可以做出图表。

从这样一些统计和总结中，也许我们可以看出，我们进度的延期最主要的因素是什么;除了客户因素之外，我们还可以做那些努力;我们不可忽略的因素是什么。

2 软件过程调整