IT外企那点儿事(7)：做一个优秀的基层

IT外企那点儿事(7)：做一个优秀的基层

千里之行，始于足下，无论你有多么的豪情万丈，总要从最基础的东西做起。

然而要做一个好的基层工作人员，并不是低头认认真真写好代码就可以的，其中可大有学问。

按照余世维所论，一个好的下属应该：

主动向上司汇报你的工作进度——让上司知道！  
对上司的询问，有问必答，而且清楚——让上司放心！  
充实自己，努力学习，才能了解上司的言语——让上司轻松！  
接受批评，不犯两次过错——让上司省事！  
不忙的时候，主动帮助他人——让上司有效!  
毫无怨言的接受任务——让上司圆满!  
对自己的业务，主动提出改善计划——让上司进步！  
我也总结了如下几点，欢迎大家补充。

(1) 做得快还是做得好？  

当前的项目管理中，多是强调结果的，号称结果导向或者结果驱动。

作为一个基层，做人重要，做事更重要，除了良好的沟通能力，能拿得出真金白银的成果，更是每个项目经理愿意看到的事情。

然而怎么叫好的结果呢？

一九五八年党的八大二次会议上，提出多快好省的建设社会主义。多快好省四个字即体现了前辈革命家的理想壮志，也成为后来中国管理者心中的梦。所以我们时常听到如下的话："这些功能下个月一定要出来"，"代码质量要高，要有详细的注释，测试用例，code review"，"最好提前一周至少三天，可以准备demo"，"项目现在经费相对比较紧张，希望大家克服一下"。

然而现代的项目管理给我们画出了如下的三角形：

范围，预算，时间三者相互制约，牵一发而动全身。欲范围大(多)，就应该增加项目预算(不省)，如增加人手，增加资源，买第三方成品，或者应该延长时间(不快)，如推迟release的时间等。欲按期完成(快)，则可以增加预算(不省)，或者减少功能(不多)。

然而现实中，老板可不这样想，预算是早就做好了的，时间也是确定了的，功能缺一不可，作为基层的程序员我们唯一可以影响的就是用加班换来更多的时间，当然还有中间的一个圆圈——项目的质量。

到底是尽快的做出一个实现基本功能但设计稍有缺陷，测试不太完备，有少量的Bug的版本出来然后慢慢改进呢，还是经过慢慢的精心设计，做出有完备的测试用例，经过严格测试少有Bug的版本呢？

这个问题如果你问程序员，大部分人会选择后者。尤其对于初涉职场，充满激情的程序员们，往往满脑设计模式，满口软件工程，几乎见不得注释中的错别字和没有覆盖到的测试边界，似乎一个不完美的方案就有辱于软件工程师的名号了，我们称之"技术洁癖"。

如果你问项目经理，也会告诉你后者，而且最好以后者的形式用前者的时间(多少有些多快好省的味道)。然而很少有项目经理会直接看你的代码，更不关心你用的何种设计模式，也不会一个个看你的测试用例来思考是否覆盖所有的边界，更不会看你写的注释了。

所以很不幸，除了少数精通技术，熟悉细节，了解程序员苦衷的项目经理外(这可是大多数程序员都翘首以待的领导啊)，大部分喜欢前者。

因为精心的设计，良好的文档是需要大量的时间，完备的测试用例的代码量几倍于实现本身，功能测试，性能测试以及Bug的修改更是难以估计时间的，所以总的时间将几倍于前者的时间，在此过程中，你献给项目经理的，除了等待，还是等待。

人是不喜欢等待的，尤其是很少反馈的等待，当我们用windows的时候，往往会出现估计时间相当不准确的进度条，然而我们还是喜欢看着进度条一直走到底，同样项目经理也是。

总是能够很快的做出项目经理能够看到的版本，便容易给人一种能力很强的感觉，至少大部分人会这样认为。

也许你会说：我做的版本Bug很少，后期维护成本低，QA一测不就能够看出孰优孰劣来了吗？

仍然很不幸，在大多数人看来，你一个月做了一个稳定的版本被认为是做了一件事情，而别人两个星期做了一个不稳定的版本，后两个星期改了三个Bug是做了四件事情，而且其每次的会议总有进度可以说，成绩斐然。

而且一个人身上所挂着的Bug的个数，实在不是一件值得羞愧的事情，反而是一件令人感到荣耀的事情，这说明了你重担在身，举足轻重。

