Как собрать, удержать и не обмануть команду на энтузиазме

Вокруг инди-команд, создающих игры на энтузиазме, в сообществе существует, мягко говоря, скепсис. Ещё бы — люди работают бесплатно, еще и на чужую идею. Так сразу и видится: предприимчивый деятель подобрал наивных мечтателей с обочин геймдева, залил сказки про профит и игру года (Stardew Valley привел в пример, а как же) и припахал к труду. Сидит, командует, мечтатели пыхтят, а когда игра выйдет — обязательно их кинет.

Я как раз тот самый деятель, и в этой статье хочу пролить свет на такую схему работы. Это – мой субъективный взгляд на то, зачем люди приходят в такие команды, как работает их мотивация и какова роль лидера команды. Ну и конечно, как же делить миллионы после релиза.

Мой проект называется Pigeon Slayer (писал о нём раньше). Проект в разработке около 8-ми месяцев, в команде сейчас 10 человек. Мы активно делаем MVP, а сейчас участвуем в конкурсе Unreal Dev Contest с рабочим билдом.

Проект зародился в рамках обучения на программе «Менеджмент игровых проектов» от ВШБИ. Я пошел на учёбу, целиком оторвавшись от прошлой жизни, с целью получить ряд теоретических и практических навыков для перехода в геймдев. За практику отвечал, собственно, проект. Я мог бы не создавать свой, а присоединиться к чужому – но уже был неудачный опыт работы в такой команде, где всё закончилось вместе со свободным временем лида. В своей же мотивации и времени я мог быть уверен.

Так или иначе, я начал свой проект. Вопрос поиска команды встал сразу – в программировании и арте я полный ноль, и учиться хотел другому. В итоге, я «назначил» на себя на роли геймдизайнера, нарративщика и ПМ (со временем добавились левелдизайн и прототипирование в движке), составил список «вакансий» и начал искать соратников.

Зачем это мне – понятно. Я хотел отработать навыки на интересном мне материале. Но зачем это кому-то еще?

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

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

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

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

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

Пусть так, но инди-проектов – вагон. Почему кто-то пошёл на мой?

Анализируя этот момент, я выделил для себя несколько ключевых причин:

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

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

До этого, впрочем, еще надо дожить – ведь собрать команду гораздо проще, чем удержать. Сейчас в команде Pigeon Slayer 10 человек, а всего в моих рядах побывало почти 20. Из первоначального состава команды остался только я.

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

Кроме того, разработка – хобби весьма энергозатратное. Это долговременные инвестиции времени и сил с неопределенным результатом. По сути — вторая работа.

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

Есть ли у него на это моральное право? Ведь все работают исключительно по доброй воле; удерживать кого-то – значит нарушить добрую волю в своих интересах.

У меня есть несколько аргументов против этого тезиса.

Как я писал выше, почти все приходят на проект ради обучения. Пока 3d-artist учится тонкостям ретопологии, ПМ учится управлению проектом. Работа с мотивацией – одна из частей этого обучения. Ведь люди, покидающие проект, часто (пусть и не всегда) уменьшают вероятность его релиза, а релиз – самое наглядное и весомое доказательство состоятельности ПМ.

Кроме того, сохранение команды выгодно для самих участников. Порфтолио, наработанное в рамках проекта, существенно потеряет в цене в случае его закрытия. Одно дело – иметь опыт работы в проекте, вышедшем в Steam, другое – в безвестно почившей задумке кучки энтузиастов.

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

Разумеется, бывают ситуации, когда удерживать кого-то бесполезно, а то и вредно. Так же, стоит оговориться, что под «удержанием» я понимаю исключительно мотивацию через позитив – без какого-либо давления, «ты подводишь проект», НЛП и вот всего этого.

НЛП нет, денег нет. Что остается-то? Методом проб и ошибок (а ошибок было немало), я выработал подходы, которые, кажется, помогают держать команду в относительной стабильности на данный момент.

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

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

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

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

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

Описание задач – отдельное искусство. Здесь работает третий закон Ньютона. Чем больше сил и уважения к участнику инвестирует ПМ в подготовку задачи, тем качественнее результат он получит на выходе.

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

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

Еще один важный момент – поддержание видения проекта. Он должен быть конкретный, единый и общий для всех. Лид – носитель видения — должен чётко знать, что ему соответствует, а что нет. Другими словами, всегда знать, что лучше. Иначе в проекте неизбежен приход лебедя, рака и щуки – и плохо от этого будет всем.

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

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

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

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

Я использовал этот подход дважды: в конце апреля мы участвовали в Открытом Питче Игровых Проектов от ВШБИ, а сейчас – прошли отбор на конкурс Unreal Dev Contest 2021.

Оба раза участие дало значительный буст разработке. К первому событию мы подготовили блокаут уровня, завершили разработку основных кор механик, ИИ врагов, добавили первые звуки и эффекты – словом, собрали прототип, который впервые ощущался как подобие игры. На ютубе доступно моё выступление с этого мероприятия:

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

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

Кратко перечислю другие полезные принципы мотивации:

Но хватит уже работать. Пора, наконец, бабки пилит!

Допустим, работают все добровольно, вышли в релиз. Как же делить мильоны профита?

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

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

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

Выглядит ненадежно, так? Обещания, понятия и никаких гарантий со стороны организатора. Есть и другая сторона: права на интеллектуальную собственность. До тех пор, пока в каком-либо подписанном договоре не сказано иного, они принадлежат создателям контента. Использование чужой интеллектуальной собственности в коммерческом продукте – история серая, а то и черная. Владелец этой собственности может, как минимум, подать жалобу в сторе. Стору проще сначала заблокировать игру, а потом разбираться. Таким образом можно неплохо подпортить жизнь негодяю.

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

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

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

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

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

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

За нашими результатами, к слову, можно следить здесь: