当一个开发团队从一个团队扩展到两个团队时，挑战是什么？

Question

我在一家中小型创业公司工作，拥有一个20人的开发团队和一个非常强大的工程文化。工程本身被分成较小的子团队，而我是唯一负责某个特定组件的人(这对整个组织来说非常关键)。

我们现在终于找到了另一个工程师，开始和我一起工作，这很棒，对我有很大的帮助，但是随之而来的挑战是离开一个单独的开发团队。

在团队中增加第二个工程师时，存在哪些挑战？我已经看过这个问题了，公认的答案意味着拥有一个good onboarding process，但实际上并没有详细说明这意味着什么。我更感兴趣的是了解我应该每天改变什么样的事情，以确保这种转变是成功的。

Answer 1

从本质上讲，这一切都归结于沟通。

如果你是唯一一个在一个项目上工作的人，你不需要像一个团队那样记录这个项目。要么你根本不写文档，相信两年后你会记住所有的事情，要么你从自己的角度去做。这给新来者带来了几个挑战：

• 可能对你来说很清楚的配方对另一个人可能就不那么清楚了。
• 假设可能是完全没有根据的。对你来说，这些假设是自然的。另一个人可能不认为他们是天生的，或者认为他们完全错了。
• 您在设计或体系结构方面所做的选择可能没有明确的文档记录，因为您是唯一接受这些选择的人。当团队做出选择时，就会进行讨论，从讨论中可以比较容易地编写文档，解释为什么这样的事情是以给定的方式完成的。您可能没有与自己进行讨论，所以您可能只记录了选择本身，但没有说明选择的原因。
• 代码中对您来说很明显的事情可能没有文档化。如果这些事情对另一个人来说都是显而易见的，那就是一个问题。当你知道别人不知道的事情时，这种情况可能会发生。例如，如果你很擅长反应式编程，但另一个人却不是，他会期望记录两行以上的反应性表达式，而你绝对不明白记录代码中很容易理解的东西的意义。

除此之外，新来者还将面临另一个困难：

• 历史因素。你的项目是因为某一时刻发生的事件而发展起来的。你知道的，所以有很多事情不需要你去解释。您知道您使用的是XML而不是JSON，因为其他服务有一个JSON序列化程序的错误实现，两年前的新年前夕，它使您的产品崩溃。但是，新来的人对这一创伤性事件一无所知，可能认为没有理由使用XML，而且可以很容易地切换到JSON。

因此，您的目标是与新开发人员密切合作，并对任何问题开放，无论这个问题在您看来多么愚蠢。成功在很大程度上取决于你是否有能力清晰地回答问题，并花时间对新来者最令人惊讶的事情进行适当的记录。

Answer 2

除了阿尔塞尼的回答:确保所有在登机前应该提供和正确的文件在登机后至少是可用的和正确的。新人的第一份工作。

你可能需要更有组织的代码评审，任务列表，决定谁开始什么工作等等。

Answer 3

首先，尊重阿塞尼已经写好的每一件事。

我想说的另一点是个人的做事方式:我假设你是一个人，你有自己的解决问题的风格，你的风格接近你的工作和你的代码风格。

到目前为止，软件已经达到了你所能做到的100%。

现在，另一个人将有他的风格和他的方法等等。如果你一直都是一个7人团队的成员，你就已经习惯了其他人的方法，但是你将不得不面对这个项目不再是100%的你。

所以，请不要因为假设只有一种方式来做事情而让新同事失望。处理其他方法。不要急于重写他所做的一切，以适应你的个人方式。只有当解决方案在客观上明显错误时才拒绝(例如，因为他使用了一个循环，您可以在其中使用流或相反的方式)。