两年的时间培养一名工程师绰绰有余，但是在IT这个人员高流动的行业里，两年可能你已经培养了N批工程师。每一次的培训都让人心有余悸，总在担心一件事情：他们能撑多长时间？也许有人会说：“怕什么，四条腿的蛤蟆难找，两条腿的人还没有吗？”人，不难找。但我们不是仅仅在找一个长着两条腿的人。

不记得这批工程师是第几批了。从学生见习到社会招聘，我们都尝试过。从最初的宣扬来了就能干，到现在的一次成功率逐月下降。两年的时间换来一句话：要重视工程师技能培训！难道这两年的时间一直没有重视培训吗？

非也！问题在于重视培训和真正重视地去做是两码事。大家都知道培训重要，会上也提，会下也说。其实两年里培训方面也具备了一定的基础。培训制度，有；培训教材，有；培训讲师，有；培训教室，有；培训管理，也有。这说明培训管理并不是一贯的无为。而是在提醒工程师培训管理出了问题。

一、培训职责不明 岗位考核无为

曾经招过一名专职的培训管理员，但不甚理想试用期内就放弃了。自此，培训管理员由服务台主管兼任。培训工作的分工很明确，服务台主管负责培训的计划、协调和准备，具体培训工作由各培训项目负责人安排讲师，发放资料。完成培训后由服务台主管回收培训评价表。一切都很规范。

但是从实际运行的效果看，服务台主管虽然被赋予培训的职能，但是并未写入岗位职责，如何考核也没有明确。培训管理的考核缺失使得大家只要能做到即可，至于做得好和做得不好并不是最需要关心的。不能要求员工都自觉具备主动的工作意识和积极的工作态度。没有明确的岗位要求，势必会带来执行上的不作为或者仅仅做到表面上的执行。

二、责任心弱化 执行不到位

虽然在培训管理上由专人（兼职）负责，但是实际执行上并没有尽到专人负责，一管到底的责任。职责不清是一个原因，表面上培训的各个环节都有人负责，但实际上谁都可以不负责。因为“这是不是我该做的”会在每一个人的心里打上问号，这些问号在工作中就会带来打了折扣的执行效果。

也许，不应该这么不信任自己的员工。我们可以非常信任他们，相信他们会主动而又积极地去做那些并不清楚是不是该自己干的工作。如果真的是这样，我们今天就不需要讨论这件事情。

事实是，当培训管理员将培训事宜告之负责工程师培训的同事之后，仿佛培训的工作已经交接完毕。剩下的事情都是他来负责了，我的任务已经OK。再问下去，听到的也只是一句：“我已经告诉他了。”回过头再去问那位负责工程师培训的同事，得到也是类似的回答：“培训制度已经做好了，还没有审批。审批之后才能正式执行。”皮球接着踢到了主管那里。其实，无意去追究他们某个人的责任，从中更应该看到的是谁应该在培训管理中起到“首问负责”？培训流程在各自为政中被割裂成一个一个的独立环节，原本起到链接的“责任心”不见了。 有人负责，但没人负责到底。这是今年工程师培训出现问题的关键。

三、培训制度难保证 培训时间有缩水

公司制度制定出来就是为了规范某些工作。当制度和具体业务冲突时，我们是遵守制度规范操作，还是撇开制度自行调整？此时，制度的严肃性面临巨大的挑战；业务的灵活性带来艰难的选择。我们可以在任务紧迫的时候，缩短前期的培训时间，但万万不能就此提前结束培训，减少培训制度规定的培训时间。使用缩水的培训培养出来的工程师去应急业务发展是短视的行为。因为培训时间的保证，其实就是在保证工程师的质量。今年的培训管理在应付了紧急任务之后忽略了工程师的再培训，直接导致一次成功率的持续下降和客户、老板的不满意。

四、新人带教未成气候 知识传递有障碍

新人们在一片迷茫中开始了新的工作。虽然每位工程师在入职后都会安排相应的课程培训，但效果并不是很理想。一次课程下来基本上对他们而言听起来比较累。培训主要以集中填鸭式为主，而且还是一次性填鸭。之后的培训就是让有经验的工程师带教新人。新人跟在“老人”的后面边干边学。如果遇到认真的老师，新人还能学到点东西；如果遇上不负责的老师，新人往往被当作劳力来使用。由此，新人的成长速度和质量就会出现因带教人而异的情况。

