软件项目如何进行技术转移

一、概述：

软件的项目的运维，需要各个角色的支持，才能进行下去。要改变过去那种技术转移的方式。

二、现象：

系统经过测试，经过现场、集中培训，在实际的现场使用情况调查来看，使用效果并不理想。

经过了解分析，发现用户还是不会使用软件的操作流程。

三、原因：

培训的思路是这样的，在软件安装现场，现场教给调度员使用的步骤。在试用一段时间后，集中起来进行培训。为了增加他们的重视程度，还在培训前进行考试的通知，在培训中由技术工程师对软件的使用流程进行实际的演练，并随由时进行答疑，在培训后，进行理论考试，考完试后，会接着对一些知识点进行解答。

培训的程度按说应该可以了。但是，经过咨询，用户说都不不记得了这些操作过程。

真正的原因：

1、人力特点：

用户公司也属于人力密集型企业，其中的个各层用户的人员年领较大，没接触计算机，绝大部分角色对计算机基本、硬件、操作、软件知识不了解。

对他们进行培训，一次、两次就期望能够熟悉使用，不太现实。 

2、软件特点

业务软件的操作流程非常复杂，尤其是异常操作流程。但从软件上，无法看出业务操作流程出来。因为软件不像是Projcect一样，可以有一个向导，系统没有向导，这个向导只有在我们的技术工程师的大脑里，只能够靠言传口教。自己都很难记得住的东西，不要期望用户比你更记得住。 

3、人生理特点

人如果接触一种新的东西，除非有特别深刻的印象，否则，这种东西很容易被忘掉。

培训力度、强度还是需要加深、重复。 

4、观念特点

用户的领导如果重视了，就会强调下，下面的人会好好听下。如果不重视，那么下面的人同样也不重视。在这样不重视的环境里，渴望系统技术转移的效率高，难度大，相当大。 

四、方法

针对以上的原因，可以拿出预防措施。

1、尽量安排有计算机知识的人来承担相应的角色。

在用户的责任分配矩阵和运营岗位要求上，尽量要求懂计算机的人来承担这种角色。 可行性20%

2、软件添加向导

给软件添加向导，而不是把各种功能堆在那里。

站在使用者的角度，从业务流程的方面，做成简明指导。不是站在产品的角度，罗列各种功能的使用。可行性100% 

3、增加培训的次数和阶段 

安装期：现场让角色了解软件的安装、配置、使用的过程，建立眼见为实的第一印象

初次理论、操作培训：简述软件的业务流程，对业务流程进行演示 

试用期：让各种角色使用软件，同时让用户里负责软件技术培训的人员，对角色进行现场跟踪培训。记录疑问点

二次培训：对业务流程第二次进行实际的操作演示，针对个别用户（能力一般的），进行特殊培训。上机操作考试：可行性 100% 

4、灌输重视程度 

给用户的上级领导灌输培训的重要性，给与下级定期强调

给用户的中层领导灌输培训的重要性，给与下级定期强调 

给使用者灌输培训的重要性，定期检查使用效果。