В офисе никого: разработка игр на удаленке

Дисклеймер. У нас нет «удаленных» сотрудников — в команде все равноудалены друг от друга. Просто кто-то работает (сейчас правильнее сказать «работал») в офисе, а кто-то дома или в коворкинге. Поэтому внутри мы предпочитаем термин «распределенная команда».

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

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

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

Онбординг

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

За качество онбординга и адаптацию отвечают:

1. Менеджер.
2. Наставник на период адаптации.
3. HR-специалист.

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

Основные задачи менеджера на этой стадии:

• Сформировать план адаптации.
• Вместе с наставником подобрать задачи для старта.
• Сформулировать ожидания и обозначить цели на испытательный период.
• Обеспечить погружение в команду и процессы.
• Мониторить результаты и вместе с наставником давать развивающий фидбек.

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

Менторство завершается после прохождения ИС или раньше (если новичок успешно освоился и начал самостоятельно без ошибок справляться с задачами) — тут все индивидуально. У одного наставника может быть 1-2 новых специалистов одновременно, чтобы хватало времени и на них, и на свои таски.

Задачи HR-специалиста. Он отвечает за процесс онбординга в целом: от взаимодействий с отделом кадров и бухгалтерией при оформлении до координации первых встреч с менеджером и наставником.

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

Как происходит процесс онбординга

Общий процесс:

1. На этапе рекрутинга определяются менеджер и наставник будущего сотрудника.
2. За две недели до выхода нового сотрудника HR ставит в Asana ряд задач по шаблонам: на выход, на онбординг и адаптацию, и на развитие специалиста.
3. HR создает в Google Календаре три встречи с помощью Google Meet в первый рабочий день: welcome-встреча с HR, встреча с менеджером, встреча с наставником.
4. Менеджер и наставник составляют план адаптации и цели для сотрудника.
5. В день выхода HR, менеджер и наставник проводят встречи с сотрудником и знакомят с командой на онлайн-дейлике.
6. На 2-3 день работы сотруднику ставятся первые задачи (всё всегда через Asana): несложные, с развернутыми описаниями. В фолловеры ставится наставник, чтобы первым следить за результатами и давать фидбек.
7. Через неделю менеджер и наставник проставляют в календаре регулярные встречи (обычно — раз в 1-2 недели).
8. Через две недели HR проводит синк с сотрудником: нужно убедиться, что онбординг идёт по плану, новичок влился в работу, ему уделяется должное внимание и т.д.
9. Через месяц менеджер проводит ревью по результатам (фиксирует фидбек в задаче по развитию специалиста). Сотрудник заполняет опрос по качеству онбординга, менеджер подводит итоги, а HR анализирует результаты опроса и, при необходимости, обсуждает их с менеджером и наставником

Теперь подробнее про первые встречи. HR на старте проводит два созвона.

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

Вторая встреча с HR (первый рабочий день): даем доступы, еще раз рассказываем о базовых правилах (условиях гибкого графика, отпуске, бенефитах, больничных в зависимости от локации и так далее), подробнее рассказываем об Asana (а также даем ссылку на задачу в проекте «Онбординг»), называем ключевых сотрудников и напоминаем о назначенных встречах. Обязательно уточняем, не появились ли вопросы.

Следующий этап — встречи с менеджером.

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

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

• Проект/отдел (где будет работать сотрудник) и планы.
• Документация проекта/отдела.
• Ключевые специалисты в команде (мотивируем писать первому с вопросами, знакомим с наставником и командой).
• Основные процессы, в которых будет участвовать специалист.
• Роль наставника и менеджера (сотрудник должен четко понимать, с какими вопросами к кому идти).
• Цели на ИС и задачи (рассказать об оценке результатов).
• Проекты компании (попросить спокойно в них поиграть — это часть рабочего процесса).
• Следующий синк через 1-2 дня (сотрудник может подготовить свои вопросы).

Вторая встреча с менеджером. Ко второй встрече сотрудник скорее всего приступил к первой задаче, отталкивайтесь от этого.

• Узнайте, как идут дела, все ли понятно. Не напирайте на сроки и наличие результата.
• Расскажите про рабочие инструменты: Asana, Slack и другие. Про внутреннюю Базу Знаний, если такая имеется.
• Спросите, понимает ли новичок роль наставника в команде? Удалось ли с ним познакомиться? Как все прошло?
• Расскажите про регулярные встречи и синки.
• Обсудите возникшие вопросы.

