Масштабируем разработку: от стартапа до сотни инженеров03.09.2018 16:02

Многие другие крупные IT-компании, начиналась со стартапа, и Badoo не исключение. За последние годы компания прошла путь от нескольких десятков инженеров до нескольких сотен. Николай Крапивный был на передовой на большей части этого пути и принимал решения: что лучше делать, а что не делать, как справляться с проблемами. Его доклад на TeamLead Conf был посвящен этому опыту и картине мира, которая в результате сформировалась.

Конечно, у каждой компании свой путь, но проблемы человеческих коммуникаций у всех примерно одинаковые. Чужой опыт поможет заранее подумать о проблемах, с которыми придется столкнуться с ростом компании. Даже, если эти ценности не подойдут напрямую, это подскажет, в какую строну думать.

Рассказ состоит и трех частей. Первая — про коммуникации, про то, как они меняются с ростом компании. Вторая часть о том, как с увеличением количества инженеров в команде попытаться сохранить скорость разработки. И третья часть — от том, почему Badoo живет на два офиса, и как при этом справиться с проблемой общения.
Приступим!

О спикере: Николай Крапивный (@cyberklin) последние восемь лет работает в Badoo, из них пять занимается управлением командами и построением процессов разработки.

[embedded content]

Перед тем как погрузиться в первую часть, я хочу сказать, что это рассказ про наш путь и не претендует на абсолютную истину. У каждой компании свой путь, но я уверен, что наш опыт, ценности, которые мы для себя сформировали, какие-то знания, помогут и вам в вашем росте, помогут построить правильный процесс. Несмотря на то, что у вас другая специфика, немного всё по-другому, надеюсь, это будет вам полезно.

Коммуникации

Для начала, давайте немного теоретически порассуждаем о том, что происходит с коммуникациями, когда компания растет.

Коммуникации — это про то, как взаимодействуют между собой отделы, как взаимодействуют между собой люди, как происходит общение для того, чтобы в компании что-то было сделано.

Рассмотрим достаточно заезженный, но тем не менее жизненный, пример: команду абстрактного стартапа. Собралось несколько человек, кому-то ближе бизнес, а кто-то больше технический человек. Но в целом, это маленькая команда, которая делает что-то, что возможно когда-нибудь станет вторым Фейсбуком. И в этой команде вся работа построена на коммуникациях. Команда маленькая, и нет никакого смысла вводить какие-то процессы. Всё работает просто так: кто-то с кем-то поговорил, договорились быстро что-то сделать, делают.

Несмотря на то, что в процессе, построенном только на коммуникациях, на разговорах: «А давай сделаем», — «А давай быстрей», — «Давай вот так», есть и определенные проблемы, у такой команды несомненно есть свои плюсы.

Работа происходит быстро. Время от идеи до того, как это идея становится доступна для пользователя, очень небольшое. Идея пришла, мы поговорили с кем-то, как это быстрее сделать, это уже делается, готово.
Это гибко. В этой маленькой команде нет такого, что кто-то занимается только чем-то конкретным, и не может, когда надо, подключиться к задаче, которая важна. В принципе, все делают всё, и если для нас что-то важно, то все прикладывают усилия для того, чтобы это сделать.
В целом, из-за того, что как таковых процессов еще не построено, такая работа достаточно эффективна. Мы не тратим лишнее время на накладные расходы, на какие-то процессы, на какие-то отстроенные формальные схемы.

Это как раз те ценности, которые каждый бизнес хочет видеть: максимально гибкое уравнение ресурсами, минимальный time-to-market и низкие операционные расходы.

Компания растет — коммуникации «рвутся».

Когда компания растёт, преимущества маленькой команды, когда всё работает быстро, на взаимодействии, на разговорах, становятся проблемой. Нагрузка на коммуникации от количества передаваемой информации начинает расти, и мы приходим к тому, что коммуникации «рвутся». Мы начинаем на коммуникациях больше терять, чем мы выигрывать. Нужно поговорить со слишком большим количеством людей, где-то возникает недопонимание при передаче информации от человека к человеку, где-то мы что-то просто потеряли, где-то забыли. И все, что было тогда построено, что давало скорость, мы потихонечку начинаем терять.

