团队业绩不佳，对团队成员而言都是个失败。下面介绍如何排查问题根源，并着手解决这些难题的方法。
译自 5 Steps to Debug Development and Operations Teams，作者 Charles Humble 是一位前软件工程师、架构师和CTO，担任过技术和内容组的高级领导和执行官。他于2014-2020年担任InfoQ的总编辑，并于2020-2023年担任Container Solutions的首席编辑......
我最近进行了一系列免费的在线导师课程，其中一个反复出现的问题是，"作为CTO，当你认为一个团队的表现不佳时，你会怎么做？"
我们都知道，衡量开发者的生产力是很困难的，但是听同事说某个团队的工作经常晚交、不可靠或质量不高，这种情况并不罕见。
这些生产力问题不仅仅发生在开发者身上。事实上，Atsign的工程师兼DXC Technology前交付CTO Chris Swan告诉The New Stack，"我们经常在运维团队看到这种情况，所以我们制定了一个重复的流程来处理它。"
严格来说，团队表现不佳是团队经理的责任。作为经理的经理，你的角色是提醒相关的团队负责人可能存在表现问题，并让他们解决它。
但是，这也是一个很好的机会来指导经理并帮助他们成长，如果你发现一个经理正在挣扎，或者他们主动寻求帮助，我认为直接参与也是可以的。
Swan也表示赞同。他告诉我们，"我们不能合理地期望线性经理在这方面有经验，所以如果他们需要帮助或者CTO或工程副总裁积极提供指导，给经理一套工具来帮助他们处理这些情况，这是完全合理的。"
值得一提的是，经理听到太多投诉，很难知道该关注哪些而忽略哪些。这带来的副作用是，你可能会发现，在一线工作的员工会知道问题出在哪里，并且之前已经提出过，所以你的部分工作就是给他们和他们的经理足够的支持和资源来进行必要的改变。
Swan 告诉我们，“很多时候我们在为一线员工获取他们需要的管理层支持。”
以下是发现一个团队表现不佳的原因的 5 个实用步骤。
我使用“团队调试”这个词来指调查表现不佳团队的过程，当我读 Camille Fournier 极好的书《经理之路》时，很高兴地发现她使用了相同的比喻。
Fournier 建议从一个假设开始，就像在调试系统时一样。她说道，“用尽可能最小的侵入方式做这件事，以防你的干涉掩盖问题。”
我自己的方法虽然与 Fournier 书中描述的类似，但首先是从数据中寻找信号，并用它们来指导一个初步的假设。我也设法记住诗人沃尔特·惠特曼的谚语，“保持好奇，不要批判。”
值得检查的好数据包括流失率 —— 相较于 IT 部门的其他部分，是否有很多人离开这个特定的团队？你能得到病假数据吗？如果能，团队成员的病假是否比部门其他地方更频繁？
这些并不一定是明确的证据，但它们可以给你一些关于可能出了什么问题的想法。请记住，即使在这么早的阶段，泄密也会惊人地快。尽量用询问的方式来表述你的问题，这样不太容易暴露你在寻找什么。
我接下来倾向于看看日历。经理是否定期进行一对一会议？团队在会议上是否花费了太多时间？
然后，Fournier 也建议，查看其他记录系统——聊天日志、电子邮件、任务工单、代码审查和签入，看它们告诉了你什么。
团队成员是否“在代码审查评论中就编程风格争论不休”？Fournier 问道。“写的任务工单是否模糊、太大、太小？团队在交流方式上是否显得热情高涨，在聊天中分享有趣的事情以及重要的工作，或者他们纯粹讨论业务？”
对于运维团队，很多注意力会放在服务管理日志上。但是根据已故的业务管理专家 Eliyahu M. Goldratt 在《目标:持续改进过程》一书中提出的约束理论，前面提到的 DXC 流程涉及获取所有服务日志，然后应用数据科学来识别约束。
Swan 告诉我们，这种方式“让我们能够关注当时最重要的事情”。解决约束最终是一种迭代过程，你解决顶层问题，然后重新测量。
“我们每次改变都小心重新测量，因为我们改变了一个动态自适应系统的运行特性，”Swan说。
根据他的说法，某些约束会经常出现: "我们经常看到的一个是工单乒乓，没有人对解决问题负责，而是把它转给其他人。"
在这种具体情况下，你要查找的是某种方式，让人们对解决问题负责，并有权力去做。
授权的问题又回到了经理身上。“我们发现一线员工感到沮丧，因为他们能看到需要做什么，但认为他们不允许去做。” Swan说。“有时这需要你查看诸如角色定义和工作说明之类的软性方面，但它也可能让你进入诸如身份管理和授权之类的硬性方面。”
Swan强调的一个特定问题是网络安全；从本质上讲，访问已被限制以防止发生不好的事情，但作为直接后果，服务代理无法解决问题。
解决这个问题需要“非常仔细的风险管理方法，这可以通过更好的系统来支持，”他说。“因此，例如，如果你可以为特权访问管理提供一条破窗的路线，那么你就不会处于员工不断拥有'神一般'凭证的情况，但当他们需要的时候可以获取到。”
另一个常见的问题源是交接。尽可能减少交接并确保在交接时它们是完整的总是很好的。
这通常出现在外包的上下文中。因此，例如，如果系统管理团队在内部，但网络团队已外包，"系统管理团队会说，'我们提出了工单，但没有任何反应'，网络团队会说，'我们收到的每张工单都是不完整的，因此我们无法对其采取行动'，"Swan说。
"这里需要有人介入，澄清两个组织之间的接口，以便高质量的信息可以跨越那个边界。"
有时数据似乎没有指向任何东西，这意味着你必须使用另一种方法。艰难团队的表现很少是单一失败点的结果(尽管我确实见过一个非常糟糕的经理摧毁一个非常好的团队)。所以接下来要看的就是团队动力。
如果你还没有这么做，团队负责人也没有接触你，那么与他们交谈。如果你和他们位于同一地点，也许可以一起喝杯咖啡。
我经常在散步时举行这种类型的会议(包括远程，我们两人一起在电话里散步交谈)，并发现环境的变化可能会有帮助。证据表明，散步可以释放创造力，但在可能令人压力的讨论情况下，我也发现它很有帮助。
这时候要直截了当、直接，请避免“表扬三明治”，有时称为更粗鲁的词语。(“你的头发看起来不错。你的团队表现不佳，我认为可能是你的错。鞋子不错。”)这对任何人都没有帮助。
明确表示你已经听说这个团队的表现可能不佳，如果是这样，你在这里是来提供帮助的。经理自己怎么看？你能做些什么来支持他们？
如果你定期进行跨层级一对一会议(如果你还没有，我强烈建议你开始这种做法)，这可能是一个与团队成员进行一次的好时机。试着深入探讨一下;有什么不对劲的地方吗？
我看到的经理的一个常见反模式是他们不参加一对一会议——可能在最后一刻发短信取消。或者经理不回复Slack上的消息。
另一个常见的反模式是有人仅将一对一会议用于无聊的状态更新，不花时间与下属讨论对他们真正重要的事情，比如职业规划、抱负或任何更有趣的事情。所有这些都可能是缺乏动力的原因。
另一种策略是参加团队会议，但要记住，由于你在场，团队动态会发生变化。在这里值得思考的好东西包括，房间里的能量如何？人们是否看起来参与其中，或者漠不关心？大部分时间是谁在说话？员工无聊吗？你无聊吗？
如果一个团队不参与进来，那通常预示着有更深层次的问题。从看日历你可能已经有一个想法，就是简单地开太多会议。
另一个常见问题是团队感觉无法影响他们的工作或制定自己的方向——与Daniel Pink在他的管理书《驱动力》中所说的“自治、掌控和目的”作为激发人们内在动机的框架相反。
一个典型的症状是团队负责人正在做所有的谈话。
Fournier在她的书中也建议问问团队他们的目标是什么。“他们能告诉你吗？他们理解为什么这些是目标吗？如果他们不理解他们工作的目标，他们的领导(经理、技术负责人、产品经理)在让团队参与工作目的方面做得不好。”
最后一件要考虑的事情是团队安全。“当我看一个艰难团队时，我的一个主要问题是，'这些人是否在一个安全的环境中工作？'” Swan说。“这有一个心理安全方面——如果他们犯了错误，这是一次学习的机会还是责怪他们？”
Swan说，还有一个更实际的方面，那就是允许犯错误但可能会造成损害的后果，但这可能会被预防。作为一个例子，他谈到在没有分支保护的情况下使用主线开发。
“分支保护是一项基本的安全措施，但它不是默认的，”他说。“没有它，时钟正在倒计时，直到有人在不应该的时候强制推送到主干。”
一个不理解这一点的团队可能也太缺乏经验，不知道如何解决它。这就是一个有经验的经理可以起到巨大作用的地方。