Кровь, пот и мини-команды. Как и зачем в Belka Games меняли структуру проекта

Виталий Кузьмин

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

Очевидно, что у каждой структуры есть свои pros и cons. Какая-то из них может отлично прижиться в одной компании, а в другой не взлетит. Эта заметка — попытка окинуть взором весь пройденный путь к мини-командам, собрать весь наш опыт воедино и представить на суд коллегам. Будем рады, если что-то вам пригодится. Если решите поделиться своим опытом, будет совсем замечательно.

Проблемы, которые подтолкнули нас к этому решению

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

Речь о структуре, в рамках которой разработка проекта распределена между функциональными отделами (например, между отделами тестирования, отделами разработки, отделами гейм-дизайна и так далее). У нас у каждого отдела был свой функциональный лид. Их работу координировали проектные менеджеры, а последними (как и судьбой проекта) заведовал продюсер.

В то время мы как раз переносили «Часовщика» на новый движок. Курс разработки был зафиксирован в роудмапе. Конечно, мы хотели предусмотреть все, но проекту на тот момент было восемь лет и он скопил приличное легаси, поэтому у нас часто возникали непредвиденные задачи. В результате скоуп версий рос, сроки релизов разъезжались, а PM-ы седели на глазах.

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

Анализ ситуации выявил, что слабым местом в нашем случае стала сложившаяся структура разработки. У нее было два ключевых минуса, которые и подтолкнули нас к трансформации:

• «Бутылочные горлышки». За время оперирования команда выросла до 60+ человек. Ее размеры не позволял PM-ам, продюсеру и функциональным лидам работать эффективно. Число задач на одного лида значительно превышало его возможности, поэтому у нас надолго подвисали задачи, где нужно было получить аппрув от менеджмента.
• Над разными фичами каждый раз работал разный состав сотрудников. Не было такой сплоченности, как в сработавшихся командах.

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

Чем выше взлетаешь, тем больнее будет падать. В нашем случае наступил конец первой волны пандемии. Выручка начала корректироваться, а проблемы никуда не исчезли. Складывающаяся конъюнктура вкрадчиво нашептывала нам, что нужны изменения.

Решение, или Vive la révolution!

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

Мы решили тоже поучаствовать в этом ралли. Цель была ясна. Также ясно было, что с текущей структурой достичь ее — практически невыполнимая задача.

В качестве будущей желаемой структуре остановились на мини-командах.

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

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

Когда у нас появилось первое понимание будущей структуры, мы зафиксировали его в презентации для CEO.

В ее рамках мы в том числе объясняли, как переход к новой структуре решит наши проблемы.

• Ликвидация «бутылочных горлышек» в лице PM-ов и функциональных лидов решается введением в каждой команде тимлида, который забирает на себя всю операционку (ведение недельных планов, создание и распределение задач, миты один на один с сотрудниками).
• От «бутылочного горлышка» в лице продюсера мы должны избавиться вводом в каждую команду фичер-оунера (по сути, гейм-дизайнера, который может принимать продуктовые решения и ведет фичу от концепции до релиза в прод). 
• Чтобы получить сплоченные коллективы, закрепляем сотрудников за конкретной мини-командой, как правило, вместе работающей над новыми фичами.
• Для развития самостоятельности мини-команд поощряем принятие решений и любую инициативу внутри них.
• Чтобы лучше понимать capacity команды и лучше настроить работу над приоритетами, задаем желаемый темп апдейтов (не реже раза в месяц). 

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

Мы должны были подготовить железобетонные аргументы — и понять, как можно адаптировать модель с наименьшими расходами. Немного забегу вперед и скажу, что не все команды укомплектованы на 100%, как предполагалось изначально. Но мы пришли к некой гибридной структуре, в рамках которой делимся незагруженными ресурсами в чате в Slack. Запросы на специалистов в нем оставляют тимлиды мини-команд.

Короткий питч у СЕО, серия вопросов и зеленый свет от руководителя у нас в кармане. Начинаем действовать.

Мини-команды в нашем прочтении

Для себя мини-командами мы считаем самодостаточные и (почти) автономные бизнес-юниты, у каждого из которых есть четкая специализация и ответственность за кусок в общем скоупе предстоящего апдейта. Самодостаточными они являются, потому что своим составом они могут вести фичу от идеи до выпуска в прод. Как правило, в состав команды входят:

