民间有一句俗语：多大的脚穿多大的鞋。

对于一个企业的管理来讲，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到自己身上，可能会适得其反。

同样，管理一个软件项目也一样，大项目和小项目的方式虽然不完全一样。

而从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。

管理一个软件项目大项目和小项目的方式不完全一样，但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。

小型软件项目中常犯的错误相对于大型软件项目，小型软件项目具有灵活性高、项目功能相对较少、开发人员较少、开发周期较短的特点。

业内常常提到“软件危机”一词，常是指一些大型软件项目延期，导致项目顺利交接存在困难。

这并不意味着“软件危机”就与小型软件项目毫无干系。

正如上述小型软件项目的特点，小项目看起来比较简单，比较容易成功实现，因而人们往往忽视了小项目的管理，其实这是一种误解，从本人的经验看来，小项目开发中容易犯以下的一些错误: 企业层面：1、草率确定项目人员对于中小IT企业来讲，人员流动性高，岗位频繁调换是不争的事实。

如果这种情况出现在项目中，将对项目造成致命的影响。

试想一下如果一个项目，即使是个小型软件项目，开发人员三天两头调来调去，开发设计怎么可能实现呢？所以企业要根据其项目的周期长短谨慎选择开发人员，保证其在开发过程中可以不间断。

2、不看重隐性影响作为一位项目组成员，当项目自开始时，就把自己与项目的命运联系在一起了。

项目的成功与失败都无疑会对项目组成员造成心理上、情绪上的影响。

在我们许多中小企业中，企业往往关心的那些大型项目的成果，而忽视了小型项目。

原因往往也很简单：大型项目意味着大收益。

然而，项目对项目组成员的隐性影响却不管项目的大小，且这些影响最终会体现在企业的人员积极性上，这不能不说是企业有效运营的关键。

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

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

2、蹩脚设计过程从小项目的特点来看，开发人员少，意味着不同人员的程序之间交互、接口相对少一些；开发周期短意味着往往是同样的几个人从头到尾负责一个项目。

这两者虽是小项目的优势，却都让人容易犯些错误，比如实施中，往往是几个人碰一下意见，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，并没有一份较正式的文档。

其实很多中小企业都是这样的。

这种做法很危险。

危险之一是有的人可能会对讨论出的接口、结构理解有偏差，应该承认并不是所有参加会议的人总是很明白，人是会犯错误的。

而往往一个单纯的误解可能造成以后的返工。

另一个危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。

其根源在于系统设计不充分，没有一个负责协调的人员不断监控整个开发过程。

第三个危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的代码，索性自己从头来。

另外，没有文档的程序，日后维护和版本升级都比较困难。

这些不仅是项目没有成功，而且为项目的后续工作要付出很多努力。

3、直奔系统测试指项目不经过单元测试而直接进入系统测试，造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。

比如为了测试一个函数是否正确，应该用一些测试数据去调用该函数，需要编写一些测试数据。

笔者曾经做开发时，也嫌麻烦，觉得反正其他模块也很快出来了，直接用真正的数据来运行几次就行了。

殊不知，一旦直接进入系统测试，发现运行结果不正确后需要一步一步查找。

同时，由于模块间的调用关系，可能查了很久才发现是某个模块的问题。

这种方法如果侥幸成功，效率可能会很高，但这种概率不超过40%。

所以，总体看来，这种方法一来效率比较低，大量的时间用在了将一个错误定位在模块上了。

另外由于这种测试不完全，真正运行系统，当调用某模块时，可能大部分时候都是正常数据，极少出现边界情况，可能某些边界情况容易被忽视，很久之后才被发现，正所谓欲速则不达。

然而，如果我们对每个模块进行单元测试时都进行一下边界测试，就会很容易消除这些隐患。

具体的解决方法解决方法，一句话形容就是"麻雀虽小，五脏俱全"，即使是小型项目的开发，仍然应该遵循软件开发的一般规律，必须的步骤是不能省略。

但是小项目有它自身的一些特点，实行起来可以相对灵活些。

笔者就以下几个方面进行描述：1、需求获取及分析在这上面花费相当时间是很必要，也是很值得的。

所有软件项目进入正式开发之前，必须先从用户处获取准确的需求信息，并对信息加以分析。

我们知道软件项目可以大致分为专用软件和通用软件两大类。

对于专用软件，需求相对较为明确，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。

但是，开发合同上往往规定的只是一个大概的框架，项目经理必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。

做好这个步骤，那么就可以避免开发后期因开发人员的理解和用户的要求存在误解，而造成的时间上的浪费。

