Как работает R&D-департамент Belka Games. Процессы и лайфхаки

Олег Тузов, проджект-менеджер компании Belka Games, рассказал об опыте запуска R&D-департамента, построении в нем процессов, а также дал несколько рекомендаций тем, кто заинтересован в запуске аналогичного отдела в компании.

Олег Тузов

Для начала коротко поделюсь тем, чего мы добились за три года работы R&D-направления.

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

Первенец — Solitaire Cruise. В октябре прошлого года проекту исполнилось два года. На момент публикации статьи он стабильно держится в топ-5 самых кассовых солитеров мира.

Второй проект — Bermuda Adventures. Его мы выпустили полтора года назад. Сейчас он входит в топ-10 кассовых ферм в мире.

1. Ключевые принципы функционирования R&D-департамента в Belka Games

Три года назад при формировании R&D-департамента мы исходили из следующих принципов:

1. разработка новых продуктов в стенах отдела не должна влиять на разработку и поддержку действующих;
2. сама разработка должна быть быстрой;
3. скейл продукта происходит за пределами R&D-отдела.

2. Подход к формированию R&D-команд

Сегодня R&D-департамент состоит из нескольких команд. Каждая из них проверяет ту или иную гипотезу.

При формировании и построении работы каждой команды мы стараемся следовать четырем правилам.

А) На старте команда должна быть небольшой по составу

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

Б) На старте каждый сотрудник должен быть максимально вовлечен в разработку

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

В) Команды должны состоять из универсальных специалистов, готовых к мультизадачности

Каждый участник R&D-команды — это состоявшийся Lead или Head своего направления. У каждого есть своя специализация, и в ее рамках он — generalist.

Г) R&D-отдел должен быть готов к тому, чтобы отпустить проект и вместе с ним своих сотрудников

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

3. Практики, положенные в основу управления R&D-департаментом

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

Речь идет о:

• построении шаблонов;
• ведении документации в соответствии с едиными стандартами;
• детальным прописыванием roadmap-а;
  недельных спринтах;
• правильной постановке задач;
• обязательных follow-up-ах;
• встречах one-to-one;
• ведении backlog-а идей сотрудников.

Разберем каждую из этих практик по отдельности (заодно дам несколько советов по работе с ними).

3.1 Шаблоны

По многим регулярным процессам мы готовим templates или, говоря по-русски, шаблоны. Это экономит кучу времени менеджеру на повторяющиеся или однотипные задачи.

Например, мы в Belka Games используем шаблоны в том числе для таких задач, как:

А) Выход нового сотрудника

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

Б) Разработка однотипного контента

В проекте может быть контент, который разрабатывается по одному пайплайну. Например, главы или ивенты, которые отличаются только артом. Собственно, мы один раз подготовили шаблоны с полным списком задач, в котором, условно, меняем Хэллоуин на Рождество.

Совет: раз в 2-3 месяца пробегайтесь по своим шаблонам, чтобы актуализировать информацию в них.

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

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

А) Разработка общей структуры ТЗ

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

Б) Полнота ТЗ

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

В) Восприятие и читабельность

Наше ТЗ должно быть написано так, чтобы прочитав его, любой сотрудник понял, как работает данная фича или механика.

Рекомендации:

1. Вводите единую и сквозную терминологию и добавляйте в нее новые термины по мере возникновения.
2. Избегайте сослагательных наклонений — возможно, хотелось бы, примерно. Это самые главные враги для четкой работы вашей фичи или механики. Фича должна выглядеть так, работать вот так, если нужно — вот референсы.
3. В разрезе документа используйте фиксированные величины — часы, минуты, секунды. Не полчаса, а 30 минут. До окончания акции не два дня, а 48 часов — и так далее.
4. Заведите шаблон на документ по ТЗ, где будут сразу прописаны все необходимые блоки.

Дополнительно мы фиксируем общие подходы к нарративу. Если в проекте есть диалоги, то должен быть гайд по работе с ними, и так далее.

Совет: тщательно продумывайте цели и рекомендации по составлению документации. Это здорово экономит время команды и минимизирует риск получить не то и не в те сроки.

3.3 Roadmap

При старте разработки roadmap у нас всегда расписан до первого запуска проекта в техлонч.

Как правило, мы составляем roadmap в три итерации.

В первой итерации продюсер проекта, глава департамента и директор по разработке формируют список продуктовых фичей и KPI.

Во второй итерации показываем этот план сотрудникам, отвечающим за свои направления, шлифуем документ.