如果你做了一个模块，用了一个月，后来半年都不曾出过Bug，而另一个人做一个模块两个星期，出过多个Bug，并且后来兼任其他模块的时候还在改Bug，还是很不幸，你会被认为所做的模块相对简单，不容易出Bug，并随着项目的进行而被淡忘，会被这样提及："他在半年前做过一个项目"，而另一个人却会被认为所做的很复杂，有很多疑难杂症，而且后来会被认为身兼数职，会这样被提及："随着能力的提升，同时维护并负责多个模块，有并行工作的能力，有很强的解决问题的能力"。

也许你觉得我说的太极端，那就举一个历史上的例子吧，有兴趣大家可以看李亚平的《前清秘史——入主中原之路》，其中是这样描写当时并称“南戚北李”的两位将军的：

李成梁屡立大功，受封为伯爵，跻身于帝国贵族行列。在当时，他的地位、名望等，很有可能已在戚继光之上。有一种看法，包括《明史》的作者们认为，恰恰因为戚继光威名太盛，坐镇蓟门十六年，使敌人从来不敢来犯(没有Bug啊)，于是转道入侵辽东，才给了李成梁屡立战功的机会。张居正死后，新政被废，受到张居正支持重用的戚继光被迅速边缘化，在郁郁寡欢中死去(可能明朝认为蓟门这个模块不需要再维护了)。而李成梁，他同样受到过张居正的支持和倚重，然而，可能由于下面的三个原因：其一，远离京师，与张居正没有过多的私人交往；其二，赫赫战功给万历皇帝留下了深刻印象(每次总有进度可说)；其三，动荡不安的辽东局势离不开这位骁将(辽东模块还需要维护啊)。从而，李成梁避免了池鱼之灾。

当前社会中，不是如此吗？是修了坚固的河堤的市长感动中国，还是和民众一起抗洪抢险的市长感动中国呢？是治理的地方路不拾遗的公安局长应该升职，还是让黑社会猖狂十年然后一举击溃的公安局长会升职呢？

如果你觉得你的项目经理英明过于历史甚至当朝首辅，那么恭喜你。

(2) 有问题要尽早喊

当一个模块或者一个任务交给你的时候，可能存在各种各样的困难，会出现各种各样的问题，需要各种各样的资源，这一切都应该慎重考虑后尽早提出。

问题的尽早提出，其实是风险控制的一种手段。

调配资源，排除干扰，风险控制是一个项目经理的重要责任之一，然而不要认为项目经理会英明神武到知道一切细节，也不要认为这是项目经理的事情，与你无关。其实一个模块，真正了解细节的是你。

所以对团队来讲，事先问题没有提出，到时候出现是你的甚至你的团队的责任，问题及早提出了，项目经理向相关人员请求资源，到时候没有解决就不是你的责任，甚至也不是你们团队的责任了。这个样子既帮助你的项目经理控制风险，又能够在外国人面前撇清责任，是每一个项目经理都欢迎的事情。

对你个人来讲，问题及早提出了，以后或有Bug，或有delay，都不会给人一种突然的感觉，也给项目经理一种对你，也对整个项目可控的感觉。

从心理学上来讲，人们多惯于先听坏消息，再听好消息，而不愿意先听好消息，再听坏消息，这就是我们常说的冷热水效应：一杯温水，保持温度不变，另有一杯冷水，一杯热水。当先将手放在冷水中，再放到温水中，会感到温水热；当先将手放在热水中，再放到温水中，会感到温水凉。

一个经常举得例子是：某汽车销售公司的老李，每月都能卖出30辆以上汽车，深得公司经理的赏识。由于种种原因，老李预计到这个月只能卖出10辆车。深懂人性奥妙的老李对经理说：“由于银根紧缩，市场萧条，我估计这个月顶多卖出5辆车。”经理点了点头，对他的看法表示赞成。没想到一个月过后，老李竟然卖了12辆汽车，公司经理对他大大夸奖一番。假若老李说本月可以卖15辆或者事先对此不说，结果只卖了12辆，公司经理会怎么认为呢？他会强烈地感受到老李失败了，不但不会夸奖，反而可能指责。在这个事例中，老李把最糟糕情况――顶多卖5辆车，报告给经理，使得经理心中的“秤砣”变小，因此当月绩出来以后，对老李的评价不但不会降低，反而提高了。

(3) 用Bug来说不

