高功能团队的习惯

我经常很难解释成为一个高功能软件团队的一员意味着什么。当然，有堆积如山的文献，还有一整套LinkedIn思想领导力的流派，声称关于团队运作的各种指导方针和启发式方法，但根据我的经验，如果你从未见过什么是好的，就很难内化这些想法并效仿别人的模式。

在我职业生涯的这一阶段，我非常幸运地与数十名(如果不是数百名)开发人员直接合作过。我曾经参加过一些不健康的团队：在这些团队中，人们感到恐惧，出于对工作保障的明显或真实的担忧，他们将自己的名片藏在胸前。我也曾参加过功能失调的团队，他们浪费了很多天或几周的开发时间，而团队却在不清楚的优先事项之间来回奔波，或者协调的成本变得如此之高，以至于没有人愿意这样做，使得团队成为一个个人的集体，而不是一个团队。但幸运的是，我花了很多时间在一些表现非常出色的团队中。当我在那些团队的时候，我每天来上班都很兴奋，我不怕公开反对那些比我高的人，我觉得我的声音和我的工作都有影响。

在这篇文章中，我将尝试记录我所在的表现最好的团队的特点和习惯。

心理安全作为一个概念已经存在了一段时间，所以我不会花太多时间来解释它。如果您以前没有遇到过这个概念，请先阅读本文。

软件团队的工作人员是在无形的社会和政治结构中运作的真人，他们从出生起就被社会化，变得更自信、更恭顺、更直言不讳、更有礼貌、更好辩论、更安抚，等等。我说这些明显的陈词滥调是为了表明，心理安全不仅仅是雇佣一些顾问对员工进行培训，了解这个概念的含义：创造真正的心理安全需要领导者和经理评估所有无形的、社会化的人与人之间互动的规则，并理解这些规则如何影响一个人有意义地参与团队讨论和动态的能力。简而言之：社会特权是一件大事。否则，如果侵蚀团队凝聚力的小事情开始显现出来，也不要感到惊讶：微攻击性、刻板印象威胁、将生存偏见编码到你的信念中，即是什么让你成为一个有效的团队成员。

据我观察，心理安全程度高的软件团队有以下几种行为：

定期回顾，在“哪里不太顺利？”中有合理数量的项目。纵队。它不应该总是看起来像阳光和彩虹。这实际上会让我质疑是否在倒退中提出了困难的话题。健康的团队应该能够开诚布公地反思和自我批评，因为每个人都明白建设性的反馈是为持续改进服务的。

个人不会在一个问题上花费很多时间被卡住或受阻。有一个明确或隐含的“奋斗时间框”，在这之后，他们会向同龄人寻求帮助，并且知道他们不会因为这样做而被负面评价。

个人将他们对团队的价值与他们可见的产出分开。我见过一些案例，人们对他们的代码行后来被删除或重构感到沮丧。在健康的团队中，人们接受这样一个事实，即改进是渐进和持续的，他们的贡献是对整个团队的结果，而不是对特定的输出，如行或代码。这是一种表达“这是我们交付的东西”，而不是“这是我交付的东西”。此外，安全团队还可以讨论价值的含义，以及它如何不仅仅是几行代码。

有趣的是，人们往往需要更多的PTO和病假。我相信，这是他们相信团队其他成员会在他们缺席的情况下继续做出正确决策的症状，因为已经进行了足够的对话，这使得整个团队在产品和技术决策上感到一致。但我不太确定这件事的因果关系。如果人们真的筋疲力尽，他们也可以服用更多的PTO。

当一个团队有高度的心理安全时，你可以尝试一些非常酷的过程实验，我相信这些实验会产生自我强化的积极反馈循环，创造更高水平的信任和安全。在我的第一个高绩效团队中，在我们的一次回顾中，每个人都觉得一年两次的绩效评估周期，在那里我们的经理们从同事那里收集反馈，不够频繁或不够精细，不足以促进职业发展，特别是在我们团队的优先事项演变得如此之快的情况下。所以，我提出了一个实验：

