应用软件项目失败原因分析

相对其他软件项目而言，应用软件项目失败的风险更大，其中有用户对自己需求认识不清、用人不当的原因，也有软件开发商开发能力不足，或者由于价格战，导致开发商动力不足的原因。

我国的应用软件产业已经走过了几十个年头，从最初的财务软件到MIS，到MRP、MRPⅡ，再到ERP、CRM，真正达到商家和最终用户双赢的项目并不多，更多的是失败的教训，甚至是一些不堪回首的记忆。尽管如此，却很少看到能够勇于面对这些失败的项目并进行深度分析者，毕竟失败是很没有面子的事情。但如果我们连正视失败的勇气都没有，又从何处积累经验、总结教训，在以后项目中进行有效的防范呢？在此，笔者从两个方面来讨论应用软件项目的失败，即软件开发商和用户。笔者并非要各打五十大板，只是从不同的角度对失败进行剖析、阐述。

用户: 需求不清，边界不明

用户作为项目的发起者、软件需求的提出者，在整个应用软件项目中所起的作用至关重要。没有需求，应用软件开发商就成了无本之木，而且当应用软件开发完成以后，用户才是对软件功能体会最深的、最有发言权的人，那么用户在应用软件项目中容易走入哪些误区呢？

1. 对软件认识不到位

“重硬轻软”是最普遍的一种错误心态。硬件买回来以后放在屋子里“一大堆”、很占地方，看上去也很招人喜欢。而软件呢？不过是一张光盘（以前更不起眼，几张软盘而已）。笔者就听到过“一张盘就值几十万？”类似的质问。事实上，软件的重要性已经有很多论述，但要从根本上转变这种观念并非易事。

2. 用人不当

计算机和应用软件目前虽然已经十分普及，但是对于大多数人来说还是比较陌生的，尤其是对于国内企业的中、高层管理人员。而年轻人接受新事物快，因此项目负责人、信息中心负责人不乏二十多岁的年轻人。然而，年轻人经验阅历不足，为了弥补这个不足，很多企业由副总或其他拥有更强业务能力、更高职位、更高威信的人担当项目总负责人，看起来似乎很合理，可是这样的组织结构为后期的失败已经打下了“坚实”的基础。原因如下:

（1） 所谓应用软件，一定与实际业务息息相关，往往需要很多工作经验才能够很好地对业务进行把握，尤其是涉及到核心业务功能或企业业务流程重组的时候。对于刚刚毕业或参加工作不久的人员来说，确实不具备这样的能力。

（2） 随着企业对应用软件需求的不断细化，各部门的业务协调、业务协作必不可少。有些时候复杂度甚至超过某些软件功能本身，如果其中还存在直接或间接的利益冲突，那就更加可怕了。这些问题会让阅历和资历都不足的年轻负责人苦恼万分。

也许有人存在这样的疑问: 不是有一个“有更强业务能力、更高职位、更高威信的人”可以咨询吗？事实上，这样的人很难发挥作用，因为其中很多人是企业的关键人物，同时负责诸多项目，他们一般只在涉及到企业直接利益的项目上花费较大的精力，而其他项目只是挂个名。所以，选择项目或信息中心负责人时千万不要以计算机熟练为惟一的评选标准。

3. 需求不清，边界不明

如果已经存在用人不当的问题，则需求不清，边界不明”这个问题就早已经存在了。那么是不是找一个业务能力超强、具有独特眼光的人或者某个领域的专家就没有问题了呢？答案是否定的。

说到需求虽然用户最有发言权，但是可能会走向另一个极端，那就是对软件要求太高，认为软件能够解决一切问题，即: 将软件的功能边界无限扩大，反而使原本清晰的需求变得摇摆不定，甚至含糊不清。笔者参与过这样一个项目，用户方有一个行业专家，有近三十年的工作经验。在分析和设计阶段，需求报告反复修改了多次，该软件差不多包括了所有与业务相关的功能，而且已经考虑到了以后几年的发展，从物料编码到业务流程，无不功能强大、覆盖面广。然而，种种限制使得我们无法开发出这样完备、全面的软件系统，最后的结果并不理想。

在此不是要否认专家的作用，而是我们应该如何借用他们的智慧。笔者认为进行需求分析和边界定义的时候，采用“四象限法”比较好（如表1所示）。可以把需求按照“重要且紧迫”、“次要但紧迫”、“重要但不紧迫”、“次要且不紧迫”划分为四类，把项目分成几个阶段，首先完成“重要且紧迫”的，而后完成“次要且紧迫的”，第三完成“重要但不紧迫”的，最后在完成“次要且不紧迫”的。这样不仅保证了核心需求的边界，而且充分考虑了软件功能的扩展性，进而确保项目的正常进度和效果。

软件开发商: 重打单，轻做单