项目进度计划延期的分析【转】

luoyear

项目进度计划延期的分析

以下仅为一家之言，言辞、分析不周之处，敬请原谅！！

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

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 软件过程调整
根据以上的分析，我们可以对软件过程进行适当调整，尤其是针对开发中采用C/A/S结构的系统，从而来改变我们增强需求获取的目的性，而且需求获取也会变得较为明显和容易。

对公司已经经历过的软件过程进行分析从而决定在下一个项目中将要采用的软件过程。例如，对采用B/A/S结构的系统可以采用直接从界面和数据进行概要设计的方式，并以此来计算页面设计时间和数据库设计时间。而对于
其中所需要实现的其他的功能，则在每个界面当中进行详细设计，此时对每一个功能实现所需要的时间进行估算，这样就能够计算出整个项目的一个较为可靠的时间，根据用户的需要和需求功能实现的关联就能对项目进度有一个
适度的安排。

这样在概要设计中，主要对界面和数据库设计进行评估；而在详细设计中对功能的设计和实现进行评估。
3 市场人员交流的技巧
我并不知道市场人员在交流的时候使用了什么样的技巧，但是市场人员的营销技巧和交流技巧确实对我们在争取项目的主动权上有着至关重要的作用。

如果能够充分掌握开发人员的相关因素和公司现状，那么在前期获得客户沟通、需求获取、和项目的时间把握等上，后期的产品交付、验收等问题上，都可以获得一定的余地！

在这儿要需要说明！
不管你是公司的技术人员，还是市场人员，与用户交流的时候，你就是一个与用户在进行交流的市场人员，同理，不管是懂技术的客户，还是不懂技术的客户，他都是提供用户需求的客户！

市场人员交流是需要一定的技巧的，而掌握这些技巧就需要市场人员掌握相关技能。
对于技能和技巧的掌握，没有人天生就会，只有不停的进行锻炼，并经过相关的培训和实践。

思考以下几个问题：
为什么用户需求总是在发生变化？是我们不理解用户的需求吗？还是我们低估了用户？还是我们分析不到位？
如果用户的需求超出了我们的期望值，我们处理好了吗？我们是在敷衍，还是继续努力，让用户理解我们？

我们获得的与开发人员所需要的需求差别在哪里？我们了解我们的开发人员及其所拥有的技能？

不尽之处，多多！ 请您点拨——

刘洪鹏

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

如下表，进行一些数据的统计。
所有时间的综合 在没有进行修改的情况下项目所花费的时间 引起代码修改的原因 用户需求更改的情况下项目所花费的时间 设计发生修改的情况下项目所花费的时间 功能实现的错误的情况下项目所花费的时间 测试发现
错误的情况下项目所花费的时间
花费的时间

刘洪鹏

概要设计中，主要对界面和数据库设计进行评估；而在详细设计中对功能的设计和实现进行评估。

刘洪鹏

没有图  还老是提到下图  有问题   说实话  是原创吗

jjlgirl

分析得很透彻，要是版本能够附上图表就更好了。