Главная » Хабрахабр » Масштабируем разработку: от стартапа до сотни инженеров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В программе выступления от весьма известных компаний: Сбербанк-Технологии, Avito, JetBrains, Spotify… да они все крутые! Подсмотреть за новой порцией чужого организационного опыты приглашаем на Saint TeamLead Conf.

Этот доклад — один из десятков докладов, если вы не хотите ждать, когда у нас дойдут руки расшифровать их и опубликовать на Хабре, то смотрите плейлист конференции на нашем YouTube-канале.

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

[Из песочницы] Валидация сложных форм React. Часть 1

Для начала надо установить компонент react-validation-boo, предполагаю что с react вы знакомы и как настроить знаете. npm install react-validation-boo Чтобы много не болтать, сразу приведу небольшой пример кода. import React, from 'react'; import {connect, Form, Input, logger} from 'react-validation-boo'; class ...

[Перевод] Микросервисы на Go с помощью Go kit: Введение

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