对于通用软件，一方面是从经济效益考虑，另一方面是从技术的角度，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等。

为得到这些信息，需要做一定的市场调查，并根据调查的统计结果决定即将开发的软件的一些技术指标。

需求分析就是将需求用一种模型来表示。

目前比较流行的分析方法是面向对象的方法，这部分涉及到具体的方法，在此不详细讨论，只想强调分析与设计过程的衔接。

分析过程的内容是用类的结构来表示目标系统，并不设计具体实现，如采用什么编程语言，在什么操作系统平台上运行等等。

这些具体实现是在设计阶段来完成的。

面向对象方法的优点是分析、设计、编码过程表示法统一，能比较好的衔接。

但是，是把分析和设计阶段分开，采用瀑布式开发，还是采用其他方式，要看具体的情况。

一般来讲，对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一份比较完整的分析文档。

2、设计过程包括对分析模型必要的修改。

可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。

比如定义界面部分、数据访问(数据库)部分。

由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。

于是设计阶段的工作量并不大。

3、编码与测试进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。

测试阶段正如前所述，即使是小项目，也应该严格地进行测试，在此不再赘述。

4、人员的安排比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。

在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。

由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用，据经验来讲，我们需要下面几点原则：A .协调工作比自己去做更重要.项目管理主要工作就是协调，如果协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。

只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。

B .给每个开发人员明确的任务书.不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系统。

但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。

C .让大家都大致熟悉设计模型.让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。

大型软件项目中的组织环境一、项目组织概述项目组织是保证项目正常实施的组织保证体系，就项目这种一次性任务而言，项目组织建设包括从组织设计、组织运行、组织更新到组织终结这样一个生命周期。

项目管理要在有限的时间、空间和预算范围内将大量物资、设备和人力组织在一起，按计划实施项目目标，必须建立合理的项目组织。

1、项目组织结构设置原则（1）.目的性原则项目组织机构设置的根本目的，是为了产生组织功能实现项目目标。

从这一根本目的出发，就应因目标设事，因事设岗，因职责定权力。

（2）.精于高效大多数项目组织是一个临时性组织，项目结束后就要解散，因此，项目组织应精干高效，力求一专多能，一人多职，应着眼于使用和学习锻炼相结合，以提高人员素质。

（3）.项目组织与企业组织一体化原则项目组织往往是企业组织的有机组成部分，企业是它的母体，项目组织是由企业组建的，项目管理人员来自企业，项目组织解体后，其人员仍回企业，所以项目的组织形式与企业的组织形式密切有关。

2、常见的项目组织结构类型有：（1）、职能组织型：该结构呈金字塔形，高层管理者位于金字塔的顶部，中层和底层管理者则沿着塔身向下分布。

公司的经营活动按照设计、生产、营销和财务等职能划分成部门；一个项目可以作为公司中某个职能部门的一部分，这个部门应该是对项目的实施最有帮助或最有可能使项目成功的部门，例如开发一个新产品项目可以被安排在技术部门的下面，直接由技术部门经理负责。

（2）矩阵组织型：现代大型项目中应用最广泛的新型组织形式，它是职能组织型和项目组织型的结合，将职能组织型的纵向优势和项目组织型的横向优势有效结合起来。

一个矩阵组织型由垂直的职能部门和水平的不同项目组结合而成一个矩阵，把集权和分权结合起来，从而加强了各职能部门同各项目之间的协作关系。

（3）项目组织型：在这种组织形式中，每个项目就如同一个微型公司那样运作，项目组的成员来自不同的部门，完成每个项目所需的资源完全分配给这个项目，专门为该项目服务。

这种组织在大型软件开发中应用较多。

下面，我们将三种常见组织类型进行一个全面比较（见表一），以便更好地根据自己企业和项目的特点，选择和设计项目的组织结构。

3、项目组织结构类型的选择前面介绍的是项目组织经常采用的几种组织结构形式，除了这几种常见的组织结构之外，还可能存在其他组织结构形式。

通过前面的介绍，大家可以看出，每一种组织结构形式都有其优点、缺点和适用条件，没有一种万能的，最好的组织结构形式。

对不同的项目，应根据项目具体目标、任务条件、项目环境等因素进行分析、比较，设计或选择最合适的组织结构形式。

一般来说，部门控制式(职能式)的组织结构适用于项目规模小、专业面窄、以技术为重点的项目；如果一个组织经常有多个类似的、大型的、重要的、复杂的项目，应采用项目式的组织结构；如果一个组织经常有多个内容差别较大、技术复杂、要求利用多个职能部门资源时，比较适合选择矩阵式组织结构。