Инструменты, процессы и структура Not Friendly Games

С прошлой нашей статьи прошло целых 1,5 месяца и вы, наверное, уже подумали - «NFG кончились, не успев начаться».

Но не тут-то было😁 Завязнув в работе, проекте, хобби и играх, я совсем не нашёл времени написать новую статью.

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

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

И слово было - Miro.

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

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

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

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

Таким образом, в Miro мы организовали пространство так, как нам было удобно в работе - выделили место под складирование рефов и готовых артов, скринов готовых моделей, схемы, стикеры с ссылками на текстовые документы и таск-трекер.

В дополнение к Miro мы использовали Google Docs/Sheets для ведения документации по игре + Google Drive для хранения файлов.

Забегая немного вперед, я скажу, что Miro мы пользуемся до сих пор, но уже в меньших масштабах и в основном для работы с графикой. Тем не менее, я считаю, что связка Google Drive + Google Docs + Miro - это наилучшее решение для проекта, если сроки его реализации невелики и не превышают 3-4 месяцев. Мы, например, продолжаем использовать эту связку для джемовских игр. И именно такую связку, будучи наставником в Gamebox, я рекомендую своим студенческим командам.

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

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

Или, иными словами, пересаживаться на более серьезные инструменты.

Закончив с пересмотром своего концепта A Scarlet Way и прикинув, что на разработку при средне-положительном прогнозе уйдет минимум полтора года, а команда увеличилась до 15 человек, я стал думать о смене инструментария, чтобы было проще вести менеджмент команды, а с документами стало удобнее работать.

К этому моменту я уже работал в Playrix и мне было откуда почерпнуть здоровые решения "взрослой" разработки. Суммировав эти знания с результатами моих поисков в интернете, я пришел к тому, что мы будем использовать связку Asana + Notion + Slack + Google Meet, оставив при этом Miro (для работы с рефами и артами) и Google Sheets (для работы с балансом).

И сейчас немного о новых инструментах:

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

- Notion - великолепная разработка, которая совмещает в себе Google Docs и Wikipedia. В этом инструменте, на мой взгляд, прекрасно все. От возможностей wiki-верстки, до складирования всех мелких разрозненных документов в один большой том. По итогу получается, что каждый раздел ГДД - это не отдельный документ, а странички книги.

- Slack - замечательный корпоративный мессенджер, схожий с Discord (который мы использовали раньше), но с большим функционалом и удобством. Но самая важная часть в нем - интеграция все с теми же Asana, Google Services, GitHub и много чем еще.

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

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

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

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

В заключительной части хочется немного рассказать о наших структуре и процессах.

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

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

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

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

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

Если вам понравился этот материал, вы заинтересовались чем-то конкретным или у вас просто появились мысли/вопросы — я буду рад прочитать это все в комментариях.

Спасибо за ваше внимание!