Третья встреча с менеджером проводится спустя неделю работы.

• Узнайте, как идет прогресс, впечатления от проекта и команды.
• Спросите, есть ли трудности с оборудованием, инструментами, поиском информации или чем-либо еще? Расскажите про проект Technical Support в Asana (где оформляются заявки на поддержку) на случай трудностей (и если ранее не рассказывали).
• Если по первым задачам уже можно дать фидбек — дайте.
• Проставьте регулярные статусы 1-1. Расскажите, для чего они нужны.

Дальше встречаемся с новичком 1-2 раза в неделю, пока он не войдет в рабочий поток. Повестки будут зависеть от результатов, фидбека и так далее.

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

1. Проводим встречу в первый день: знакомимся, рассказываем о задачах, о роли наставника и воркфлоу.
2. Второй раз встречаемся, когда у нового сотрудника появляется первая задача. Обсуждаем постановку и способы решения.
3. Затем наставник с менеджером выбирают оптимальный формат взаимодействия. Чаще всего делается ежедневный синк (на 10-15 минут) наставника и новичка по текущим задачам. Через две недели встречи можно реже (раз в 2-3 дня).

Техническое обеспечение

Процесс дефолтный — в первый же день у сотрудника должны быть все необходимые инструменты.

Для этого HR создает специальную задачу по новому сотруднику и назначает на нее ответственного из IT-отдела. В головной задаче «IT New employee Request — Ф.И.» менеджер/наставник утверждает список техники и софта, согласно внутреннему стандарту.

На IT-отделе распределение сабтасков на ответственных, закупка и передача софта в день выхода сотрудника.

Софт по умолчанию: Slack, Chrome, Unity, Sourcetree, OVPN для ноутбуков и работающих вне офиса. В остальном сильно зависит от роли сотрудника и отдела. Выдача доступов идет в основных сервисах сразу после обновления информации по выходу сотрудника в соответствующих директориях.

Коммуникации на удаленке и обмен опытом

Когда люди не сидят рядом в офисе и не сталкиваются на кухне за обедом — вопрос организации коммуникаций становится еще важнее. Инструменты тут общие для всей компании: Asana и Slack для текстовой коммуникации, а для видеовстреч используем Google Meet и Zoom (если много участников или нужно сделать запись доклада/круглого стола).

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

Регулярные встречи. Видеоконференции, созвоны, коллы — за их эффективностью на удаленке нужно постоянно следить. У нас расписано очень много митов, какие-то проводятся раз в три недели (синк лидов компании), какие-то раз в несколько месяцев (Q&A-сессии по компании в целом). Для удобства занесли все форматы регулярных встреч в Google Sheets. Что туда входит на примере мита 1 на 1 менеджера с сотрудником:

• Тема. 1 на 1 с сотрудником.
• Частота проведения. Раз в две недели.
• Формат. Произвольный (например, созвон по видеосвязи).
• Участники. Менеджер и сотрудник.
• Модератор. Менеджер.
• Повестка. Обмен фидбеком, обсуждение текущих статусов задач, прогресс по последнему фидбеку, обсуждение возникших вопросов и проблем.
• Хранение результатов. Произвольно, в виде текста: Google Docs или задача в Asana.
• Примечания.

Рекомендации для встреч по продукту

Основные принципы:

1. Присутствие каждого участника должно быть обосновано.
2. В повестке должны фиксироваться решения и договоренности. После встречи — создаются задачи в Asana и запускаются в работу по приоритету.
3. На каждой встрече должен быть виден прогресс по ключевым вопросам. Договоренности и задачи не должны теряться.
4. Фоллоу ап — после каждой встречи. Для этого можно создать постоянную задачу «Встреча по проекту/продукту», добавить участников и фиксировать информацию.
5. Для небольших проектов (или на ранней стадии) проводить одну встречу, где обсуждать и продуктовые аспекты, и ход разработки. Когда количество вопросов для обсуждения увеличится, то можно разделить встречу на две: по продукту и по проекту.

Встреча по продукту

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

Периодичность. Раз в две недели, после просмотра билда (когда получен фидбек от всех участников). Повестка крепится в описание, а встреча называется: «Встреча по продукту. <Имя проекта>».

Состав. Producer, Lead GD, Art Director (опционально), внешние продюсеры, Head of Product. На встречу дополнительно может быть приглашен эксперт (из команды или внешний), если есть необходимость.

