团队啊团队，Team work(团队精神)成为当前大大小小的企业共同的价值观。

然而这个企业文化是模糊的，却经常被当做政治大帽子高高举起，占据道德至高点，如果有人胆敢公开对抗，就会被冠以缺少团队精神，缺少沟通能力，不符合公司文化等，从而带来严重的后果，以至影响绩效，加薪，甚至升职。

这里列举几个常见的大帽子。

我们是一个团队，大家一起做

在工作中，你是否遇到过类似的情形：如果你一个任务，你发邮件给你团队中多个人一起做，而没有做具体的分工，则这件事情往往会拖拖拉拉，而很可能大部分事情是被一个人完成的，而且质量往往不佳。当产品来一个新的需求，可以在A模块实现，也可以在B模块实现，如果你长期不分配任务，而是将各模块负责人都找来，大家一起商量着做，大家多半会喊忙，推托，最终也很可能是最老实的人来做。

你是否听过管理者说：“咱们是一个团队，什么不该你做该他做的，大家一起来做，最终的成绩是大家的，做不好也是大家吃亏。”管理者也大多期望，当一个新的任务到来的时候，每个员工都能自发的敏锐的发现其中自己应该负责的那一部分，并踊跃承担，并互相驱动，最后水到渠成，任务顺利完成。

然而现实却有很多的问题：一个任务，可能多种方式来做，到底哪种方式更好呢？模块负责人会根据对于最终架构的好坏来选择方案，还是暗藏私心，根据对自己模块带来的工作量来选择方案？一个任务，总有简单的部分，复杂的部分，简单貌似复杂的部分，复杂貌似简单的部分，核心模块易出成绩的部分，边边角角费力不讨好的部分，好事谁都想抢，坏事谁都想推，谁来做哪一部分？任务成功了谁受赏，任务失败了谁负责？

这些问题处理不清楚，便如红楼梦第十三回《秦可卿死封龙禁尉王熙凤协理宁国府》中描述的宁国府的情况：事无专执，临期推委，事无大小，苦乐不均。

所谓事无专执，即任务没有具体的负责人。这首先会造成不够努力，在组织行为学中有个词叫社会懈怠，其表示当人们在团队中工作比独自工作时付出更少的努力，尤其是在不容易识别个人结果的大型团队中更易出现。大家一起做，谁知道谁做了多少，无论做多做少，大家一起承担结果，何苦这么卖力呢。其次会造成无人承担责任，反正大家一起做，做砸了又不能怪我一个人，从而心安理得，继续犯错。

所谓临期推委，即遇到事情互相推拖。也即上面讲到的好事都想抢，坏事都想推。吃力不讨好的事情谁也不愿去做，最终造成真正的难点，瓶颈点反而成为最后才解决的问题。

所谓事无大小，即做事情不分轻重缓急。由于员工不知道哪些是应该做的事情，做哪些工作才能使得上司满意，哪些是难点瓶颈点需要尽快解决，从而只好采取先来先做的方式，甚至哪个被相关模块催的急，催的勤，就做的快一些，哪些脾气好的，不乐意催别人的，则总是得不到支持。

所谓苦乐不均，即老实人受欺负，会哭的孩子有奶吃。正是前面三种现象，领导没有做好任务分配，团队内部的平衡，期望员工自发驱动，造成了员工完全靠相互之间的博弈来分配工作。不能不说，有的人老实，有的人狡猾，有的人就一门心思搞技术，有的人口若悬河，善于说服，于是老实人总是因为不好意思，脸皮薄，说不过别人，做最多的工作，干最吃力不讨好的活，反而承担更多的责任。最后劣币驱逐良币，真正踏踏实实干活，埋头做技术的都被挤兑走了，剩下的则是善于博弈的，会搞政治斗争的，让本该潜心开发的技术人员，却不得不时时刻刻留一个心眼互相设防，从而无法全力以赴。

