我经常需要费力地跟人解释，作为高效软件团队的一员到底意味着什么。当然，关于这一点已经有大量的资料，比如 LinkedIn 就有整套思想领导力理论介绍了各种帮助团队有效运作的指导方针和启发性思考，但根据我的经验，如果你从来都不知道什么样才算好，就很难内化这些想法并遵循别人的模式。
我非常幸运，到目前为止，我在职业生涯中已经直接与几十个（甚至是几百个）开发人员合作过。我曾在一些不健康的团队工作过：在那些团队里，人们会感到害怕，出于对职位的担忧，他们会把自己的底牌捂得很紧，不让其他人知道自己的计划或意图；我也在功能失调的团队工作过，那些团队由于工作优先级不明确而摇摆不定，或者协调成本太高而没有人愿意干活，许多天甚至数周的开发时间被浪费掉，团队成了一个个体的集合，而不再是一个工作单元。
但幸运的是，我也曾在一些非常优秀的团队工作过。当我身处这些优秀团队的时候，我每天去上班时都很兴奋，对于那些比我年长的人，我也不怕公开提出反对意见，因为我认为自己的声音和工作很有影响力。
在这篇文章中，我将试着记录下，我所共事过的表现最好的团队所具有的特质和习惯。
1. 高度的心理安全感
心理安全这个概念被提出来已经有一段时间了，所以我不打算花太多时间来解释它。如果你以前没有看过这个概念，请先阅读这篇文章。
https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/
软件团队由真实的人组成，他们在无形的社会和政治结构中生活和工作，他们从出生起就被社会化，变得更加自信，更加谦恭，更加直言不讳，更加礼貌，更加好争论，更善于安抚，等等。显然，这都是陈词滥调了，我说这些是为了证明，心理安全不仅指的是招聘一些顾问来开展员工培训、告诉大家这个概念意味着什么：建立真正的心理安全感需要领导者和管理者评估人与人之间交往的所有无形的社会规则，并理解这些规则如何影响一个人参与团队讨论、贡献团队动力的能力。简而言之：社交特权很重要。否则，当一些微不足道的小事情开始侵蚀团队凝聚力的时候，不要感到惊讶：攻击性的言语或小动作、刻板印象威胁、将幸存者偏差变成成就高效团队成员的信条。
根据我的观察，具有高度心理安全感的软件团队会有以下某些行为：
- 定期回顾，在“什么进展不顺利？”这一栏里列出适当数量的事项。那里不应该总是阳光和彩虹。那会让我怀疑回顾中是不是没有提出并讨论什么难题。健康的团队应该能够公开地反省并自我批评，因为每个人都明白，建设性的反馈是为了不断改进。
- 个人不会在一个问题上花很多时间。他们会有一个或明或暗的“奋斗时间窗”，在这个时间之后，他们会向同伴寻求帮助，他们知道，自己不会因此而得到负面评价。
- 个人从看得见的输出中分离出他们对团队的价值。我见过这样的情况，人们对自己的代码后来被删除或重构感到沮丧。但在健康的团队中，大家接受这样一个事实：改进是增量的、渐进的，贡献是对团队整体结果的贡献，而不是对特定输出（如代码行数）的贡献，表现出来就是“这是我们交付的”，而不是“这是我交付的”。此外，具有高度心理安全感的团队可以讨论价值的含义，以及价值为什么不仅仅是几行代码。
- 带薪休假时间和病假时间往往会更长，这很有趣。我认为，这是他们的信念的一种体现，即团队的其他成员可以在他们不在的情况下继续做出正确的决策，因为他们之间已经进行了足够多的对话，这使得整个团队都认为，他们在产品和技术决策上非常一致。但我不太确定这其中的因果关系。因为人们如果发高烧，也会申请更多的带薪休假。
当一个团队有高度的心理安全感时，你可以尝试一些很酷的试验。我相信，这些试验会产生一种自我强化的积极反馈循环，创造出更高层次的信任和安全感。在我的第一个高绩效团队里，在一次回顾中，每个人都觉得一年两次的绩效评估周期不够频繁，也不够细致，无法促进职业发展，尤其是在我们团队的优先事项发展得如此之快的情况下。所以，我提出了一项试验：反馈周。
2. 反馈周
这是一个为期一周的过程，每个人（包括团队负责人和项目经理）都被随机分配去收集对另一个人的反馈。这个过程进行得如此顺利，以至于在我的队友加入新的团队后，也带去了这个试验。最终，办公室里的其他团队开始模仿我们！我在这篇博文中更详细地介绍了这个试验。我还在 2019 年的多伦多 DevOpsDays 大会上就此做了一场演讲。
https://deniseyu.io/2018/03/03/better-team-feedback.html
https://www.youtube.com/watch?v=6VARlKoEAPI
能够开展类似这样的反馈周，就说明你的团队处于高度的心理安全状态。如果你足够幸运参与其中，我的建议是：不要只站着不动。这是一个大胆试验你的过程和实践的机会，尝试像反馈周这样的事情，可以帮助你挖掘隐藏的积极反馈循环。如果你确实想出了一些很酷的东西，请告诉我！
3. 良好的开发规范
随着系统复杂性的增加，系统中任何单个行为主体的自有模型的准确性都会迅速降低。— Woods Theorem
我就直说了吧，我永远不会有一个完整的 GitHub 心智模型。它太庞大了，有太多的逻辑路径，坦率地说，花费过多的时间学习代码的所有部分，并不能使我的工作做得更好。而且，它可能明天就又变了。
因此，当我必须收集足够的上下文信息以实现下一个特性或 Bug 修复时，我会依赖于代码中已有构件的准确性，这些构件是在我之前从事这些工作的人留下的。
我花了很多时间来研究代码：运行 git blame，查看过去的提交、 有关问题，以及任何有助于我理解为什么某行代码这样写的信息。如果我看到一个难以理解的改动，提交信息是“WIP”，这就会变成效率杀手。
良好的软件开发规范意味着需要额外花一些时间来记录当前的上下文信息，这可能表现在：
- 描述性的提交信息。至少，做到每个提交信息都包含一个动词。有些团队甚至更进一步，要求每次提交都可以跟踪到问题编号。务必选择适合你的团队认知投资水平的方法；
- 遵循语言和框架约定、可以表明意图的类名和方法名；
- 单元测试带有有用的描述信息，使用符合实际的变量名和数据，而不是“foo”和“bar”这样的变量；
- 在问题跟踪系统中就相关特性反复沟通，而不是在 Slack DM 和其他地方。今后，入职不满 6 个月的团队新成员将无法访问这些地方。
最后，良好的开发规范事关同理心。工件越整洁，团队成员就可以越快地了解上下文，花在上下文切换和探查上的认知精力也就越少。此外，这其实对未来的你自己也是有好处的。道德哲学的一个分支认为，未来的你是一个有道德权利主张的不同实体，我想说：推广这些开发规范后续一定会得到回报，特别是在凌晨 3 点有人因为你写的一行代码给你打电话时！
4. 主动重新分配“经验点”
我喜欢角色扮演游戏，尤其是《火焰徽章》和《口袋妖怪》系列，我最近还慢慢地喜欢上了《最终幻想》。
提这个是因为我认为，在《火焰徽章》中组建军队的方式和组建均衡的软件开发团队之间有很多相似之处。在 RPG 游戏中，我拥有自己的核心团队，我非常喜欢将所有角色都均衡升级。如果我获得了一个等级较低的新角色，但他有一套技能或亲和力可以给队伍做补充，我就会对他进行投资，给他升一点级，这样他就可以在地图上到处移动而不用担心敌人的攻击。如果我的角色一开始就有一个很高的等级，我就会避免让他们与较弱的敌人战斗，因为这只会占用经验点，而这些经验点会让我的低等级角色受益更多。
我倾向于认为，软件团队中也存在类似的原则，但这些经验点不是为了增加力量、防御、魔法和抗性，每一项新工作都是一个“敌人”，一旦交付，就会扩大团队的领域上下文和信心。通常，团队中是没有核心“谋士”这样一个角色的，至此，这个类比就开始变得不恰当了（主管和项目经理不算，他们通常没有足够的视野或最新的上下文信息，无论如何，把如此复杂而又动态变化的事情都集中在一个人那里是个坏主意）。如果你的团队里已经有很多优秀的骑士和圣骑士——呃，我的意思是，高级开发人员——那么作为一个团队，你应该注意，不要总是只安排他们去处理困难的工作。在健康的团队中，上下文再分配也是他们工作的一部分，这样一来，一个缺乏经验的战士——我的意思是，工程师——也可以获得一些有价值的经验点。如果每个人都觉得自己至少在某种程度上具备了应对任何挑战的能力，那么这将提高整个团队的生产力和士气。如果没有，他们知道自己可以增加一个猎鹰骑士作为副官——换句话说，向更有经验的人寻求帮助。
5. 慷慨大方地交流
关于最后一点，我想了很多。在对我的想法的所有描述中，我认为最好的是 Nat Friedman 在最近一次全体会议中所做的介绍。他说过类似这样的话：“我们彼此之间的交流应该遵循稳健性原则：发送时要保守，接收时要开放。”他还鼓励我们坚持宽容性原则，尤其是在非常困难的情况下与对方沟通的时候。但是我认为，高绩效团队会百分之百遵循这个原则。
我非常喜欢这种框架化，因为它让我想起了多年前我在 codebar 做志愿者时所经历的导师培训。“假设你接触到的每个学生都知识有限，但智慧无限。”这样一来，指导者就有责任确保他们的解释容易理解——考虑到老师和学生之间固有的权力不平衡，这是传达附加的情绪劳务的一种很好的方式。
同事之间慷慨大方地交流意味着，我们假设任何时候任何人问问题时：
- 已经做了基本的研究，如已经用谷歌进行了搜索；
- 他们是因为在任何地方都无法找到答案才找人问。因为这个地方很难找，或者根本不存在。
换句话说：假设你的同伴是一个有能力、聪明、通情达理的人，他们问问题是因为他们不了解上下文，虽然他们已经设法了解过。
当你开始寻求帮助时，你的上下文信息和工作经验被不断地“四舍五入”，我都不知道该怎么表达这是多么令人沮丧。是的，这里面有性别因素，但这超出了我们现在的讨论范围。以前，我曾发过多条推特，表达了当别人认为你实际上远没有那么经验丰富和知识渊博时的沮丧。当然，别人是不可能真正知道的，无所不知是不可能的！但是，这里有一个折中方案，也是一个合理的要求：慷慨。
像下面这样就不够慷慨：
我：嗨，这里为什么有一个负载均衡器？
X：负载均衡器用于将请求分发到多个服务上，这样我们就不会遭受 DDoS 攻击了！这里有一些文章介绍负载均衡器的基础知识，以及从理论上讲我们为什么要使用它们！
我：好的，但我问的不是这个。我知道负载均衡器是什么。我只是想了解下，在架构决策时，为什么要把 HAproxy 放在这个特定的服务前面。
X：奥！好吧，你应该直接这样问！
相反，下面这样就是慷慨的：
我：嗨，这里为什么有一个负载均衡器？
X：我猜你是在问我们为什么选择 HAproxy，以及为什么选择这些服务。如果不是的话，现在就告诉我。
我：对，就是那样！谢谢你先确认我的问题。
X：不用客气。是这样的，18 个月前，当我们构建这个系统时……
上面两种互动方式的关键区别在于，在慷慨的互动中，在给出答案之前，回答者会确认他们对问题的假设，进而核实提问者的上下文层级和意图。采用慷慨的交流方式有非常积极的影响：首先，注意到交流时所使用的词汇减少了吗？他们实际上可以更快地得到答案。其次，没有产生不必要的摩擦。两个人团结一致消除了不确定性，而不是纠结于每个人知道多少，如果是后者，也许最终他们也可以得出答案，但同时也失去了一些信任和善意。
