后端开发教程 - Java、Spring Boot 实战 - msg200.com
解决组织难题的三条简单规则
无论规模大小、所属行业如何，每家公司都会面临一些问题。职责分配不合理、沟通不畅或不顺畅等问题都会拖慢团队的进度。本文将探讨三条简单的规则，帮助您应对这些常见挑战，让您的组织步入正轨。
在本文中
单一职责
每位了解设计模式的开发者都听说过 SOLID 原则——编写优秀代码时要遵循的五条简单规则。这是一个非常热门的话题，以至于我那篇关于React 中 SOLID 原则的文章，尽管市面上有很多类似的内容，却依然是我阅读量最高的文章之一。
我们今天不打算研究这些原则，但我们会简要介绍第一个原则，即 S。SOLID 中的 S 代表单一职责原则，它规定一段代码应该只有一个职责。
背后的原因很简单。同时管理两个或多个任务很困难——不是对计算机而言，而是对开发人员而言。代码变得更难阅读，更难测试，更难重用，而且引入 bug 的可能性也会增加。
问题不在于为什么我们有这条代码规则，而在于为什么公司在为员工分配角色时不遵循这一原则？
我再说一遍，运行同时执行多项操作的代码并不麻烦，而是人类的大脑难以理解和维护它。
事实上，这并非代码独有。通常来说，人类不擅长同时处理多项任务。就是这样。因此，公司不应该让同一个人承担两到三项不同的职责。每个人应该只做一项工作。
你是否是一位经理，最近刚刚给你最优秀、最可靠的员工分配了新的职责？恭喜你，你找到了让他们失败的最快方法。
责任重大，会议精彩
沟通
一家公司可能已经把所有角色、工作量和所需任务都安排好了，但在交付产品方面却惨败。其主要原因往往是沟通不畅或沟通不畅。有效的沟通对任何公司都至关重要，无论其规模大小。
不同层面的沟通有很多重要方面。为了简洁起见，我们将重点关注两个关键概念：
- 拉取信息与推送信息
- 避免单人沟通瓶颈
拉取信息与推送信息
信息必须可用。缺乏适当的信息，团队无法有效工作，从而导致大量时间损失。然而，信息的接收方式至关重要。这不仅包括媒介（Slack、电子邮件或面对面沟通），还包括接收者是主动请求信息还是被动接收信息。
处理信息流的方式没有绝对正确或错误——无论是应该推送给别人，还是让别人自己去寻找。当接收者不知道他们需要知道的信息时，信息持有者必须主动分享。然而，如果人们知道如何获取他们需要的信息，就没有理由把信息推送给他们。
这听起来很简单，但在实践中却很少奏效。我们大多数人每天都会收到大量不相关的邮件。许多人被自动分配到与我们无关的邮件列表和 Teams 群组。
与此同时，由于信息不畅，产品出现了问题，我们却责怪别人没有与我们分享重要信息。我们不明白为什么那些与我们工作息息相关的会议竟然没有邀请我们参加。
虽然这个问题很有挑战性，但也有可行的解决方案。最重要的一步是沟通哪些信息可用。每个公司和团队都应该有一个中心位置，方便大家找到特定信息。这些信息可能包括联系人列表、链接集合或可用 Slack 频道的概览。
一旦人们知道在哪里可以找到信息，方法就应该转向信息订阅模式。每个人都可以订阅自己认为必要的信息，这样，只要有关于该主题的新信息，他们就会收到通知。
不过，这里有一个小细节必须提一下——你必须把这些信息来源推送给所有员工，确保他们知道如何查找和使用。如果他们不知道，他们就无法获得任何信息。
避免单人沟通瓶颈
大型公司有很多职位，每个职位都有特定的职责。例如，产品负责人 (PO) 负责其产品。虽然 PO 了解其产品的一切并随时掌握最新动态很重要，但这并不意味着所有与产品相关的沟通都需要通过他们。
产品负责人 (PO) 与许多利益相关者互动。在大型组织中，他们可能与功能负责人、系统验证工程师、设计师以及其他人员沟通。作为开发人员，我们应该直接与这些利益相关者沟通，而不是将所有事情都交给 PO。
如果所有信息都通过产品负责人（PO）传递，就会造成严重的瓶颈。就像在生产环境中扩展硬件资源一样，沟通也应该水平扩展，而不是垂直扩展——这意味着团队成员之间进行多次直接对话比将所有信息都集中到一个人那里更好。
依赖消除
几年前，我坚信沟通是大公司成功的关键。然而，事实证明，沟通只是关键的一半，另一半在于消除依赖。
我可以继续讨论沟通的重要性，但事实是，沟通总是失败。关于沟通的书籍会告诉你，沟通是发送者和接收者共同的责任，但传输过程中会存在各种干扰。虽然这个理论是正确的，但沟通最终会失败，而且往往是巨大的失败。
除了沟通不畅之外，造成这种失败的原因之一是信息保留不力以及后续行动不足。学习金字塔是一个直观的模型，可以显示不同学习方法的保留率，很好地说明了这一点。
学习金字塔
正如你所见，人们只能记住他们听到内容的5%，这意味着你的同事会忘记你告诉他们的20件事中的19件。他们能记住他们读到内容的10%左右，所以即使是在Slack上写消息，你也需要把每条消息发给他们十遍。
结合听觉、阅读和视觉元素可以在一定程度上提高记忆力。小组讨论（也就是昂贵的会议）可以达到50%的记忆力。然而，由于一半的参与者可能会查看手机，有效记忆力会远低于这个数字。
发现这个规律了吗？沟通至关重要，但效率低下。只有一种方法可以避免沟通不畅、信息丢失以及信息无法到达目的地：消除依赖——这是避免沟通的万无一失的方法，因为它完全消除了沟通的必要性。
对于那些可能想知道我们为什么如此关注人机交互的开发者来说，让我们回到技术场景。想象一下，如果你：
- 再也不用向其他团队请求功能了
- 再也不会被其他队伍的 bug 所阻碍
- 从未因 PI 计划失败而错过交货
- 无需向其他开发人员解释如何实现 API
这些不仅仅是通信问题——它们是您应该最小化或消除的通信依赖关系。毕竟，您难道不希望您的 API 精简高效吗？
如何消除依赖关系
“但是丹尼斯，你不能就此停止沟通，解决所有问题，那样太荒唐了。” 是的，确实荒唐。但你可以尽量减少沟通的需要。
优秀的架构师会考虑到这一点。他们会检测重要的数据流，并确保服务仅在必要时通过简单易懂的渠道进行通信，最好是基于订阅而不是推送或定期轮询。
同样的原则也适用于团队和管理结构。应该消除团队之间不必要的沟通和依赖。实践中，可以通过以下几种方式实现：
- 通过在团队之间转移职责和产品
- 通过实施适当的团队结构（跨职能团队、孤岛等）
- 确保团队自组织，承担工作责任，而不是询问别人该做什么
- 让人们订阅他们需要的信息，而不是用不相关的信息淹没他们
- 通过明确职责，让人们知道谁应该做什么
- 确保每个人只承担一项责任（减少他们的依赖程度）
你的公司是否有被其他团队阻止的功能？那么第一个要点中的解决方案可能就是你所需要的：让被阻止的团队承担阻碍他们的依赖关系的责任。
你的测试人员是否因为开发人员没有充分测试他们的软件而感到不知所措，导致错误在开发和测试团队之间来回传递？关于团队结构的第二点或许能解答你的疑问。毕竟，如果没有一个单独的团队来报告错误，哪个测试团队会不堪重负呢？
Bug 仍然存在，但测试人员可以凭借对测试内容更深入的了解直接验证这些 Bug。他们无需费力寻找需求来了解每个应用程序的工作原理。正如你不希望开发人员开发数十个应用程序一样，测试人员又何必如此呢？
虽然跨职能团队和自组织团队听起来很相似，但含义上却有所不同。跨职能团队处理的工作通常跨越多个部门（开发、测试、生产监控等），而自组织团队则负责管理自己的任务，而不是等待经理的指令。
通过成为一个自组织的团队，可以减少与公司其他部门的沟通和互动，同时还可以建立一支能够控制其产品的非常强大的团队。
关于第四点：你的邮件中有多少是真正让你感兴趣的？你仔细阅读了多少个 Slack 或 Teams 频道？反过来，有多少人真正在普通频道里阅读了你的消息？
现实情况是，信息太多了，人们理应关注与工作相关的信息。如前所述，理想情况下，人们应该搜索自己需要的信息并订阅相关更新。唯一需要沟通的应该是解释如何找到这些信息。
最后，关于职责明确且每人只负责一个任务的最后两点，让我们回到了我们最初提出的单一职责原则。每个人都应该有一项明确的工作。为什么？正如在沟通部分所讨论的，当人们处理过多的信息时，就会成为瓶颈。信息会被卡在他们身上，而不是到达预期的接收者。
减少个人责任可以减少依赖性，确保信息到达正确的目的地，并允许人们专注于他们实际被雇来做的事情。
文章来源：https://dev.to/perssondennis/ Three-simple-rules-to-solve-unsolvable-organizational-problems-3o3n