Если проэкстраполировать и посмотреть на модель развития компании на длинном временном интервале, то она похожа на цикл. Количество людей увеличивается, нагрузка на процесс увеличивается, коммуникации начинают рваться. То, что ранее работало, перестает работать. Поэтому мы вынуждены в этих местах что-то чинить. Часто это происходит на границах отделов. Чтобы починить, приходится формализовывать процесс общения. И этот цикл повторяется много раз: количество людей увеличивается, что-то начинает работать неэффективно, мы вводим новые процессы, как-то их формализуем, получаем новый запас для роста пока не порвется в другом месте и так снова и снова. Это как с масштабированием системы, как с производительностью: если увеличить нагрузку на систему — самый слабый элемент, самая медленная часть не выдержит. Мы чиним, как-то улучшаем, появляется окно, в котором можно увеличивать нагрузку на систему. Так и с масштабированием компании.

Это была небольшая вступительная теоретическая часть.

Теперь давайте на практике посмотрим на то, какие циклы мы проходили, с каким проблемами сталкивались, и как их решали.

Техническое задание

В качестве первого примера рассмотрим задачу формализации отношений между бизнесом и инженерной командой. Техническое задание, или, как мы его называем PRD, — это запрос на то, что должно быть изменено с точки зрения проектной функциональности. Это достаточно очевидная формализация, которую проходят все компании. Я думаю, что большая часть из вас, работает в компаниях, где есть какой-то формальный процесс передачи задачи на разработку. От продуктовой команды, от бизнеса или от внешнего заказчика — неважно.

Мы прошли несколько частей усложнения этого процесса. Сначала мы просто писали. Когда команда стала больше, чем та, которая позволяет делать дела просто разговаривая между собой, мы стали писать это всё в задачи. Задачи были сформулированы в виде «что должно быть сделано». Дальше сложность продукта росла, количество людей в компании росло, и мы пришли к тому, что полезно в одном месте поддерживать актуальную версию текущей работающей системы. Мы перенесли это все в Вики, а обсуждение изменений в комментарии к вики, для того чтобы все было в одном месте. Следующим шагом была формализация того, что должно быть в PRD + процесс ревью PRD. Теперь у нас есть шаблон, который фиксирует, какая информация обязательно должна быть в PRD, что должно быть описано и какие данные должны быть собраны перед началом работы. Например, сейчас шаблон PRD содержит следующие блоки:

Цель, зачем мы делаем этот функционал.
На каких платформах, продуктах, странах мы планируем запускать.
Описание функционала в формате use cases: основные случаи + заранее прописанный список «сложных случаев», про которые все забывают.
Лексемы (отдельно обрабатываются копирайтером).
Коммуникации: будут ли email/push уведомления для этого функционала и если да, то какие.
План релиза, зависимости от маркетинга/остальных проектов в компании.
Аналитика: как мы будем оценивать результаты, какие бизнес метрики нам нужно добавить для оценки успешности изменения.

Таким образом, в текущем виде взаимодействие между продуктовой и технической командой формализовано достаточно сильно и помогает нам не терять какие-то важные моменты в процессе передачи задачу в работу.

Server-Client

Мы росли дальше, появилась мобильная разработка и стала одним из ключевых направлений. Возникла следующая точка, в которой коммуникация «оборвалась». Это точка на стыке между клиентом и сервером. Речь идет о том, как клиент должен взаимодействовать с сервером на уровне протокола, на уровне взаимоотношения. Это решалось разговорами между клиентскими ребятами и серверными. Но количество команд росло, количество людей в этих командах росло. И то, что информация о взаимодействии клиента и сервера хранилась только в головах разработчиков, стало приводить к проблемам.

Документация

Проблемы, с которыми мы сталкивались, были достаточно простые и очевидные. Взаимоотношение клиент-сервер — это не только протокол, но ещё и схема взаимодействия согласно этому протоколу. Какие команды посылать и когда, как клиент должен запрашивать что-то, как приложение запускается — все должно следовать протоколу.

