【IT实施培训那些事儿】

序：一切不以应用为目的的软件开发都是无用徒劳的。

正文：一款需上线的软件如何去检验，在一个非专业开发人员的角度去看，无非有两点：1，软件能不能用。2，软件好不好用。

1、能不能用涉及到的层面是需求是否符合要求，流程逻辑是否通顺。

2、好不好用就是所谓的开发设计人员所做的良心活儿，包括用户体验是否良好，操作性是否便利等。

当然很多软件公司做好第一点就已经很不容易了。

原因绝大多数在于应用阶段出现的各种问题，所以，更高效更有效的培训成为了软件实施应用的重要且必要环节。

如何做好培训工作呢？

培训前准备工作：

1、一份详细的培训大计划，用于乙方内部使用。

①、培训周期、培训时间。在计划中确定培训时间，每次培训的开始时间和结束时间。

②、培训地点。确定培训地点，不同岗位的培训需设置在不同的培训地点，便于参与者的学习和实践。

eg.有一次我们的项目经理给企业做仓储流程的培训，地点设置在了会议室。虽然做了很详细的PPT，讲解如何进行集中分拣等出入库流程，但结果培训之后，到实际应用中完全不了解是怎么个流程。之后，我们又去了进行培训，地点设置在库房，对分拣单、验收单、装货单等一一的进行操作讲解，既演练了流程达到了培训的目的，又使操作员强化并加深了操作方法。

③、培训人。一般来说培训的人应该是该项目的负责人、项目经理、或是咨询顾问等高层角色。至少是一个精通该业务的IT人员。该角色应完全参与调研、设计、测试环节，至于是否参与开发就无关紧要了。编筐编篓全在收口，精通业务可以在培训中进行互动，使参与者加深印象。参与调研、设计，会让你面对甲方的额外需求时不会尴尬。参与测试，会让培训者更有底气，临时出现问题也好随机应变。

eg.有一次由于公司的项目经理安排了一个开发人员进行培训，回来后开发人员带回来N多的新需求，当然开发人员对于需求该不该做，费用怎么计算说的不算。但是，确实是会影响到客户满意度。

还有一种情况是例外，我在早些年前去给人培训财务模块。本身我不是学财务的，对财务一窍不通；老板非要让我负责，我是硬着头皮去的。首先，我不能忽悠客户，不懂装懂。先与客户建立好关系，虚心的向客户请教财务知识。虽然我是去培训，但是放低姿态（毕竟我不懂财务知识），以一个学习者的姿态面对客户财务人员让他感觉自己像老师一样，建立好关系之后，客户也会向我请教软件的应用，我依然是本着互相学习的态度去进行讲解和相互的讨论。在此期间，我不断的向客户询问财务相关的业务和知识，客户也很乐意为我解答。有了第一次的经验，之后的财务软件培训我就做的得心应手了，一来二去，我也学到了不少财务知识。

有些人问我，业务从哪里学？不同的企业业务是不同的啊？我会回答：业务来源于客户，在教别人的同时自己也在学习。在给企业设计业务流程及企业规划的时候都是需要去各个部门进行调研的，在这个过程中就会了解不同企业的不同的业务。（有点儿说多了...跑题了！）

④、参与人。指定参与人这个非常关键，做好了可避免二次培训或重复培训的工作。记住一个原则：不错重复的培训！ 一个岗位的培训如果涉及到上下两个或几个岗位的，需要这些岗位的人员都进行参与。一个流程的培训，不要每个环节一一培训，要整个流程统一培训。不要觉得参与的人员过多不好安排，整体统一培训是少不了的环节。

eg.比如培训一个采购环节，涉及到的不光是采购的人员还要涉及到入库环节的相关人员；因为需要退货，一旦退货就需要走库房环节。如果需要审核和质检，那么质检部财务部都需要参与了。

⑤、培训内容。培训人员做好PPT，有时间的话就大家讨论一下。

2、甲方参与培训的人员计划。（张贴在甲方办公地的明显位置）

包括什么时间，哪位讲师进行培训，培训什么岗位的什么内容，需要哪些人参与等。

