谁动了项目的质量

又一个项目结束了，终于闲出空来写些东西。有了以前的经验教训，这次在做项目的时候，我对时间的控制很关注，最后也基本上达到了计划的要求。但最终交付产品的质量却让我不太满意：客户在做接受测试的时候发现了很多的问题，而且在我们进行修改的同时，又有BUG源源不断的报过来。甚至把更新的版本发给客户以后，还会发现不少问题，给客户留下了很不professional的印象。为什么问题总是要到项目快结束的时候才会出现呢？软件的质量为何不好？究竟是谁动了项目的质量？

    大家知道，项目的时间、成本及质量的三大要素是缺一不可。这三方面的符合程度直接决定了项目的成败与否。但事实上，想达到一个完美的等边三角形几乎是不可能完成的任务。这次的项目就让质量这个角短了很多，质量的问题暴露地很明显。所以，接下来，我就从项目的流程角度出发，一步步地分析到底是哪里出了质量问题。

    1、分析阶段

    项目的开始阶段，也是质量控制的开始。在这个阶段中，主要的工作是从客户方获得足够多的项目需求，并准确地记录在案，而且要使得项目组的成员对于需求足够得了解。先说说这个项目的基本情况：一个信息管理系统，而且是在原来的版本上进行的功能增加。项目组的成员，除了我以前参加了前一个版本的开发，其它的人员都不了解这个项目。就是这样的一个项目，在开始阶段，我先是安排了组员对以前版本的需求文档进行了阅读，并安装使用了软件。随后对新的需求进行了研究，分析了它们对于原有系统的影响。由于是在旧有系统的文档进行增加，所以加入的新内容并不是很多，需求文档很快就完成了。所谓的分析阶段的里程碑也就结束了。

    在需求阶段＂顺利＂结束的同时，问题也随之留下来，并对后面的阶段起到了＂乘数效应＂――影响变得越来越大：

    A. 对旧系统的理解不足

    由于开发人员没有参与过上一个版本的开发工作，他们对于旧系统并不了解。虽然在阅读了以前的需求文档以及使用了软件之后，大概对系统的功能有了一个初步的认识。但是对于系统中出现的各种逻辑关系并没有深入了解下去。作为项目经理，在这项工作中，失误之处在于任务的结果（即输出）没有事先定义清楚，从而也就导致无法确认目标是否已经达到，再加上需求文档描述的也不是十分清晰。最后，只是在开发人员觉得已经理解该系统的基本上，进行了下一步的工作。没有进行进一步的确认工作，不知道组员进行旧系统已经了解到了什么样的程度。这个问题的结果，就是直接导致了后期的开发过程中，由于对于原先系统的逻辑关系不是很清楚。对于旧代码理解和新代码编写进行地不是很顺利。

    B. 对新需求的分析不够

    这还是个老问题，但又不是一个问题。说它是个老问题，因为分析需求要求考虑细致全面，并且能引导客户，启发客户提供更有价值的信息。事实上，需求分析我们做的算是很尽力了，同时客户把需求一条条的列出来给我们，相对来说需求已经很清楚了。我们在接到这些需求后，不仅研究了新功能，还把他们对于旧系统的影响都做了分析。但还是有些问题没有能在需求文档中反映出来，后面的影响也是可想而知的了。我以前的文章中才曾提到过相关的问题，在这里就不再重复了。不过，从另一个角度来看，它又不是一个问题。为什么这么说呢，因为需求实在不是能够在分析阶段就能完全理解透彻的，甚至有的需求客户也模模糊糊，直到交付以后才提出了改动的要求。软件开发经过这么多年的发展，大家已经认识到了一点：需求是变化的。要达到能够拥抱变化的要求，我们要对开发方法进行改进，相关的问题我在后面也会提到。