要解决这些问题，首先要任务落实到人，哪怕是几个人一起做，也需要指定一个负责人，并赋予其占用其他配合者劳动时间的权力。其次，要对任务排优先级，一个员工可能同时做多个工作，哪个是最重要的，要指明，这样员工也可做好时间安排，如果另一个模块催的很急，员工可以说：“我正在做一个优先级更高的东西，你的那个我两天后给你。”其三，要在任务分配方面做好平衡，善于争取利益的，不能让他们每次都占便宜，不善于争取利益的，也使得他们的利益不受损。最后，要奖惩分明，虽然团队整体做一个项目，一起成功或者失败，但是还是要有所区分，成功了，也要惩罚其中出现问题者，失败了，也要奖赏其中的好的执行者，使得每位成员的工作得到衡量，来避免社会懈怠问题。

我们是一个团队，大家要和谐一致

怎样才是一个好的团队氛围，很多管理者头脑中都有这样一个类似电视剧中的理想场景：工作外，员工们打成一片，好像兄弟姐妹，互相开玩笑，脸上总是洋溢着阳光的笑容。工作中，员工们个个朝气蓬勃，互相赞赏，讨论时大家彼此支持，最后决策时大家一致同意，最后拍手称快，齐声喊yeah.

诚然大多数管理者喜欢和谐一致，对冲突却是讳莫如深，他们认为冲突是对其领导能力的质疑，连手下的人都压不住，当着你的面就争吵，让上级和其他team看了，多没面子啊。另外还担心冲突会造成团队的不团结，团队成员引起冲突，吵红了脸，以后再一起合作就不那么方便了。再一点就是冲突如果不及时制止，有的人善于争吵，有的人则内向腼腆，则冲突失败的一方也可能是十分优秀的员工，这样会导致其士气受到影响，进而影响工作效率甚至离职。最后一点，冲突表示当前的方案还不足够完善，如果大家不能够达成一致，则执行的过程中必然不能众志成城，反对的成员必然不能全力以赴。

所以管理者喜欢维护和谐的氛围和表面的融洽，在冲突刚刚开始萌芽的时候就及时制止，在决策的时候，总是尽量找到可以顾及方方面面的方案，形成谁也不得罪的权宜之计。

然而现实中，表面的和谐和融洽下面并不是看上去那个样子，余世维先生在成功经理人讲座中说过这样的话：世界各强国开会的时候，一样的吵，一样的闹，但是开完会出去后是一种声音，我很少听到美国人在别人面前批评另外一个美国人，也很少看到德国人在别人面前批评另外一个德国人。而中国人开会都是沉默的，高喊拥护领导，一出去就对别人说，他以为他是谁，放马后炮，扯后腿。所以为了避免伤害感情而避免冲突，则团队成员在不能当面发表不同意见的时候，转而采取背后的人身攻击。

其实冲突也是多种多样的，在《克服团队协作的五种障碍》一书中，有这样一个图：

有的冲突是建设性的积极的冲突，人们围绕着团队的重要问题进行热情的毫无保留的讨论，争取得出对于组织来讲最优的结论。

有的冲突则是破坏性的，带入办公室政治，为了争论而争论，为了赢得争论和背后的目的不择手段。

作为管理者，保持刻意的和谐是不好的，要鼓励一定程度的良性冲突，将被掩盖的问题和不同意见摆到桌面上来，不要求全部同意，而是通过公开的讨论，广泛的倾听各方意见，做出决策，那些即便是不同意的成员，由于其观点被倾听和讨论，明白了事情的来龙去脉，也在实践中更容易支持最终的决策。当然对于冲突也要有一定的掌控，首先要就事论事，而不能人身攻击，比如对于一个方案，你可以说这个方案优点在哪里，但是有可能有哪些问题，而不能说你这个方案简直是个垃圾，你原来做没做过，怎么这个都弄不好，因为再初级的程序员也是有尊严的，再有经验的程序员都是从不会开始到会的。其次要摆事实讲道理，而不要运用辩论技巧，比如这个功能我认为在你的模块中实现比较好，因为从架构方面如何如何，从性能考虑如何如何，从开发速度如何如何，而不能采取类似诱供式的提问，一开始并不把所以的信息公开，而是慢慢诱导，最后莫名其妙的对方掉到你的坑里，任务归了对方，因为这样即便真的应该是对方的任务，被欺骗诱导的滋味都不好受，反而增加了双方的敌对和预防心理。最后，如果团队成员形成积怨，应尽早解决，比如当工作中双方出现了激烈的争吵，即便就事论事，也会让人感受到攻击感，则应该通过工作外的一些活动，把事情说开，因为积怨会越积越深，最后针尖对麦芒的两个人，只要听到对方的名字就会火冒三丈，可是谁也说不清楚当初是为什么。

