【IT168 专稿】
一个企业的管理，大公司有大公司的方式，小公司也有小公司的做法。如果把别人的经验生搬硬套到自己身上，可能会适得其反。同样，管理一个软件开发项目也一样，大项目和小项目的方式也完全不一样。如很多人认为小型软件开发项目不需要严格的管理，但事实上却恰恰与此相反，小型软件项目不单需要进行项目管理，而且不能完全照搬大型软件项目的管理方式和开发模式，应该要遵循一种适合小型软件项目的管理方式。
近期，我在负责的一个小型软件开发过程中忽视了小型软件项目的特点，结果是麻烦事情特别多，差点儿项目要以失败告终。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的，但必须要切合实际来灵活运用。本文结合我在这个小型软件开发项目中得到的经验和教训，首先分析小型软件开发项目中常见的问题，然后提出相应的解决办法。
一. 小型软件开发项目中常犯的错误
小型软件开发项目一般具有项目需求相对较少、人员较少、开发周期较短的特点。因此，小型软件开发看起来都比较简单，比较容易成功，因而人们往往忽视了小型软件开发的管理，其实这是一种误解。例如，由于人员较少就分工不明确或由于开发周期较短就忽视项目计划和进度表的控制，结果是经常会出现开发流程混乱，重编码轻设计，甚至到编码完成后再回头编写各种文档资料等现象。从我这次的开发经验看来，在小型软件开发管理中最容易犯以下的错误：
（1）没有重视项目计划，做一天和尚撞一天钟
往往由于项目较小，便很草率地制定一个开发日程表，也没有认真地估计项目难度，结果是实际完成时间与估计完成时间往往有较大差别。还有人是这样说计划的："计划、计划，纸上画画，墙上挂挂，计划不如变化"。因此，由于观念的不正确使到计划管理经常成为空话，特别是在小型软件开发中影响计划的因素太多时或加上想省事怕麻烦，结果计划管理就形同虚设了。
但是，软件进行项目管理的目的就是综合各种因素，制定合理的计划，并通过计划的实施，使其规范化，从而提高人员效率，降低项目成本。因此，软件开发无论项目大小，其实都需要计划过程。只是对于小型软件项目来说，计划阶段可能切换的很快。例如，有时候项目负责人只是脑海里想一遍就把计划确定了。但项目负责人必须心里要清楚：有时候想省事儿，可能反而会更加费事儿。俗语有云：一年之计在于春、一日之计在于晨。其意义不是说越早做越好，而是阐述一个目标的实现需要尽早做规划。
（2）没有完整的开发文档，无意之中增大项目风险
一个完整的软件开发项目应包括有相当多的相关文档：例如项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、开发进度月报、测试计划和开发总结报告等。而在实际中，许多小型软件项目只有简单的流水帐式的开发日志。最常见的借口往往是以文档滞后来解释文档的不健全，这似乎没有什么不妥，而且好象还理直气壮的。但如果将软件项目叫做"工程"的话，再将其与建筑工程相比较，那我们也就可以说：大楼有了，图纸滞后，这是很可笑的。还有许多开发人员认为软件设计已经在其脑子里完成了，在其意识里工作就只是一堆需要敲出来的程序，既然能直接敲得出来，自然没必要再做写文档的重复工作。
这样做的结果使到设计思路和实现细节在项目团队内的交流很困难，开发过程会由于需要大量尝试性、重复性工作而变得缓慢，而且会出现许多意想不到的大大小小的问题，狼烟四起之时最重要的工作就变成了"救火"。所以，在小型软件项目里会"救火"的技术人员会成为大家推崇和依赖的英雄。但这种"救火"式的行为最终结果却是项目延期成了普遍现象，产品质量也得不到保证。另外，如果这个英雄半途离开，那没有任何文档支持的中间结果对其它人来说基本上就是"一堆垃圾"而已，项目被迫中断就成了家常便饭。
（3）人员没有技术分层，职责不清分工不明
许多小型软件开发项目一直采用个人主义式的开发方式，决定了规范化开发方式的不被认可。对规范化管理的淡漠，抑制了团队工作效率的提高，甚至扼杀了其生命。所以，小型软件项目往往要求主要的项目人员从各个方面都得是非常出色的，不仅要全面地掌握系统架构知识、具有业务分析和系统设计能力，而且还得是多种流行开发工具的专家、数据库的专家、网络配置的专家等，但这样的全才和通才往往是可遇不可求的。
因此，小型软件项目更需要做技术分层，例如系统分析员、需求分析师、程序员、测试员等。在项目开发中相应的角色必须要有相应的专业人员来担当，当然可依据项目规模大小和现有人员来合理配置。这里强调技术结构分层和技术人员划分，更多的是技术责任的明细，而非具体个人的技术定位，将技术任务和相应的责任划分到具体的岗位、将岗位落实到具体的人，这与具体技术人员身兼数职是不矛盾的。
而我们经常看到的是在许多小型软件开发过程中，人员职责不清、分工不明的现象非常严重。有的甚至从调研到分析、设计，到开发、调试，再到测试一气呵成。先不说工作量有多大，仅从项目的风险来说就是非常可怕的，更不用说最大限度发挥开发人员的长处了。
