作者 内容
 zlwenny  项目进度计划延期的分析
　

项目进度计划延期的分析

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

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

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 市场人员交流的技巧
我并不知道市场人员在交流的时候使用了什么样的技巧，但是市场人员的营销技巧和交流技巧确实对我们在争取项目的主动权上有着至关重要的作用。

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

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

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

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

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

不尽之处，多多！ 请您点拨——
　
 04/02/06 13:41 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  软件过程改进建议 回复: 项目进度计划延期的分析
　

软件过程改进建议

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

1 改进用户需求过程
1.1 改进用户需求的获取方式
1) 研究用户特点
2) 成立需求调查小组
1.2 改进获取用户需求的态度
1) 正式的外部文档方式
2) 正式的提交过程
1.3 改进用户需求内容准备工作
1) 专业的用户需求调查表单，力求取得用户的配合，由用户或需求调查人员填写表单
1.4 改进用户需求的内外部沟通
1) 用户需求的分析、总结，须及时反馈到用户方，以取得及时而有效、满意但不多余的需求
2 改进需求分析方式
1) 改进需求分析的前提条件——正确的获取用户的需求
2) 针对不同类型的系统采用不同的需求方式和模型，更有助于界定需求的范畴
3) 及时总结、改进需求分析方式和模型，形成需求分析模式库
4) 复用和改进需求分析模式库
5) 加载有效的、适用的、先进的需求分析理论于经验分析基础之上
6) 改进项目组内需求分析的沟通和流通
7) 在需求分析初始，尽早分析需求的可行性，并作备案
8) 对不适当需求，与用户沟通，以取得理解和信任
9) 对不合理需求，协调用户，以降低成本
10) 需求一旦获得认定，尽快进行系统分析和设计
11) 及时有效的控制需求的变化，防止对需求随意的更改和增删
3 改进系统分析和设计原则
1) 以最小的代价实现系统
2) 以开发人员最熟悉的方法、技术和工具实现系统
3) 尽量采用先进的方法和理论，以适应发展的需求
4) 在系统的相关处，与具体的实施人员进行及时有效的沟通，寻求实现的最佳途径
5) 以简单、易懂的方式进行分析和设计
6) 以简单、易懂的方式表现系统
7) 系统分析的方式要易于复用，并及时进行调整、改进，系统系统分析库
8) 对系统的分析、设计加以控制、遵守，防止系统结构的随意更改
4 改进系统的实施和验证
1) 确保在取得共同的理解后才进行系统的实施和验证
2) 系统的实施和验证遵循一定的流程，以约定的方式进行沟通
3) 系统的变化能够以多种不同方式进行沟通，以确保变化被告知、并被认可
4) 确保在系统的实施和验证过程中，所采用的方式和方法是易于理解的，且不易发生变化
5) 系统的实施和验证完成标识明显，易于被相关人员识别
5 改进用户验收被动局面
1) 理解和支持用户的行为
2) 取得用户的理解和支持
3) 对系统进行充分的验证
4) 提高系统安装的成功率和速度
5) 改进系统界面，使系统直观、有效
6) 保证进度，提高诚信度
6 改进系统维护过程
1) 对用户进行有效的培训
2) 快捷、有效、合理的处理用户的问题
3) 跟踪问题，形成问题库


不尽之处，多多！ 请您点拨一下——
　
 04/02/06 13:42 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 spide   很难用条块分割方法管理好项目进度，应该有更高层、强迫开发过程更有效、更能参与竞争的东西。通常我们迅速给用户实现一个初级的版本，也许仅仅实现了几分之一的功能，但是这些功能非常有吸引力，在以后的各版本中也同时升级和美化。以后的各版本也是如此。
　
 04/02/06 17:13 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  等完成详细设计才定计划不现实也不好，基本的详细设计完成后，计划应有一次修正，但出入不应太大，因此，计划是否准确取决于项目经理的经验和洞察力。
　

其实，大部分项目失控虽然表现为技术原因，但根本原因在于pm的调控能力和洞察力太差所至，另外，pm的管理艺术也是一个问题。
 04/02/06 22:58 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 等完成详细设计才定计划不现实也不好，基本的详细设计完成后，计划应有一次修正，但出入不应太大，因此，计划是否准确取决于项目经理的经验和洞察力。
　

项目的管理内容太多，范畴较广。

只针对项目进度延期进行分析，不针对计划的制定进行讨论。

因此我们，可以假设项目的计划是在不停地进行修改、调整。

但是不管怎样，延期就是一个更改的事实，延期就是项目执行的效率低下的表现。