咱们是一个团队，要民主，要沟通

在著名电视节目秀The Apprentice(学徒，或者有叫飞黄腾达)的第二季的第二个案例中，任务是设计一种口味的冰激凌，并努力销售，赚的更多钱的一组获胜。其中一个组的项目经理Ivana由于在上一个案例中极度反感上一个项目经理的独断专行，而决议采取民主的方式，以期群策群力。于是她将整个团队关在一间会议室里面讨论冰激凌的味道，大家七嘴八舌，写了整整一个白板，一直到三点三刻才做出决定，而冰激凌必须四点之前开始做，整个过程没有分工(另一组有人负责口味，有人负责采购，有人负责销售)，没有控制，以至第二天卖冰激凌的时候，两辆冰激凌车互相找不到对方，最终落败。

这是很多初为管理者经常出现的现象，一方面是长期受压迫的结果，一方面不好意思立刻对原来平级的同事发号施令。可以想象，原来你还和同事吃饭的时候抱怨上级的专制，现在突然角色转换就颐指气使，多少有点子系中山狼，得志便猖狂的感觉。于是会议慢慢的多了起来。如果你仔细回想每天的时间安排，你会发现，有的外企不是很忙，任务不是很重，但是照样老加班，就是从早上开会，下午开会，这个会，那个会，终于到了下午五点钟，所有的会议都没有了，写程序才开始慢慢进入状态，下班后反而成了coding的高效率期。

想想这些让人头疼的会议，多有以下的特点：首先，会议主题模糊，多为About XXX, 或者Let’s talk about XXX，没有具体的资料，内容，日程，使得与会者无法准备，所以一定要具体，并且有可讨论方案，比如要讨论接口，那么至少有一方写一篇文档给出一到多个接口的方案，提前发出来，而不要接口调用方和提供方到会议上现场讨论。其次，会议邀请提前期短，使得与会者来不及准备，以致在会议中边讨论边想，不但想法会有漏洞，而且时间难以控制，所以会议邀请最好提前半天。其三，邀请范围过广，所以每天每个人都能收到多个会议邀请，参加完这个马上参加另一个，既没有办法准备，也不能集中精力，每个会议邀请要分必须参加的和可选择参加的，根据组织行为学理论，会议规模在七人以上，则彼此之间缺乏足够的机会进行直接交谈，五人左右最佳，所以必须参加人数控制在五人左右，如果的确需要较多的人参加，则说明议题过大，可进行分割，或者将头脑风暴会议和决策会议分开，前者向更多的人广开言路，后者将由相关方慎重决策。其四，重复的问题多次讨论，不能形成结论，很多时候发现，这个问题好像原来讨论过，但是大家都忘了当时怎么讨论地了，只要重新再来，每当发生这种现象的时候，会议记录是必须的，每次的会议记录要发出或者写到wiki上，形成结论，结论应该包括方案是什么，谁来负责。最后，会议时间过长，本来五点钟开会，说六点结束，结果往往开到七点多，最后大家精疲力尽，造成会议后期讨论的结果有效性较差，在学校阶段四十五分钟一节课还是很有道理的，一般前一个小时还能够积极思考，后来便死气沉沉了，所以会议时间应该控制在一个小时，如果的确要超过一个小时，说明议题过大，需要进行分割。

团队的优势就是人多力量大

人多力量大，一加一大于二，是我们常常对团队的力量的赞美。

然而如果问大家，在程序中需要处理一个很大的任务，要想能够加快速度，该怎么办？我想很多人的答案中都会有多线程这一项。什么样子的任务适合使用多线程呢？是不是线程越多越好呢？请大家回想一下自己在处理以及debug多线程问题的时候的痛苦，就可以预见，人多并非一定好事。

