民间有一句俗语：多大的脚穿多大的鞋。对于一个企业的管理来讲，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式虽然不完全一样。而从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。管理一个软件项目大项目和小项目的方式不完全一样，但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。

    小型软件项目中常犯的错误
 
    相对于大型软件项目，小型软件项目具有灵活性高、项目功能相对较少、开发人员较少、开发周期较短的特点。业内常常提到“软件危机”一词，常是指一些大型软件项目延期，导致项目顺利交接存在困难。这并不意味着“软件危机”就与小型软件项目毫无干系。正如上述小型软件项目的特点，小项目看起来比较简单，比较容易成功实现，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误:

    企业层面：

    1、草率确定项目人员

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

    2、不看重隐性影响

    作为一位项目组成员，当项目自开始时，就把自己与项目的命运联系在一起了。项目的成功与失败都无疑会对项目组成员造成心理上、情绪上的影响。在我们许多中小企业中，企业往往关心的那些大型项目的成果，而忽视了小型项目。原因往往也很简单：大型项目意味着大收益。然而，项目对项目组成员的隐性影响却不管项目的大小，且这些影响最终会体现在企业的人员积极性上，这不能不说是企业有效运营的关键。

    项目管理层面：

    1、草率的计划方案

    企业往往由于项目较小，在软件开发之前没有认真地进行项目可行性和工作量的估计，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间与估计完成时间往往有较大差别，这种偏差必将是项目陷入困境。

    笔者从一位做项目管理咨询工作的朋友哪里了解到，许多中小企业对于这种偏差的认识始终停留在是执行过程除了差错，然而根源却是项目的前端出了问题。

    2、蹩脚设计过程

    从小项目的特点来看，开发人员少，意味着不同人员的程序之间交互、接口相对少一些；开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者虽是小项目的优势，却都让人容易犯些错误，比如实施中，往往是几个人碰一下意见，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，并没有一份较正式的文档。其实很多中小企业都是这样的。这种做法很危险。
　
    危险之一是有的人可能会对讨论出的接口、结构理解有偏差，应该承认并不是所有参加会议的人总是很明白，人是会犯错误的。而往往一个单纯的误解可能造成以后的返工。
　
    另一个危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于系统设计不充分，没有一个负责协调的人员不断监控整个开发过程。
　
    第三个危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。这些不仅是项目没有成功，而且为项目的后续工作要付出很多努力。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。