Например, разработчики клиентской части решают задачу и считают, что в API есть подходящая команда, которую можно вызвать и всё будет хорошо. Этот клиент релизится и создает проблему на сервере, так как команда оказалась слишком тяжелой для него и требует слишком много ресурсов. К тому же iOS и Android понимают API немного по-разному, и реализуют по-разному, из-за этого мы не можем быстро внести изменения в API. Таким образом, мы пришли к тому, что протокол нужно документировать.

Релиз не вернуть назад

Особенность мобильных платформ еще и в том, что нельзя вернуть релиз. Если приложение выложено в store и пользователь его поставил, то, скорее всего, с этой версией клиента придется жить очень долго. Ошибка на стадии проектирования протокола, на стадии определения взаимодействия между клиентом и сервером, дорогая. В Badoo еще год—два мы должны будем поддерживать любое приложение, которое выпустили, пока количество пользователей не упадет до определенного предела.

Чтобы решить эту проблему, мы решили выделить отдельную команду MAPI, которая будет документировать протокол, и будет точкой обмена знаниями между клиентом и сервером. В эту команду входят сотрудники со стороны клиентской и серверной разработки. Эта смешанная команда занимается превращением продуктовых требований в изменение протокола и его документации. Поскольку ошибка на стадии реализации протокола для нас достаточно дорогая, процессы в этой команде немного сложнее и тяжелее, чем во всех остальных. Они используют двойной code review, стараясь максимально исключить тем самым возможность ошибки.

Эта команда быстро стала центром обмена знаний. Часто возникают ситуации, когда разработчики клиента и сервера не могут договориться о том, как они должны взаимодействовать. Например, iOS может только так, но для Android это не подходит. Новая команда решает эти спорные проблемы, при необходимости собирает нужных людей, чтобы принять верное решение.

Если посмотреть на схему нашего процесса, то команда Mobile API — это промежуточное звено между тем, когда готовы требования, и тем, когда начинается разработка. То есть:

от продуктовой команды поступает задача на разработку ТЗ (PRD);
команда проектирования протокола составляет документацию;
начинается разработка клиентской и серверной части согласно документации.

При таком процессе, серверная и клиентская разработка может идти независимо, и мы это часто используем.

Компания продолжала расти и развиваться, стало больше людей и проектов. Потихоньку мы пришли к тому, что выделилась отдельная команда, которая занимается данными, статистикой, помогает продуктовой команде анализировать то, как пользователи реагируют на изменения. Как я уже говорил, проблемы появляются на стыке команд. У нас появилась новая команда, и через некоторое время этот стык тоже стал работать неэффективно.

Дело в том, что аналитикам необходимы хорошие данные, чтобы выявлять закономерности и отвечать на каверзные вопросы продукта. Под хорошими данными имеется в виду то, что вся статистика должна быть подчинена какому-то единому языку. Когда мы говорим о статистике и о нашем продукте, мы должны говорить на каком-то одном языке.

До этого, в каждом техническом задании продукт-менеджер описывал принципы сбора статистики словами: у этой кнопочки нужно измерить click rate, у этого экрана — конверсию. Но дальше разработчик сам решал, какие события отслеживать, как измерять (с клиента или сервера), какие графики рисовать, и к примеру, какие разрезы добавлять в эти события. Разработчик может сделать графики, разрезанные по типам девайсов, добавить пол, собрать статистику по странам. Эти разрозненные данные приходят в аналитический отдел, но на их основе нельзя точно оценить качество решения в продукте. Вследствие этого возникает обратный вал задач: мы вносим изменения, эти изменения реализуются, менеджер продукта запрашивает анализ, команда статистики запрашивает дополнительные данные, задача уходит на доработку, дорабатывается статистика, мы опять ждём… Это удлиняет продуктовый цикл и это и была проблема для нас.

Процесс сбора и анализа статистики нужно формализовать.

Мы решили, что требования к статистике будут записываться в ТЗ, а владельцами знаний о требованиях будут являться аналитики. Аналитик, на стадии передачи работы по ТЗ в разработку, говорит, какая нужна статистика, какие события отслеживать, по каким срезам разбивать данные. Если аналитик просит расширить существующую статистику или добавить новую, то мы добавляем новую функциональность или изменяем существующую. Для этого мы формализовали работу с данными в коде. Мы сделали единый API, который просто не позволяет отправить недостаточное количество данных или невалидные данные.

