XX项目的现状与对策

A项目，作为B集团C区域公司的业务支撑项目，D软件公司投入大量的人力物力进行系统的开发。虽然每一期的业务需求都可以满足客户的需要。但是随着项目的推进和业务的继续深化。为了维持这种良好关系需要付出更多的精力和费用。虽然项目费用价格还比较高，但是D软件公司还是需要花费大量的人力去应对哪怕是一个小需求的变更。最终D软件公司的项目核算利润不高。

目前系统存在运行效率过低，开发效能底下。有些问题是值得我们反思：

1，人员变动率过大。项目从开始到现在已经做了五期，也前后经历了快3年的时间。但是核心人员没有被保留下来。

2，项目分工混乱。项目管理，项目需求，项目设计都一个人来完成。系统上线也有多个人来操作。项目组的人员的工作可以互相交叉，也可以授权或者委托他人做。但是项目中的每个步骤的责任人必须明确。只有明确责任人才可以做到项目的可控。还要避免一人多职的情况。

3，系统的需求把控。作为C区域公司的业务系统，其业务需求功能是比较明确的。但是业务层面的功能如何转化为系统上实现。如何控制和精确把握每期的系统需求。客户谈需求比较广泛，但是如何去提取系统中有效需求。如不满足系统中的正常业务需求，要委婉拒绝。有部分外包的业务项目，也未了解和指挥该外包的项目需求。

4，项目需求变更的测试验收。项目需求改定，很大一部分未经过严格统一设计就马上让开发人员去做，而开发人员在不了解系统原有功能和目前需要改定的功能下就马上去更改代码。更改代码了之后未进行严格测试把关就直接提交到正式环境中使用。随着系统的深入，这种开发模式导致的数据错误，系统效率低下等情况在后期都爆发。

5，客户的抱怨。与客户的沟通方式改善。由于系统的不稳定和Bug过多，导致在整个项目合作中，D软件公司都是作为被动方。系统方面的问题不断出现，需要紧急对应。对于客户方提出的不合理需求，已经没有信心可以拒绝掉。

6，项目组成员的抱怨。项目组人员天天处于加班紧急应对Bug问题。项目人员也未了解整个系统功能。很多开发人员只知道写代码而不知道这个功能在客户实际业务中的作用。加班多，会影响单个小时的效率，在项目中不值得经常长期使用。

以上这些问题，个人也提出了自己的一些对策建议：

1，分工明确。A项目很有可能作为B集团的全集团推广项目。

   业务专家：由于B集团缺少区域业务系统的IT人员。D公司应该有专门负责B集团该系统的业务专家出现。业务专家不仅需要全面了解B集团的业务需求和相关系统，根据这些业务需求提取出相关的解决方案。更需要对这些业务数据提取相关的统计分析报告。利用过去的历史大数据挖掘商机给B集团相关领导决策。这个需要业务专家足够强大和B集团的领导支持。

   项目经理：对这个项目的总体把握。对整个项目进行严格管理。保证每个过程和过程之间的规范化。尽量保证项目的质量。项目的开发环境，测试环境，正式环境要绝对独立。

   维护人员：A项目作为B集团的业务系统。其很多内部数据是比较敏感。而A项目的整个运营维护也全部交给D软件公司来操作。不仅保证系统处理业务的安全，更要保证其内部数据安全。硬件安全，网络安全，人员安全。操作正式数据库的数据都必须有严格记录，尽量减少直接操作表方式。保证正式环境的相对独立，与开发环境要绝对分离，专人负责。项目中的其它人员不得接触该正式环境。从正式环境拷贝的数据也要经过处理方可导入到测试环境中。

2，系统的框架平台。对于记录单据比较多的业务系统，如何快速实现业务需求。尽量减少冗余代码，减少代码错误，快速实现项目需求的小变更。这些都需要一定的框架平台来实现。组织机构，审批流，历史履历，数据权限控制，系统权限，BI智能、与其它系统的数据接口等都必须在框架的底层中实现。数据层和业务逻辑层分开。目前的框架，为了更改一个小的需求改定，导致要花N倍的时间。而且改动后的效果也不是很明显。部分大的需求改定基本上无法动手。

3，系统的业务总体规划。业务总体规划考虑。数据库底层的通用化和扩展化。尽量减少表数量，提高基础表的通用化。预留部分扩展字段。所有的业务分析设计文档需要经过评审方可进入下一阶段开发。

4，数据的挖掘和分析。数据的使用上，如何挖掘这些大数据来提高B集团的业务系统数据使用。利用一定的商业建模规则推理来实现业务上的智能推荐和风险控制。提高数据的使用上。

张小军 厦门
2014-3-31