Повестка. Примеры вопросов для обсуждения:

• Видение по продукту: какой продукт мы делаем и для кого.
• Ключевые особенности и фичи с кратким описанием.
• Обсуждение последнего фидбека по билду, снятие противоречий.
• Мы ощущаем прогресс продукта? Он развивается правильно?
• Что можно улучшить? Какие есть идеи?
• На чем сейчас стоит сфокусироваться?

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

Подготовка к встрече. За 1-2 дня до встречи продюсер обновляет повестку, затем присылает ссылку остальным участниками встречи, чтобы каждый участник встречи заранее приготовил вопросы.

Ретроспективы внутри команд. Еще один пример регулярных встреч, опишу отдельно. Многие недооценивают его эффективность, но на деле с ним мало что сравнится.

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

В основе лежит концепция цикла Деминга (PDCA — Plan-Do-Check-Act или Планируй-Сделай-Проверь-Реши). Цель: получить план действий (задач), которые исправят проблемы и что-то улучшат. Сама ретроспектива — это стадия Plan в цикле.

Разницы между между обычной рабочей встречей и ретроспективой — в неформальности. Чем доверительнее атмосфера, тем больше профита все получат. Существуют специальные упражнения, чтобы разговорить участников, найти проблемы и способы их решения. Подсмотреть можно, например, в книге «Быстрый старт в ретроспективы» Алексея Кривицкого.

Строгого расписания ретроспектив нет, привязываемся к каким-то майлстоунам — выпуск нового проекта или окончание очередного спринта. Всё в онлайне, а в качестве доски со стикерами используем Miro.

Несколько рекомендаций по ретроспективе:

1. Не стоит в этот момент заниматься задачами, отвлекаться на трекер или мессенджер. Это сложно сделать, когда все сидят дома за своими компьютерами, но возможно.
2. Никаких посторонних. Только коллеги, которые работают вместе.
3. Не превращайте ретроспективу в книгу жалоб. Профита не будет, если все будут искать виноватых. Ведущий должен следить за конструктивностью — жалобу превращать в сформулированную проблему, а выяснение личных отношений попросту пресекать.
4. Обязательно фиксируйте итоги ретроспективы так, чтобы к ним в любой момент был доступ для участников.

И самое главное, чтобы это все работало: план и обещания, данные на ретроспективе, должны выполнятся. Если раз за разом вы будете собираться, общаться, записывать задачи, но ничего не будет меняться — доверие к ретро пропадет, а люди вообще перестанут говорить о проблемах. Поэтому убедитесь, что план понятен для всех, у него есть ответственные и он выполняется.

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

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

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


Промежуточный скриншот урока

Встречи команд вживую. Тут всё просто. Стараемся раз в 6-7 месяцев собирать каждую команду в одном из офисов — поработать и пообщаться вживую.

Обучение и развитие

Мы пришли к достаточно простой внутренней системе развития сотрудников. Ее основные компоненты:

1. Анализ результатов работы + карта компетенций.
2. Развитие через фидбек.
3. Наставничество и регулярные встречи с ментором.

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

Карта компетенций — это портрет идеального специалиста с учетом контекста и требований проекта. Например, мы стараемся качать художников-дженералистов (универсальных спецалистов, которые, кроме 2D, могут делать что-то еще — FX или анимацию). Карта делается в виде Google Таблицы, где отмечается уровень скилла специалиста в каждой области — базовые навыки (основы 3D, UI/UX, FX и так далее) и софт-скиллы (ответственность, коммуникабельность, инициативность, наставничество).

В фидбеке для сотрудника отмечаем области роста и даем для этого релевантные задачи.

Анализ работы. Как он проходит и из чего состоит:

1. Ежемесячный анализ. Это промежуточный чек, чтобы увидеть прогресс, внести коррективы в работу, дать фидбек и так далее.
2. Ежеквартальный анализ. Сбор расширенного фидбека.

Менеджер дает фидбек на статусе с сотрудником 1 на 1. Лид и/или наставник по развитию этим тоже занимаются, но обычно прямо в процессе работы и по той области, в которой работает сотрудник.

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

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

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

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

Также хорошо работают круглые столы и доклады внутри отделов. Впоследствии любой желающий может посмотреть и перенять опыт.

Разработка на удаленке — есть ли отличия

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

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

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

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

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

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