Параллельно, с точки зрения инструментов, у нас есть быстрый инструмент Microstrategy для визуализации данных и свой инструмент для A/B тестирования. Владельцами всех знаний о том, как правильно использовать эти инструменты, являются аналитики.

В схему процесса добавляется еще одна стадия. PRD проходит стадию согласования в отделе аналитики, и только после этого передается в MAPI и разработку. Так это работает прямо сейчас.

Следующая проблема связана с ростом нагрузки и взаимодействием внутри одного отдела. Я руковожу командой разработки бэкенда для наших продуктов, и на ее примере проиллюстрирую, какие проблемы появляются с ростом числа сотрудников внутри одной команды.

В команде до 15 человек все достаточно просто. Мы считали, что все делают всё и распределяли задачи в основном по принципу, кто сейчас свободен — тот и делает. Почему до 15?

Считается, что один или тимлид или техлид должен руководить командой до 7–9 человек. Это эмпирически установленное число адекватного количества подчинённых.

У нас было тимлид команды и его зам, поэтому вдвоем мы контролировали 14–15 человек. С дальнейшим ростом, стало нужно какое-то дополнительное деление. Поток задач на разработку нужно балансировать. Мы определили, главное требование к этому процессу: формируем специализацию. У каждого кусочка кода будут эксперты, 1–2, а лучше 3, которые этот код знают лучше всего, и которые этот код поддерживают. Но при этом, есть ортогональное требование: сохранять гибкость. Например, если пять человек поддерживают мессенджер, и поступило слишком много срочных задач, то они не должны простаивать. Если в команде есть свободные ресурсы, они должны включиться в выполнение чужих задач. Эти требования противоречат друг другу, но мы всё равно хотим попытаться этого добиться.

Мы разделили большую команду на группы разработки по 4–9 человек. Во главе каждой группы стоит техлид и он является непосредственным руководителем команды. Мы вводим такое понятие, как компонент. Компонент — это законченный с точки зрения продуктовой функциональности кусочек кода. Каждый компонент закреплен за определенной группой. У каждого компонента внутри группы есть 1–2–3 человека, которые являются экспертами по этому кусочку, и занимаются его развитием и поддержкой.

С точки зрения разделения нагрузки, у каждой задачи есть компонент.
Задачи технического долга и поддержки распределяется в «родную» группу — та, за которой этот компонент закреплен.
Новую функциональность стараемся распределять в «родную» группу. Но только, если у нас есть такая возможность.
Чтобы сохранять гибкость, мы не исключаем ситуации, когда одна группа помогает другой, и делает что-то, что с не связано с ее компонентами.
В таком случае проводится либо ревью техзадания, либо ревью кода — это делает «родная» группа.

В таком варианте мы работаем сейчас. В команде 30 человек, 5 групп и 22 компонента, которые мы делим между ними. Пока мы не видим предела для дальнейшего роста в этом формате и до определенного масштаба будем его придерживаться.

Интересный побочный эффект: что происходит в команде, когда количество проектов, количество людей, количество изменений растёт достаточно сильно. Мы столкнулись с тем, что всего стало так много, что трудно понять конкретные причины какого-то изменения.

Приведу пример роста регистрации новых пользователей в Бразилии. Причиной может быть: спам-бот, который регистрирует новые аккаунты и портит нам жизнь; проблемы с сессиями; просто промокампания; запуск новой волны маркетинга в Бразилии. На графике видно изменение, и нам хочется минимальными усилиями понимать, из-за чего оно произошло.

Мы сделали для себя инструмент, который называется WTF. Это один инструмент, который собирает в себе со всевозможных подсистем и частей продакшена то, что может как-то влиять на метрики. Это инструмент интегрирован в инструмент построения графиков, и можно посмотреть изменения на интервалах. Бонусом, мы стараемся интегрировать не только технические метрики (аварии, конфигурационные изменения), но и бизнес метрики (промо и рекламные компании).

Интерфейс простой: красная линия — это изменение, связанное с каким-то конфигурационным изменением. Такой инструмент помогает отслеживать изменения в условиях выросшего проекта.

Подведем итоги первой части моего доклада:

