如何对付团队中的“害群之马”
文/Brian W. Fitzpatrick Ben Collins-Sussman软件开发中最难的是跟人打交道,防止那些捣乱的家伙破坏你的团队辛辛苦苦建立起来的合作氛围。更重要的是,我们要探讨一下怎么对付那些已经在团队里的害群之马。什么是“害群”我们已经讨论了培养稳定的、沟通无碍的团队文化有多重要。我们一直在强调,好的文化氛围应该包括基于共识决策的开发模式、高质量的代码、代码审查,以...
·
文/Brian W. Fitzpatrick Ben Collins-Sussman
软件开发中最难的是跟人打交道,防止那些捣乱的家伙破坏你的团队辛辛苦苦建立起来的合作氛围。更重要的是,我们要探讨一下怎么对付那些已经在团队里的害群之马。
什么是“害群” 我们已经讨论了培养稳定的、沟通无碍的团队文化有多重要。我们一直在强调,好的文化氛围应该包括基于共识决策的开发模式、高质量的代码、代码审查,以及能让人放心尝试新事物或者快速失败的环境。

同样重要的是还要了解哪些东西不应该包括在文化里面。如果你打算打造一支高效敏捷的团队,那么知道自己不要什么也是非常重要的。虽然优秀的工程师能让团队更快更有效率,但是有些不好的习惯和做事风格会拖累团队,让公司变得不再那么让人舒服—最终这些都会侵蚀队伍的团结。 我们刚开始在研讨会上说到软件开发中的社交难题的时候,用的演讲标题是“怎么对付坏蛋”,大会主席建议我们把它改成“项目如何才能在害群之马的铁蹄下幸存”,希望这种八卦风格的标题能吸引到更多听众。事实上他是有道理的,这个演讲在很多研讨会上大受欢迎,听众多得连站的地方都没有。吸引听众的不单是“害群”这样非常负面的词汇,还有一个原因就是很多人都有这样不得不和那些叫人恼火的人打交道的经历。演讲到最后几乎肯定会变成一场诉苦大会,听众们会交换自己的故事,商量对策。 不过这样其实是很危险的。一般来说,一个人总是让自己沉浸在负面情绪里是不健康的行为—长远来讲,它会侵蚀你的一切,制造更多麻烦。“害群之马”是很大的帽子,一下子就把“我们”(也就是好人)和“他们”(捣乱的坏蛋)对立了起来。其实完全可以换一个思路来看这个问题。在带领团队的时候,不要把自己想成是一帮精英,众志成城地要把所有的烂人都轰走,而是要培养一种拒绝容忍负面行为的文化氛围,这才是正确的态度。要剔走的是行为本身,而不是人,单纯地区分好人和坏人是很幼稚的想法。规定好哪些是不可容忍的行为,然后予以惩戒,才是更有建设性的务实态度。 简单起见,我们暂时继续采用“害群之马”这种修辞手法来指代那种行为不端的人,但是在日常对话里千万不要轻易使用这个词哦!
保护团队 还记得酵母的比喻吗?团队文化和创始人的气质是紧密联系的。对团队文化影响最深的就是创始人,要是创始团队的文化不够强势,那么后来的文化就会压过它。如果创始团队很清楚哪些行为是可以接受的,哪些行为是不可以接受的,那么这些东西就能传承很多年。 我们两个在开源项目圈子里混了好多年,多年的经验也充分印证了这一点。 Subversion
是我们接触最多的项目,刚开始的时候它只有很少的成员。大家都非常谦虚,相互之间有一种自然而然的信任感和尊重。十一年来,项目的参与者来来去去至少三四拨(大部分创始人早就离开了),但是传统还是保留了下来—大家都和和气气的,很有礼貌,相互尊敬。这不但是因为它坚持了高标准,还因为文化总是会进行自我选择。物以类聚,人以群分。 自我选择也很容易往坏的方向发展。如果团队一开始就聚集了一帮愤青,那么它就会有越来越多的同类。有些项目我们实在是不愿意提,比如
Linux
内核社区就是典型的例子—无止境的斗嘴,狂妄的发言,还有各种出口伤人。这样的团队或许能完成很多工作,但是总体上的运营效率却叫人怀疑。要是在人身攻击上没有浪费这么多精力,那么能多做多少事情?如果没有把那些礼貌的人拒之门外,那么他们的潜在贡献有多大? 我们再次提到这个话题是为了让你明白其中的代价,害群之马会直接危害到你的高效团队。如果容忍了不良行为的存在,不但你的生产力会受到影响,还会渐渐侵蚀团队的文化。而对抗它的最好办法就是通过一系列强有力的最佳实践和流程来提高团队的抵抗力。这些内容在第二章里都已经讲过了,这里再简单回顾一下。
保护团队,抵御不良行为
- 写一份明明白白的任务宗旨。这样可以随时保持专注,知道哪些是目标,哪些不是。
- E-mail讨论要有礼仪。保留归档,要求新人研读,防范那些“嘈杂的少数人”。
- 所有历史都要有记录。这不单指代码历史,还有设计决策、重要的bug修复,以及过去犯下的错误。
- 有效地进行协作。利用版本控制,代码改动要尽可能的小,方便进行审查,扩大“公车因子”,避免出现领地感。
- 修复bug,测试,发布软件要有清晰的政策和流程。
- 降低新人加入时的壁垒。
- 依赖基于共识决策,在无法达成共识的时候也要准备好化解矛盾的方法。
有时候等天上掉馅饼的心态会演变成过激行为。在运营Google的项目托管服务时,我们就遇到过这样的例子,当时有一个项目作者要求我们封掉一个用户,因为他的所作所为实在是太讨厌了。这是一个开源的电视游戏模拟器项目,而这个用户最喜欢的游戏却无法在上面正常运行,于是他在问题跟踪系统里提交了一个口气相当粗鲁的bug报告。开发人员礼貌地解释了那个游戏跑不起来的原因,还告诉他相当一段时间里可能都没办法修复那个问题,结果那个人接受不了,每天都来骚扰开发人员。他不断地提交同样的bug报告,里面充斥着各种不满,还在其他bug报告里评论说拒绝修复他的问题的程序员是个“蠢货”。尽管项目人员和Google管理员屡次警告,他的用词却反而越来越不堪。不管我们怎么努力去消除他的这种破坏性行为,他就是冥顽不灵,万般无奈之下,我们只好祭出最后一招—彻底把他封掉了。
- 虽然短期之内会损失一些注意力和专注力,长远来讲你真的相信项目会因此受益吗?
- 你相信这些冲突最终会以有益的方式解决吗?
我有不少朋友都认识他。其中有一个是这样说的,“他常常游走在天才和疯子之间。可问题是,现在天才已经不稀奇了,没人会因此接受这样举止古怪的人了”。—格雷格·哈德森这里格雷格说的不是通常意义上的“天才”,他的意思是这个世界上有的是合格的程序员。如果你发现有人在长远来讲会威胁到团队的文化,那么不妨再等另一个出现。 我们在 Subversion 项目里就曾经遇到过这样的情况。团队有严格规定,不准把名字写到源文件里(这一条我们在第二章里就讨论过了),我们觉得做只会产生领地感。如果代码里有别人的名字,修改的时候会觉得有点担忧,而且这么做还会人为地降低公车因子。所以在版本控制的记录里认可大家的贡献才是比较恰当的做法,我们在项目的根目录里放了一个这样的文件,里面有所有贡献者的名字。 有一天,来了一个非常聪明的程序员,主动写了一个所有人都想要的新特性,工作量还不小。在他提交代码审查的时候,我们只是要求他删掉文件开头的名字—我们会在和别人一样的地方感谢他的贡献。可是他拒绝了,谈判陷入了僵局。最后,大家决定拒绝接受他的代码,他带着自己的玩具离开了。虽然大家都很失望,但是我们不愿意仅仅是为了能快点得到新特性,就打破自己的规矩(进而放弃自己的传统)。几个月之后,就有其他人重新实现了这个特性。 在这里要再次明确强调:为了短期利益而打破规矩不值得—特别是对于那些不懂得尊重 HRT 重要性的家伙来说,再大的天才也没用。 小结 我们讨论了很多场景,说到最后似乎会产生一种偏执的感觉。但是别忘了,这个世界里混蛋其实并不多。正如罗伯特· J ·翰龙所说的: 不要把用愚蠢可以解释的行为归结为恶意的。 这里我们更倾向用“无知”而不是“愚蠢”,但是基本思想还是一样的。就像我们在一开始提到的,把人简单地分成好和坏是很幼稚的。没有什么坏人处心积虑地想要毁掉你的文化—大多数人只是被误导了而已;又或者只是想要得到认可,同时又不太擅长与人交际罢了。不管怎么样,你的任务不是要培养傲慢的态度,把那些没有那么聪明的普通人赶出项目;你的任务是拒绝容忍毁灭性的行为,明确自己对 HRT 的期望。有智慧的人才能体会其中的差别,而有能力的人才能真正予以执行。 本文选自《极客与团队》一书,作者Brian W. Fitzpatrick Ben Collins-Sussman,徐旭铭译,由人民邮电出版社出版发行。
更多推荐
所有评论(0)
您需要登录才能发言
加载更多