是谁送走了我们的同事

* 好友刘毅的一篇博文，道出了现在IT公司 普遍存在的问题。

题记：对于我们将要讨论的问题来说，以本人做看客的本领，只能观察体会个万一，要解决问题可以去咨询职业顾问。关于吸引员工或者挽留员工的办法，专家们能够提供很多精彩的案例，请大家移步互联网去搜索“IT员工流动”等相关关键字，相信不会让你们失望。

离开比我早——不断惋惜和等待


年复一年，伴随固定的那几个月的员工流动大潮，不经意间我们身边的同事一个个各奔东西，他们的出走有的是为了更高的收入，有的是为了自己的职业理想，还有一些是出于对家庭等其他一些特殊问题的考虑……很高的员工流动在软件外包行业倒不算个新鲜事，不过在一家对员工发展一直有着长期规划和帮助的大公司（一般以甲方的姿态出现在IT行业）来说就有点奇怪了，尤其在公司给大部分员工大幅加薪的当口，一个个员工的离开就更加令人困惑了。当然另外一方面，只要不是被“卖来卖去”，适当的人才流动是能够促进行业技术发展的，只是谁能够从流动大军中获取自己所需那就得看公司的各方面实力了。


最近我们一个资深的、工作态度和业绩都相当不错的同事离职了，在讨论这个问题的时候，我们的部门经理很困惑的感叹了一句：“这到底是为什么呢？！”我没有参与谈话，不过我能想象的到我们领导脸上的表情，我也知道他这句为什么绝不单单是在惋惜这一个同事的离开，而是在对公司当下的情况表示困惑。对于一个有着数年上百人队伍管理经验的经理来说，分析这种事情原本不是个事，想来大方向也就是薪水和职业两方面。其实我觉得领导们可能忽略了一些细节，而恰好这些细节就是一个个地送走我们身边熟悉的同事的根本原因！要找到这些细节，就必须换位思考，彻底地把自己摆在与员工同等的位置上，否则在根本观念上就无法达成一致，更不用说找到底层员工所思所想的一些细节问题了。


我一度也有离职的想法，虽然被家人、同事乃至网友劝阻了好几次，但我的初衷还是没有变化，只不过现在还在幻想着、等待着公司的变化。大家不要批评我为何不主动去改变这个公司，因为这种事情本身很敏感，如果你去联合一群人来传播、推行你所谓的思想，试图去改变什么的话，公司将面临更大的不稳定，所以看起来向上级反馈一些不成熟的建议并且期待改变的到来恐怕只能是我们当下最好的选择了。总之我也算得上一个有离职动机的人，在我个人看来，让我们不爽的原因有以下几点，愿与大家分享。


员工的事业——公司事业的基石


要知道百年之前就有先贤指出职业和事业之间的差别，我也是约一、两年前借读开发部同事的《改变从阅读开始》这本书才领悟到的。通过网络上的搜索也可以看出很多人都在对这个问题进行思索，并且大家都把这个问题和工作中的自身归属感和主人翁意识联系在一起：求职业者唯养家糊口，求事业者可扭转乾坤。可惜的是有些老板却至今仍津津乐道于自己如何用一份薪水和一个职位，成功地把每一个员工变成一颗螺丝钉，并且牢牢拧在了不停运转的公司机器上。


你可能认为做螺丝钉和成就一番事业并不冲突，但其中的差别还是不容忽视的：如果有做事业的想法但仍然被看作一颗螺丝钉，那么我们的心理定位就彻底被颠覆了，我们会失去自我成就感和自我认同感。从最开始的满怀激情，以公司为家、以公司目标为己任，处理任何事情主观能动性都很强，到后来逐渐丢失掉这份激情。作为螺丝钉，我们所看到的公司的一些好或不好，并不能因为自己的激情而改变，无可奈何的落寞和被忽视的感觉衍生出强烈的挫败感。经历一段时间之后如果仍怀有理想，坚持成就自己的事业或者实现个人价值的体现，就会自然而然的产生牢骚情绪，而且这种情绪能够很快的感染到别的同事；而如果因挫败感而失去斗志，这个人将长期被禁锢在一个定位上，失去激情，失去创新力，甚至失去接受新鲜事物的能力——对于企业来说，还有什么比这更可怕的事么？


