近期，我在负责的一个小型软件开发过程中忽视了小型软件项目的特点，结果是麻烦事情特别多，差点儿项目要以失败告终。但从另一个角度来看，项目的大与小并没有本质的区别，很多方法是共通的，但必须要切合实际来灵活运用。本文结合我在这个小型软件开发项目中得到的经验和教训，首先分析小型软件开发项目中常见的问题，然后提出相应的解决办法。

　　一. 小型软件开发项目中常犯的错误

　　小型软件开发项目一般具有项目需求相对较少、人员较少、开发周期较短的特点。因此，小型软件开发看起来都比较简单，比较容易成功，因而人们往往忽视了小型软件开发的管理，其实这是一种误解。例如，由于人员较少就分工不明确或由于开发周期较短就忽视项目计划和进度表的控制，结果是经常会出现开发流程混乱，重编码轻设计，甚至到编码完成后再回头编写各种文档资料等现象。从我这次的开发经验看来，在小型软件开发管理中最容易犯以下的错误：

　　(1)没有重视项目计划，做一天和尚撞一天钟

　　往往由于项目较小，便很草率地制定一个开发日程表，也没有认真地估计项目难度，结果是实际完成时间与估计完成时间往往有较大差别。还有人是这样说计划的："计划、计划，纸上画画，墙上挂挂，计划不如变化"。因此，由于观念的不正确使到计划管理经常成为空话，特别是在小型软件开发中影响计划的因素太多时或加上想省事怕麻烦，结果计划管理就形同虚设了。

　　但是，软件进行项目管理的目的就是综合各种因素，制定合理的计划，并通过计划的实施，使其规范化，从而提高人员效率，降低项目成本。因此，软件开发无论项目大小，其实都需要计划过程。只是对于小型软件项目来说，计划阶段可能切换的很快。例如，有时候项目负责人只是脑海里想一遍就把计划确定了。但项目负责人必须心里要清楚：有时候想省事儿，可能反而会更加费事儿。俗语有云：一年之计在于春、一日之计在于晨。其意义不是说越早做越好，而是阐述一个目标的实现需要尽早做规划。

　　(2)没有完整的开发文档，无意之中增大项目风险

　　一个完整的软件开发项目应包括有相当多的相关文档：例如项目开发计划、软件需求说明书、概要设计说明书、详细设计说明书、开发进度月报、测试计划和开发总结报告等。而在实际中，许多小型软件项目只有简单的流水帐式的开发日志。最常见的借口往往是以文档滞后来解释文档的不健全，这似乎没有什么不妥，而且好象还理直气壮的。但如果将软件项目叫做"工程"的话，再将其与建筑工程相比较，那我们也就可以说：大楼有了，图纸滞后，这是很可笑的。还有许多开发人员认为软件设计已经在其脑子里完成了，在其意识里工作就只是一堆需要敲出来的程序，既然能直接敲得出来，自然没必要再做写文档的重复工作。

　　这样做的结果使到设计思路和实现细节在项目团队内的交流很困难，开发过程会由于需要大量尝试性、重复性工作而变得缓慢，而且会出现许多意想不到的大大小小的问题，狼烟四起之时最重要的工作就变成了"救火"。所以，在小型软件项目里会"救火"的技术人员会成为大家推崇和依赖的英雄。但这种"救火"式的行为最终结果却是项目延期成了普遍现象，产品质量也得不到保证。另外，如果这个英雄半途离开，那没有任何文档支持的中间结果对其它人来说基本上就是"一堆垃圾"而已，项目被迫中断就成了家常便饭。

　　(3)人员没有技术分层，职责不清分工不明

　　许多小型软件开发项目一直采用个人主义式的开发方式，决定了规范化开发方式的不被认可。对规范化管理的淡漠，抑制了团队工作效率的提高，甚至扼杀了其生命。所以，小型软件项目往往要求主要的项目人员从各个方面都得是非常出色的，不仅要全面地掌握系统架构知识、具有业务分析和系统设计能力，而且还得是多种流行开发工具的专家、数据库的专家、网络配置的专家等，但这样的全才和通才往往是可遇不可求的。

　　因此，小型软件项目更需要做技术分层，例如系统分析员、需求分析师、程序员、测试员等。在项目开发中相应的角色必须要有相应的专业人员来担当，当然可依据项目规模大小和现有人员来合理配置。这里强调技术结构分层和技术人员划分，更多的是技术责任的明细，而非具体个人的技术定位，将技术任务和相应的责任划分到具体的岗位、将岗位落实到具体的人，这与具体技术人员身兼数职是不矛盾的。

　　而我们经常看到的是在许多小型软件开发过程中，人员职责不清、分工不明的现象非常严重。有的甚至从调研到分析、设计，到开发、调试，再到测试一气呵成。先不说工作量有多大，仅从项目的风险来说就是非常可怕的，更不用说最大限度发挥开发人员的长处了。

　　二. 小型软件实行项目管理的方法和步骤

　　为什么小型软件开发项目却会面临更多的失败风险呢?在我所负责的项目面临下马前的每一个夜晚，我的脑袋里一直在思考这个问题。也许是多日思考的沉淀，也许是思绪在不停的四处游荡后的突发灵感。使我明白到原来决定小型软件项目成败的核心因素，是有没有坚持进行实行项目管理。现总结为以下几个要点：