С ростом команды коммуникаций будет не хватать. Они будут перегружаться и становиться неэффективными.
Чаще всего это происходит между отделами, в нашем случае между серверной и клиентской разработкой.
Там, где рвется, — формализуем процесс.
Понадобятся новые инструменты с ростом количества проектов.

У нас сработало:

Формальное взаимодействие между продуктовым и инженерными отделами реализовано через ТЗ.
Взаимодействия с BI, основаны на требованиях аналитиков;
Команда MAPI занимается протоколом для работы клиентской и серверной части.
Все взаимодействие внутри отдела, происходит по принципу компонента — это способ формализации распределения задач.

В процессе разработки участвует 200 человек. С дальнейшим ростом, возможно, мы столкнемся с новыми проблемами. Тогда через пару лет будет новый доклад про то, как мы все переделали :)

Скорость

Мы хотим сохранить скорость внесения изменений в систему с ростом команды. При этом, сталкиваясь с проблемами в коммуникациях, мы внесли ряд формальных процессов и получили многоэтапную схему.

Time-to-marker с таким процессом всё увеличивается и увеличивается. Теперь мы выглядим вот так.

Наша система как большой корабль. Он плывёт очень быстро, круто вооружен, всё классно, пока не нужно внести какое-то очень маленькое изменение. Чтобы маневрировать, реагировать на рынок, нам нужно изменение прокачать через всю нашу схему.

Тогда мы задумались:, а может быть всё не так. Может быть, мы вообще неправильно растем, и нужно всё переделывать. В голову приходит вариант с кросс-функциональными командами. Мы масштабируем систему вертикально. Говорим: больше работы — больше людей. И потеряли в скорости доставки. Может быть, стоит перейти на схему, когда наша команда представляет собой большое количество стартапов. Каждый стартап будет сам делать часть работы, а внутри у него будут эффективные коммуникации. Тогда не нужно будет вносить формальные процессы

Идея переделать функциональные команды в кросс-функциональные, чтобы всё ускорить, возникала много раз с раз в процессе нашей эволюции. Мы от неё отказывались из-за нескольких минусов.

Меньше гибкость ресурсов. Перераспределять людей между кросс-функциональными командами сложнее. Реакция на изменение нагрузки или процесса медленнее.
Вопрос технологического контроля в системе. Есть 10 команд с бэкендерами, фронтэндерами и аналитиками в каждой. Возникает вопрос:, а не станет ли каждый бэкендер писать на своем языке и не утащит ли стек разработки в свою сторону. Это грозит еще и созданием новых велосипедов для решения одних и тех же задач. Это вносит дополнительную нагрузку на администрирование всей системы.
Эта система работает только от какого-то масштаба. Нужно обеспечивать bus-фактор больше единицы, поэтому нельзя сделать команду только с одним бэкендером. Всех специалистов должно быть хотя бы по два, и субъективно кажется, что нужно больше людей, чтобы делать то же количество задач.

Если представить нашу систему, как систему массового обслуживания заявок (где заявки — это продуктовые гипотезы и изменения), можно найти ответ на вопрос про скорость. На графике диаграмма насыщения теории массового обслуживания, у которой по оси OX запросы в секунду. Для нашего процесса это обозначает количество выполненных задач. По оси OY время обработки каждого запроса.

С точки зрения теории массового обслуживания систему можно оптимизировать либо по количеству решаемых задач, либо по времени обработки задачи.

Функциональная команда оптимизирована на количество выполняемых задач. Кросс-функциональная — на время доставки. В кросс-функциональной команде всё происходит быстрее, time-to-market меньше, но и меньше решенных задач. Чтобы какую-то задачу сделать быстрее, нужно, чтобы какое-то количество ресурсов было либо свободно совсем и ожидало прихода задачи, либо выполняло какую-то задачу, которая не так важна и ее можно отложить. В рамках функциональных команд мы, по сути, оптимизируем использование ресурсов разработки. За счет этой внутренней оптимизации мы получаем большое количество выполненных задач.

