Project Management в инди команде на примере игры Crush Link TD

Это продолжение серии статей о первом опыте в геймдеве на примере разработки игры Crush Link TD.

Прошлая статья была об игровом балансе в жанре Tower Defense.

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

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

Команда

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

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

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

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

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

Инфраструктура

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

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

Что и для чего использовали:

MIRO – создание логических схем, макетов интерфейса и уровней

FIGMA – создание «чистовиков» интерфейсов

EXCEL – план проекта диаграммой Ганта, расчет баланса

GIT – система контроля версий

TRELLO – таск-трекер. Мне доводилось работать в JIRA и Redmine, но TRELLO на мой взгляд проще в использовании. Да и нашим целям он полностью отвечал

CONFLUENCE – база знаний и информационный хаб проекта, где гейм-дизайн документация (ГДД) разбита по тематическим статьям

GOOGLE DRIVE – облачное хранение рабочих файлов и пресс-кита

PINTEREST – визуальные референсы для создания концептов игровых сущностей и локаций

DISCORD – канал для общения команды. Разбит на чаты по блокам работы, чтобы легко находить обсуждение тематических вопросов

ITCH – хостинг для наших демо-версий

SOCIAL MEDIA – полный спектр социальных сетей для анонсов новостей проекта и продвижения перед релизом. Кстати, подписывайтесь на наши социальные сети (https://linktr.ee/4teamgb)

Создать инфраструктуру не так сложно, как актуализировать и поддерживать в рабочем виде.

Процессы

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

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

Вкратце процесс управления проектом выглядел так:

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

2. В Confluence разбил ГДД и общую информацию по тематическим статьям, которые дополнял и обновлял

3. В Pinterest по папкам собрал визуальные референсы для игровых элементов и сущностей

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

5. После звонков я заносил задачи в Trello. Каждая задача помимо ответственного и сроков выполнения имела описание и ссылки на статью в Confluence или на папку с рефами в Pinterest или на схемы и интерфейсы в Miro и Figma соответственно. Когда информация по проекту структурирована, это позволяет легко ставить SMART задачи команде. Каждый отслеживал свои задачи и двигал их по статусам. Правила работы с задачами в Trello были прописаны в одной из статей в Confluence

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

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

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

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

Подводные камни

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

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

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

В личном плане трудности было две. Первая – нести на себе нескольких ролей. Помимо ведущего ГД я был также проджектом, продюсером, занимался паблишингом, продвижением, маркетингом и SMM.

Вторая – это время. Я посвятил год жизни этому проекту.

Проект

В завершение хочу отметить цель проекта было создать и опубликовать качественную игру для портфолио. Это была первая игра для каждого из нас, и мы добились поставленной цели. Не побоюсь сказать, что Crush Link TD – это не студенческий проект, Crush Link TD – это профессиональный проект, сделанный студентами. Один человек из команды получил повышение из-за проекта, а те, кто искал работу по специальности, нашли или стали получать больше ответов на отклики. Ребята продолжают участвовать в других проектах и джемах. Мои ребята большие молодцы, я благодарен им за проделанную работу и желаю успехов на профессиональном пути.

Единственное, о чем жалею, – что ни с какой стороны не было совета, помощи или экспертизы по премиум проектам. Было много советов как сделать F2P игру, но в нашем случае это было не релевантно.

В результате участия в нескольких геймдев конференциях на игру обратил внимание ряд F2P паблишеров. Мы хорошо пообщались, но по ясным причинам это никуда не привело. Сразу после релиза игры на Google Play я отправил финальный вариант нескольким крупнейшим инди паблишерам, работающим с премиум играми. Одни проигнорировал, другие ответил отказом. И вдруг пришел ответ от Raw Fury; они ответили, что команда скаутов заинтересовалась и проанализирует игру. Raw Fury известны такими играми как Sable, Bad North, Call of the see и др. К сожалению, в итоге они ответили, что Crush Link TD не совсем их формат и пожелали удачи.

Инвесторов мы никогда не искали. Инвестиции на рекламу, участие в эвентах и конференциях, плата за инфраструктуру и т. д. – мои личные траты.

Сегодня проект опубликован и закрыт.

Вывод

1. Соберите команду и на берегу договоритесь о правилах, целях и формате проекта

2. Поддерживайте культуру открытой коммуникации, поощряйте обсуждение и обмен идеями

3. Создайте инфраструктуру для командной работы на проекте

4. Сделайте информацию доступной, открытой, понятной и актуальной

5. Используйте инструменты управления задачами на микро и макроуровне

6. Не отказывайтесь от советов экспертов и цените обратную связь

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

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