这是一个为期一周的过程，每个人(包括团队领导和PM)都被随机分配来为另一个人收集反馈。事情进行得非常顺利，我的队友们去了新的团队后，他们把实验也带来了。最后，办公室里的其他团队开始模仿我们！我在这篇博客中写得更详细。我甚至在2019年的多伦多DevOpsDays上做了一个关于它的演讲。

能够运行像“反馈周”这样的活动表明您的团队处于高度的心理安全状态。如果你有幸在那里，我的建议是：不要只是站着不动。这是一个大胆尝试你的过程和实践的机会，并尝试像反馈周这样的活动，这可以帮助你挖掘隐藏的积极反馈循环。如果你真的想出了什么很酷的东西，告诉我！说真的，我喜欢谈论这些东西。

随着系统复杂性的增加，任何单个Agent自己对该系统的模型的准确性都会迅速下降。

我直截了当地承认，我永远不会有一个全面的GitHub巨石的心理模型。它太大了，有太多的逻辑路径，坦率地说，把过多的时间投入到学习代码的所有部分上并不会让我的工作做得更好。另外，明天就会变了。

因此，当我确实必须收集足够的上下文以便实现下一个功能或错误修复时，我依赖于代码中工件的存在和准确性，这些工件是由那些在我之前从事这项工作的人留下的。

我花了很多时间研究代码：运行git错误、查看过去的提交、链接的问题，以及任何可以帮助我告诉我为什么以这种方式编写某一行代码的事情。效率杀手是当我看到一个神秘的差异和提交消息时：“WIP”。

良好的软件开发卫生意味着花一点额外的时间来记录当前的上下文。这可以采取以下形式：

描述性提交消息至少，每个提交消息都包含一个谓词。有些团队甚至走得更远，要求在每次提交时都跟踪问题编号。选择适合您团队的认知投资水平。

带有有用描述的单元测试，它们使用真实的变量名称和数据，而不是变量的“foo”和“bar。

将关于该功能的所有来回交流保持在跟踪问题内，而不是在松弛DM和其他地方，因为从现在开始的6个月内，您的新团队成员不可能访问这些地方。

归根结底，遵循良好的卫生习惯是关乎同理心的。更干净的工件意味着你的队友可以更快地吸收上下文，在上下文切换和洞穴探索上花费更少的认知能量。但同时，体谅你未来的自己也是值得的。有一个完整的道德哲学分支认为，未来的你是一个拥有道德权利的独特实体(这就是为什么今天多吃一桶Ben&；Jerry‘s或参加赛车来享受现代的享乐主义在道德上可能是一种可疑的行为)，但我不会太深入地讨论这一点，我只想说：在早期培养这些卫生习惯方面的投资稍后会得到回报，特别是如果你因为一天凌晨3点因为你写的一行代码而被寻呼的话！

如果你曾经和我谈过电子游戏，你就会知道我喜欢角色扮演游戏。尤其是“火徽”和“精灵宝可梦”系列中的那些。我也慢慢地迷上了“最终幻想”游戏！

我之所以这样说，是因为我认为我在Fire Emblem中建立军队的方式与我构建平衡的软件开发团队的方式有很多相似之处。在RPG中，当我有我的核心团队时，我真的很喜欢尝试让我所有的角色平均升级。如果我获得了一个较低级别的新角色，但她有一套技能或亲和力，可以补充我团队的其他成员，我会投资让她升级一点，这样她就可以在地图上移动，而不会那么担心敌人的攻击。如果我的角色一开始就处于超高水平，我会避免让他们与实力较弱的敌人作战，因为他们只会独占经验点，这会让我的中低级战士受益更多。

