IT外企那点儿事(17): 左右逢源，还是左右为难？

作为一个管理者，上有高层，下有基层，内有同事，外有客户，想游刃有余与各方之间，实在是一件不容易的事情。

各方各面都是需要处理好关系的：高层自不用说，你的绩效完全掌握在他的手里，关系着你将来的前途和钱途，当然不敢说不。基层也不能得罪啊，你的工作的完成全靠他们了，如果他们积极性不高，做事拖拖拉拉，事情完不成或者出现很多问题怎么向上面交代啊；手下的人，水平不高的干不好，水平高的不太听话，招人的时候，有的人问了半天一问三不知，有的人你看上人家人家不屑来；现在基层想法越来越多，就算对整个公司机制有所不满，也会算在你的身上，而且高层门开着，邮件随便发，来个越级反映问题就会被质疑领导能力。同事也不能得罪啊，对于其他的团队管理者，可能你需要别人的技术支持，可能你需要调用别人的接口，可能你的程序运行在人家开发的平台上，可能你们需要相互评价，有点私心的话，也可能推荐些自己的好友到别人的团队来赚一点推荐费；IT, HR, Admin，甚至前台MM都不能得罪啊，虽然他们不是公司和核心部门，然而他们却是公司的唯一部门，根据供需关系，供方只有一个，需求方有这么多研发部门呢，他们的重要性一下子就上去了，比如，新来的员工快点领到机器，需要在服务器上部署东西或者查看log，申请增加些内存硬盘，帮你尽快招人，有合适的人优先推荐给你们团队，你们看上的人不会因为性格测试，背景调查，企业文化等方面的问题挂掉，无论是旅游，运动会，年会都能安排一个比较不错的位置，甚至可以得到一些小道消息，等等等等；客户更是上帝啊，不管是真正的外部客户，还是美国那面的项目发起者，或者是产品经理，时间紧，任务重，资源少，还改来改去的。

然而，无论是高层，还是基层，都是对你有压力的。高层想：你是我提拔起来的，当然应该替我着想啊，没有我哪有你的今天；给你这么重要的项目，上面眼巴巴的望着呢，还不赶紧弄出的名堂来，不压一压你的团队怎么出业绩啊，不出业绩怎么向上面交代，你接下来怎么再提高一步啊；再说这个项目我看也没有那么难么(高层总是不能体会基层很多耗费时间的具体问题)，就算有些难度，养兵千日用兵一时，又不是你自己去做，多给你手下的人锻炼的机会嘛；刚给你的团队点压力你就叫苦连天的，你是想立山头，护犊子？这点压力都承受不了，是不是领导能力问题啊。基层想：活每天都是我们干的，你天天和我们在一起，我们有哪些苦哪些类你应该清楚，你不替我们说话谁替我们说话啊，在上面，你就是我们的代言人啊；我们有问题有想法你不敢向上反映，有活有项目揽的到快，你是表现的积极主动了，全不管我们死活，害我们天天加班；在我们面前牛掰的不得了，不知道在上面的面前多怂呢。

作为一个中层管理者，真可谓左右为难。

根据经典理论，作为管理者角色认知，在下属面前，你代表的是公司，传播和维护公司的政策制度，监督和激励员工完成组织目标。在上司面前，你代表的是团队，代表团队发表言论和建议，代表团队申请资源和利益。然而在现实生活中，经典理论似乎不怎么好使。当你在下属面前代表公司的时候，下属并不认帐，心想：都是打工的，何苦装的跟主人翁似的，好像公司是你的一样，跟你有一毛钱关系木有。当你在上司面前代表团队的时候，上司同样不买账，心想：把你提拔起来是为我办事的，替我分忧的，弄得你的团队是你们家的一样，多让你们干点活还有意见，又不是你干，让你的手下干嘛。

所以，当我们注意观察身边的管理者的时候，基本是以下这么几种类型：主管级别的，由于刚从普通员工提拔上来，深知员工的痛苦和劳累，平时更多的和员工在一起工作，甚至还会担任工作中的核心部分，因而更多的倾向于代表员工的利益。总监及以上的管理者，大多数有公司较多的股份，由于其离开编程岗位已经多年，因而更多代表公司的利益。而中间的经理级别，根据自己的经历，公司的文化，自身的性格不同而偏向上述两种类型的一方。如果经理所管理的项目同自己原来经历过的项目十分相似，则就会表现的更加强势，更站在公司的角度想问题，经理可能会想：少跟我所什么技术难，多复杂，时间不够，这些东西都是我原来从基层一点一点做过来的，你们那些花花肠子当我不知道？如果经理所管理的项目是其不太熟悉的领域，则他会更加依赖自己的团队进行架构，技术攻关，则会更多的表现出亲民的一面，从而更站在团队的立场想问题。如果公司的文化更强调等级，等级表现在工作中的各个方面，比如同等级一起午餐，同等级旅游的时候一起住宿，甚至按照等级选择办公室里面的座位。这些标志性的差别和待遇明确的告诉升职后的经理们，你们混出来了，多年的媳妇熬成婆，你可以从此不用站在媳妇的立场想问题了，可以站在婆婆的角度了。当然，不同的婆婆性格也是不一样的，在经历了做媳妇的千辛万苦后，有的婆婆会想：当时我做媳妇的时候，婆婆的管理方法有一些问题，现在我要避免这些问题，争取让我的媳妇不要再受这个苦；有的婆婆则会想：哪个媳妇不是这样熬过来的，那些苦我都受了，现在轮到你们了，你们也得给我受着才能成长。

