一个企业的管理，大公司有大公司的方式，小公司也有小公司的方式，如果把别人的经验生搬硬套到 自己身上，可能会适得其反。同样，管理一个软件项目也一样，大项目和小项目的方式不完全一样。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的。 
一、小项目的特点 
　　大家知道，“软件危机”的出现起源于一些大型项目的不断延迟甚至失败。小项目相比之下，具有以下特点: 
1、项目功能相对较少；2、开发人员较少；3、开发周期较短。
　　另外，在现实中，有很多小项目是由一些中小公司进行开发的，这些公司往往人员流动性较大，这也是不容忽视的一个现实。
二、小项目开发中常犯的错误 
　　小项目看起来比较简单，比较容易成功，因而人们往往忽视了小项目的管理，其实这是一种误解，从经验来看，小项目开发中容易犯以下的一些错误: 
　　1、开发之前没有认真地进行项目可行性和工作量的估计。 
　　往往由于项目较小，便很草率地制定一个开发日程表，没有认真地估计项目难度，结果实际完成时间 
与估计完成时间往往有较大差别。 
　　2、没有真正的设计过程 
　　开发人员少，意味着不同人员的程序之间交互、接口相对少一些。开发周期短意味着往往是同样的几个人从头到尾负责一个项目。这两者都让人容易犯些错误。往往是几个人碰一下头，讨论一下最基本的数据结构、函数接口便分头去做自己的工作了，没有一份较正式的文档。 
　　这种做法潜在的危险之一是有的人可能会对讨论出的接口、结构理解有偏差。一个误解可能造成以后的返工。 
　　另一个潜在的危险是由于讨论时忽略了某些情况，等大家都按当时的分工完成属于自己的工作后，才发现各个模块组合起来却形不成一个完整的系统。其根源在于没有一个负责协调的人员不断监控整个开发过程。 
　　第三个潜在的危险是一旦有人中途退出开发队伍，其他人加入时，新来的人难以理解以前别人做好的 
代码，索性自己从头来。另外，没有文档的程序，日后维护和版本升级都比较困难。 
　　3、不经过单元测试而直接进入系统测试 
　　造成这一现象的原因是每个模块相对比较简单，但是为了测试一个模块需要建立一些测试环境。 
三、合理的开发流程 
　　合理的开发模式，一句话形容就是“麻雀虽小，五脏俱全”，即使是小型项目的开发，仍然应该遵循 
软件开发的一般规律，必须的步骤不能省略。但是小项目有它自身的一些特点，实行起来可以相对灵活些。 
比较合理的模式：
　　1、需求获取 
　　在进入正式开发之前，必须先从用户处获取准确的需求。在这上面花费相当时间是很必要的。 
　　软件项目可以大致分为专用软件和通用软件两大类。 
　　对于专用软件，例如给某单位开发一套该单位专用的系统，一般用户对于软件要完成哪些功能已经有了一个比较清楚的轮廓，而且往往在开发合同中已经大致地规定了。 
　　但是，开发合同上规定的只是一个大概的框架，在进入开发之前必须与用户进行比较具体的交流和讨论，了解清楚用户心目中的产品究竟是什么样子。这个步骤如果没有好好做，往往到了开发工作的后期才发现开发人员的理解和用户的要求有一些误解，那么必然造成时间上的浪费。 
　　对于通用软件，在开发之前应该做一定的市场调查工作，一方面是从经济效益考虑，调查产品的潜在 
    市场有多大，另一方面是从技术的角度，必须了解清楚潜在用户对软件的各种技术上的要求，例如，用户现有硬件配置如何，软件配置如何，使用什么网络，使用什么数据库等等，根据调查的统计结果决定即将开发的软件的一些技术指标。 
　　为了比较好地与用户进行交流，使用一些工具是很有好处的。 
　　2、需求分析 
　　在了解用户的需求之后，将需求用一种模型来表示，就是需求分析，目前比较流行的分析方法是面向对象的方法，通过分析用户需求，用类、类之间的各种关系来表示整个系统。 
　　这部分涉及到具体的方法，在此不详细讨论，但是原则上是提取类->类之间关系,可能需要不断修改而形成一份分析文档。 
　　对于需求潜在变化不大的项目，可以采用瀑布模型，有一个很明显的设计阶段，这样做的好处是有一 
份比较完整的分析文档，这样以后如果需要采用不同的编程语言、或者采用其他的平台时，便可以以这份 
分析文档作为开发的基础。 
　　对于需求变化频繁的项目，可能采用少量分析->少量设计->少量编码->测试的方式更合适，而且随时 
可能要返回到前面某个一阶段去进行修改。但是这意味着可能没有一份完整的分析文档。 
　　现在很多CASE工具并不区分分析和设计的阶段。但是，这并不意味着开发就可以对分析和设计不加区 
分，CASE工具如同一支笔，如何用好还得还人。 
　　3、设计过程 
　　设计阶段的工作包括：
　　对分析模型必要的修改。可能需要对某些类结构进行一些修改，这些修改的原因可能是编程环境的要求，或者为了重用以前的某些工作。 
　　由于目前很多编程语言都可以可视化地设计界面，所以界面部分工作往往留到了编码阶段来完成。于是设计阶段的工作量并不大。 
　　4、编码 
　　进入编码工作之后，可能会发现前面分析或设计阶段的某些错误，这时应返回到前面的阶段进行必要的修改。 
　　5、测试 
　　如前所述，即使是小项目，也应该严格地进行测试。 
四、人员的安排 
　　比较小的项目，往往是几个人来完成，这几个人基本上从头到尾参加开发。在这几个人中，有一位项目负责人，负责分析、设计和协调的工作。由于项目小，项目负责人也要参加编程,那么这人必须把时间合理运用。
　　经验告诉我几条原则: 
　　1、协调几个人的工作比自己完成一段编码更重要。
　　由于协调上出了漏洞，可能导致很大的问题，所以项目负责人必须随时监控各开发人员的工作，包括内容是否与要求发生偏差，进度是否滞后等等。 
　　只有在完成这些工作之后，项目负责人剩下的时间才能用于编程。 
　　2、给每个开发人员明确的任务书。
　　不管是用面向对象或者其他方法开发，分析、设计模型只是从功能的角度来描述系统。但是，具体开发时每个开发人员必须非常明确自己的任务，这些任务应该采用明确的文档来表示。 
　　3、让大家都大致熟悉设计模型。
　　让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，有时侯可能会发现设计模型中的漏洞，避免了各人的代码编写完毕之后又要修改的后果。