不知从何时开始《致加西亚的信》以及《没有任何借口》此类的书开始畅销，从而以执行力的名义把责任全部推到被领导的一方，用军队的方式来要求自己的员工，不讲条件，没有借口，从不说不，来完成领导所给的任务。真不知道资本家有什么资格这样要求自己的员工，作为军人为祖国献身后至少能够成为烈士，家人受到抚慰，而资本家在员工连跳九人的情况下却在论证这个数字其实低于全国平均自杀率的。

然而大多数的领导的的确确喜欢没有借口的下属，也不喜欢听到说不。所以当一个任务下达的时候，或者一种方案被指定的时候，不要直接说不。

领导毕竟是领导，能做到现在的位置，毕竟有强于你的地方；领导毕竟也是人，提出的方案也可能是拍脑袋拍出来的，也许会有不合理性。

然而需要记住的一点是：上情下达可以拍脑袋，下情上达则要用证据。

当你认为领导给的任务或者方案有问题的时候，除了上面提到的喊难在前之外，一定要加一句，"我试试看"。

当你经过实验测试，有数据或者日志足以证明你的结论的时候，可以尝试说，"我觉得可能有些问题"。

然而有时候简单的测试并不能够证明的时候，或者领导再次坚持的时候，那就上手做吧，只是别忘了做的有扩展性一些，能在多种方案之间较容易的切换，并将领导坚持的方案暴露出来。当测试人员发现问题的时候，将比你说不有效果的多。这时候领导关心的便是如何Bug进行修复，不在纠结到底应该采用你的方案还是他的方案了，当然此时你千万不要得意洋洋的指出领导原来方案的不合理性，你不指出，领导其实是从心里认可了你的方案的，并且为你记了一功，如果你指出来，就适得其反了，大部分领导绝不会表面承认自己的错误的，可能会再次坚持自己的方案的合理性，并把因此带来的项目失败或者delay记在你的头上。也许大家清晰的记得曹操不承认"鸡肋"的退兵禁令而杀杨修的故事吧。如果你觉得你的领导气度大于曹操，那么再次恭喜你。

也许你会说：这不是浪费了一个过程吗？其实不然，你先做了领导的方案，然后改Bug的时候应用了自己的方案，在领导眼中，你是一个好的下属，好的执行者，你是做了两件事情的。

如果你坚持做了自己的方案而没有优先用领导的方案，则会有以下风险：

你永远失去了证明你的方案优于领导的方案的机会  
你会被认为固执，难于沟通，执行力差  
一旦你的方案出现问题，你将单独的承担责任，甚至整个项目delay的责任。如果你优先采用了领导的方案出现问题的时候，一般合格的领导会勇于承担起责任，替你说好话："我们采取的方案是相对较优的，也是经过测试的，Bug是难免的"，相反，如果你固执己见，则没有人会替你说话，反而会说："要是用原来的方案就不会出现这个问题" 。  
领导的方案一般是由一定原理上合理性的，你的方案可能是比较符合你的实际需要，然而当时过境迁，context不在的时候，你百口难辨。  

所以，毫无怨言的接受任务——让上司圆满，如果有问题，让Bug来说。  

(4) 该干什么的时候干什么

在外企，一个常说的词叫"professional"，何为职业化，一个通俗的说法就是，该干什么的时候就干什么，当然无论干什么，永远不要忘记，你是一个程序员，一个基层的程序员。

前面说过，除了写程序，外企的生活是丰富多彩的，健身，按摩，小食品，饮料，旅游，年会，各种协会等等不一而足，而且外企的氛围是相对宽松的，你可以在任何时间尽情享用，没有人会有意见，当然是在你完成了工作的基础之上的。

然而永远需要记住的是，写程序才是你的天职，而多彩的生活是公司对员工的福利，是一种施舍，说的不好听一点，公司花钱请你来是写软件的，不是让你来娱乐的，公司让你娱乐是给你脸，你总不能给脸不要脸吧。话说的难听一点，但细想想，话糙理不糙，试想如果项目经理每次来巡查的时候都看到你或大声的说笑，或尽情的饮食，或玩桌上足球的时候，其内心不会有上面的想法？只不过是一种优雅的方式表达出来罢了。比如走到你的面前，微笑着问："你的feature做的如何了？"，"Bug XXX有没有结果？"，顺便强调一下你所做的模块的难度和重要性："你做的这部分比较有难度，是对你能力的挑战"，并在最后来一句："慢慢做，不着急"。你可知晓此彬彬有礼下面的深意？经理两次到你这里来说"不着急"的间隔越短，其实是说明这件事情越着急的。