至于，项目管理过程其管理者的艺术和能力是促进项目有效进行的重要因素。
 04/02/07 16:05 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  呵呵，是你先谈的计划，不是我。
　
 04/02/07 16:10 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 呵呵，是你先谈的计划，不是我。
　

你好！

我是对计划延期的分析。嗬嗬！
 04/02/07 16:11 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 smilemac  俄，那你说的不错，详细设计不足是会导致计划无法执行。
　
 04/02/07 16:21 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  关于需求变更
　

1. 当你问用户时，你有什么需求时，用户自己也不知道；当你把需求文档呈现给用户时，用户也不能确定；但是，当你把一个可以简单使用的系统拿给用户时，用户会挑出若干问题， 提出另外若干需求。

2. 在把业务目标和需求分解成对软件的需求， 在人和计算机系统之间分配责任，在确定计算机管理的严格程度上，很难做出具有先见之明的决策。

3. 世界在变，企业所处的市场在变， 企业也在变，企业所采用的软件系统也需要不断的变化来适应企业的变化。

 04/02/12 13:33 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 关于需求变更
　

观点非常准确。

需求变更，本事就是一种，需求。（鹦鹉学舌了，嗬嗬！）

变更的方法，就只能控制变更。这与治水的方法背道而驰的。

当你明确告诉用户，某些需求，是目前的技术所不能解决的时候，她可能会要求提供另一种解决问题的方法。此时的主动权就在你手中。

你就可以建设性的提供用户需求，并引导用户提出需求。

重要的是，你对系统的把握程度，以及引导的方法。
 04/02/12 16:32 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  你帮用户提需求，这要求你比用户站得更高
　

你能够指导用户如何在计算机的帮助下安排作业流程，你能够指导用户如何利用计算机/软件来增加价值。 这需要何等的高度。

 04/02/12 16:35 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 你帮用户提需求，这要求你比用户站得更高
　

是这样的。否则，需求的变更将是长期的，随时的，巨大的。
　
 04/02/12 16:38 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  而国内对此的认识不足，人力资源上的准备更是不足。
　

国内的软件企业更在乎，如何把单子拿下来。生存是大问题
 04/02/12 16:40 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 而国内对此的认识不足，人力资源上的准备更是不足。
　

所以，有时候不得已而为之。

没办法了，只好大家再努力一点！都来提高自己。

水涨船高！
 04/02/12 16:45 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  我们开发人员中，即使是了解领域最多的分析人员
　

甚至是领域专家，也很难站在如此高度给用户进行指导。

 04/02/12 16:48 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 我们开发人员中，即使是了解领域最多的分析人员
　

兄弟，不是个人，是团队！
 04/02/12 16:50 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  是啊，可是团队的知识/能力不是个人知识/能力的汇集么。
　
 04/02/12 16:51 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 是啊，可是团队的知识/能力不是个人知识/能力的汇集么。
　

在这个方面，我真的不是很好。但是，有一点可以肯定，随着项目的扩展，相对应的技术人才的储备也要增加。否则，是不可能成功的。
 04/02/12 16:58 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  我曾经说过一句话
　

CMM真的很好，也许10年后今天看来很次的公司都实行CMM,可是今天就开始推行CMM的企业也许10年中就已经倒闭了。

虽然说， 我们要讲超前，但是更重要的是，如何在现行的游戏规则中取胜。

 04/02/12 17:01 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 我曾经说过一句话
　

稍微绝对了些！

重要的理解cmm的精髓！

它要求事务必须按照适当的规律，采用适当的方法，到达适当的目的。
 04/02/12 17:07 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  因为CMM对市场的要求， 对客户的要求， 对企业的要求， 甚至对个人的要求
　

都不是现在能够达到的。

现在需要的是一人当两人用，日生产率在80-200行/每人日，乖乖，如果能够有这个水平，美国制定CMM的那帮人应当到中国当学生来了。

 04/02/12 17:10 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 因为CMM对市场的要求， 对客户的要求， 对企业的要求， 甚至对个人的要求
　

谁这样制定了？

这样做就是扯淡！瞎胡闹！

这是一种不知其然也不知其所以然的人在作怪！
 04/02/12 17:14 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  解释一下
　

不是谁制定了，当时公司里一个统计结果是生产力40行-60行/日，某一项目组deadline比较紧，就提高到100行作为估算的基础，后来项目推迟，为了赶上进度，把100行调到更高的生产力，结果是....
 04/02/12 17:17 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 解释一下
　

不知道这种计算是怎么来的？

如果计算的code还包括dead code的话，而且不计用户的沟通和交流，后期的维护，等等，那完成的可能性是很大的。

在项目管理中，经验确实很重要。

但是，完全依照经验来进行一个项目的管理，可能会导致项目执行效率的下降。