　　(1)树立小型软件开发也需要项目管理的理念

　　但凡专业的软件开发人员都学过《软件工程》这门课，纵观这些指导性的理论以及建议。我们应该要树立即使是小型软件开发也应该在一定程度不要违背开发理论，必须要遵从于工程化软件理论的原则和方法，落实规范化的管理。否则，失败的风险将伴随着整个开发过程，而且越到后期失败的可能性会越大。

　　对小型软件项目而言，最急需的不是设计方法，也非分析方法，当然也不是开发方法，而是管理方法。因此，无论项目大小都必须要遵循一定的项目管理步骤。从概念上讲，软件项目管理是为了使软件开发能够按照预定的成本、进度、质量顺利完成，而对成本、人员、进度、质量、风险等进行分析和管理的活动。实际上，软件项目管理的意义不仅仅如此，进行软件项目管理还有利于将"英雄"式的开发人员的个人开发能力转化成团队的开发能力，团队的软件开发能力越高，就越能减小项目的开发风险。

　　(2)项目需求的确认

　　在软件开发中，最重要的活动是要明确项目的范围、需求和提出至少一个可用的软件架构方案。在明确项目范围的过程中，不能认为是小型软件开发项目就马马虎虎的、想当然的认为已经了解了客户的真实需求。项目经理应要就项目的边界、功能、限制条件等与客户进行协商，并应以需求说明书和功能说明书的形式把客户的需求记录下来，并且和客户达成一致的认识和理解。在此基础上，再提供至少一个合适的软件架构方案，并且完成原型系统。原型系统的目的不但是为了验证技术上的可行性，而且是为了给客户一个感性的认识，更好地完善对需求的理解和确认。

　　(3)人员角色的安排和定义

　　角色定义包括个人或团队的行为和职责，包括设计人员、编程人员、测试人员、项目管理人员和辅助人员。比较小的项目往往是几个人来完成，这几个人基本上从头到尾参加开发。而且由于项目小，项目负责人除了负责分析、设计和协调的工作外，也要参加编程。但在此过程中必须要合理进行人员角色的安排和定义，将技术任务和相应的责任划分到具体的岗位，再将岗位责任落实到具体的人身上，避免推卸责任或由不专业的人马虎应付了事。例如，一个人可以同时担当几个角色，一个角色也可以由几个人来共同承担，但前提都是要有责任的、有专业技能的。

　　(4)建立合理的开发流程，注重过程的衔接

　　一句话形容就是"麻雀虽小，五脏俱全"。也就是说即使是小型软件的开发，仍然应该遵循软件开发的一般规律，必须的步骤和合理的开发流程还是不能省略。不但要建立合理的开发流程，而且还要注重分析与设计过程的衔接。当然，小软件项目也有它自身的一些特点，实行起来可以相对灵活些。

　　例如：①要强调协调几个人的工作比某一开发人员完成一段编码更重要。因为在协调上出了漏洞，就可能导致很大的问题。②是给每个开发人员要有明确的任务书，也就是说每个开发人员必须非常明确自己的任务，而且这些任务是采用文档来表示。③是要让每个开发人员都清楚自己所做的工作在整个系统中处于什么地位，避免各人的代码编写完毕之后又要重复修改。

　　(5)重视文档化过程

　　在小型软件项目中有两个特点：①是由于人员少，意味着不同人员的程序之间交互、接口相对少一些;②是由于人员少，往往是同样的几个人从头到尾负责这个项目。但这两个特点会让人容易犯错误，就是往往是几个人碰一下头，讨论一下最基本的任务分工便分头去做自己的工作了，没有一份较正式的开发文档。当有人对任务理解有偏差时或有误解时，就可能会造成返工。因此，小型软件开发项目也不应该忽视文档化过程的作用。

　　文档化有三方面的作用：①是有助于团队沟通，能给别人一个交待以及给自己一个备忘。②是有助于自我理解，一般来说如果你不能写下它，你就可能没有真正的理解它。③是有助于连贯一致性，它会使团队拥有可重复的优势。虽然文档是如此重要，但在小型项目中有用的文档最好也不要太冗长繁杂，一般1-2页的过程说明就足够了。

　　(6)使用好制度与纪律这个工具

　　有效的团队制度与纪律是非常有利于团队有序工作的。也许在一、二十年前经常听到某位大侠单独完成了某种创举，成了人们崇拜的对象。可今天这种以自我为中心的大侠已经很难有生存空间了，取而代之的是要发挥团队力量才能攻克难关。

　　因此，软件开发虽然是一项创造性的智力活动，但无可置疑的是制度与纪律对于能否成功也是至关重要的。如果因为项目小、人员少、周期短，在管理上可以一目了然就失去了制度与纪律的观念，必将会导致开发过程混乱不堪。所以，使用好制度与纪律这个工具，将有助于小型软件团队改进开发过程，遵从纪律来构建软件将会得到大大的益处。

　　总而言之，大中型软件开发项目事情会是很多，例如需求分析、概要设计、详细设计、编码、测试、安装及维护等。但事实上，小型软件开发项目的事情也并不少，同样也需要管理好这些事情。虽然可根据实际的简易程度进行适当的取舍，但只有坚持应用项目管理这个工具才是正道，才会取得成功。