许多其他大型IT公司都是从一家初创公司开始的，Badoo也不例外。近年来，该公司已从数十名工程师增加到数百名工程师。 尼古拉·克拉普尼 （ Nikolai Krapivny ）在这条道路上走在最前沿，并做出了以下决定：什么是最好的事情和不该做什么，如何处理问题。他关于TeamLead Conf的报告致力于这种体验以及由此产生的世界图景。

当然， 每个公司都有自己的方式 ，但是人与人之间的交流问题对于每个人来说都是大致相同的。别人的经验将帮助您提前考虑公司发展所面临的问题。即使这些值不直接适用，也会告诉您如何思考。

故事分为三个部分。首先是关于沟通 ， 关于沟通如何随着公司的成长而变化。第二部分是关于如何随着团队中工程师人数的增加来保持开发速度 。第三部分是Badoo为什么住在两个办公室 ，以及如何应对沟通问题。

让我们开始吧！

关于演讲者： Nikolay Krapivny（@ cyberklin ）在Badoo工作了八年，其中五人参与了团队管理和开发过程。

在开始第一部分之前，我想说这是一个关于我们道路的故事，并不声称是绝对真理。每个公司都有自己的道路，但是我确信我们的经验，我们为自己形成的价值观，一些知识将帮助您发展，建立正确的流程。尽管您的特异性不同，但一切都有些不同，我希望这对您有用。

通讯技术

首先，让我们从理论上谈一谈公司成长时通讯发生了什么。

沟通涉及部门之间如何进行交互，人们如何进行交互，如何进行沟通以使公司中有所作为。

考虑一个相当老练但仍然至关重要的例子：一个抽象的启动团队。有几个人聚集在一起，有人更接近企业，而另一个人则更像技术人员。但是总的来说，这是一个很小的团队，其工作可能有一天会成为第二个Facebook。在这个团队中，所有工作都建立在沟通之上。团队很小，没有必要引入任何流程。 一切都是这样的 ：某人与某人交谈，他们同意快做某事，他们正在做。

尽管在此过程中，它完全建立在交流和对话的基础上：“让我们去做”，“让我们做得更快”，“让我们那样做”，但仍有某些问题，这样的团队无疑具有优势。

工作很快 。从构想到如何使构想对用户可用的时间非常短。想法来了，我们与某人讨论了如何更快地完成它，它已经完成，已经准备就绪。
它很灵活 。在这个小团队中，没有人会只从事特定的事情，并且在必要时无法连接到重要任务。原则上，每个人都会做所有事情，如果某些事情对我们很重要，那么每个人都会努力做到这一点。
通常，由于尚未建立这样的过程，因此这种工作非常有效。在某些流程，某些已建立的正式计划上，我们不会在管理成本上花费太多时间。

这些只是每个企业都希望看到的价值：最灵活的资源平衡，最短的上市时间和较低的运营成本。

该公司正在成长-通信“被撕毁”。

当公司发展壮大时，如果一切快速进行，互动，对话，那么小团队的优势就会成为问题。传输的信息量给通信带来的负担开始增加，我们发现通信“被撕毁” 。我们开始在交流上失去的越来越多。我们需要与太多的人交谈，在某个人与人之间传递信息时会产生误解，在某个地方我们只是失去了一些东西，在某个地方我们忘记了。后来建造的所有东西，给了速度，我们正在慢慢开始失去。

如果您推断并长时间查看公司的发展模型，那么它看起来就像一个周期。人数增加，过程负担增加，通信开始中断。以前的工作停止工作。因此，我们不得不在这些地方修理一些东西。通常这发生在部门的边界。要解决此问题，您必须规范化沟通过程。 这个循环重复了很多次 ：人数增加，某些事情开始效率低下，我们引入了新的流程，以某种方式对其进行了形式化，我们获得了新的增长动力，直到它在另一个地方破裂等等。这就像扩展系统，提高性能一样：如果增加系统的负载-最弱的元素，则最慢的部分将无法承受。我们修复（以某种方式改进）后会出现一个窗口，您可以在其中增加系统的负载。因此随着公司规模的扩大。

这只是理论上的一小部分。

现在，让我们看看我们经历了哪些周期，遇到了哪些问题以及如何解决这些问题。

职权范围

