一、概述

此文档电子化项目是×公司作为BPO项目外包给某北京知名外包公司的项目的一个子项目，于2008年8月正式启动。此文档电子化项目的功能是把×公司多年的纸质文档通过软件和人员录入，录入到计算机内，以电子文档的方式进行保存，以便于长期保存，并方便之后的查询和使用维护。此软件的使用者包含×公司的项目管理人员，现场作业人员，笔者所在公司的大概200个录入人员，图像采集（扫描和拍照）人员，电子图像优化和质检人员，条码打印人员等等，使用者较多，业务流程较为复杂。此项目乙方的管理团队包括项目经理，下设开发团队和测试团队，分别由技术经理和测试经理负责，本人有幸作为测试经理参与了此项目。根据本人多年的项目经验，结合此项目的实际特点，并与项目团队进行了深入和沟通和讨论，总结出此项目的相关风险，以进行管理，最后使此项目的成果能够成功上线运行，使此BPO项目能够顺利的进行下去。

二、项目管理风险

此项目的管理工作是采用的项目经理负责制，项目团队下设软件开发团队和测试团队，以及业务咨询团队，并设有各自的团队管理人员。项目管理采用项目经理每周五召开项目管理者例会，各团队的管理者向项目经理汇报项目的进展情况。各团队项目经理根据各自团队的进展情况，自主召开团队会议，商议各种情况，并制定措施。

由于项目经理和下面项目组成员沟通很少，有时候对项目的实际进展情况并不是很了解，在项目计划的制定和调整方面与实际的项目进展情况有些脱节。软件开发团队包含8名成员，由技术经理进行负责。技术经理是技术出身，很多疑难的技术都自己进行攻关解决，由于技术经理太专注于技术，导致团队管理有些混乱。当测试团队发现BUG之后，指定了责任人，但是由于核心的东西都是由技术经理进行开发的，且技术经理经常会根据自己的意愿进行修改，开发人员并不知道内部技术细节，BUG的修改速度很慢。

三、版本控制和质量保证风险

（1）项目开始初期，没有测试团队的介入，完全是软件开发团队进行的，版本管理的任务自然由开发团队承担下来。虽然团队建立了VSS进行版本控制管理，但是由于开发人员自身的特点，且管理的宽松，很多时候开发人员开发的源码没有及时的放到VSS上，导致打包安装程序的人员提交给测试人员的版本常常是不完整的新版本。经常会出现在测试人员测试出现问题，流程走不通，请开发人员过来救急的时候，才发现测试人员测试的并不是最新版本。给测试人员的心理和感情上造成一定的刺激，激发不满，给测试人员的情绪造成负面影响。

（2）测试人员是在软件基本成形后才介入的。因为没有完整的文档支持，所以了解业务需要经历一个痛苦的阶段。由于系统初始编码，是业务人员和技术经理根据其他公司的BPO流程进行一定的研究之后，根据和客户的初步沟通所定制的，因此需求会经常的进行变更。而为了赶进度，技术经理经常是通过口头传达需求变更细节，质量保证人员有时候并不能及时的获得最新的需求，无法及时做出应对。同时，由于需求的变化，质量人员需要进行大量的重复测试。

（3）开发人员打包后的安装程序需要一定的组件支持，对环境的依赖性较强，有时在客户端安装卸载后再次进行安装就无法正确运行，需要开发人员查找原因，有时是所需要的组件没有正确注册，有时又是其他的原因。这就要求测试人员完全模拟用户的实际运行环境进行测试，并且必须对干净的系统进行GHOST，随时准备重做系统。

四、项目沟通风险

（1）项目组内部的沟通项目组的成员除了项目经理、技术经理是专门为此项目招聘的人员，其他都是为了此项目临时从其他事业部的资源池内抽调过来的，人员各自的项目技术和行业背景都有所不同，技术能力也参差不齐。这就要求技术经理能够和项目组成员做详细的沟通，了解其技术背景，并根据各个成员的背景来进行任务分配。由于此项目本身文档不够完备，业务变更比较频繁，为了赶进度需要通过技术经理口头传达需求变更细节，所以要求项目组内部需要多多的沟通，避免导致需求版本不一致。

（2）新建立的系统必须为×公司已有的系统留有接口，方便之后的系统集成工作。必须对×公司已有的项目运用的技术有一定的了解，并据此进行设计。所以很多设计必须依赖和受限于×公司现有的系统的设计。必须和×公司，及其原有软件的提供商做好各方面的沟通和协调工作。

×公司文档电子化的程序涉及人员和部门较多，软件的使用角色也较多，且文档类型较为复杂，必须经过深入的沟通才能理清此间的业务关系。

五、技术风险

（1）需要用到打印机和扫描仪，实际现场的工作量每天要达到5000页（共3台扫描仪），而且根据客户的要求，需要分别表明扫描后纸张的正反面。但是现在选定的扫描仪是kodak，其提供的扫描程序在速度上很快，能够支持现场的需要，但是并无法区分正反面，不能够满足用户的要求。项目经理写了扫描驱动程序，能够区分正反面，但是速度上不去，不能满足客户的要求。这是一个技术难题，需要尽快予以解决。

（2）图像优化程序是使用的第三方的控件，所有都被封装，但是有些功能实现的并不好，需要进行改进。这就需要拿到第三方的源码，需要自己进行技术突破或支付一定的费用，但是这并不在预算范围内。

（3）此项目的流程非常的复杂，有很多个流程状态，且流程分支很多，需要进行细致严谨的逻辑测试。

结论

此软件开发项目的风险因素很多，但是由于我们在项目初期和中期进行了深入的分析，及时的进行必要的调整，采取了适当的防范措施，加强了项目内部的沟通，及时发现问题并积极予以解决，此软件项目现在已经成功上线并开始使用。