项目周期中的各个阶段

    按照一般的软件项目周期来说，一般要经历以下几个阶段：

    一、定义阶段。包括多项目的可行性进行分析，对系统采用的架构、数据进行规划，与客户确认需求并签订相关合同。该阶段就是一个规划、打基础的阶段，项目未来做出什么样子，能够达到什么样的高度，都是由这里决定的。

    在这个阶段，很重要的一个过程：需求分析，往往会被忽略。对一个一般的业务系统来说，系统的根本目的，是为客户的业务管理等做服务的，也就是，一切是为客户的需求做服务的，对应的，就必须把客户的需求充分重视起来。

    很明显的，客户的需求有重要的，有不重要的；有合理的，也有不合理的；有明确的，也有隐含的，等等。总之，需求是多样的。如何把这些需求，转化成为正确的功能，让系统能够与客户进行顺利的衔接，这就是需求分析要干的事情。

    需求分析，首先要区分哪些是必要的、不可缺少的需求。就跟人的需求分层次一样，客户的需求也是分层次的。对应人第一级需求，生存的需求，企业也是一样的。直接关系企业生存的需求，也就是能够创造效益的需求，必然是最迫切的，也是系统必须解决的问题。解决了生存问题，才能进一步的去考虑情感、社会贡献等的高层次需求。当然，需求的分级必须考虑各类显式及隐式的效益。

    需求分析，还有一个重要的问题，就是要充分发掘隐含的需求。在记录客户需求表达的同时，还应该充分考虑客户表达需求的场景、背景等相关内容，因为这些，往往隐含了许多必要的需求。而客户在表达的同时，往往会因为工作习惯的关系，惯性的忽略掉了。当然，在发掘隐藏需求或者避免需求陷阱的方面，业务专家的重要性也就体现出来了。

    做了好了现有的需求分析规划，还应该适当的对客户需求进行优化，并将优化后的需求反馈给客户。毕竟，软件系统的开发上线，必然会对原有的业务关系进行冲击。系统开发的原则的尊重原有业务，并对原业务进行优化升级，以取得更好的效益。说白了，信息化了，肯定要变的。如何变，这才是关键。

    以政府项目为例简单说明。政府项目说的简单点，就是“严格与灵活”表现非常充分的。首先严格，就是行为方式必须符合对应的法律法规等，半点都不能突破，这个原则绝对是严格执行的；灵活呢，就是在规则的允许下，过程可以是任意多变的。

    总之，定义阶段结束，实际上项目的未来基本上就已经是可预期、可见的，项目的成功程度，也是可以估算的。就跟盖大楼一样，这就是选好了地基、做好了设计规划图、大体的材料等。

    二、开发阶段。实际上就是对定义阶段的内容进行充实、实现，也就是一般说的概要设计、详细设计、代码实现、测试等环节。这些环节是在定义阶段的框架下，对系统功能进行充实、完善。一般来说，到了这个阶段，只要过程质量控制的不错，项目出现意外的可能性不大。国家标准里面也有各类标准文档，按着做就基本问题不大了。

    概要设计着重要说明白的是，需求是如何对应到功能的，各个功能如何配合实现某项需求；详细设计说明的是功能具体如何实现，各种数据流如何运作，操作如何对其进行影响。

    跟盖房子一样的，这个时候可以分包给施工队，只要施工队按照设计图走，一般不会出现质量问题。

    这个过程中，忌讳的是各种实验性质的技术使用，即应用各类不是完全掌握的技术。技术本身可能不存在问题，但是如果掌握不好，就容易遭成“豆腐渣”工程。

    三、运维阶段。运维阶段就是对系统进行保养。保养的好坏，关系到系统的使用年限。此阶段，主要是解答各类用户问题，还有是根据客户的个性化要求进行重新装修。重要的问题，就是要顺延设计思路，控制住客户的需求，千万不要因为用户的强烈要求，就把房间的承重墙给砸了。

    其实，项目的各个阶段都是相互关联的，并没有严格的界限。每个阶段的任何行为，都会对其他阶段造成影响。但明显的，前阶段对后阶段的影响、限制更大一些。前面多做一些，后面就会相应的少一些，指望在后续阶段解决前一阶段的问题，付出的代价往往是巨大的。

    实际上，在许多公司，项目的各个阶断是分布在不同的部门的，而且缺少明确的项目经理进行整体的统筹安排，造成了各个阶段之间实际上的割裂。而系统上线运行后，面对客户的却经常是后阶段的员工在负责，这就导致了是后阶段在推动修改前阶段的问题。这个工程的痛苦是谁参与谁知道。浪费人力物力不说，导致项目延期，不能按时交付等等，各种问题，领导也是意见多多。

    解决这个问题的一个关键点，就是必须有一个“强势”的项目经理或者类似的人员，能够贯穿整个项目，将项目的思想从开始就把握好节奏，并且能够有能力弥补部门之间的间隙，保证各个阶段之间的顺利衔接。