可以拆分成互相独立的子任务的，可以用多线程，比如网页抓取，一共10000个url，10个线程每个线程1000条。有的时候，子任务是需要访问共用的资源的，很不幸，需要互斥锁了，在互斥锁保护的代码序列中，各个线程是依次运行的。有的时候，子任务之间是相互有依赖的，java里面用wait/notify，linux下用conditional variable，windows下用signal，也即等待和通知，在等待的线程，只有在另外一个任务到达一个条件的时候，才能继续运行。而且在并发之前任务要拆分，处理完毕之后结果要合并，线程之间需要通信，需要调度，等等等等。

人，只可能比程序复杂。作为一个团队，除了去完成任务需要耗费精力以外，团队本身的发展和维护，也同样耗费精力(技能培训，彼此沟通，工作交接，文化冲突，个性抵触)，这在组织行为学上称为过程损失。而且正如我们的多线程程序，有的任务是不能拆分的，比如娶一个女人，怀十个月孕，能生出个孩子，可是娶十个女人，怀一个月孕是生不出孩子来的。有的时候是需要访问共享资源的，比如一次给客户的服务器(windows)上搭建一个环境，为了安全，客户同时只允许一个用户登录远程桌面，虽然这个环境需要三个人一起来搭。有的时候任务是会相互依赖的，比如他那里没有完成，我们没法联调。

在这里推荐大家读《人月神话》这本书，相信会大受启发。

团队成员要相互信任

团队成员当然是需要相互信任的，然而信任也是分不同的层次的。

我们都知道，在TCP/IP协议中，客户端和服务器需要建立连接需要三次握手。其实信任也是存在相互交互的三个层次。我们举一个例子，假设A需要依赖于B开发出来的接口，层次一，就是A应该相信B有这个能力在两个星期内完成这个任务，然而这个时候B可能由于经验问题，觉得两个星期可能不够，但是B就会陷入犹豫，如果承认自己的能力和经验不足会不会在绩效评比或者升职的时候被作为弱点攻击，如果延长时间会不会在将来不能按期demo的时候作为替罪羊(然而在工作中这种现象经常出现，所以很多职场经验都教育我们的员工不要在关键问题上示弱，否则这些弱点总是会及时的在关键时刻被提及，从而影响前途，所以要关键问题示强，边缘问题示弱)，所以层次二，就是B要相信A，在承认自己的不足的时候不会有负面的效应，这样B才能开诚布公，而不是蓄意伪装，从而造成整个项目时间不可控。当A得到B能力和经验不足的信息后，A显然应该对这件事情格外的上心，更加频繁的检查状态，适时进行督促，有可能的话提供帮助，然而每天跟在别人后面督促别人是一个得罪人的活，很可能被人误以为针对个人的攻击行为，所以层次三，就是A要相信B会认为督促他是为了整个项目和整个队伍，而非个人的恩怨。

整个三次握手后的信任氛围是理想的，一方面，每个人都能够自愿公开长处或者短处，这样整个团队才能够掌握最真实的信息，来准确的预估项目的进度，进行最合理的安排。比如A如果真实了解B经验方面的不足，就不会出现A做完了发现B还要等待三天，或者B强行上线的是一个没有经过严格测试的Bug无数的版本，A完全可以提前安排和C在这三天进行联调。另一方面，如果每个人都相信督促是善意的，则成员的相互检查状态并进行督促，就不会有很大的心里压力，从而可以尽快的得知每个模块的状态，在可能影响进度的时候尽快的做出调整。比如A如果尽早发现B遇到了一个没有预料的问题，就可以建议B换一种方案，或者得知B的某个接口调用有问题，则A也可以修改自己的代码来调用B的另外的三个接口来达到相同的功能。

不过很遗憾，很多的团队的信任仅仅停留在层次一，于是开会的时候，到处都是“没问题”，A模块说：“我们这面两个星期后可以联调”，B模块也马上说：“我们也差不多那个时候可以做完”。当联调的日期临近，当问及进度的时候，B也还会咬死说：“没问题”，而A也不好天天催，或者真正审核一下B是不是没问题，于是眼睛盯着当时发的邮件中B写的联调日期，终于等到了这天，B强行上线，A一调用发现有问题，于是就发出邮件来证明自己的无罪：“在X月X日的邮件中，安排我们和B联调，根据事前的文档，某个接口的调用结果应该是这样的，然而现在测试下来，结果是另外一个样子，请B检查一下问题所在，谢谢合作。”而项目却是真的被耽误了。

