Google 极客谈软件开发团队的不良行为
开发团队是一个整体，稳定的、沟通无碍的团队文化非常重要。好的文化氛围应该包括基于共识决策的开发模式、高质量的代码、代码审查，以及能让人放心尝试新事物或者快速失败的环境。Brian和Ben是Google的两位开发主管，他们在“极客与团队”中列举了软件开发团队的典型不良行为，提醒开发者时刻保持警惕，并提出了一些实际的解决办法。
Brian和Ben指出，团队的注意力和专注力是最容易受到威胁的。团队规模越大，编写软件和解决有趣问题的能力就越强—不过这种能力毕竟是有极限 的。要是你不去主动保护它们，很容易就会被害群之马引入歧途。团队最终会争论不休，变得心烦意乱、身心疲惫。所有人都会把注意力和专注力放到那些编写优秀 软件以外的事情上去。
根据我们的经验，很少会有人故意干坏事（也就是存心捣乱的那种）。我们管这种行为叫作“钓鱼”，通常无视这种人就可以了。而大多数人在行为出格的时候，要么是没有意识到自己过分了，要么就是根本不在乎别人的感受。无知和冷漠其实比蓄意更严重。
他们列举了一些典型的不良行为。第一条就是不尊重别人的时间 ，总会有一些人搞不清楚项目的状况，他们的危害通常是浪费团队的时间。他们宁可不断地拿那些很容易就能找到答案的问题去骚扰整个团队，也不愿意自己花点时间去读一读最基本的项目文档、任务宗旨、FAQ，或是最近的邮件讨论。 这里有一个现实当中的例子：
我们在Subversion项目里就曾经碰到过这样一个人，他把开发主论坛当成了自己每天报流水账的地方。查理实际上没有 贡献什么代码，但他每隔两三个小时就会发布自己最新的异想天开。这样就无可避免地产生了很多回复，去解释为什么他的想法是不正确的，不可能的，已经在开发 中了，之前已经讨论过了，或者是已经有文档记录了等。更糟糕的是，查理甚至开始回答那些临时用户的问题，而且都答错了。这样，我们的核心成员只好不断地去 更正他的回复。过了好久我们才反应过来，这位和蔼可亲的热心人其实是好心办坏事，大家被他牵扯了太多的精力。
第二条是自负，这里“自负”可能不是最恰当的词，Brian和Ben想要表达的是那种无法接受多数人决议，无法 倾听和尊重其他观点，以及不愿作出妥协的人。这种人常常会重新挑起些早就已经结束（并且保留在邮件存档里）的讨论，仅仅是因为当时她不在场。这种人不肯去 读存档，也压根不想去思考，她只会要求为了自己重启争论。她常常会就项目的前途作出极端的评价，声称除非按照她的思路走，否则失败就在眼前。
过分索求是另外一种不良行为。每当有陌生人跟你要求做什么的时候，一定要提高警惕。这样的人把所有的精力都用来抱怨软件功能不足，却不愿意自己动手作点贡献。有时候等天上掉馅饼的心态会演变成过激行为。在运营Google的项目托管服务时，Brian和Ben就遇到过这样的例子:
当时有一个项目作者要求我们封掉一个用户，因为他的所作所为实在是太讨厌了。这是一个开源的电视游戏模拟器项目，而这个用 户最喜欢的游戏却无法在上面正常运行，于是他在问题跟踪系统里提交了一个口气相当粗鲁的bug报告。开发人员礼貌地解释了那个游戏跑不起来的原因，还告诉 他相当一段时间里可能都没办法修复那个问题，结果那个人接受不了，每天都来骚扰开发人员。他不断地提交同样的bug报告，里面充斥着各种不满，还在其他 bug报告里评论说拒绝修复他的问题的程序员是个“蠢货”。尽管项目人员和Google管理员屡次警告，他的用词却反而越来越不堪。不管我们怎么努力去消除他的这种破坏性行为，他就是冥顽不灵，万般无奈之下，我们只好祭出最后一招—彻底把他封掉了。
除此之外，还有两种行为需要警惕：
- 幼稚或是莫名其妙的交流——这样的人不会用真名。他们常常会用一些幼稚的昵称，比如 “SuperCamel”、“jubjub89”，或是“SirHacksalot”之类。更糟糕的是，这样的人往往会在不同的地方用不同的昵称—E- mail一个，即时消息里又是另外一个，可能提交代码的时候还有一个。更有甚者，你会看到他们用火星文、黑客语、全部大写，甚至含有大量标点符号的沟通方 式！
- 偏执妄想——在上面的例子里我们看到，有时候不切实际要求会直接转变成对项目的恶意。我们无数次看到它彻底演 变成偏执。当团队和访客的意见不一时，这种心怀恶意的人就会抛出某种阴谋论。要是太把他当真，去花精力和时间反驳的话就实在是太滑稽了。而且如果你已经建 立起一条开放透明的沟通渠道的话，这种指控只会显得更加可笑，因为所有的谈话内容都是有公开记录的。我们的建议是根本就不用去理会这种指控。当这种人真的 做到这一步的时候，你说什么都是没用的，既然这样干嘛还费这劲呢？还不如把时间用来写代码。
最后一条是完美主义。乍看之下，完美主义者根本就是无害的。尽管时不时地会有一些奇怪的强迫症类型的行为出现，但是总体上这样的人都是谦虚有礼貌的，而且愿意倾听别人的意见，看起来满是良好的本意。那么问题出在哪里呢？答案就是太追求完美会变得瞻前顾后、犹豫不决。现实当中的例子：
帕特里克是一名非常出色的工程师。他做的设计非常出色，代码和测试的质量也很高，人也非常容易相处。但是每当要设计新软件 的时候，他就会无休止地调整、改进自己的设计。他从不满足，好像永远也不会开始写代码一样。尽管他对我们所面临的问题有非常好的见解和洞察力，但是团队里 的其他成员最后都被折腾到不行。这样下去就没法工作了，我们几个考虑了很久要怎么办。一方面，对团队来说帕特里克是巨大的财富；另一方面，他也妨碍了团队 前进的步伐。每次我们打算开始编写代码的时候，他就会很有礼貌地否定我们的方案，指出其中只在理论上成立的潜在问题，而且都是一时半会不会产生什么影响的 问题，不知不觉中他让我们整个陷于瘫痪状态。
Brian和Ben提出了一些实际的解决办法：
- 写一份明明白白的任务宗旨。这样可以随时保持专注，知道哪些是目标，哪些不是。
- E-mail讨论要有礼仪。保留归档，要求新人研读，防范那些“嘈杂的少数人”。
- 所有历史都要有记录。这不单指代码历史，还有设计决策、重要的bug修复，以及过去犯下的错误。
- 有效地进行协作。利用版本控制，代码改动要尽可能的小，方便进行审查，扩大“公车因子”，避免出现领地感。
- 修复bug，测试，发布软件要有清晰的政策和流程。
- 降低新人加入时的壁垒。
- 依赖基于共识决策，在无法达成共识的时候也要准备好化解矛盾的方法。