作为第一个示例，请考虑使企业与工程团队之间的关系正式化的任务。职权范围，或我们称为PRD，是对设计功能方面需要更改的要求。这是所有公司都要经历的相当明显的形式化过程。我认为你们中的大多数人都在有某种形式的正式流程来转移开发任务的公司工作。来自产品团队，企业或外部客户-没关系。

我们经历了此过程复杂化的几个部分。起初我们只是写。当团队规模扩大到只允许您通过相互交谈来开展业务的团队规模时，我们便开始将所有这些内容写在任务中。这些目标被表述为“需要做什么”。此外，产品的复杂性增加了，公司的人员也增加了，我们得出的结论是，将当前版本的当前工作系统保持在一个地方很有用。我们将所有这些移至Wiki，并讨论了Wiki注释的更改，以便所有内容都集中在一个地方。下一步是正式确定珠三角+珠三角审查程序中应包含的内容。现在，我们有了一个模板，该模板可修复PRD中必须包含的信息，应描述的内容以及在开始工作之前应收集的数据。例如，现在PRD模板包含以下块：

目标是我们为什么要执行此功能。
我们计划推出哪些平台，产品，国家。
用例格式的功能描述：主要案例+每个人都忘记的“复杂案例”的预定义列表。
令牌（由撰稿人单独处理）。
通讯：此功能是否会有电子邮件/推送通知，如果有，则通知哪些。
发布计划，取决于市场营销/公司中的其他项目。
分析：我们将如何评估结果，我们需要添加哪些业务指标来评估变更是否成功。

因此，以当前的形式，产品与技术团队之间的互动非常正式，可以帮助我们在转移任务到工作的过程中不会失去一些重要的观点。

服务器客户端

我们进一步发展，移动开发出现并成为关键领域之一。接下来出现了通信“中断”的情况。这就是客户端和服务器之间的交汇点。它涉及客户端应如何在协议级别（在关系级别）与服务器交互。这是由客户端人员和服务器人员之间的对话决定的。但是团队数量增加了，这些团队中的人数也增加了。有关客户端和服务器交互的信息仅存储在开发人员的头脑中的事实开始引起问题。

该文件

我们遇到的问题非常简单明显。客户-服务器关系不仅是协议，而且是根据该协议的通信方案。发送什么命令以及何时发送，客户端应如何请求，应用程序如何启动-所有内容都必须遵循协议。

例如，客户端部分的开发人员解决了该问题，并认为API具有可以调用的合适命令，并且一切都会很好。此客户端已释放，并在服务器上造成问题，因为团队对此不堪重负且需要太多资源。此外，iOS和Android对API的理解有些不同，并且以不同的方式实现它，因此，我们无法快速对API进行更改。因此，我们得出的结论是该协议需要记录。

释放不回来

移动平台的独特之处还在于该发行版无法退还。如果应用程序已放置在商店中，并且用户已安装了该应用程序，则使用此版本的客户端很可能将花费很长时间。亲爱的，在设计协议的阶段，在确定客户端和服务器之间的交互的阶段，错误。在Badoo中，再过一两年，我们将必须支持所有已发布的应用程序，直到用户数量下降到一定数量为止。

为了解决此问题，我们决定分配一个单独的MAPI小组，该小组将记录该协议，并将成为客户端和服务器之间知识交流的重点 。这个团队包括来自客户端和服务器开发的员工。这个混合的团队正在将产品需求转换为修改协议及其文档。由于协议实施阶段的错误对我们来说是相当昂贵的，因此该团队中的过程比其他所有过程都更加复杂和困难。他们使用双重代码审查，试图尽可能消除错误的可能性。

这个团队很快成为知识共享的中心。通常，在某些情况下，客户端和服务器开发人员无法就应如何进行交互达成共识。例如，iOS可能是唯一的方法，但对于Android则不合适。新团队解决了这些有争议的问题，并在必要时召集合适的人来做出正确的决定。

如果您看一下我们的流程图，那么在准备好需求和开始开发之间，移动API团队是中间的纽带。那就是：

来自产品团队的任务是开发传统知识（PRD）；
协议设计团队起草文件；
开始根据文档开发客户端和服务器部件。

通过这样的过程，服务器和客户端开发可以独立进行，我们经常使用它。

统计问题

公司不断发展壮大，有更多的人和项目。慢慢地，我们得出了这样一个观点：已经成立了一个单独的团队来处理数据，统计数据，并帮助产品团队分析用户如何响应更改。正如我所说， 问题出现在团队的交汇处 。我们有一个新团队，不久之后，这个联合也开始工作效率低下。

