10、未考虑软件开发过程的循环、迭代特性
/ i! f, `' d- n/ F6 B/ W3 f {3 H 对软件开发的各个过程分类过于精细,制定进度计划时各项工作过于紧凑、没有弹性,造成的后果是,定期提交项目进度阶段报告的制度只有在表面上起到效果,按照计划的时间表提交阶段成果也只是在表面上起到效果。因为“上有政策、下有对策”,强行的规定会使人产生一些错误的认识:如在项目计划中“规定”某个时间只能做某某类别的事情,那么严格执行的后果就是编码阶段就不能修改文档;另外错误的“里程碑”概念可能会使大家轻易地相信上一个阶段的工作成果都是“通过评审”最终定稿了,而实际上可能只是因为时间到了该提交的人提交、该评审的人评审了。如果上下阶段是不同的人就根本不会去检查其中是否还有错误;如果上下阶段是同一个人,就可能非正式地修改上一阶段的错误,但占用的时间和精力却是下一阶段的,并且这样的修改时没有记录的。这样关于阶段进度控制的措施实际上只是在表面上有效。最为普遍的情况是,用户在合同中限定了提交软件系统的时间,实际上这个时间对完成项目任务来说是远远不够的,但计划只能按照合同来进行,所以要不用户让步,要不只能按照时间的约定提交实际上还未完成的软件系统,完成系统的安装,但这时候的“完成阶段任务”只是一个表面现象,系统虽然安装了,但可能是没有经过严格彻底测试的,也可能是只完成了部分的功能,省略了某些功能,有些是整块功能省略,有的是省略了某些功能的某个过程,如数据录入里面隐含的数据录入前缺省值设置、数据录入检验等功能,而是实现了比较粗糙的功能。这样,系统交付并不意味着项目的完成,而在项目交付之后还要花更多的时间。/ D4 y3 h; Y4 C/ m& x( M8 `1 [' Q, j6 r
/ e' s! t& A% z2 d
11、其他因素
5 _! j& G4 `- a) _% [8 G: W: V4 U7 \- H
以上这些因素是影响项目进度的几个主要方面,除此之外还有很多其他的影响因素。其实最主要的因素还是人的因素,这里的人包括所有与项目相关的人。项目经理的素质、管理者的水平、用户的因素、项目成员的因素等等,都会对项目进度造成影响,这是因为由于软件开发的特性。因为篇幅有限无法一一列举,只能在此分析一些常见的因素。
2 G R8 D1 ]' h- v, K
. N( d$ L0 m, \9 J+ n+ ] 不可否认,软件开发项目进度可控性还是带有一定运气成分的。特别是需要用户配合的那些软件开发项目,其可控性与用户的成熟度、软件应用领域的成熟程度和行业标准规范的完备程度有很大关系。关于可控性方面会涉及到一些与客户打交道经验,虽然我们说,顾客是上帝、以顾客为中心,但并不是说我们要把主导权交给他们,而关键是我们如何去主导、引导、把握。因此,项目控制的好坏与相关人员人际关系方面的经验也有关系。
0 k& B0 s' N8 R! A, \& q
6 t% A2 k8 s0 d' k2 S" w, Z, a2 z/ ^ 尽管存在很多不可控的因素,我们的任务是首先分清哪些是可以控制的,哪些是我们不能控制的。项目经理一是要尽量扩大可控的领域,减少不可控的领域,二是不要在“不可控”上花太多时间,而是多花一些时间把可控的工作控制好,做好防范措施,减轻不可控因素对项目进度的影响。3 o$ _1 r, q* U C' D
% C# l1 x3 u! o2 ?4 P" W
项目进入实施阶段后,项目经理的几乎所有的活动都是围绕进度展开的。进度控制的目标与成本控制的目标和质量控制的目标是对立统一的关系。项目的进度、质量和成本构成一个相互制约的三角关系,需要项目经理去平衡。
' s* S- ~' k: w. i) [. ]9 s; u0 k: Y5 S' B
二、项目进度控制的目的$ A5 z9 W5 p( j. L X' M3 u
" [: H' [& L% z5 g! l
项目进度控制和监督的目的是:增强项目进度的透明度,以便当项目进展与项目计划出现严重偏差时可以采取适当的纠正或预防措施。已经归档和发布的项目计划是项目控制和监督中活动、沟通、采取纠正和预防措施的基础。 |