В ходе уже третьей итерации показываем roadmap всей команде. Если вопросов у нее не возникает, то отправляем в работу.

Обычно в нашем roadmap-е у каждой версии игры прописано, какие у нее:

1. даты (когда должны начать, а когда закончить работу над ней);
2. цели;
3. ключевые фичи;
4. второстепенные фичи;
5. улучшения (арт, UI, UX и так далее);
6. внутренние инструменты разработки;
7. документы.

Какие-то пункты в зависимости от версии могут не заполняться (например, ну какие на старте работы у проекта могут быть улучшения?!), однако в шаблоне они есть.

Совет: время разработки первой версии не должно превышать две-три недели. Это позволит держать команду в тонусе.

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

3.4 Недельные спринты

Как понятно из подзаголовка, в Belka Games длительность спринта — неделя.

В R&D-департаменте мы работаем со спринтами следующим образом:

• PM готовит предварительный план работ на неделю на основе roadmap-а;
• затем на созвоне с командой этот план корректируется;
• после согласования спринта PM публикует его в чат проекта;
• в конце недели PM подводит итоги (что удалось реализовать, с чем не справились).

Сам спринт напоминает описание версии игры из roadmap-а:

1. даты спринта;
2. ключевое в спринте (старт версии, релиз и так далее);
3. что пойдет в недельный билд;
4. что не пойдет в недельный билд, но будет в работе;
5. аналитика;
6. документация;
7. вопросы (например, на что-то нужно обратить внимание,
8. решить сопутствующую проблему или скорректировать процесс).

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

3.5 Задачи

При формировании задач мы, как правило, идем по следующему шаблону:

А) Название задачи

Из него должно быть понятно, что нужно сделать. Не расписывайтесь на много букв — оставайтесь лаконичными. Также можно указать приоритет и/или специализацию.

Б) Описание задачи

В описании максимально полно (но без воды) раскройте, что нужно сделать. В зависимости от задачи приложите все необходимые ссылки — на ТЗ, гайд по диалогам и пути необходимых исходников. Также можете дать ссылку на похожую задачу в качестве примера.

В) Зависимости задач

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

Г) Ассайн на исполнителя + дью дейт

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

Д) Фолловеры

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

У каждой задачи должен быть компактный список фолловеров. В большинстве случаев не нужно подписывать на задачу непрофильных специалистов или весь арт-отдел — пожалейте их инбоксы.

Е) Расположение задачи

Структура версии проекта всегда повторяет структуру нашего roadmap-а. Задача всегда должна лежать в своей фиче и в правильной секции. Не должна задача на анимацию окна банка лежать в секции аналитики батл-пасса.

Совет: заводите задачи сами — не скидывайте дело на других. Это позволит видеть целиком всю фичу / версию / проект.

3.6 Follow-up

Сейчас, когда большинство в IT работает удаленно, очень важно, чтобы информация не осталась похороненной в Google Meet. Поэтому у себя в R&D мы активно пользуемся системой follow-up.

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

Как правило, раз в неделю PM проходится по follow-up-ам и заводит задачи на их реализацию.

Совет: Если вы не можете принять участие в созвоне, обязательно просите его организатора подготовить вам follow-up встречи. Так вы точно всегда будете в курсе происходящего.

3.7 Встречи one-to-one

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

По каждому сотруднику у PM заведен отдельный документ, который открывается на встрече вместе с ним. В документе PM дублирует полезные ссылки на проект разработки, производственный календарь страны сотрудника и так далее. Тут же прописываются KPI сотрудника, актуальные вопросы, которые нужно было ему решить к встрече, и архив уже решенных вопросов.

Совет: встречи рекомендуется проводить в начале каждого месяца. Лучшие книги по их проведению: «Обратная связь в бизнесе» Анжелы Лэйн, «Все начальники делают это» Брюса Тулгана и «Высокоэффективный менеджмент» Эндрю Гроува.

3.8 Backlog-и идей сотрудников

В начале статьи я упоминал, что нам нужно максимальное вовлечение каждого сотрудника. И backlog идей нам в этом очень помогает. У нас в R&D заведено рабочее пространство, где каждый может зафиксировать свои идеи по текущему продукту или любым другим.

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

4. Заключение

В R&D-департаменте Belka Games мы считаем, что главная ответственность за результат ложится на плечи PM-а. Соответственно, ошибки разработки — это недоработка в первую очередь тоже именно PM-а.

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

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