3、计划确认。

这个环节很重要啊，计划的内容需要甲方一把手或直接的负责人进行确认。

确认内容包括参与人是否能参与培训，培训场地、设备等。

eg.有一次去客户那里进行培训，原定的2、3个人，我想用个笔记本直接演示讲解就OK了。结果到了客户那里，客户老总召集了10来号人，当时我也没想有这么多人，就没有带投影仪，弄得场面很尴尬。结果客户老总从家里搬来个大电视，解决了我的燃眉之急。

培训前的准备工作都做好了，就开始按照计划进行培训了。

培训中需要注意的一些事儿：

1、新需求。

  这个是项目经理或培训人员最头疼的问题，尤其是在产品演示的时候，会听到“这里用着不方便啊”、“字体能不能改大些啊”、“这里的按钮能不能放到上面啊”之类的问题。这些问题会直接影响培训的进行，所以在会议之前，一定要树立“规矩”。例如：在我讲解的时候大家可以随时提出问题，如果是本次软件中不涉及到的需求，我会记下来，然后和负责人进行探讨，如果是设计和操作习惯的问题我也会记下来，然后在会后与负责人和参与人一起讨论。这样在会议过程中，遇到问题就可以先记下来，不必马上作答，当然简单的就可以马上回复了，这样不会影响整个会议的进行。

2、BUG。

  测试不到位就会遇到Bug，这时培训者是很尴尬的。遇到BUG首先不要慌，尽可能的去了解BUG是如何产生的，然后截图并记录。这个是要给开发人员看的。给客户的解释一定要客观的说明该BUG的产生，（纯技术的BUG就不要说了，只说是开发人员的疏忽并道歉就OK了）。人无完人，客户不会因为BUG吃了我们的。

eg.有一次真的是因为BUG导致整个系统运行不下去了。当然我没有慌张，因为我带着开发的相关文档以及操作手册等相关文件。我把BUG现象等发回开发人员进行修改，然后我打开每个操作页面的文档进行的培训讲解。改完后，我又简单的做了一下软件演示。做足准备，才会避免临时问题。

3、参与人咋讲都不会。

  这种人其实并不是不会软件操作，简单的说他们是在“闹情绪”。因为上了软件增加了他们的工作量或是其他原因。在培训中经常会遇到这种情况。首先需要单独的进行沟通，（企业上了软件员工不可能不用，除非不干了）大概就是围绕这个主题进行灌述，当然不要这么直白。实在沟通不行的需要上报其上级领导，就是打小报告了！没办法，说不通只能这样做了。

培训之后：

1、需要进行培训确认，确认细到每个功能或者模块，这个是为了防止以后有纠纷。

eg.我还真遇到过不讲理的，口干舌燥的讲了一下午，第二天那大姐啥都不知道，然后她们经理问为啥不会，她说我没教她。导致我又去了一次进行的二次培训。这让我心情很是不愉快，如果真的是自己忘记怎么操作了，问一下我又不会不告诉她，来这么一出，着实让我措手不及。后期我养成了培训后签字确认的好习惯，都是被逼的~被逼的~逼的...

2、找“小帮手”。在培训后确认该岗位的负责人，以后的所有的问题都要通过该负责人。也就是说遇到不会的第一个要请教该负责人，如果该负责人也不会，就记录下来。我们会向参与人发放一个需求单，然后遇到问题后统一提交到岗位负责人那里，然后负责人整理之后再发给我。这样在过程中，一些简单的问题负责人就给解决掉了，我们也省去了不少麻烦。

3、信息部。这个部门是要全程参与培训的，他们是我们最大的资源，相当于我们的员工（免费的且十分实用的）

eg.我也遇到过不配合的信息中心的管理员，所以在给企业做咨询的时候把他直接干掉了，并推荐了另一个员工上位。因为我和企业有着共同的大目标，企业之所以能这么作，也是坚定了信息化的决心和态度。（顺我者昌逆我者亡！！！

开玩笑啦...我也没那么NIU X 了，估计是该员工早与企业不合~~）

结论：用心做事儿更要用心做人！