IT外企那点儿事(11)：你的员工为什么不努力有很多人抱怨员工不努力工作，常常想为什么有的人年纪轻轻就不努
IT外企那点儿事(11)：你的员工为什么不努力
有很多人抱怨员工不努力工作，常常想为什么有的人年纪轻轻就不努力奋斗，甚至想现在的年轻人的艰苦奋斗的劲头可是越来越差了。
大部分人认为拿一天工资就应该好好的干一天活，哪怕做一天和尚也应该撞一天钟。这的确是最基本的职业行为，然而在现实生活中，我们却发现，当一个员工心不在焉的时候，也就失去了做好每一天工作的动力，似乎公司对其有所亏欠，而支付的工资是对以往的债务和每天流逝的青春的补偿。
似乎仅仅用懒和不努力并不能够完全解释好这一切，而事实往往相反，表面上表现出不努力和不思进取的员工，却在你不知道的方面非常的努力和进取，也许他在钻研自己感兴趣而你的项目中用不到的技术，也许他在准备跳槽，进入一个比现在的工作强得多的公司或者职位，也许他在暗地里创业，并且心理非常鄙视你这种在外企小富即安的生活状态。其实很容易明白，当年这些小伙子小姑娘们意气风发的成功加入这家公司，必定是有一定的激情和能力的，没有一个人愿意懒，愿意不进取，愿意放弃，你不必抱怨当时这些人是怎么被招进来的，招人的人多么不负责任，也许应该反思为什么他们的激情和能力没有被激发出来而日益埋没。举一个比较极端的例子来讲，如果说让一个人每天工作16个小时，工作三个月，则给1000万，相信没有一个人是不努力工作的，哪怕是平时我们认为很懒的人。
在管理学中，有一个期望模型，内容是：激励是一个人欲望的大小及其对实现欲望的概率估计二者的乘积。也即一件事情是否能够激励人们努力去做，一方面取决于这件事情本身的价值(这件事情能够满足人们多大的欲望)，一方面取决于这件事情做成的概率。
对于上面的例子中，显然1000万能够满足人们对于财富的欲望，这1000万对于大多数程序员来说还是很有诱惑的，很有价值的。而对于做成这件事情的概率，相信大部分人还是能够坚持三个月每天16个小时工作的，概率大大的。所以很难有人不全力以赴。
当然对于程序员有价值的事情不仅仅是金钱，还有比如加薪，升职，以及是否使用期望掌握的技术，是否是核心模块，产品对于公司是否重要等等。
了解员工的需求他是期望做C++还是Java还是Python，是期望从事windows平台开发还是linux平台开发? 虽然作为管理者来讲，觉得语言和平台不是问题，无所谓，能够完成功能即可，况且让他多学一门语言和平台，也是对他能力的提升嘛。可是事实有时候不这么简单，有的程序员是具有宗教式的语言和平台崇拜的，如果感兴趣，大家可以搜索一下各大论坛有关哪种语言好，哪种语言快的讨论贴，也基本验证了一句所谓的论坛规律：当回帖超过一定的数目，双方就不再是摆事实讲道理，而是无理的互骂了。还有一个很囧的笑话来描述这种现象：搞C的看不起搞C++的. 搞C++的看不起搞java的. 搞java的看不起搞.net的. 搞.net的看不起搞js的. 搞js的看不起搞html的. 搞html的看不起美工. 最后美工周末去泡mm的时候, 一群傻X在那里加班！
他是期望做底层还是上层? 程序员还是有各种各样的性格和目的的。有的人期望做出一样东西来很快的能看到成果，从而心中不断充满了成就感，而有的人则期望深入底层代码，甚至公共库，尽量把每一行程序写得完美和高效。有的人急性子，改点东西要马上运行一下，如果有bug，再debug来改，程序运行到这个地方，变量的值大概是i，他才懒得考虑具体是i + 1还是i – 1，运行出来效果不对再调整。而有的人写完代码一遍遍的自己code review，甚至用笔演算，保证准确无误，才运行看看。有的人实现功能，倾向于用最直接简单的方法，先实现出来跑通再说，有的人则倾向于事先做长时间的设计，考虑种种复杂的场景，最后达成一个在其心目中完美的设计。有人期望更多的了解业务，进而以后能够接触客户，转售前，或者出去创业，能够接项目或者做个互联网应用啥的，有的人则期望成为技术专家，在某个方面挖的足够深，成为大公司的技术骨干。
他是期望加薪升职还是期望跳槽或创业? 大部分领导都认为，在公司里面工作，加薪和升职是每个员工必然的追求，其实事实并不一定如此。有一部分人可能并不认同公司的文化，而仅仅是想学习这里的一门技术，将公司作为跳向其理想公司的一个跳板的。或是其想创业，但是还需要一个工作来吃饭。这类员工看起来往往认真刻苦，但却不出成绩，不以组织目标为目标，而利用部分上班时间和大部分业余时间进行学习，其不怎么爱参加集体的任何活动，他们喜欢单独执行的任务，不愿意参加需要大量沟通的任务，他们喜欢从事机械性的任务，而不愿意接触核心模块的复杂设计工作，团队开会的时候总沉闷不言，自己看自己的电脑，对什么反应都是好好好，工作外却异常活泼，有很多公司外的社交活动。对于此类员工的管理相对困难，你对他们讲前途，讲加薪，讲升职是没有用处的，所谓人心散了，队伍就不好带了，他们的心已经不在这里了，他们会想等我跳到另一件公司，薪水起码翻一倍，或是你加的这点薪水，对于物价房价飞涨的今天根本没有用处，等我创业成功才是正道，当你苦口婆心讲在公司如何发展的时候，他们在心目中甚至连你也一起鄙视，心想你混得也一般么，众多程序员中芸芸众生中的一个，我一定能闯出一番事业，一定比你强。所以，对他们来说，务实的沟通是最必要的，对于心已经飞出公司的跳槽者，你们可以在会议室里面将这层彼此知道的遮羞布揭开，然后给他一段时间，比如两个月，三个月，仅仅给他零碎的，边角的，独立完成的活来干，让其尽快的集中精力完成这次跳槽，无论是对他(不必浪费时间)，对你(可以空出名额招人)，对团队来讲(不会影响团队人心)都是有好处的，但是要明确告知这样会影响其当期的绩效，如果三个月后并未跳槽成功(该面试的基本都面过了)，则他一般会稍微的收一收心(外面的行情没有想象的那么好，或者自己的水平还需要积累)，这时候你们可以再次坐下来谈一谈，看当前的工作中，是不是可以有他更感兴趣的工作，希望他在接下来的一段时间内(至少半年)可以全力以赴的工作，如果工作出色，可以弥补上面的绩效损失，这个时候，大部分员工都会沉下心来重新投入到工作中，如果其还是不能够完成基本工作，则已经基本仁至义尽了，则可以再次坐下来谈谈，劝说其自愿离职，这样他可以继续集中精力准备跳槽，不必每天在公司痛苦不堪，如果不愿意自愿离职，则在过一段时间，就可以进入观察期，观察期不合格，就可以进入辞退流程了。如果有的公司没有辞退流程，则可以两年绩效评价四级(Not meet)以下，就可以辞退或者不续签合同了。对于在公司混碗饭吃的创业者(本人其实是不太崇尚兼职创业的)，可不安排他们具有挑战性的核心工作以及在公司内部有发展性的工作，只要其能保证完成基本工作，给予他们基本绩效就可以了，如果不能，则也需要坐下来好好的谈谈了。
知其然，知其所以然其次，在了解了员工的期望后，在分配工作的时候，要尽量顾及员工的期望，让员工知其然，而且知其所以然，也即不但让员工了解要做什么，还要了解为什么这么做，这么做如何符合组织目标也符合其个人目标(其实大多数员工，尤其是有很长时间工作经验的员工更注重个人目标)，而不能像至加西亚的信中写的一样，只关注结果。有一个不值得定律是这个样子说的：不值得做的事情，就不值得做好。 这个定律反映出人们的一种心理，一个人如果从事的是一份自认为不值得的事情，往往会持冷嘲热讽、敷衍了事的态度。不仅成功率小，即使成功，也不会觉得有多大的成就感。毕竟你不能要求每一个员工都是罗文，如果每个员工都是罗文了，还要你这个领导干什么？
在分配任务的时候，使员工了解整个项目的全貌也是很重要的。很多程序员都不甘于自扫门前雪，而是很希望看到系统的整个架构，自己做的模块在架构中的哪个位置，如何层层调用，这样不但能够帮助其了解工作的价值，而且会感觉这些信息透明是对他的尊重，并有利于其在朋友同事面前描述其工作的时候更加的高屋建瓴。
如果能在项目设计，计划，模块划分，任务分配阶段，能够较早的让员工有所参与是很必要的。哪怕是仅仅与会而没有发表成熟的建议，或者头脑风暴的idea没有被接受，员工也会认为自己是项目参与者，而不仅仅是执行者，往往会在工作中更加的投入，更加的愿意承担责任。大多数程序员并不乐意看到这样的情形：一帮子领导在会议室里面开会，不知道说些什么，也不让自己参加，没头绪的开完会自己头上多了个任务，这个任务从哪儿来到，要和那些人合作，做成什么样，为什么不是另外一种方案，全部不得而知，还需要一个个的去沟通。他们往往认为：对有关自己任务决策的会议的参与是必要的，哪怕自己的水平不足以做架构，自己的方案比不上资深架构师的方案，经过讨论败下阵来，明白前因后果，来龙去脉，也算心服口服。自古就有文人相轻的说法，程序员身上多少还真有些文人的高傲气质，如果不加讨论的利用职权将方案A强加于他头上，他往往心理一定认为自己的方案B是好的，并在以后的工作中下意识的来努力证明A方案的不足，一碰到困难就会说：看，我早就知道这个方案会有这个问题，用我的就不会。而且会在后续的工作中逃避责任，于是说：方案是他们定的，性能能达到这个就很不错了，很难再进一步的提高。
提高成功概率再次，在制定任务目标的时候，要把握好任务成功的概率。既不能把目标定的太高，也不能太低，一个通俗的说法是，制定一个跳起来能够够得到的目标。如果定的目标太高，使得员工无法企及，从而产生极大的挫折感，从而自暴自弃。一个笑话是这样说的：如果领导安排的任务上班时间能按时做完，那是谢天谢地，可以准时回家了，如果上班完不成，那就需要加班完成了，如果加班完不成，那就需要通宵搞定了，如果发觉通宵也搞不定，靠，不干了，于是准时回家了。所以在制定目标的时候，一定需要同员工开会商议决定，由员工来预估时间，然后根据进度要求作微小的调整，或者减少功能，你可以仔细询问员工预估时间的理由，并确保没有什么难题对员工的工作造成阻碍，因为可能在上司或者有经验的人员看起来顺利成章，轻而易举的事情，对员工来讲是一个很大的难题。在这个方面，scrum如果执行较好的话，是一种比较好的实践。当然如果目标定的太低的话，会使得工作没有挑战性，从而丧失激情和意义，程序员多是热爱挑战的群体，他们大多抱怨日复一日的ctrl+C/ctrl+V的重复性工作，期望能经常研究一些新的或者更加深入的技术。所以任务分配中的一人管一摊，做什么总做什么的现象也是不好的，一方面缺少backup，当出现人员流动的时候，不是临时交接就能够交接的了的，另一方面大家的工作都缺少挑战性，也不利于员工了解项目的全貌。所以应该一两个精通的来保证质量，带一两个一般的，这样一方面促进沟通能力，一方面对一般的来说是一个挑战。而在此任务中精通的到了其他任务上，可能就变成一般的了，同样也具有了挑战性。如此下去，大家都了解了项目的全貌，其中素质较好的员工就可以预备成为架构师了。
另一个提高任务成功概率的方面，是对任务执行过程关键点的把控。有时候，我们的员工工作没有成效，并不是员工不努力，而是努力的方向不对，不知道那些是正确方案，遇到问题应该找哪些人寻求帮助。所以作为管理人员，是有义务对过程进行监控的，而不仅仅是要结果。比如在写代码之前，对员工的设计和方案进行评审，就是很重要的一个环节，通过这个环节，可以确保员工做的正是你想要的，而不是代码写了一大堆，却发现南辕北辙，大大的挫伤积极性。程序员是最讨厌一个东西改过来改过去的，一行行的代码就是一行行的心血呀，哪能说扔就扔呀。所以网上流传着一首改编的歌：当初是你要修改，改就修改，现在又要拍脑袋让我改回来，设计不是你想改，想改就能改，让我改版让我修改你丫自己来。虽然在新产品的开发过程中，返工是不可避免的，但是作为有一定经验的老人，是可以通过架构方面尽量的减少这方面的冲击的，新人在这方面是需要指点的，对程序员劳动成果的尊重是最大的激励。
兑现回报最后，应该给予员工的应有的回报来匹配员工的付出。如果曾经有没有兑现的回报，则会大大降低人们心目中的概率。就像上面的例子中，如果一开始说给1000万，后来只给了10块钱，那下次就再也没有人会努力工作了。