Вернемся к проблеме. Нам всё-таки не хватает гибкости и скорости для быстрых продуктовых проектов. Мы хотим, чтобы время доставки было минимальным, и не хотим терять время на процессах. Хотим взять плюсы от обоих подходов. Чтобы этого добиться, мы разделили наш workflow. Для бизнеса и некоторых конкретных задач (например, маркетинг) важна скорость. Для них мы будем применять подход с кросс-функциональными командами. А для области, в которой скорость доставки не так важна, мы будем применять общую схему.

Фактически, это проектные команды. Продуктовый отдел говорит, что нужно сейчас, что важно для компании, где мы хотим прибавить и улучшить. Чаще всего это экспериментальные проекты, в которых точно не известно — полетит или нет. В них не нужно вкладывать много ресурсов на документацию или построение идеальных решений. Большое количество компаний в маркетинге работает по принципу — либо делаем это за 2 дня и запускаем кампанию, либо упускаем эту возможность. Для таких областей мы формируем проектные команды, которые обеспечивают нам скорость доставки. Для всего остального, процессы работают по схеме, о которой я говорил раньше. В проектных кросс-функциональных командах какие-то этапы могут опускаться, для каких-то задач работа может двигаться как в стартапе, просто на коммуникациях.

Эта система нуждается в постоянном контроле. Мы постоянно отслеживаем какие области для нас критичны, где на данный момент нужна скорость, какие временные проектные команды создавать.

Процентов 70–80 задач проходят длинный формализованный путь. Все задачи, связанные с техническим долгом, и поддержка тоже идут по обычному пути. В этой схеме мы сохраняем технологический контроль, документацию и надежность принимаемых решений. Потому что проектные команды временные, они делают что-то и их члены расходятся обратно по своим отделам, и дальше поддерживают свой код.

Давайте подведем итоги второй части.

Функциональные команды — это оптимизация количества, кросс-функциональные — оптимизация скорости сделанного.

В каждой компании нужно решить, какой баланс вы хотите. Если вы готовы тратить чуть больше времени, чуть больше ресурсов, и готовы решать какие-то проблемы, связанные с технологическим стеком, но хотите большей скорости — возможно кросс-функциональный подход вам подходит. Если вы не готовы, и хотите просто расти эволюционно, как мы — функциональный подход. Мы используем оба для разных задач.

Москва—Лондон

С относительно серьезными темами разобрались, давайте поговорим о том, как мы работаем между двумя офисами. Как так получилось, что мы сидим в разных офисах. Почему так получилось, какие проблемы с этим идут и как мы их решаем.

Сложилось это исторически. У нас бизнес всегда располагался в Лондоне, а Москва была технологическим офисом. Мобильная разработка, как стратегическое направление, появилась сразу в Лондоне, возле бизнеса. Она активно развивалась, и в какой-то момент мы пришли к тому, что клиентская разработка сидит Лондоне, а бэкенд, server-side и веб, исторически сидят в Москве. Мы поняли, что с нашим подходом, связанным с кросс-функциональными командами, мы теряем очень сильно. Расстояние между офисами создает проблемы, если нам нужна маленькая команда, но сразу из специалиста по server-side, веб, продукту и аналитики. Тогда в 14 году, началось великое переселение народов. Мы переместили всю команду веб-разработки в Лондон, и половину server-side. Сейчас все клиентские команды вместе с вебом работают в Лондоне, а server-side разделен 50/50. Это решение кажется странным, но в целом, с точки зрения процесса, мы выиграли. Потому что теперь в Лондоне, возле клиентщиков, возле продукции, есть какой-то кусочек бэкенда, который может участвовать в быстрых проектах, может помогать и может работать быстрее. С точки зрения нашего отдела, мы немного потеряли, потому что команда разделена на два офиса.

Бонусом к этому всему мы получили и другие преимущества.

Улучшение возможности найма —можем нанимать и из Европы, и из России. Можем принимать тех, кто хочет поменять работу не потому, что ему что-то не нравится здесь, а потому что ему просто хочется уехать, такие люди тоже бывают.

Улучшилась коммуникация от бизнеса до инженерки. Потому, что теперь часть нашей команды сидит в Лондоне, и она быстрее получает информацию о том, что происходит, какие проекты будут и какие результаты уже есть. Я назвал это «присутствие в центре».