对于我们年轻人来说，求职业易，求事业难！难就难在老板们往往只关注全局，相比员工的事业成就需求，更加在意自己的事业，并且要求员工要理解他们为何这么做，我理解这就是所谓的“一将功成万骨枯”。关注全局自然是对的，但是如果忽视了员工的成就需求，那“万骨”未必会枯，这“一将”是肯定会枯的。老板们往往也在纠结于到底是该审计每个员工的行为还是彻底相信他们，让他们发挥自己的主观能动性，老板不同的选择决定了公司的文化氛围：是中规中矩、步步为营还是开放活泼、激情创造。事实上很早之前就有很多聪明的老板已经意识到一个有斗志、有激情的团队才是成就他们“大事业”的根本，所以他们在开发员工潜力上下了很多功夫，力求员工的“小事业”和公司的“大事业”同步发展。可惜有些老板在在他们的“大事业”成就之后对“小事业”关注度就没有那么高了，无论他们是否愿意承认，正是降低对“小事业”的关注度，让他们从“激情创业”转而陷入了“艰难守业”的尴尬境地。


我们公司给员工定制了十分清晰明朗的职业发展路径，对员工的职涯规划非常关注，我们的培训机制在整个行业来看都算得上凤毛麟角，虽然一般员工在职的时候觉得这都是理所当然，不过只要离开这里到别处供职就会发现这里提供的一切是多么的优越。但是，这只是提供了成就自我的一些基础素质的培养，在实际工作中所需要的行事自主权、积极的氛围、独立的个人心理空间以及自由的技术发展方向等各方面因素综合起来才有可能让我们问鼎“成就”二字。


决策参与感——我们不是路人甲


底层员工一般不奢望能够参与公司的战略发展方向的决策，但是正常情况下我们都有去了解的欲望。所以，上层的任何决策，我觉得都有必要及时知会给我们所有员工：让我知道我还是这个公司中的重要一员，而不只是一个看客，而看客是绝不会以公司的事业为自己的事业的。


与我们日常工作息息相关的一些问题的决策权一般都在我们的主管和经理们手里。领导的作用是领航和导向，他们对这些问题的看法都比较全面透彻，所以一般情况下他们都会直接决策，然后传达到各级执行层。只不过在IT领域里有些问题还是需要站在不同的角度去考虑的，只是看到决策的合理性和可行性是并不足够的。例如，我们公司在制定软件开发EPG流程的时候就是由几个专家一起形成的规范体系，然后交由各个部门进行培训和推广，在实施过程中遇到问题再逐层搜集反馈回头，再由专家组进行规范的修订。在整个过程中，绝大多数员工是没有决策参与感的，即便知道这些规范从大局上说是合理的，也会因为在实际操作过程中发现的一些不合理的地方或者疏漏而产生抱怨情绪：为什么你们拍脑袋定出一些说不通的规范来让我遵守？这明显是不利于我们工作的嘛。


就拿上面这个EPG规范流程定制的例子来说，很明显我们应该还有更积极的方式来形成我们的决策。我们可以限定公司每个员工最多提出两条规范条文，汇总呈递，再由专家组组织各个部门或者各个领域的代表进行会议讨论。参会代表可以根据工作表现和工作内容的特殊性进行筛选，避免由考核界定或者领导指定，以免产生不必要的误解。这种会议内容其实很简单，即便与会人数众多，也不会拖沓冗长，因为只需要对于条陈上的每一个建议规范进行分析和“民意表决”即可，最终很快就能形成广为认可的规范章程。这样一来，一个人或者一个小组中的某些人总有可能是对应领域规范的其中一条或者几条的提出者，那么在执行这些规范章程的时候应该不会含糊，因为这个规范的提出和决策都是由我们自己或者我们所属的小团体参与形成的。


我们也能够看出，其实要想让员工有决策参与感，就要把事情从底层向上做起，领导提出议题，底层员工讨论、决议，逐层向上呈报。虽然最终拍板的还是老板，但是毕竟大家都应该知道这是怎么一回事，因为我们经历过这件事情的决策讨论。这种从下到上的流程比起领导找来几个人把决定做了，再从上往下推行的做法来得更简单，执行过程中所遇到的问题也更少一些。当然，我们也知道，对于那些非黑即白的选择性问题的决策，如果不是关乎战略发展的大事件，影响只在员工自身权益层面上的选择性问题，只要给大家机会参与投票就行了。


员工价值观——要求同更要存异