• гейм-дизайнер (он же фичер-оунер, который отвечает за документацию и за то, чтобы видение по фиче не распадалось на куски по ходу разработки);
• разработчики;
• художники и UI-дизайнеры;
• аниматор;
• тестировщик.

Каждой командой руководит тимлид. Он полностью фасилитирует процесс разработки, а также берет на себя people management: встречи один на один, цели, планы развития.

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

Мы разделили мини-команды по трем зонам ответственности.

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

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

Функциональные руководители никуда не делись. Они обрели гордый тайтл «экспертов» и находятся вне структуры мини-команд. Их основная задача — улучшать качество работы спецов своего профиля. Иными словами, ведущий разработчик ревьюит код разработчиков, ведущий UI-дизайнер отсматривает макеты и дает правки, ведущий QA следит за полнотой тест-кейсов и так далее. Чтобы они могли заниматься развитием специалистов полноценно, мы постарались максимально освободить их от операционки, поэтому задачами в таск-трекере и их распределением занимаются тимлиды.

Ниже приводим схему нашей организационной структуры.

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

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

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

Важный нюанс

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

Суть в том, что мини-команда «Альфа» работает над апдейтом номер 1, а мини-команда «Браво» в то же самое время трудится над апдейтом номер 2. При этом они не конкурируют за ресурсы и не пересекаются в задачах, так как каждая команда делают свою фичу. Полный цикл разработки такой фичи «под ключ» в среднем занимает два-три месяца. Начав разработку в нужных точках, мы сумели выйти на частоту релизов раз в полтора-два месяца.

Слабые места и проблемы мини-команд

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

Большие «транзакционные издержки». У каждой мини-команды должны быть точки синхронизации для слаженной работы и понимания, к чему она идет и на каком этапе находится. Наши команды синхронизируются через чат в Slack, проект в Asana и встречи в Google Meet. Как раз количество таких встреч и является болевой точкой. Мы стартовали с такого набора:

• общий звонок всех тимлидов и экспертов в понедельник с утра;
• пятнадцатиминутные дейлики с командой каждый рабочий день (с понедельника по пятницу);
• подведение итогов и планирование в пятницу вечером.

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

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

Получилось ли это у нас? Опять же, не в полной мере. Но мы считаем, что нам удалось сильно продвинуться в этом плане. Текущий «горизонт» планирования на проекте составляет полгода. Это значит, что мы знаем, какие фичи мы будем делать в ближайшие полгода, и для каждой из них есть готовое ТЗ.

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

Поговорим о плюсах

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

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

Вовлеченность. Еще в больших компаниях при расширении штата сотрудникам сложнее осознать свое влияние на продукт и вклад в общее дело. Когда у вас 20 тестировщиков в отделе, сложнее осознавать, что делаешь что-то важное и полезное ради глобальной цели, и многие начинают просто «работать работу». В мини-команде чувство цели возвращается: перед отделом стоят ясные KPI, работа одного непосредственно влияет на работу остальных, и благодаря этому каждый максимально вовлекается в процесс.

Бутылочных горлышек меньше. Теперь все операционные задачи распределяются по командам через тимлидов. Функциональные лиды перестали быть бутылочными горлышками — и более того, теперь у них больше времени совершенствовать процессы и развивать сотрудников своего направления.

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

Итоги

Достигли ли мы своих целей? Определенно, да. Переход к новой структуре вкупе с другими изменениями помог нащупать зрелому «Часовщику» свой новый финансовый потенциал. Во многом — из-за более частых поставок нового контента в прод. Напомним, от более долгого цикла разработки мы пришли к апдейтам раз в полтора-два месяца. Как итог, мы дважды «пробивали» потолок дневной выручки и ставили исторические рекорды по ней.

Являются ли мини-команды панацеей, решением всех проблем? Определенно, нет. Для зрелых команд переход точно будет болезненным. И, конечно же, он должен быть оправдан: вы должны четко понимать, какие проблемы вы решаете. Если есть устоявшаяся организационная структура, позволяющая вам решать свои бизнес-задачи, подумайте 10 раз, прежде чем ее «расшатывать».

Для себя мы решили, что схема рабочая, и в данный момент пытаемся внедрить ее на другом проекте — перенимая опыт первопроходцев, применяя удачные практики, но докручивая их и адаптируя под текущую реальность.