三个简单的规则解决棘手的团队管理问题

无论公司规模或行业如何，每家公司都会面临一些问题。比如职责分配不当和沟通不足或过多等问题都会拖慢团队的步伐。在这篇文章里，我们将分享三条简单的规则，帮助你应对这些常见的挑战，让组织重回正轨，更高效地运作。

• 单一职责
• 沟通
• 减少依赖

每个懂设计模式的开发者都听说过SOLID原则——遵循的五条简单规则来编写优质代码。这话题非常热门，以至于我写的关于SOLID原则的React文章是我最受欢迎的文章之一，尽管类似的内容已经很多了。

今天我们不讨论这些原则，但会简单提一下第一个原则，即单一职责原则。SOLID中的S就是指单一职责原则，它要求一段代码只能有一个职责。

其实原因很简单。同时管理两项或多项任务对开发人员来说很难，对计算机来说则不是问题。代码会变得难以阅读、测试和重用，同时错误的可能性也会增加。

问题不在于我们为何有这条代码规则，而是为什么公司在给员工分配角色时不会遵循这一原则呢？

再说一次，不是计算机处理起来复杂，而是人类的大脑很难理解和维护同时做多件事情的代码。

事实上，这不仅限于编程，而是更广泛的问题。一般来说，人类在同时处理多项任务方面表现不佳。因此，公司不应将两到三个不同的职责分配给同一个人。每个人都应只专注于一项工作。

恭喜你，你刚刚找到了一种让最佳和最可靠的员工快速失败的方法。

重任在肩，会议多多

蜘蛛侠开会也躲不过

## 代码审查的艺术及你为何需要它 Dennis Persson ・ 10月1日, 2023 #生产力 #Web开发 #职业 #编程

一家公司在岗位职责、工作量和所需任务方面可能安排得非常妥当，但在推出产品时仍可能表现得很糟糕。最常见原因是沟通不畅。有效的沟通对于任何公司都是至关重要的，无论大小。

在不同的层面，沟通包含许多重要的方面。为了简洁，我们将主要讲两个关键点：

1. 拉取信息与推送信息
2. 避免一个人的信息瓶颈

拉取信息 vs 推送信息

信息必须可获取。没有合适的信息，团队无法顺利工作，这会浪费大量时间。而且，信息是如何被接收的也很重要，这包括信息传递的方式（比如 Slack、邮件或者面对面交流）以及接收者是主动索取信息还是被动接收信息。

处理信息流动并没有绝对的正确或错误的方式——是应该主动推送给对方，还是应该由对方自己去查找。当接收者不了解他们需要知道的信息时，信息提供者必须主动传递。然而，如果人们知道如何找到他们需要的信息，就没有必要主动推送信息给他们。

这听起来很简单，但实际上很少这么简单。我们大多数人都会收到许多无关的电子邮件。我们中的不少人会被自动拉入不相关的邮件列表和Teams群组。

与此同时，由于信息差距，产品问题也因此出现，我们怪别人没有跟我们分享重要信息。不明白为什么没被邀请参加那些对我们工作很重要的会议。

虽然很具挑战性，这个问题还是有可行的解决方案。最关键的是要传达可用的信息。每个公司和团队都应该有一个中央位置，让人们可以找到特定的信息。这可能包括联系人列表、链接集合或Slack频道的概述。

一旦人们知道在哪里找到信息，就应该转向信息订阅模式。每个人都可以订阅他们认为重要的信息，一旦有新信息，他们就会收到通知。

这里有一个虽然很小但是至关重要的细节必须提及——你必须让所有员工都能接触到这个信息源，确保他们知道怎么找到并使用它。如果他们不清楚这一点，他们就什么信息都没有了。

避免单点通信瓶颈

大公司有许多角色，每个角色都有特定的责任。例如，产品所有者（PO）对其产品负责。虽然重要的是PO需要对产品了如指掌并时刻关注产品动态，但这并不意味着所有产品相关的沟通都必须通过他们传递。

PO需要与许多利益相关者互动。在大型组织中，他们可能与功能负责人、系统验证工程师、设计师等沟通。作为开发人员，我们应该直接和这些利益相关者打交道，而不是让所有事情都通过PO来转达。

如果所有信息都必须通过PO，将会形成一个严重的瓶颈。跟扩展生产环境中的硬件资源一样，沟通也应横向扩展，而不是纵向扩展——换句话说，团队成员之间直接沟通要比通过某一个人来传递信息更好。

## 你为什么不应该成为一名反应式开发者 Dennis Persson 2022年10月9日 #webdev #programming #productivity #beginners

几年前，我相信沟通是大公司成功的关键因素之一。但后来发现，光有良好的沟通还远远不够，另一半则是减少依赖。