我愿意认为类似的原则也适用于软件团队，但不是建立力量、防御、魔力和抵抗力的经验点，而是每一项新工作都是一个“敌人”，当交付时，将在您的团队周围传播领域上下文和信心。然而，团队中通常没有核心的“战术家”角色-这就是这个比喻开始分崩离析的地方(经理和PM并不重要-他们通常不会有足够的可见性，或者没有最新的上下文，而且无论如何，将如此复杂和动态的事情集中在一个人身上是一个坏主意)。如果你的团队已经有很多伟大的骑士和圣骑士-呃，我的意思是，高级开发人员，作为一个团队，你应该指出，不应该总是只部署他们来解决困难的故事。对于健康的团队，参与上下文重新分配也是他们工作的一部分，这样经验较少的拳击手-我的意思是工程师-也可以获得一些有价值的经验点。如果每个人都觉得自己至少在一定程度上具备了应对任何挑战的能力，这会提高整个团队的生产力和士气。如果没有，他们知道他们随时可以增加一名猎鹰骑士作为副手-换句话说，向更有经验的人寻求帮助。

关于最后这一点，我想了很多。在所有其他人说出我脑子里想什么的方式中，我认为最重要的是，我最喜欢纳特·弗里德曼在最近的一次全体会议上所说的话。他说，“我们之间的交流应该遵循稳健性原则：发送的东西要保守，接受的东西要自由。”他继续鼓励我们坚持慈善原则，特别是在当前非常困难的情况下相互沟通时。但我认为，在表现出色的团队中，100%的时间都会遵循这一原则。

我真的很喜欢这个框架，因为它让我想起了很多年前我在Codebar做志愿者时经历的一次导师培训。“假设与你互动的每个学生都有有限的信息，但有无限的智慧。”这将确保他们的解释有意义的责任直接放在了导师的肩上-考虑到教师和学习者之间固有的权力失衡，这是分配额外情感劳动的好方法。

同龄人之间的慷慨交流意味着在任何时候，我们都假设任何提出问题的人：

是在问人类，因为他们在任何写下来的地方都找不到答案。因为那个写下来的地方很难找到，或者它还不存在。

换句话说：假设你的同龄人是一个有能力的、聪明的、理性的人，他们问问题是因为他们缺乏上下文，而他们已经试图自己获得上下文。

我不确定我能用语言来表达，当你开始寻求帮助时，不断地“四舍五入”你的背景和经历是多么令人沮丧。是的，这其中有性别因素--但这已经超出了目前的讨论范围。过去，我在推特上写过很多帖子，说别人认为你的经验和知识远没有你的实际水平高，这是多么令人泄气。当然，另一个人没有办法真正知道--当然，无所不知是一个不可能的要求！但是，这里有一个中间立场，这是合理的要求：慷慨。

X：负载均衡器用于将请求分散到多个服务上，所以我们不会收到DDoS！这里有一些关于负载均衡器的基础知识的文章，以及为什么我们在理论上可能会使用它们！

我：好的，但那不是我的问题。我知道什么是负载均衡器。我只想了解将HAproxy放在此特定服务之前的体系结构决策。

X：我猜您是在询问我们为什么选择HAProxy，特别是为什么选择这些服务。如果这是错的现在就阻止我。

谢：当然可以。所以，当我们在18个月前建造这个系统时，…。。。

这些互动的关键区别在于，在慷慨的互动中，回答者在回答之前检查了他们对问题的假设，进而检查了提问者的上下文水平和意图。慷慨的互动有非常积极的影响：首先，注意到交流的话变少了吗？他们实际上更快地找到了解决方案。第二，没有产生不必要的摩擦。两个人都团结一致，杀死了这条不确定的巨龙；而不是陷入每个人都知道多少的角力中，然后带着可能的答案离开，但也失去了一些信任和善意。

随着我在加入(和建设)方面积累了更多的经验，我可能会不时地回来访问这个帖子。表现出色的团队。我希望这篇脑洞大全是有价值的，如果你在类似的团队中有过经验，并且你花了很多时间在精神上合成，请发推特给我-让我们聊天，继续提高健康团队的标准！