事实是，分析师需要良好的数据来识别模式并回答棘手的产品问题。好的数据意味着所有统计信息都应服从一种语言。当我们谈论统计数据和产品时，我们需要说一种语言。

在此之前，产品经理在每个技术任务中都用文字描述了收集统计信息的原则：对于此按钮，您需要测量此屏幕的点击率-转换。但是随后，开发人员自己决定要跟踪哪些事件，如何度量（从客户端或服务器），要绘制哪些图形以及例如要向这些事件添加哪些部分。开发人员可以按设备类型制作图表，添加性别，按国家/地区收集统计信息。这些不同的数据会送至分析部门，但基于它们，无法准确评估产品中解决方案的质量。结果，出现了相反的任务：我们进行更改，实施这些更改，产品经理请求分析，统计团队请求其他数据，任务进行修订，统计信息正在定稿，我们再次等待...这延长了产品周期，这就是我们的问题。

收集和分析统计信息的过程需要形式化。

我们决定将统计要求记录在ToR中，有关要求的知识的所有者将是分析师。分析师在将传统知识的工作转移到开发阶段，表示需要哪些统计数据，要跟踪的事件，要中断数据的切片。如果分析人员要求扩展现有统计信息或添加新统计信息，那么我们将添加新功能或修改现有统计信息。为此，我们正式使用了代码中的数据。我们制作了一个API，该API根本不允许发送不足的数据或无效的数据。

同时，从工具的角度来看，我们有一个快速的Microstrategy工具用于数据可视化，还有我们自己的工具用于A / B测试。分析人员是拥有如何正确使用这些工具的所有知识的所有者。

流程图中添加了另一个阶段。 PRD会经过分析部门的协调阶段，然后才转移到MAPI和开发中。因此，它现在可以正常工作。

负载分担

下一个问题与一个部门内增加的负载和交互有关。我将领导我们产品的后端开发团队，并以其示例为例说明一个团队中员工人数增加带来的问题。

在最多15人的团队中，一切都很简单。我们相信每个人都可以做所有事情，并主要根据谁现在有空来分配任务，这就是他的工作。为什么要达到15？

人们认为，一个人或团队负责人或技术负责人应领导最多7至9人的团队。这是根据经验确定的足够数量的下属。

我们有一个团队负责人和他的副手，因此我们一起控制了14-15个人。随着进一步的增长，有必要增加一些划分。开发任务的流程需要平衡。我们已经确定了此过程的主要要求：我们正在形成专业化 。每段代码都会有1-2位专家，最好是3位专家，他们最了解此代码并支持此代码。但是，与此同时，有一个正交的要求： 保持灵活性 。例如，如果有五个人支持Messenger，并且紧急任务已经到达太多，那么他们就不应闲着。如果团队拥有自由资源，则应将其包括在执行其他人的任务中。这些要求彼此矛盾，但是我们仍然想尝试实现这一目标。

我们将一个大型团队分为4-9人的开发小组。每个小组的负责人是技术负责人，他是团队的直接负责人。我们引入了这样的概念作为组成部分。 组件是根据产品功能完成的一段代码。 每个组件都分配给一个特定的组。该小组中的每个组成部分都有1-2-3个人担任此文章的专家，并致力于其开发和支持。

在负载分担方面，每个任务都有一个组件。
技术债务和支持的任务分配在“本机”组中，该组分配给该组。
我们正在尝试在“本地”组中分发新功能。但是只有我们有这样的机会。
为了保持灵活性，我们不排除以下情况：一个小组可以帮助另一个小组，并且做一些与其组成部分无关的事情。
在这种情况下，将执行技术任务评审或代码评审-由“本地”小组完成。

在此选项中，我们现在正在工作。该团队有30人，5个小组和22个小组，我们在小组之间共享。尽管我们看不到这种格式会继续增长的限制，但我们会在一定程度上坚持下去。

一个有趣的副作用：当项目数量，人员数量，变更数量急剧增长时，团队中发生的事情。我们面临这样一个事实，即总数如此之多，以至于很难理解发生变化的具体原因。

我将举一个巴西新用户注册量增长的例子。原因可能是：注册新帐户并破坏我们生活的垃圾邮件机器人；会议问题；只是促销活动；在巴西启动新的营销浪潮。更改在图表上可见，我们希望以最小的努力了解发生了什么。