那立场应该如何站，才能左右逢源呢？所使用的方法和经典理论正好相反，即我们在上司面前，应该站在上司的立场上，而在下属面前则应该表现为团队的代表，而管理者，则作为中间的渠道，转接以及缓冲。

如果领导将你找来，说：“你看咱们能不能添加这么一个功能，上次给客户(或者美国老板)demo的时候，他们还特意提到了，觉得这个很重要，希望下个月再demo的时候，能够看到。”在明确了需求了以后，你粗粗估计了一下，这个功能看似简单，但有很多的细节，真正实现出来，起码要两个多月的时间。但是这个时候，不要说：“这不太可能，很难，时间太短了。”因为你应该知道，你的领导也是面临者很多的来自客户和美国大老板的压力的，他真的非常希望他的手下能够在关键时刻替他分忧，所以在领导面前，不要总是说不，这容易让他对你和你的团队丧失信心，不要以为说这是保护你的团队，但是最终还是伤害你的团队(最后你会发现你们团队的表现机会，team building的机会，加薪的额度，升职的机会都相对较少)。而且，你的领导虽然不太清楚具体的细节，但是在找你谈话之前还是进行了一定的考虑的，如果你当场就驳回，就等于无形之中对你说：作为老板，你不体恤下情，办事拍脑袋，考虑不周全。这样你的老板多没有面子啊。当然，你也不可能一口答应，这样你的团队加班加点也做不完，就算做完了，也很辛苦，而且你的领导却因为你的态度认为是理所当然的，这样你的团队必将满腹牢骚，对你和公司丧失信心，离职率上升。所以这个时候，你应该说：“不错，这个功能要说实现出来，的确是咱们产品又一大亮点啊，如果需求我理解的没有问题的话，那我这就回去计划一下，三天内给您个回复。”

当你回到团队的时候，如果你立刻宣布要一个月实现这么一个模块，团队一定炸锅了。所以你要把架构师和主要功能模块的负责人找来，说：“前一阵兄弟们辛苦了，今天老大把我叫过去，说咱们上次demo的很成功，本周五看有空咱们吃个饭。今天老大说，接下来，美国佬那面让咱们实现这么一个功能，……，你们先想想，今天晚些时候咱们开个会，讨论一下这个东西怎么弄，不过老美那面要的还有些急，你们看怎么弄大概一个多月，最多两个月能搞定。”在团队面前，你尽可以称上面的人为老美，那帮大佬等等，当然这不是对美国那面的不尊重，就像新东方的老师经常在一起拿俞敏洪开涮，称为老俞，这样会给团队一个印象，就是你是和他们在一起的，大洋彼岸哪些没有见过的面孔是任务的提出者，你和他们一起来分担这个任务，而非你是美国那面的代言人。然后对于任务时间，当然不能一步到位，一压到底，这样不但给他们了心里准备，就是时间紧，这样他们在设计的时候，会考虑比较直接的方案，而且这个时间虽然稍紧，但是是reasonable的，也表示你是为他们的工作量考虑过的，不是传话筒，或者拍脑袋做事情。

在接下来的初步方案讨论会上，一般会形成两种类型的方案，一种是完美型的，无论设计模式，接口封装，模块划分都是中规中矩，这样扩展性较好，以后比较好维护，但是耗费时间较长，一种是直接型，即有很多by pass的方法，能够尽快完成，但是需要后期进行一定的重构。这两种类型各选择一个最优方案，然后请架构师和模块负责人预估时间，越详细越好，尽量每个任务都以小时为单位。这样最终完美型的方案时间会在两个多月，而直接型的方案时间会在两个月不到。