对于带教人只有带教要求，没有激励措施。又是一个指望员工自觉主动、积极工作的情况。何为带教？带教不是请客吃饭，而是传道、授业、解惑，是知识的转移。带教新人需要热心、耐心和爱心。这样在带教的知识转移过程中，被带教人才能得到更多，成长更快。作为激励，难道不应该给予主动传授知识的员工一个合理的奖励吗？

培训考核的缺失导致培训管理稳定性差，培训制度严肃性与业务灵活性之间的关系处理忽视了培训作为保证IT技能质量的基础作用。这两点是今年培训出现滑坡，一次成功率呈下降趋势的关键原因。

IT服务提供给客户的是什么服务？不是你的长相，不是你的服务技巧，也不是你的管理流程，而是你的IT技能。IT技能体现在工程师身上就是解决问题的能力。我们往往会从管理的角度来分析关键业务，来寻找工作的重点。但是我们是否认真考虑到IT服务的关键点在哪里？IT服务关键点就是工程师解决问题的能力。这种能力包括原本就具备的基本IT技能和进入公司后续培养得到的IT技能。人才在21世纪最贵。这贵就贵在解决问题的能力上。

如何稳定地保持工程师解决问题能力？培训，除了培训别无他法。很多人认为：培训=会议室+投影仪+讲师+培训资料+培训设备。这样的培训认识没有什么错误的地方，只是过于狭隘。应该从更宽泛的视野谈培训。引用知识管理的概念，培训其实就是利用各种机会、各式工具、各色人等来充实自身知识，提高自身能力的活动。所以这种自我修炼的活动就不必拘泥于会议室，可以是实地带教，也可以是工程师之间的日常交流。 培训可以保证IT技能的稳定，什么可以保证培训的稳定呢？首先，明确培训职责。责任到人，考核到位。这才是稳定培训的基础。是专人专岗，还是兼职担任并不是主要考虑。就在写总结的时候，总公司下发了一个工作岗位调查表。如果能利用此次机会将培训管理的岗位职责清晰定位，那么明年的培训工作就会有一个良好的开端。

其次，培训的规律需要得到尊重。俗话说：十年树木，百年树人。这其中暗含着一个时间的规律。时间不是保证培训质量的惟一要素，但是没有时间保证的培训绝不会取得高质量的效果。因此，无论是在培训制度上，还是实际的培训过程中，保证培训时间是需要放在首位考虑的。特别是当培训要求与业务的紧迫性发生冲突时，遵照培训的时间规律保证培训质量才是面临冲突时应该具有的态度，而不是以牺牲培训时间为代价单方面解决业务紧迫性问题。二者之间应该是双赢，而不是“零和”。

第三，带教需要环境，带教需要激励。应该考虑为工程师营造积极主动的学习氛围。会议室这样的集中式培训固然必不可少，但是更关键的是之后持续性的培训。记得前年一个项目从实施转为运维后，我们采取的方式是“营造气氛，以谈代培”。一个工程师回来我都会和他聊聊。比如：今天遇到什么问题，你怎么解决的，还有什么问题没有等等。顺便把其他工程师也拉进话题一起聊。这样慢慢地他们回来之后自然而然地就会聚在一起聊各自遇到的问题。一个问题大家都在讨论，讨论的结果得到最大范围的传递。

带教前面已经提到过它是一种知识的转移。现实地讲这种知识转移带有风险，因为你是在培养一名竞争对手。我曾听到有人说某某工程师不愿意给同事讲太多的技术细节。说实话，我听到这件事心里很不是滋味。这名工程师曾经是我的部下，当年实施我们在一起讨论问题时大家并没有去隐藏什么技术细节。为什么现在会出现这样的情况？是自身有危机意识，还是缺乏分享的氛围。也许二者皆有。

也许我们没有“人类失去联想，世界将会怎样”的严重后果，但是“带教失去激励，培训将会变得怎样”我们还是可以在不远的将来预见到。

最后再问一下：是谁在支撑我们的IT服务？

答：是具备解决IT问题能力的、合格的IT服务工程师。