当项目进度延误，依靠提高编码速度来完成项目，是经常发生的。

其实，可以采用一种较为变通的方法，部分完成，部分交付的方式。
 04/02/12 17:28 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  如果遇到变通的领导当然幸福了
　

我曾经做一个项目，立项时告诉老板按期做不完，要么增加人员， 要么减少feature,要么略微推迟一下。

告曰：不行，要努力按时，按质完成。 晕倒。

 04/02/12 17:33 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 如果遇到变通的领导当然幸福了
　

是这样的。
不要晕！

在这种时候，也就是没有办法的时候，我们制定计划的时候，要想清楚那可以节省时间就可以了！
 04/02/12 17:35 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  赫赫，这样的话最好的办法
　

就是不干
 04/02/12 17:37 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 eddiewang   可能还有风险预测及危机管理不足及沟通基点的变化，咨询？
　

可能还有风险预测及危机管理的不足，偶曾做的一个项目就是如此，在联合调试及部署阶段发生意外，导致项目严重超期。
另，与客户的沟通，可能是甲方（代表客户）与乙方（代表技术团队及市场人员）的出发点与切入点不同所致，随着项目的进展，甲方不断的了解项目及所用技术，甲方的基点在不断变化，所以，致使甲方对同一需求又有了不同的见解，也可能导致甲方提出的需求在发生变化。
偶现在正做一个项目，已经进行了一年之久，按照一年的进展情况，还需半年时间完成项目（已经比预期时间超出5个月了），而公司的规定只有三个月，（采用传统的面向过程的设计方式，开发采用的瀑布式开发，最初为迭代，但迭代失败了，设计阶段已经简化了，而且为平行作业方式）如何还能提高进度？

 04/02/14 12:54 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 可能还有风险预测及危机管理不足及沟通基点的变化，咨询？
　

你分析得很好。因为你做过。

这里牵涉到两个问题，当然应该还有更多的问题我没有考虑到。

1——用户需求的变更，正是如你所说一样，随着对项目的了解，其需求在不停的发生变化。因为用户在不停的进步。此时的需求变更，小则进度延期，大则进度变更。

2——项目的风险管理和进度延期是有本质的区别的。
由于风险所起的进度变化，它应该是隶属于一种进度变更的范畴，当然在另一种意义上也是进度的延期。
如果此时依旧拿着原有的进度计划来要求和评价，是完全不正确的。

其实很多项目即使在需求不发生变化的情况下，依旧发生了延期。所以我们需要改善我们的过程。参见我的过程改进一文（谢谢！）。
 04/02/17 11:15 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 eddiewang  回复: 可能还有风险预测及危机管理不足及沟通基点的变化，咨询？
　

实际偶认为这是概念的问题，而对于结果就是进度延期，这是无法回避的事实。你最后的话说的很好，风险引起的进度变化是进度变更的范畴。合同法中也强调了这个问题，不可抗力（合同法中明确规定了什么是不可抗力），换个角度来考虑，也就是除非遇到不可抗力，客户才允许你进行进度变更（很严格的哦，当然现实生活中也存在这样的客户，或者这也就成为了客户的借口），所以，在计划定制的时候，应充分考虑各种因素，无论是风险，还是需求发生变化或其它因素，进度变更最终会导致进度延期。
另你的过程改进一文在何方，想看，非常感谢！
 04/02/17 11:51 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 可能还有风险预测及危机管理不足及沟通基点的变化，咨询？
　

the last of this

(xie bu le han zi )
 04/02/17 12:43 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 leo-leo-leo  不用废话乐。 中国的项目延期， 多半是销售为抢单子，承诺的交货时间严重不足。
　

在中国的老板眼里， 10个好项目经理也顶不上1个好sales, 拿到项目就是大爷。 神仙都没法不延期。

 04/02/17 22:54 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 zlwenny  回复: 不用废话乐。 中国的项目延期， 多半是销售为抢单子，承诺的交货时间严重不足。
　

我并没有分析这个啊！
 04/02/18 13:28 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 eddiewang  按照你的思路扩展一下
　

照这个思路扩展一下，多半的项目拿下后，不可能按照正常期限付款，那是不是意味着就可以去延期了？还有很多项目尾款都收不上来，那是不是就可以没有期限限制了。实际是不太可能的。很多外部因素我们无需考虑。多分析一下自身原因吧。不过现在的老板们已经开始转变了。请多给他们一些时间和关爱吧。
 04/02/18 16:33 酷帖！    臭帖！    回复  
酷帖评价：           臭帖评价：
返回页首
 j2ee  回复: 软件过程改进建议 回复: 项目进度计划延期的分析
　

1 