所以说在办公室的大部分时间，你都应该低头写程序，谈话也要讨论技术问题，娱乐要适度，除非你想被人觉得工作量太少，不努力，或者你有足够的信心自己负责的模块不会出问题。

另外在开会的时候，你由于任务太多，总是盯着自己的笔记本默默写自己的代码吗？不要这样，这样会让组织会议的人感到不被尊重，会让领导觉得你对项目组不够关心，不够投入，甚至不够忠诚。开会的时候，就要像开会的样子。你可以提前阅读材料来准备几个问题；你可以支持，补充或建议组织者的方案；你可以在外国人面前举出证据来维护中国团队的利益；实在没招，你至少可以记会议记录，会后发meeting minutes。这样你给人的印象永远是你是有想法的，你是有贡献的，你是关心项目的，你是热爱团队的。

一个Team出去吃饭，或者出去旅游的时候，你是得意忘形的放开手脚去玩吗？甚至脱离团队和要好的朋友去逛吗？不要这个样子。余世维在《经理人常犯的11个错误》的演讲中曾经说过，出去Team building，对于员工来说是休息，而对于经理来说是工作。的确，你要清楚资本家为什么会出钱让员工去做这些和工作看起来无关的事情？为什么要大家一起出去而不是每人发钱自己去玩？当然是要增加团队的凝聚力和归属感，为共同合作奠定基础。既然对于经理来讲是工作，难道你不应该有责任辅助你的经理做好工作吗？在大家一起吃饭的时候，如果冷场，积极的起一个话题吧；在经理提出玩一个团队游戏的时候，率先支持，主动去做吧；在外出旅游的时候，帮助你的经理订餐馆，清点人数，摄影照相吧；当爬到山峰，或者年会表演节目的时候，喊出增加团队凝聚力和影响力的口号吧；在活动结束后，整理资料，相片，发出email来进一步增加活动的效果吧。这样你就是有组织能力的，辅助经理成功的，有良好影响力的，也是热爱团队的。

这里提到了团队聚餐中的话题问题，这里顺便提一下，当然根据不同的Team的氛围以及当时的情况而定，话题的优先级依次如下：

项目话题：如进度，难点，后面还会提到，学会喊累，喊忙，这是一个比较好的机会。当然此话题比较适合加班或者中午时的团队聚餐，不太适合旅游时候的团队聚餐。此话题可表明你对项目的关心。  
技术话题：比如语言排名，那家公司被收购了，平台之间的差异等等。此话题可说明你对技术无限热爱。  
员工生活话题：比如周末干什么了，介绍女朋友，结婚，孩子教育等，当然以当事人意愿为准，不要太当真。此话题可说明你关心同事。  
娱乐话题：比如看什么电影，娱乐圈出来什么事情等，这是万能话题，也是最保险的话题。  
员工敏感话题：比如非议其他Team，或者美国团队等，此类话题最好不要涉及，背后议人不太好。  
公司敏感话题：如有的Team裁员，减薪，福利下降等，此话题千万不要提及，这是领导层想尽力遮盖的问题，甚至不在项目经理的权利范围之内。涉及此类话题将给人以你是一个不可托付大任的人。 
 
最后，如果你在学校中是演艺明星或者体育明星，那么年会的表演以及团队之间的比赛也不是你表现英雄主义的地方，而是体现团队意识的地方，也是交流沟通的好机会。所以不妨在节目中介绍一下自己团队的产品；不妨在角色设定的时候劝说core team的人加入扮演一个牛人角色(欢乐可以一定程度上冲淡马屁味道)；不妨申请印有团队logo的运动衣；不妨在运功过后和高层一同边走边聊(比平时冲到高层办公室里面好的多的机会)；不妨去敬HR一杯酒，被她们多灌几杯(HR的办公室是个敏感区，平时很难交流感情啊)；不妨去维护机房的团队那里敬酒以感谢他们的工作，去前台那里敬酒以夸赞她们的服装，发型等(他们对你来说真的很重要，想想几百人的团队，前台和运维都只有两三个人，还是那就话，当供需相差很大的时候，价格都会越来越高)。这将使你成为一个受欢迎的人。