然后你可以拿着这两个方案再来和你的老板谈，说：“我们开过初步的方案讨论会，这是我们的两套方案，并且都预估了时间，您看一下，由于这次的时间要求比较紧，所以我觉得第二套方案比较适合，您看呢？”由于你的架构师们预估的时间比较详细，而且他们是到时候真正上手做事情的人，所以从他们那里说出来的时间紧，相对于你这个不具体做事情的人说的话，往往是比较容易接受的。“我知道这个时间还是有些长了。然后，不知道美国那面是不是下个月想看到的是这个功能的主要部分，我想一些边角功能是不是可以不用在下次demo前完成，还有如果这个部分能够先按照XX模块一样的话，最后效果差不多，但是代码可以重用，时间会大大降低，从这个预估时间表来看，可以在一个半月完成。”“为了能够在下个月高质量完成demo，希望能够借调一些外包人员，这样大家一起辛苦一下，能够在下个月弄完。”“如果模块不能减少，希望能够将下个月的没周六调休到下下月，这样可以多出差不多一周的时间”在具体的时间预估表下，这样你的领导会认为你在千方百计的替他想办法在下个月弄完，你的团队也是愿意艰苦奋斗承担责任的，而非推脱任务。当领导得知最后一个月能够完成，心满意足的时候，别忘了可以给团队争取点什么。“鉴于上次demo还可以，我们准备周五晚上聚餐，然后再去K歌，大家high一把，您要不要参加一下。”这次小型的team building既是对上一阶段工作的慰劳，也可以引起大家对下次的期待，请领导参加，既是一种礼貌，当然如果幸运的话，一般都是职位最高的人买单，这样就不用花你们team的经费了。“如果咱们下个月实行周六调休，那么在下下个月就有四天，连上周六周日就有六天，我想在下次demo如果成功，拿出其中的三天组织一个郊游，如果经费不足希望借用下个季度的一点budget”。当然，让大家卖命干活，还是需要有些甜头在前面的，在给员工承诺之前，向上面请示一下是必要的，否则如果不兑现，则会损失你的信用度，下次再激励就不好用了。当然这个请示也是有技巧的，所谓借用下个季度的budget，其实如果demo的成功的话，可能根本不需要，说不定领导还会补贴，但是没有办法，这是成功之前和领导说，你没有资格谈条件，只能从自己身上想办法。这就是所谓的风险和收益原理，如果想获得他人尤其是领导的支持，你所需要做的，就是风险由你来承担，收益大家共享。比如很多人说，我有个很好的idea，来改进产品，结果领导就是不采用，保守的使用老办法，其实这个时候最好的方法是，你利用业余的时间，做一个你这个idea的prototyping，然后demo给你的领导看，如果真好，他一定会接受的。因为如果你空口白牙的说，那么风险是由你的领导承担的，毕竟他要对整个团队的产品负责，而收益则是你和你领导分享的，而如果你业余时间做出demo来，则风险由你来承担，如果失败则牺牲的就是你的时间，如果成功了收益则是你和你的领导共享，这样谁不愿意呢？这里也是这样的，如果最后demo不成功，承担风险的是你的budget，下个季度少花点呗，如果成功了，领导自然高兴，到时候再谈旅游经费就相对容易了。当然，如果没有申请下来，可以根据团队本身剩余的经费，甚至自己出一些钱，吃个饭，玩个保龄球，桌球，看场电影什么的，也是需要的，当上面又要马儿跑，又要马儿不吃草的时候，作为中间的buffer的你，需要做一下小小牺牲，就像一个弹簧，当两面压力小，你就可以相对轻松自在，当两面压力大，你就应该压缩一下，毕竟不是一锤子买卖，以后你不但需要领导的支持，也是需要兄弟们帮你干活的啊。

和领导谈完，就可以召集你的团队开会了，你可以这样说：上次咱们说的那个新功能的方案，领导还是很满意的，本来说是两个月完成的，结果美国那面非得要一个月弄完。不带这样玩的，那功能，人手，时间总有让步的吧，要不这活儿没法干。后来经过商量，准备把这几个次要的部分先砍掉，大家减少些压力，然后下个星期回来一些外包人员，你们挑几个能干的兄弟带一下，干活的时候注意code review，别他们走了，代码还要重来。另外下个月可能需要辛苦一下大家，加几天班，不过没有关系，我已经申请了调休，这个周五咱们吃个饭，K个歌，大家high一下，下个星期准备进入战斗状态，只要咱们最后demo完，下下个月我给咱们头儿说了，批准咱们在调休的中拿出三天来，大家旅个游，带上家人，好好玩一把。

对于员工来讲，这个消息听起来不是全都是bad news，毕竟你还是砍掉了模块和增加了人手的，说明你是为他们想过争取过的，虽然下个月非常辛苦，周六还要上班，但是好在是调休，也不算牺牲什么，还能完成后公费玩一把，也算有个期待了。

注：本文转至 http://www.cnblogs.com/forfuture1978/p/3329389.html