某集团公司信息化项目经验总结
1.概述
2007年作为项目经理，负责了一个集团公司信息化（软件）系统项目，该项目涵盖了对公司从生产到管理的各个环境的管理，系统需求复杂，建设周期长。该公司主要是从事路桥建设业务的，在全国很多地方都有项目部，同时又兼做该集团所在地的部分路桥工程的甲方。因此系统即包括对他作为乙方的业务的管理，又包括他作为甲方的业务管理功能。
根据公司的业务情况将系统分成了三大块分别进行建设： 项目管理子系统：主要是对各项目经理部业务的管理功能； 工程管理子系统：主要是对公司作为甲方的业务的管理功能；
日常管理子系统（协同办公）：主要是对集团各管理部门日常工作的信息化，如：财务、人力、行政、资产、安全等等的管理；
该项目涉及业务范围广、涉及部门及用户多、业务处理流程多并且复杂，从需求调研开始一直到系统开发完成共花费了15人年的工作量。作为这个项目的管理者和主要设计人员，在该项目中积累了很多的经验教训，也碰到过很多的挑战。在这个项目中我主要从事了可行性分析、需求管理、系统分析设计、软件开发过程控制、项目团队管理几个方面的工作，下面就分析从这几个方面来进行总结。
2.可行性分析
在刚拿到这个项目的招标文件时，根据该项目涉及的功能点多，涉及业务部门多且范围分散的特点。我们进行了初步的项目风险分析：
1、功能点多，业务部门多，因此需求调研的对象会很多，调研周期会很长；
2、系统复杂、开发周期长；
3、因为开发周期长，那么就很容易出现在开发期间用户需求变更的情况；
4、用户业务部门分布的地域比较广，因此系统实施、培训难度会比较大。 针对上面发现的这些风险我们做出了，将系统分割成三个子系统，然后逐个进行开发，逐个进行部署和培训。在第一个子系统的开发过程中开始进行第二个子系统的需求调研及分析工作，在第一个子系统进行入部署阶段时，开始第二个子系统的开发阶段，同时第三个子系统进行需求分析阶段，从而减少系统复杂度。通过与用户协商我们决定先开发作为甲方使用的工程管理系统，然后开发作为管理部系统的协同办公子系统，最后再开发项目管理子系统。
3.需求管理
3.1 需求调研
在需求调研时，我们采用各个业务部门分别组织调研。首先与被调研的业务部门组织需求调研会议，我们了解业务部门的业务情况，了解业务部门各工作岗位的职能和日常工作。然后与部门负责人确定什么业务可以实现信息化，什么是实现不了的。调研会议完成之后，我们编写出需求调研报告，需求调研报告的主要内容是，对该业务部门的业务说明、业务流程归纳，各业务岗位的职能说明等等。完成调研报告后再将报告提交给各部门的对口人员阅读，由他进行确认，是否涵盖该部门的业务，业务流程归纳得是否正确，然后再根据业务人员对报告的意见进行修改，最后确定无误之后由部门负责人进行签字确认。
在调研过程中我们经常会发现有很传统地业务处理方式，无法进行信息化自动化的，或者要进行信息化很困难，对于这种情况我们首先会向用户提出是困难，然后申明我们实现不了，如果用户同意不实现，那么我们将在调研报告中明确说明不实现，如果有些用户要求必须实现，那么我们就设计一种较容易实现的替代方案来实现该业务要求，并要在报告中说明。这个问题非常重要，如果我们不能在调研阶段估计出需求的可行能，那么会直接影响项目的进程，增加开发成本和开发时间。
在需求调研过程中，因为客户的个人知识结构不同、或性能不同，往往会有不同的侧重点，有些人强调结果，有些人强调细节，我们发现如果跟着客户的思维走，往往会很偏面，经常出现遗漏的业务。因此需要在调研时对客户进行引导，不要出现偏移主题，或者在一个问题出现长时间争论的情况。对于有些我们熟知的业务，或者做过类似功能系统的业务，我们要给客户进行介绍说明，通过类比的方式得出完整的业务需求。
在调研中我们还经常发现各部门业务需要与其它业务部门接口的情况，或者需要使用其它部门的数据，或者需要为其它部门业务提供数据，或者需要其它部门协办的业务需求。对于这种情况我们采用的方式是，先将这些问题在调研报告中记录下来，等将有业务关系的这两个部门的需求都了解了之后，再组织这两个部门的相关人员和我们一起讨论接口业务问题。
3.2 需求分析
根据对各部门调研生成的调研报告，使用UML中的用例分析方式来进行分析，将自然的业务表达语言转化为专业的，可以精确表达需求的UML语言。在需求分析过程中重点关注业务处理流程、业务数据流程。同时关注具体每一个用例的处理场景、输入输出、异常情况处理等细节。在需求分析和细化的过程中我们会发现还有很多细节是我们在调研过程中并没有涉及到的，那么需要我们对客户进行二次调研。最后生成系统需求规格说明书。
在需求分析过程中我们在进行用例识别是要特别注意用例的粒度问题，如果粒度太小，需求文档会过大，而且会出现过多关注细节而忽略整体的情况，如果粒度太大，又会遗漏很多具体的业务细节。我的经验是，在进行用例识别时，有一个标准，只有完成一个原子的业务功能单元，就是一个用例，原子业务单元是对可以客户达到一个业务目的最小单元，而不是为了完成业务中间的一个步骤。
3.3 需求变更管理
随着项目的深入展开，开发人员对客户的业务越来越熟悉，客户对系统的轮廓也越来越清晰，这是双方都会发现在需求调研阶段又一些没有考虑到的问题，或者理解错误的问题，这时候就会不可避免的出现需求变更的情况，需求变更是对项目进度影响最大的事件。因此要求我们在需求调研和分析阶段必须仔细认真的理解业务，同时要求我们尽可以的帮助客户清晰将来的系统轮廓，这样就可以做到在开发中少出现需求变更的情况。 但是需求变更或多或少都会在开发中出现，在我们项目，我们使用两种方式来减少需求变更对项目进度产生影响。一是从设计上，调计出耦合度少，层次清晰的系统，这样当要进行功能调整时，速度为较快，设计上的问题将在下一节中进行说明。别一个方面当出现变更时，我们先要客户提高变更的目的，是为什么解决什么问题，要解决这个问题会引起什么新的问题，因为客户往往不会从整体去考虑，我们需要找可能引起的新问题与客户说清楚，这样很多情况下可以说服用户不去做变更，如果不能说服客户，那么我们也可以变更可能影响的地方都考虑到，然后设计出代价最少的解决方案。
需求变更确定之后，编写需求变更说明书，找相关的客户负责人签字确认，以免出现同一个业务功能出现反复变更的情况。
4.系统分析设计
考虑到该系统是分成几个子系统逐一开发的，而这几个子系统之间又会存在一定的交互。因此我们在设计初期阶段就需要考虑到这个问题，但是在设计初期我们只是了解其中一个子系统的详细需求，对于其它子系统需求我们并不特别了解。因此我们在设计时采用的是通用化、模块化、标准化作为指导原则。
首先，可以识别出用户管理、部门管理、权限管理、工作流程控制、报表管理这几个模块一定会在这几个子系统中都会使用到，而且这几个子系统中使用的还必须是共用这些模块，才可以做到将这几个系统组成一个有机整体。因此我们为这些模块设计出通用的解决方案。这样到三个子系统都开发出来时，因为使用相关的权限管理、工作流、报表，所以可以用户方便做到在各系统之间跳转。各部门之间的业务流程也可以相互对接，各子系统产生的业务数据可以配置到同一张报表中，从而可以很方便的完成了系统集成功能。
考虑到该系统功能多，短时间内不可能一个人做完所有详细设计工作，因此我先做好架构设计，将系统模块划分好，设计出模块间的接口，订好设计规范之后，具体每一个模块的设计工作分配项目的几个骨干人员来完成，完成后再组织审评。
在设计阶段还对系统工程的结构进行规划，约定采用四层结构来进行来进行工程规划，即将系统分成“表现层”（即各功能页面）、“业务外观层”（对业务层进行封装供表现层调用）、“业务逻辑层”（实现业务逻辑）、“数据持久层”（实现数据查询和保存）。约定将代码放到相应的层里，这样可以减少对象之间的耦合情度，提高代码的可读取性和可维护性。
考虑我们系统使用的B/S结构，同时有大量的功能（80%）都是对业务数据进行增、删、改、查、浏览、显现的工作，这些功能的实现代码会有大量的类似性，因此安排人员根据这个项目的特点编写出了一个代码生成器，实现对这些类似功能的自动生成工作，这样开发人员只需要对自动生成的代码稍作修改就可以完成一个功能的开发，可以大大提高开发效率。 同时考虑到本项目的开发人员多，开发周期长，为了方便交流，我们制订了代码编写规范，对从变量命名、注释、接口定义、类的职责等多方面进行的规范。并在开发前对开发人员进行了相关的讲解和培训工作。
5.软件开发过程控制
项目开发过程控制我参考了RUP方法来进行过程管理方法，同是结合项目的实际情况进行了删减，并引用了部分敏捷开发思想。首先引用了RUP中的迭代思想，将项目划分成若干个迭代周期，为每个迭代周期设立一个里程碑，要求每个里程碑必须按时完成。迭代周期的划分，和每个迭代周期的工作按排，以风险等进行排列，先将风险大的排列在前面的迭代周期进行完成，以降底项目开发中的风险，尽早将大的风险识别、缓解或者解决。对了方便控制，一般将每一个迭代周期设计在2到3周的时间。对风险优先级定义的原则是，对项目进度影响越大的其优级先级就越高.风险主要用为几类，技术性的、业务性的、人员变动、客户原因等：
1、将在技术实现在有难度的列为风险；
2、准备使用新技术的，而该新技术项目组的人员没有丰富相关经验的列为风险；
3、将业务实现复杂，需要花费大量时间的列为风险；
4、将业务不清晰，或者可能出现变更的列为风险；
5、将项目可能出现人员流动的情况列为风险；
在每个迭代周期内的工作必需要在周期内完成，而不能遗留到下一个周期，如果发现不能在里程碑到来之前完成工作的话，那么可以通过添加资源或者加班的方法解决。只有控制好每个周期的里程碑才能控制住项目的总体进度。
为了控制项目质量，定期安排人员进行代码review，检查开发人员是否尊守了代码规范，是否按四层结构进行了对象划分，程序逻辑是否合理，需求理解是否出现偏差。一发现问题就要相关人员进行说明，并要求相关责任人进行修正，通过这种方试保证代码的质量。
6.项目团队管理
该项目成员多，建设周期长，因此该项目管理中的项目成员沟通交流问题是个大问题，而且在项目开发过程中又碰到了几个开发人员流失或调动的情况。这些问题占用了项目的大量时间，因为沟通问题，出现过功能重复开发的问题，出现过开发人员对需求理解错误的问题。因为项目人员流失的问题，后来人员了解前任的代码和业务都花费了大量的时间，从而增加了项目的开发时间。
为了方便管理，我们将15个人的开发团队花分成三个小组，分析组3个人，在完成第一个子系统的分析设计之后，开始进行第二个子系统的分析工作，同时负责第一个子系统的管理检查工作。另外的人员组成两个小组，然后将系统的功能划分成两大块分别给这两个小组的人员开发。
要求每个小组每天要开一个例会，对开发过程中出现的问题进行沟通，如果碰到需要与其它小组进行协作的问题，由小组负责人记录下来，会后与其他小组人员进行沟通。整个项目组每周开一次例会来进行沟通交流。小组每天的例会一般控制在半个小时以内，特殊情况下可以延长。项目周例会一般控制在两个小时以内，特殊情况可以适当延长。通以例会的形式可以及时解决开发人员的疑问，帮助他们解决工作中碰到的困难，还可以让他们更好的把握业务需求。
在出现人员流失的情况时，一定要及进补充人员，在原开发人员离开前完成好工作交接，要求离开人员编写交接报告，详细列出他在项目中所做过的工作。交接报告要求接手人签字确认。 7.总结
通过这个项目，我总结出对项目进度影响最大的三个方面，第一是需求管理、第二是系统架构设计、第三是风险控制。只要做好了这三个方面那么项目可以说就离成功不远了。这里面最重要的又是需求管理，对一个项目的前需求分析是否准确，后期是否对变更进行了很好的控制，当会直接关系到项目的成败。因此在项目的需求管理上必须投入大量资源和精兵强将来进行严格管理。一定要做到在项目前期准确完整的理解客户的业务需求，和对将来的发展规划。在项目开发的中期和后期需要让开发人员准确理解他所开发部分的业务需求，还要严格的控制客户都需求的变更，每一次变更都必须走正规的管理流程来进行控制。
系统架构的设计一定要做到合理、适量、低耦合。一定要根据项目的实际情况设计出与之相适应的设计，适量就行不要过度设计，如果设计得太灵活，必定复杂度增加，开发时间增加，太不灵活又失去了搞变性。一句话，不要为了设计而设计。
风险的控制将会直接影响项目的进度，必须将大的风险尽早的识别出来，并予以解决。风险的识别是建立在对需求的完整理解，和以往项目的经验总结基础上的。