公司运营模式一般都是比较成熟固定的，而员工自身的发展情况也是要随着公司的需求去不断变化的，这里就可能存在一种员工个人职业发展方向和公司发展需求脱节的情况。例如，公司对IT的第一要求就是稳定运营，保证业务系统的可用性压倒一切，这就意味着公司可能会长久使用一个固定的流程体系和一套技术与工具。但是在员工眼里，可能科技进步早已大步甩开了自己和自己所在的公司，技术上的追求和对公司发展前途的担忧促使他们产生很强烈的新技术的学习和使用欲望。这种情况下，公司现有的技术体系可能又不需要这些新技术或者新思想的存在，就产生了新的矛盾：以使用最新进技术来提高效率、减少自己工作时间的价值取向与稳定压倒一切、避免未经尝试而带来失败的技术引进的意识观念之间的冲突。


其实这种问题很好解决，只要领导了解员工的这种思想意识，他们自然不会轻易否定大家的思想，因为这些新兴的技术或者方法能够提高生产效率。但是往往有领导只是让员工去证明一下这些新技术、方法的优越性，却并没有从根本上去支持员工的这种改进欲望。就像自动化测试刚开始推行不多久，有人告诉测试经理一个想法：如果引进先进的框架技术将会大幅提高脚本质量和测试有效性、降低脚本维护成本，出于谨慎测试经理会问：你试验过没有？然后这个人会一五一十的把自己所实验的结果数据提供出来，测试经理赞许地说：很好，你可以试着先在组内推广一下……其实测试经理还是在谨慎，不想因贸然的推行如此大的变革而引起发意外的损失。然后这位仁兄开始在组内费力的推行自己的想法，每有种种阻力，经理总会鼓励说这件事你要持续进行，不要急躁。年底考核时，这位员工得了A+，而事实上，新技术的推行还并没有取得实质性的效果。其实推行一个新的技术和方法在一个长期使用固定流程方法的组织机构内并不是一件简单的事情，没有领导的大力支持很难完成。这位仁兄恼火于没有得到有力的支持，但是又因为得到A+的考核结果而无法发作。事实上，在领导眼里，无论是技术上还是责任意识上他都当得起这个考核结果，但是对于这位仁兄自己的信条来说却是事情没有做成就得了一个卓越的考核：是不是领导在暗示我就此收手呢？不然的话，在以结果为导向的公司中，他为什么在我没有做成事情之前给了我卓越呢？


很显然，这也是上下级价值有观偏差的一种表现，领导的保守和员工的进取不对称。上面这个例子是比较乐观的情况，结果只是给员工留下心结，最坏的结果是将来他做事情可能变得畏畏缩缩。还有不乐观的情况存在，对于员工的新想法或者不同的价值取向，有些领导会持打压的态度，根本上不愿因这些“不必要的”、“额外的”工作来影响整个部门或者公司的稳定运作或者带来人力浪费。这种粗暴的手法自然是毫无可取之处，哪怕员工的价值观扭曲、错误，也应该采取疏导的方式来进行平衡调节，须知“防民之口甚于防川”，对不同的价值观进行打压只能让对方更加确信他自己是对的，觉得是自己影响到了你的利益。因此可能会产生畸形的上下级关系，造成团队凝聚力不够等问题。


除此之外，员工对薪水、职位和工作内容等方面需求上也是有差别的。在一个能够为员工提供长期发展规划和空间的公司，很多人对当前从事工作的满意程度是综合衡量的。例如月薪可能偏低一些，但是工作机遇很好，辛苦但不会白累，或者轻松仍然能够学到有价值的知识……至少我本人2、3年前在知道自己薪水低于同等资历和技术水平的其他同事时，心里的抱怨是远远没有现在这么大的，因为当时我觉得自己做的工作很有价值，很大程度上就忽略了这个问题。但是如果工作本身时常遭人指手画脚，或者付出努力得不到应有的效果，亦或者因为受制于关联部门或者关联分组的工作效率，让自己所司的工作受到很大影响，就会让人对工作周遭环境或者工作本身心生厌倦乃至厌恶。我经常听到有人抱怨：“就是XXX部门和XXX部门拖慢了我们整个公司的办事效率！”其实，在固定的流程规约下，这种看似不痛不痒的问题，正是让大家工作得很累的根源。虽然我们不是经常加班，但是还是感觉很累、很不开心：莫非我们这种“急性子”不适合这个公司么？这或许也是一部分同事不愿意为这个公司的事业发展继续努力的原因。而职位，其实有很多人是对之有所诉求的，无论是为了获取才能的施展空间还是面子，获取一定的权力都是一种很常见的需求。所以，希望领导们能够对员工选择坚持工作下去还是离开的决定深入了解，分析每个人所界定的“综合因素”都包含什么内容，不去解决每“一个人”的事情，就会造成一个个批次的流失问题。


