在企业层面常常表现为：

① 草率确定项目人员

对于中小企业来讲，人员流动性高，岗位频繁调换是不争的事实。如果这种情况出现在项目中，将对项目造成致命的影响。试想一下如果一个项目，即使是个小型项目，开发人员三天两头调来调去，开发设计怎么可能实现?因此，企业要根据其项目的周期长短谨慎选择开发人员，保障其在开发过程中发挥的可持续性作用。

② 忽视隐性影响

项目一开始，项目组成员的命运就与项目的成败联系在一起。项目成败无疑会对项目组成员造成心理上、情绪上的影响。许多中小企业往往由于大型项目的大收益，只关注那些大型项目的成果，从而忽视了中小型项目。必然对项目组成员造成不良的隐性影响。最终影响项目实施。

在项目管理层面表现为：

① 草率的计划方案

企业往往由于项目规模较小，在项目开始之前没有认真地进行项目可行性和工作量的估计，便草率地制定开发日程表，不能正确预期项目难度，结果实际完成时间与估计完成时间往往有较大差别，从而使项目陷入困境。许多中小企业对于这种偏差的认识始终停留在是执行过程出了差错，然而根源却是项目的前端出了问题。

② 蹩脚的设计过程

从中小项目的特点来看，开发人员少，意味着不同人员的程序之间交互、接口相对少一些;开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者虽是小项目的优势，但却都让人容易犯些错误。比如，实施中往往是几个人碰一下意见，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，并没有一份较正式的文档。这种做法为项目实施带来风险：

其一，有的人可能会对讨论出的接口、结构理解有偏差，应该承认并不是所有参加会议的人总是很明白，人是会犯错误的。而往往一个单纯的误解可能造成以后的返工;

其二，由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于系统设计不充分，没有一个负责协调的人员不断监控整个开发过程;

其三，一旦有人中途退出开发队伍，其他人加入，新来的人因无法理解前人做好的工作，索性自己从头再来。同时，没有文档的程序，日后维护和版本升级也比较困难。

③ 直奔系统测试

项目不经过单元测试而直接进入系统测试，造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。比如为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。

有人嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。 殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步一步查找。同时，由于模块间的调用关系，可能查了很久才发现是某个模块的问题。

这种方法如果侥幸成功，效率可能会很高，但概率不超过40%。所以，总体看来，这种方法一方面效率较低，大量的时间用在了将一个错误定位在模块上;另一方面，由于测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现。

中小信息化项目防患于未然

"麻雀虽小，五脏俱全"，即便是中小型信息化，仍然应该遵循软件开发的一般规律，必要的步骤不能省略。但也同时根据小项目自身的灵活的特点也可以相对变通。为避免所谓的"软件危机"防患于未然，笔者将中小信息化项目管理经验总结如下：

① 准确获取需求 制定统一需求模型

在这上面花费大量的时间很有必要，也很值得。所有信息化项目进入正式开发之前，必须先从用户处获取准确的需求信息，并对信息加以分析。

我们知道一般的软件项目可以大致分为专用软件和通用软件两大类。对于专用软件，需求相对较为明确，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。但是，开发合同上往往规定的只是一个大概的框架，项目经理必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。做好这个步骤，那么就可以避免开发后期因开发人员的理解和用户的要求存在误解，而造成的时间上的浪费。

[1] [2] 下一页