由劝退一名员工所想到的

这周五我做了一件"恶事" – 劝退了一名员工。这样的事情在部门成立10年的历史中发生的次数都是屈指可数的，但却真实地让我给碰到了。

我以前只是有招人的经验，但从未做过"开人"的事情，这是第一次，心里总有些不忍。原计划由这名同事的直接Leader与他谈这件事情，但这名女leader更是抹不开面子，索性我就直接上阵了。过程还算顺利，这名同事表面上也没有太多意见，但我心里清楚：他肯定很郁闷，这个周末估计会很失落。我们也不想这样的事情发生，但之所以做出这个决定也是因为这名同事"所作所为"实在是太不给力了。

这名同事进入我们产品线大约有一年半时间，他并非是我们招入的，而是由领导从其他项目组安排过来的(恰逢那时我们缺人)。最初安排他做开发侧的技术支持角色，负责产品的升级支持以及生产环境问题的解决，算是隶属开发运维团队。但一段时间后他似乎没有得到运维团队内部的信任，给他派的活儿都是很边缘的，生产环境遇到大的问题基本都绕过他而直接找到原开发人员解决，形成这一局面的原因无非有二：一是他无法独立地及时解决生产环境中的问题；二是在自己无法解决的情况下，也没能很好地协调他人将问题解决。长此以往大家索性就不找他了。团队内部不能养闲人，我们还是给了他机会 – 尝试让他做些开发团队的工作，把他直接安排到上面提到的那位女Leader的项目组里面。经过了大半年，他给出的成绩单却是：失去了所有团队对他的信任，大家把他彻底孤立了起来。团队并非一开始就失去对他的信任，而是不断给他机会，给他的工作都是相对比较简单的，时间上也相对宽松。但即使这样，他也是不断延误进度，提交上来的东西也是频频出错，耽误了自己不说，还耽误了其他团队的整体进度，大家逐渐开始对他都不耐烦了，我这里也不断收到大家对他的抱怨，局面就是这样形成的。年中面谈时，还曾明确给他指出了不足，并就改进绩效计划达成一致，但他依旧没有达到我们的预期。木桶理论告诉我们：在一个团队里，决定这个团队战斗力强弱的不是那个能力最强、表现最好的人，而恰恰是那个能力最弱、表现最差的落后者。于是我们从全局考虑，从团队的整体考虑，我们做出了上面那个无奈的决定。

我做了一下换位思考，如果我是这名同事，到底是什么原因让我走到了这步田地呢？下面我就来帮他分析分析。

首先，我想这位同事没有走好融入团队的第一步棋 – 赢取团队的初始信任

对于一个刚刚进入团队的新人（无论是有工作经验的还是刚毕业的新人），赢取团队的初始信任都是最最重要的。下好这第一步棋其实并不难，把你的直接上司分配给你的第一个任务做好即可。当然如果要赢得超出预期的信任，那就得做的完美一些。在这个阶段，你最好能专心投入，甚至“牺牲”一些个人时间（对于程序员来说，这很容易理解^_^），快速地熟悉新环境、行业领域业务知识、产品以及团队风格。一旦你的第一个任务达到或超过了大家的预期，团队对你的信任也就建立了起来，后面的事情就变得自然而然了；而一旦你搞砸了第一个任务，那就相当于从团队成员那本来就积蓄不多的情感账户中取款，那后续走势如何就要看这个团队的耐心了，他们到底会给你多少次犯错的机会呢！

其次，能力不足且没有努力做出改进

赢得信任需要有资本，这最起码资本就是个人从事这个行业工作的能力。绝大多数行业中处于能力平均水平的人维持一份稳定的工作都不难。但问题就在于如果这个人没能认识到自己能力的不足，或是即使认识到能力不足，但也不努力改进，那这个人就危险了。我的这位同事身上显然就发生了这个问题，这一年多以来他的能力或技能只能说是原地踏步，在IT这个行业里，大家都知道这意味着什么。

最后，态度！

俗话说："世上无难事，只怕有心人"。这句话从侧面反映的是一种做事的态度，而我的这位同事被诟病最多的就是做事的态度上。我从多方面反馈了解到，他似乎就没有把分配给他的任务当成自己的事来做，总是囫囵吞枣，不断犯错，不断被指出，之后依旧不断重复犯错，似乎一点改进的意识都没有。如果把工作视为可敷衍了事的事情，那后果可想而知。

也许还有一种更为深层次的原因，我也不敢肯定，那就是他也许根本对程序员这个行当不感兴趣。缺少动力，行将就木，做一天和尚撞一天钟，因此有了糟糕的表现。如果真是这样的话，那就是严重地对自己不负责任了！说得严重些叫浪费生命，也许他换个行当就能出类拔萃呢。

在组织层面如何为避免此类事情发生呢？也许只能严把入口。但说起来容易做起来难，仅仅通过几次面试，很难全面地去认识一个人。刘未鹏不是写过一篇文章叫"怎样花两年时间去面试一个人"吗，显然也印证了这一点。

最后还是要对这位同事说一声：你还年轻，这仅仅是一时的挫折，绝不应该就此消沉，反思一下，找到一条更适合自己的路，好好的走下去。