Отказоустойчивость. Мелочь, а приятно — раньше, например, когда на майские праздники московский офис дружно уезжал копать картошку, работа в Лондоне вставала. С вариантом 50/50 мы устойчивы к 10-дневным новогодним праздникам и похожим ситуациям.

Один из вопросов, с которым мы боремся — это разница во времени. Точнее с ней сложно бороться, но она есть. Она не такая большая, всего лишь 3 часа. Наверное кто-то из вас работает в командах, где разница 12 часов. Но 3 часа — это такая неприятная разница, если работать вместе. В Лондоне человек приходит, пока он втянулся в работу, проходит первый час, приходит время, когда он выходит на крейсерскую скорость работы, и, казалось бы, сейчас вместе с Москвой что-то сделает, но Москва уходит на обед. Москва приходит с обеда — Лондон ушел на обед. Сдвиг на полдня очень неприятный. Поэтому Московский офис работает с 11:00, а Лондонский — с 9:00. Этим временным сдвигом мы частично нивелируем разницу, и работаем практически в одном режиме.

Плюс, который есть благодаря разнице во времени — это то, что релизы происходят 2 раза в день, один утром, один вечером. Утренний делается московскими ребятами, потому что для них час дня — это время серьезной работы, а в Лондоне люди только пришли, кого-то еще может не быть, какие-то, возможно, проблемы есть. А вечерний релиз делается Лондоном, если что-то пойдет не так, это будет в рабочее время и никому не придется задерживаться.

Следующую проблема, с которой мы боремся, я назвал «дефицит тепла». Из-за того, что комната разделена, взаимоотношения подчиненный-руководитель происходит удаленно. Роль руководителя для своего подчинённого можно очень грубо разделить на две:

Сэнсей: долгосрочная роль — обеспечить рост, поставить стратегическую цель и т.д.
Ментор — оперативная, краткосрочная роль, по сути, это: «я научу тебя воевать прямо сейчас». Как правильно себя вести, чтобы решать текущие задачи.

Стратегическая роль может выполняться удалённо какими-то регулярными посещениями и разговорами, поскольку она стратегическая, и не нужно постоянного вмешательства в работу. Роль ментора, оперативного управления, достаточно сложно исполнять удалённо. Поэтому для себя мы выработали правило, что для всех молодых, новеньких сотрудников техническое менторство происходит локально. Есть какой-то человек в команде, который на себя берёт на себя обязанности руководителя, который менторит человека в возникающих вопросах локально. При этом, руководитель может все еще выполнять работу, связанную с ростом человека стратегическим.

Никто не отменяет того, что просто нужно чаще встречаться. Здесь у нас всё стандартно:

Мы ездим в командировки друг к другу. Встречаемся по проектной работе.
Раз в квартал проходит performance review. Все руководители, у которых есть подчинённые в другом офисе, обязательно приезжают, чтобы поговорить один на один. Всё-таки разговор по видеоконференции — это совсем не то, что поговорить лично с человеком.
Новые сотрудники обязательно посещают разные офисы — познакомиться, посмотреть, как работает другая команда, познакомиться с менеджером продукта для инженера или наоборот.
Мы делаем встречи групп. Отдел разделен на группы, и каждая группа раз в квартал собирается вместе. Причем, в разных городах по очереди. Сначала одна группа вся собирается в Москве, сотрудники что-то делают вместе, как-то взаимодействуют, проходят своего рода тимблидинг.
Раз в год мы стараемся проводить общий сбор отдела в неформальной обстановке. Обычно это выходные, за которые можно сделать что-то полезное, обсудить проблемы, но, при этом и просто пообщаться «за жизнь». Это помогает ощутить то, что мы делаем одно общее дело.

Еще у нас есть ивент на всю компанию, который называется «All Hands». Раз в квартал собираются вообще все сотрудники компании, и кто-то рассказывает о том, чего мы добились за последнее время. Для того чтобы сокращать дистанцию между офисами, это собрание проходит то в Москве, то в Лондоне. В один квартал все, кто должен выступать, приезжают в Москву, а в Лондоне идет видеоконференция. В следующий квартал наоборот — в Лондоне происходит выступление, а в Москве —только видеоконференция.

Вот так мы и живем в Badoo.

Подсмотреть за нов
© Habrahabr.ru