公司的结构——设立技术主管吧


      我们公司的结构是CEO——总经理、总经理助理、总监——十数个部门经理——上百个分组经理——一千多个组员，简单的扁平树状结构，无论是数据库专家、架构专家还是测试专家，他们大部分都在组员这个系列当中。而在日常工作中稍微重要一些的问题的分析、决策过程中，参与者往往只有分组经理和部分经理，有的可能会升级到总经理和CEO层。而事实上在我们公司中，很大一部分的分组经理常年从事项目管理和行政管理工作，很多人不从事具体的开发或者测试工作，对于技术——尤其是新的技术都比较生疏。这样就会有一种很常见的情况：分组经理或者部门经理替大家做了技术方向上的决定，甚至一些细节都要被他们事先定义清楚。


纯粹的管理活动其实本来也并不需要十分精通技术，即便是IT的项目经理也不见得非要十分懂得编码技术或者测试技术才行。但是抛开技术出身并且经常从事技术研究的经理们来说，纯粹的管理者其实不应该替大家做技术决定的，因为细节可能并不是他们所了解的，往往决定做了之后要花费很大一番功夫去“拨乱反正”或者解释。对于这种情况我建议在每个分组设立技术主管这个角色，为我们这种8到15人的团队配备这么一个可以直接与管理者平等对话，与所有员工一起参与实际工作细节谋划实施的人。这么一个角色不见得能够分担多少实际工作，但是在一个组内却可以起到技术支持、指导的作用，并且对每个组员的工作技能和效率的提高、对大家工作有效性的保证都能起到很好的作用。就像有些公司的测试部门所设立的所谓“测试架构师”一样，测试组的技术主管们的作用就是在分析较为复杂、关联影响较多、涉及架构上的变动的需求上，在系统的自动化测试和性能测试技术上，在测试所涉及到的编码、数据库、中间件、操作系统等相关技术上，都能给组员提供相当多有指导意义的意见，为测试本身的质量提高起到很大的作用。同样的，这个职位的设立在非测试的其他部门应该也会有一定作用。


对于这种树状结构的IT服务公司来说，把技术支持的工作集中到一个专门的技术支持组中是十分不利技术的发展和推广的。我曾经偏执的认为，我们测试部门必须有这么一个技术支持组，来处理大家的技术问题，但后来的经历才让我明白自己错了。因为一旦行政所辖不在一个分组之内甚至不在一个部门之内，那么凡事都要走相关的流程和申请才能获得支持，这导致我们获得支持的时效性根本得不到保证，严重影响我们的工作进度和心情。而且像我们这样的部门分部在几个城市，而测试技术支持人员却不是每个地方都有，这也让我们平时的沟通效率也很低，对此，我们很多同事还是有一定抱怨情绪的。另外，这样一群人聚集在一起很容易脱离实际的工作，与每个不同分组的工作内容和需求脱节；容易产生技术团体的清高的毛病，与其他分组沟通时可能会时常发生矛盾。


如果把这些技术人员分散到每个分组中去就不会有这样的问题，同时，与实际工作和一起工作的同事朝夕相处不会让技术专家和一般的组员产生距离感，能够营造很好的技术探讨和共同进步的良好氛围。把这么个岗位角色设立起来也能够说明公司对技术工作的认可，而不至于让大家都普遍认为“技术嘛，能做几年，有机会还是转管理吧”。而正是由于这种“技术不长久”的思想，导致了我们现有的技术水平和国外差距较大，但从自动化测试这一个方面就可以看出我们落后了好几年。在国外，一个编码或者测试的资深工程师或者专家能够潜心技术十几年甚至几十年，但是在国内就非常少见，这就是我们自上而下的观念都更加偏向与看重管理技术导致的。所以，只要公司认可技术人员，提升技术人员的收入和地位，那么技术人员就会更加专心的为公司的发展提供更好的技术服务。


后记：细说起来，讨论我们工作得爽或不爽，需要考虑的可能还不止这么几个方面，比如还有激励、福利等等，但是这些并没有让我觉得有何不舒服，所以也就不再妄加揣测了。我想我看到的只是一个典型，大家或多多少都会遇到一些类似的情况，只是大家如何想我就不知道了。最近公司设立了很多新的表彰和鼓励的制度，是拿来主义也好、拾人牙慧也罢，只希望能够落到实处，再等等看吧。