团队利益高于个人利益

这种论调原来经常出现在小时候的思想品德课上，比如集体利益高于一切，比如牺牲小我成就大我。

而在企业中，换成的大多数说法就是：“大家不要太斤斤计较，咱们这个项目只有做成了，大家才有机会。”

于是出现了很多以维护团队利益之名，忽视团队成员的个体需求。不要怕加班，不要不愿意做边角的模块，不要嫌我们这次加薪少，不要太在乎这次的绩效评级，不要太纠结这次没有给你升职，不要……，相信只要咱们这个项目做好了，大家都有机会。于是本来意气风发的程序员对这些个体需求望眼欲穿，一个个demo过去了，一个个项目做完了，可是最后发现自己还是自己，而且由于长时间忙在项目上，连跳槽所需要的几门功夫都已经不如当年了，于是积极性大为受挫。所以，工作多年后，江湖上便流行一句话：除了钱，什么都是假的。便是这种现象的逆反心理所在。

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

IT外企那点儿事(18): 当“we are a team”成为口头禅相关推荐

IT外企那点儿事(7)：做一个优秀的基层（转）
转自:http://topic.csdn.net/u/20100524/09/635885a9-e075-4eac-b63a-2f75015d0c39.html?69859 1-7在博客中的链接如下, ...
IT外企那点儿事(转)
IT外企那点儿事(1)外企业就那么回事外企,一个听起来似乎充满光环的名字,每年众多大学毕业生向往的地方. 说起外企,总能让人联想到很多令人心动的名词:高薪,人性化,浮动工作制,年假,完善的流程,各种 ...
IT外企那点儿事(6)：管理路线和技术路线 (转载)
IT外企那点儿事(1):外企也就那么回事 IT外企那点儿事(2):多种多样的外企 IT外企那点儿事(3):奇怪的面试 IT外企那点儿事(4):激动人心的入职演讲 IT外企那点儿事(5):像系统一样升级 ...
IT外企那点儿事(5-7)
IT外企那点儿事(5):像系统一样升级进行完入职培训,便开启了你在外企中的程序人生了,需要说明的是,此文章不仅限外企. 如果待足够长的时间,你将从程序员,高级程序员,team lead,一直到man ...
然而由于1-6全部发在《IT外企那点儿事(1)：外企也就那么回事》
1-7在博客中的链接如下,在博客中格式较好,更容易观看: 然而由于1-6全部发在<IT外企那点儿事(1):外企也就那么回事>1-7在博客中的链接如下,在博客中格式较好,更容易观看: IT外 ...
IT外企那点儿事--也说跳槽
原文地址:http://www.cnblogs.com/forfuture1978/archive/2012/11/26/2788610.html 跳槽的学问不在一个跳字,而在于长期的职业生涯规划.跳 ...
IT外企那点儿事(12)：也说跳槽
跳槽的学问不在一个跳字,而在于长期的职业生涯规划.跳槽可以帮助职业生涯更上一层楼,而跳槽之所以能够成功,也是因为以往有了较好的职业生涯规划. 什么决定了程序员的价格所谓的职业就是企业和员工之间的价值 ...
程序员修炼之路(十四)IT外企那点儿事--也说跳槽
最近一个月一直在忙项目,几乎没什么时间写博客,今天中午才有时间看看csdn,在论坛上看到一篇很好的文章,分享给大家.也给自己留作备用. 原文地址:http://www.cnblogs.com/forf ...
IT外企那点儿事(13): 你总是在画饼吗？
慢慢的,很多公司和领导都领教了目标的魅力,于是展开了一系列轰轰烈烈的画饼运动. 如果你有幸参加公司的招聘会,入职演讲,每年每月的All hands meeting, Team meeting,无不充斥 ...

IT外企那点儿事(18): 当“we are a team”成为口头禅