我可以继续讨论沟通的重要性，但实际上，沟通常失败。关于沟通的书籍会告诉你，沟通是双方之间的共同责任，但在实际操作中往往会出现问题，并且在传递过程中会遇到各种干扰。虽然这个理论是对的，但沟通最终还是会失败，而且往往是彻底失败。

其中一个导致失败的原因是信息保留不佳和跟进不足，而不仅仅是沟通不畅的问题。学习金字塔模型，很好地说明了这一点，是一种展示不同学习方法记忆保持率的视觉模型。

学习金字塔图

正如你所见，人们只会记住他们听到的5%，这意味着你的同事会忘记你告诉他们内容中的19个中的20。他们大约只会记住他们读到的内容的10%，所以即使你发Slack消息，也得每条重复发十次。

结合听、看、读可以稍微提升记忆。小组讨论（即：昂贵的聚会）可以达到50%的保留率。然而，由于一半的参与者可能都在玩手机，实际的记忆率会远远低于这个数字。

看到这个模式了吗？沟通虽然必不可少，但效率低下。唯一避免误解、丢失消息和信息永远无法到达目的地的方法是消除依赖——通过完全消除沟通的必要性，从而实现绝对的安全，确保信息不再迷失。

对于可能疑惑我们为何如此重视人际互动的开发者们，让我们回到技术方面的话题。想象一下你遇到以下情况：

• 再也不用向其他团队请求新功能了
• 再也不用因为其他团队的 bug 而被卡住了
• 再也不用因为 PI 规划失败而错过交付了
• 再也不用指导其他开发人员如何实现 API 了

这不仅是沟通问题，而是沟通上的依赖性，应该尽量减少甚至消除。毕竟，谁不想让自己的 API 简洁高效呢？

## 如果电影角色都有领英档案，会怎么样？ Dennis Persson ・ 2022年9月4日 #笑料 #工作 #Web开发 #设计

如何摆脱依赖

"但是丹尼斯，你不能只是通过不沟通来解决所有问题，那样确实很荒谬。确实很荒谬。但是你可以尽量减少需要沟通的情况。当然，你可以尽量减少这种情况。"

一个好的架构师会考虑这些因素。他们会识别重要的数据流，并确定哪些通信是必要的，确保服务只在必要时通过简单的、易懂的渠道进行通信，更倾向于基于订阅，而不是推送或定期轮询的方式。

同样的原则也应适用于团队和管理结构。应减少不必要的团队间沟通和依赖关系。实际上，这可以通过几种方式来实现：

• 通过在团队间转移职责和产品
• 通过实施适当的团队结构（跨功能团队、独立团队等）
• 通过确保团队自我组织，负责自己的工作，而不是询问他人该做什么
• 通过让团队成员订阅他们需要的信息，而不是被不相关的信息淹没
• 通过明确职责分工，让每个人都知道自己该做什么
• 确保每个人只负责一项任务（减少他们可能的依赖关系）

你的公司是否有功能被其他团队限制？那么第一个选项中的解决方案可能正是你需要的话，让被限制的团队接管阻碍他们的依赖关系。

你的测试人员是否因为开发人员没有充分测试软件而导致问题在开发和测试团队之间来回传递而感到忙不过来？第二个团队结构的问题可能就是你的答案。毕竟，如果没有专门的团队来跟进这些问题，哪个测试团队会不觉得压力山大呢？

问题仍然会存在，但测试工程师可以直接凭借更具专业知识来验证它们，无需查阅需求文档来理解每个应用程序的工作方式。我们不期望开发人员同时处理几十个应用程序，我们又怎能要求测试人员做到这一点呢？

虽然多技能团队和自主团队听起来相似，但它们在含义上有区别。多技能团队负责涉及多个部门的工作（如开发、测试、生产监控等），而自主团队则自己安排任务，而不是等待上级的指示。

作为自我组织的团队，可以减少与公司其他部门的沟通和互动，同时有利于建立一个很强的团队，这个团队对他们的产品有控制权。

关于第四点：你们有多少邮件真正吸引你们的注意？你们会仔细阅读Slack或Teams中的频道吗？反过来，又有多少人真正阅读了你们在general频道的消息？

事实是信息量太大，人们自然会把注意力集中在与工作相关的信息上。正如我们之前讨论的，人们应该去找他们需要的信息，并订阅相关的更新。唯一需要的沟通就是解释如何找到这些信息的方法。

最后，关于明确职责，每个人只负责一项任务，这又让我们回到了单一职责原则的起点。每个人应当只执行一项明确的任务。为什么？正如之前在沟通部分提到的，当一个人需要处理过多信息时，信息会滞留在他们那里，而不是送达预期的接收者。

减少个人的职责可以减少依赖性，确保信息能够正确地传达，并让人们能够专注于他们真正的工作职责。

我以前是老师，撰写关于软件开发及其相关话题的文章。我希望能为世界各地的人提供既有趣又有教育意义的文章。