在我十多年的工程师生涯中，我经历了从 6 人的小团队到千人以上规模的大公司的各种团队。优秀的团队有很多共同之处，而表现不佳的团队各有其独特的问题。这篇文章描述了优秀团队的共性。

一. 信任
信任是任何优秀团队的基石。你必须相信你的团队成员知道他们在做什么，他们对自己的工作持有和你一样的标准，他们真的在乎工作。他们不必将公司的使命视为生命，但他们必须关心交付高质量的成果。当生产中出现紧急事件时，你需要能够信任那个说 “我在处理” 的队友确实在处理问题。他们可能不会亲自解决所有问题，但必须能够妥善处理这种情况，并迅速地协调适当的人来解决问题。

当出现错误时，你需要相信那个说已经修复了错误的人确实做到了。我们都遇到过这样的人或团队 —— 你听到他们说，“没问题了，X 已经解决”，然后你就不再追问。而我所在的最佳团队，正是由这样能够解决问题的 “X” 们组成的。

信任还意味着要信任团队成员的人品。在我的职业生涯中，我大多数时间都在使用敏捷方法工作，这通常意味着在冲刺或重大项目后会有回顾会议。最好的团队会在这些会议中坦率地表达他们的感受，因为他们相信其他团队成员会倾听并帮助解决问题。我曾经将整个冲刺周期专门用于讨论产生的工作，这是非常有价值的，如果我的团队成员不愿意发声，这些工作就不会发生。

建立信任是很困难的，你必须努力获取，但是它又很容易失去。但在我所参与的每个优秀团队中，信任都是不可或缺的。

二. 尊重
尊重与信任紧密相连，缺一不可。即使是在高效的团队中，也不可能总是一帆风顺。每个人都有自己的见解，我们都坚信自己是对的，尤其是工程师。这意味着争论不可避免。我观察到，在优秀的团队中，即便争论变得激烈，人们总是保持尊重。他们可能会激烈地争论，但不会涉及个人感情，而是将焦点几种在工作上。

事实上，这些分歧往往能够揭示出更广泛的误区，例如：“我们到底为什么要开发这个功能？我们的时间投入在其他地方是不是更合适？” 你的团队必须能够进行这样的讨论，如果没有尊重，这些讨论很快就会变得没有意义。

三. 沟通与协作
在所有人际关系中，沟通都是关键所在。在远程工作流行的今天，沟通变得更加重要，同时也更难以做好。能够及时帮助解决问题，或者通过屏幕分享和配对编程来协助他人，这是非常重要的。

软件工程的领域非常广阔，没有人能够通晓一切，但一个团队中的工程师总是能够汇集大量的知识。你必须愿意提出问题，而你的团队也必须愿意提供帮助。

对于新入行的工程师来说，求助可能是一件挑战。知道自己何时真正遇到难题比想象中要困难，但这是一项极其有价值的工程技能。如果团队中的新手看到其他人经常寻求（并得到）帮助，他们也会更加倾向于自己提问。他们当然应该这样做！与一个有经验的团队成员进行一次快速对话，比你独自挣扎相同的时间能学到的要多 —— 这也是我自己的学习技巧。

四. 谦逊
我之前提到了能够寻求帮助的重要性。这隐含了一个前提，那就是必须承认你不知道某件事情或还没有解决它，这需要一定的专业脆弱性。因此，在交流中展示谦逊是非常重要的。

有些问题可能看似很基础，你可能会想 “这问题有点傻，他们本应该知道”，但如果你带着这种态度去互动，求助者将不会再向你求助，结果整个团队都会受到影响。

或许你确实更了解情况，但即便如此，如果别人觉得他们被你看不起，他们就不想和你共事了。

五. 所有权与责任
除非你的公司很小，否则它很可能由多个团队构成。每个团队对其负责的领域拥有明确且具体的所有权是很重要的。谁负责什么必须明确；责任共享最终总会变成别人的责任。

所有权与责任是相辅相成的。拥有某个领域的人或团队也应该对其负责。如果我的团队负责支付服务，当出现问题时，我们应该承担责任。如果发生与支付有关的事件，我会期望值班人员立刻联系我们。

责备与事后分析
责任所隐含的是责备的可能：“支付系统出了问题，是贾斯汀团队的错。” 确实，可能是我们发布了有问题的代码。但也可能不是这样，可能是某个依赖服务宕机了。无论哪种情况，责备我们都无助于解决问题，只会使我们未来更不愿意发布任何东西。你应该始终认为别人是出于好意；没有人故意制造故障。

一个高效的团队可能会提出以下问题，而不是指责：
1.究竟发生了什么？
2.我们是否被及时通知？
3.这个问题是如何通过测试的？
4.这个问题是如何解决的？
5.我们如何防止将来再次发生同样的问题？

我参与过的最有效的团队将这一流程正式化为每次生产事故后都要进行的无责备事后分析会议。这次会议有一个明确的负责人，在会议结束之前，所有后续的工作都会指派给个人。

事故总是不可避免的。即使你的代码是完美的（虽然事实上不是这样），你的依赖也可能会失败。一个高效的团队将每一次失败看作是提升的机会，而不是去责备他人的机会。

六.招聘
开始如果没有合适的人才，本文提及的其他任何事项都不可能实现。你需要那些具有正确技术技能和态度的人，而一次糟糕的招聘足以毁掉一个团队。这也是为什么 Steve Jobs 将招聘视为他最重要的工作的原因。

招聘很难做好，值得你投入大量时间来优化你的招聘和面试流程。我见过的最佳招聘流程非常明确：为每个级别的每个模块制定了详细的评估标准，面试官提前对模块进行培训，独立完成评分，之后所有参与流程的人员进行总结讨论。这个流程可能看起来是基本操作，这取决于你之前在哪里工作，但请相信我，这并不常见。

七.会议
工程师对会议特别敏感。自 2009 年以来，“创造者时间” 一直被讨论，这是一个非常真实的概念。编写优质软件是个深度工作，需要长时间不间断的专注。如果你需要 30 到 60 分钟来全面理解一个问题的上下文，但每 90 分钟就有一个会议，你将无法完成任何工作。如果这种情况经常发生，你甚至不会尝试去完成工作，因为你知道一会就得中断。

我所在的最好的团队明确认识到了这一点，甚至在一周中的某些时间里，不会安排任何会议。当然，不开会可能不现实，但至少团队应努力仅邀请真正需要参会的人员。在多数企业中都可以适用某种形式的 “两个披萨原则”。

八.关于管理者的话
我自己从未担任过管理者，所以关于这部分的描述我会非常简短。一个好的管理者有点像你的小指。当一切顺利时，你可能几乎不会注意到他们。但一旦出现问题，他们就是你的依靠。

人们喜欢把问题归咎于他们的管理者，但根据我的经验，一个糟糕的管理者至少和他们成为问题原因一样经常是更大问题的征兆，如缺乏信任，或组织上的不一致。

我遇到的最好的经理大部分时间都让我们团队自由地做我们的工作。如果我们需要他，他总能提供帮助，但由于我们已经证明我们可以可靠地交付高质量的工作，他就让我们自由地做我们的事情，除非我们需要他的意见，对此我们非常感激。你让经理的生活越轻松，每个人就越快乐。

九.结论
这并不是一个详尽的标准清单，但足以看出构建一个高效的开发团队为何如此困难。如果上述任何一个特质缺失，团队都会受到影响。这就是像 “工程总监” 或 “CTO” 这样的头衔的人获得高薪的原因。他们的工作是尝试打造一个在以上所有方面都做得好甚至更多的组织。如果他们能够做到，那么为他们支付的每一分钱都是值得的。