在本章中，我们将探讨在开始使用 Erlang 时，如何最佳地组建团队以取得成功。我们讨论的不是工具，而是团队成员。不用担心，您不需要解雇或替换任何人；但是，您需要在目前缺乏专业知识的新领域建立专业技能。
我们将提供两种主要方法：围绕专家构建团队或内部培养专家。我们还将探讨远程团队的主题。
一条在所有情况下都很有价值的建议是：首先选择那些愿意并渴望学习新技术（在本例中为 Erlang）的人。您无法强迫人们违背意愿学习，但绝对可以帮助那些愿意学习的人。
围绕专家构建团队
获得新技术或新业务领域专业知识的最简单方法通常是聘用拥有该专业知识的人员。不幸的是，这本身并不能真正解决您的问题；您将依赖您的专家来处理所有事情。这最终会导致所有更改都通过系统传递时出现瓶颈，当您的专家休假时，会导致巨大的速度下降。
聘用专家
在本节中，我们或多或少地假设您知道如何自己找到专家，并将重点放在团队结构以及确定此类专家需要帮助您解决的问题上。有关实际招聘人员的帮助，我们将添加一个“如何招聘”章节，以帮助澄清这些问题。
在撰写本文时，行业内的平均任职时间低于 5 年。这意味着一个希望可持续发展的团队将不断聘用专家，而没有尽头。关键是在找到第一位专家后培养自己的专家。我们认为，公司能够持续招聘更多初级员工，并见证他们在多年后离开成为专家，比一直挖角专家和高级员工，然后看到他们同样离开要健康得多。
请不要误解，我们并不是反对专业知识。我们是在支持它：专业知识非常重要，您应该专注于内部培养它。无法提供有助于员工成长的环境的公司，将受制于竞争对手为他们做这件事。因此，围绕专家构建团队意味着专家是您构建团队其他成员的合作伙伴。事实上，团队的其他成员也应该意识到这一点，以便他们树立正确的思维方式，并确保从中获得最大的收益。
这应该是一个他们充分了解的角色，并且您会随着时间的推移与他们讨论。预期应该是您从专家和组织中最热衷于学习 Erlang 的人员开始缓慢地进行。在最初的几周内，您的专家的角色主要是向您的员工提供他们入门所需的必要基础知识。这通常遵循大多数初学者书籍的模式：基本的语法和数据类型，教授递归和编写小型模块，展示他们如何测试代码，然后慢慢添加多处理和 OTP 行为。
一旦您的团队开始对基础知识感到足够舒适，您就可以让您的员工开始着手他们想要长期编写和维护的系统的第一个原型。一个有趣的方法是实际上将第一个原型用作培训设置，仅此而已。船上的每个人都知道原型并非旨在投入生产，如果它真的投入生产，路线图上的第一件事是在您获得适当经验后替换它。
但是，原型很重要；通过选择他们熟悉的问题，它成为一个测试平台，您的员工可以在其中自由地进行实验，以便对语言及其特性感到满意。这为他们提供了重新审视其领域知识并将其教授给专家的机会，而专家则与他们一起找出如何在 Erlang 的上下文和语义中重新构建他们所知道的知识。希望这将有助于他们在他们之间建立融洽的关系和默契，其中关系从“培训师和受训者”转变为只是很多人互相教授东西。
在进行此原型设计工作时，您的专家应该开始引导您的团队走向更广泛和更复杂的概念：开发容错能力（如何正确构建监督树？），构建和部署 OTP 版本，以及最后与性能相关和生产调试问题。
我们最喜欢的实验之一是让专家指导团队构建他们自己的监督结构，理想情况下使用团队一直在使用的原型。
- 从团队已识别的各种组件（Web 服务器、连接处理程序、编码器/解码器、配置管理器等）开始，并在白板上绘制它们。
- 绘制组件之间的通信通道。突出显示消息传递或网络通信发生的位置。
- 询问每个通信通道“我们是否预计它经常会失败，如果失败会发生什么？”。让团队意识到系统中存在故障的可能性。
- 对于每个故障，询问每个组件持有的状态应该如何变化。它是暂时的吗？是否允许丢弃？可以重建或从某个地方获取吗？
- 在可能发生故障的组件上方插入监督程序，并假设在每个故障后，每个组件都从可预测的非动态状态（监督程序传递的初始参数）开始。
- 迭代地重新设计组件并重新构建它们；将您无法承受损失的状态从更容易预见故障的框中移出，并考虑在每次重新启动时信息如何传输到那里。
在这个练习中，我们看到了关于 Erlang 最多的“顿悟”。团队突然意识到他们已经积累了足够的理解，可以重新构建和重新构建他们设计软件的整体方法。他们开始使用 Erlang 虚拟机和 OTP 框架独有的功能，并以不同的方式构建，利用新的功能。即使您的一些开发人员放弃了 Erlang 并回到他们之前的工作，他们也可能会将这种如何构建事物的方法的经验应用到旧的地方。我们听说过人们这样做，并说他们在尝试过之后对他们的 C#、Go 或甚至 Ruby 设计有了不同的思考。
一旦您认为他们理解了，请要求整个团队使用他们现在所掌握的知识重新设计原型。他们可以保留一些组件并重复使用它们，但他们绝对不应该对丢弃其中很多感到难过，您也不应该感到难过：您将用一些经验丰富的人员编写的代码替换由几乎完全的初学者编写的代码。作为回顾，比较他们在原型中所做的工作与他们在最终产品中得到的结果很有趣。
完整的学习实验可能需要几个月的时间，但即使在几周后，您也可能会看到一些非专家员工慢慢地获得信心并开始帮助他人。您的专家知道您希望他的专业知识传播，因此实际上应该鼓励这种行为，并开始将更基本的问题委托给他人。然后，向更成熟和功能齐全的团队过渡将开始进行。人们将互相教授各种主题；您的专家越来越不需要专业知识——可能仅适用于越来越罕见的棘手问题——然后他们可以自由地以更平等的姿态参与项目，或者开始转移到您拥有的其他团队，这些团队也希望采用该技术。
提示
无论您在那时如何运作，请确保您的专家不时与团队的其他成员坐下来，并询问他们遇到的各种摩擦点。找出他们对工具、语言等的哪些方面感到烦恼。这将帮助每个人重新校准和改进事物。否则，新手经常会认为“就是这样”，他们最终可能会忍受比他们原本应该忍受的更多的烦恼。
在没有专家指导的情况下构建团队
在没有专家指导的情况下构建团队肯定有点棘手。这并非不可能（有些人不得不自己成为专家才能开始），并且有很多资源可用——书籍、演讲、论坛、聊天室等等——但这绝对更具挑战性，并且成本可能更高。在没有专家指导的情况下构建团队的最大风险是，您可能不知道要在错误的路径和错误的途径上花费多长时间，而且早期学到的错误知识可能会持续更长时间。
从根本上说，这与常规开发并没有太大区别，但您将自愿朝着这个方向前进。因此，您可能希望以稍微不同的方式构建事物。与其选择一位专家和您的热心员工，您希望将需求和角色扩展到每个人，以尝试获得专家本来会促进的动态。
确定具有函数式编程语言先前知识的人员；他们不会知道所有内容，但他们已经有一个先发优势。还要确定一些自主学习者，那些喜欢坐下来钻研某件事的人。他们的工作是在其他人之前几周阅读书籍并弄清楚事情；他们实际上是钢琴老师，只是比您早了几周。您需要找到一个喜欢教学、编写文档或准备演示的人。这通常很困难，因此如果您找不到任何人，则为该职责分配轮换时间表。让他们负责进行更广泛的信息传播、维护文档以及快速“入门”指南，了解您在组织中所做的事情。
让每个人都进行一些开发并习惯语言的感觉，参与社区中的事务，并利用现有的代码。以下是一些想法
- 研究现有代码，并展示各种库及其方法；深入研究以了解它们的结构。
- 如果您无法弄清楚开源库为什么执行其操作，请随时在问题中询问其作者，或在 Slack、邮件列表或论坛上询问其他人。获取真实的答案，并将其展示出来。
- 对您编写的代码进行代码审查，主要目标是让每个人讨论一些您（迄今为止）尚未达成一致意见的事情。这可能包括语法和对齐方式，但更有可能包括诸如文档编写程度、您更倾向于标准化的更好的测试方法等等。
- 当您遇到难题时，可以进行快速交流，以确定哪些方法可以解决问题，您将如何进行实验，最后确定如何做出决策以继续前进。
- 进行实验报告；如果您的团队中有一些人处理了一些棘手的问题，让他们进行汇报并与其他人分享他们的经验。
您还需要在线寻求帮助。答案可能很慢，但最终会得到回应。StackOverflow还可以，但从未真正成功地为Erlang培养出一个社区。更具互动性的区域（例如 Slack、IRC、邮件列表、论坛）往往拥有更持久的成员，并且能够更好地确定您实际需要什么。请记住，新接触某项技术的人员总是面临着 XY 问题 的风险，您的团队也一样。
如果您遇到了一些难以克服的问题，或者感觉您需要一位更专业的专家来确保您走对了方向，另一种选择可能是聘请顾问或咨询公司工作一到两周，以回答您最大的问题并帮助解决您最突出的问题，这可能比寻找和聘用专家要省事。
是否采用远程工作
Erlang 及其社区的问题在于，寻求工作的人总是多于招聘的人，而与此同时，招聘的人却找不到合适的员工。这本质上是由于 Erlang 开发人员和 Erlang 公司的地理分布并不一定一致。想要 Erlang 工作的人和想要 Erlang 开发人员的人往往不在同一时间同一地点。
选择远程员工意味着找到专家或熟练的 Erlang 工程师会容易得多，并且他们能够利用自己的网络吸引更多人加入。然而，这确实会带来习惯上的改变，在经历了 2020 年全球 COVID-19 大流行之后，这可能成为大多数科技公司尝试过一段时间的事情。
因此，在这方面的最终选择将取决于您管理团队的偏好；直接可用性可能是促使您聘用远程员工以更快地为您的团队添加专业知识的因素；世界上大多数地方都没有现成的 Erlang 专家随时准备在其当地市场为他们工作。在获取外部市场的人员来快速帮助您方面，可以节省大量的时间和成本，尤其是在与从头开始做所有事情并开发自己的内部专业知识（没有直接帮助）的替代方案进行比较时。
此类节省可能需要通过改变团队的工作和沟通方式来实现。如果您目前没有进行远程或分布式工作，并且您的专家将是唯一的远程人员，这也对您的专家提出了挑战；作为团队中唯一的远程人员可能会特别孤立，保持他们的积极性可能会变得复杂。
下一步
因此，我们已经广泛地介绍了如何在专家的帮助下或在没有专家帮助的情况下开始工作以及如何构建团队。在所有情况下，都应注重学习、培训和培养团队。这是一个健康的模式，无论您是远程工作还是全部在现场工作，它都是健康的。
在涵盖了这些广泛的要点后，我们可以开始探讨无论您采用哪种方法都需要实施的流程和实践。