“Не нанимай человека, которому не доверяешь, и доверяй человеку, которого нанял”.
Китайское изречение
Кто я, чем я делюсь и почему вам может быть интересно, указано в первом посте.
Дисклеймер: я не рассказываю, как правильно делать игры, но рассказываю, как экспериментировал, обучался и продолжаю развиваться в этом направлении.
Ссылки на все статьииз серии в приложении.
В предыдущих частях я уже делился мнением “почему люди могут хотеть примкнуть к инди-команде” и писал о том, где можно искать таких людей. Теперь хочу немного подробнее остановиться на том, как принимать их в команду, как с ними жить, как делить разработку и какие особенности “бесплатной разработки” мы для себя выявили.
АКЦЕНТ: я описываю только тот опыт, который получил в рамках работы над текущим проектом. Работая в других компаниях, я нанимал людей за деньги, но в S.O.S. мы все работаем на энтузиазме — бесплатно. У нас собственная нематериальная мотивация. В этом случае приоритеты онбординга отличаются от тех, что присутствуют при работе за деньги. Далее - схема работы “бесплатной команды”.
“Найм”
Притомившийся HR нашей команды.
На мой взгляд, работа с кадрами — это как секс: все об этом слышали, все в теории понимают, как это. Но пока сам не попробуешь нанимать и увольнять — не поймешь, как это работает. Совет для тех, кто собирается нанимать персонал: начинайте, как только почувствовали потребность в кадрах. И обязательно сделайте это сами, собственноручно. Заранее предстоит определить для себя:
критерии, по которым будет происходить первичный отсев
что вы можете обещать человеку в качестве поощрений или других плюсов, которые он получит от работы с вами (в краткосрочной и долгосрочной перспективе)
как объяснить человеку, почему именно к вам ему стоит прийти
как будете проверять кандидата
как оценивать результат тестового задания и формировать первичные долгосрочные договоренности
как проводить онбординг(интеграцию в команду) кандидатов
Но прием в команду — это полдела. Пока вы не “уволите” двух-трех человек, вам сложно будет понять, насколько эффективен ваш пункт №1 из вышеупомянутого списка. С каждым “выходом” пункт №1 будет корректироваться. Вы поймете, как на это влияет первое собеседование: с каждым новым отвалом (а их будет много), вы сможете точнее предугадывать, подойдет вам кандидат или нет.
После того, как вы пройдете “прием и увольнение” 3-4 раза, сможете настроить первый вариант процедуры онбординга. Цель онбординга — минимизировать количество усилий и времени на вход и выход человека из команды. Автоматизировать процесс, насколько это возможно.
В настоящее время в момент первичного знакомства мы спрашиваем:
Мотив.Зачем человек идет в геймдев? Если отвечает “хочу попробовать”, то с ним работы не выйдет. Это не тот, кто принесет вам пользу. Он будет бесконечно пробовать, а потом уйдет, так как геймдев оказался не совсем тем, чего он ожидал.
Играет ли кандидат в игры?100% тех, кто НЕ играет в игры хотя бы пару раз в неделю ради удовольствия, но очень хочет попасть в команду / хочет в геймдев, отваливается, не закончив даже тестовое задание. Если человек — не игрок, советую не тратить на него время, да и ему голову не забивать. У вас с ним просто не совпадают взгляды на фан. Вас прет от геймдева и процесса создания, а он этого фана даже не понимает.
Какие у кандидата есть еще проекты, в чем он участвует? Если человек уже состоит в какой-то инди-команде, работает, завел собаку, пошел учиться, играет в театре, любит автогонки, рисует, волонтер и вообще супер активная личность, а для полного счастья ему не хватает только участия в вашей команде, то не стоит его принимать. Он не уделит проекту достаточно времени. Оптимальная формула загрузки кандидата: “Работаю, хочу в свободное время заняться реализацией своей мечты, свободен на 20 часов в неделю”.
В нашей практике люди уходили из проекта, когда у них только второй ребенок появлялся. В классической ситуации при наличии двух родителей это — не приговор. Так что изучайте свободное время кандидата заранее.Какой опыт? Очевидно, что на бесплатной основе критически трудно найти профессионала, который сделает вам половину проекта. Также понятно, что тех, кто ничего не умеет, принимать не надо. Кандидат должен обладать минимальными знаниями. Примеры: разработчик должен быть знаком с движком и языком программирования, аниматор — с набором программ, левелдизайнер — с архитектурой или дизайном. Вот тут очень полезными будут те самые сертификаты онлайн курсов, которые сейчас лезут из каждого рекламного баннера. Для принятия на работу они не имеют решающего значения, а вот в инди-команду — да.
Особенно здорово, если кандидат хоть что-то пытался делать сам и у него есть, что показать. Пусть даже это из разряда “палка, палка, огуречик”.Оцениваем “на глаз” уровень энтузиазма.Это очень необъективный показатель. Это могут быть просто ощущения от общения или субъективная оценка степени адекватности. Вкусовщина, если так можно сказать. Она скорее дополняет портрет кандидата. Помогает, когда вы колеблетесь “брать / не брать”. Может помочь склониться в ту или иную сторону. Но основываться только на этом, конечно, нельзя.
Если при онбординге вы соблюдете хотя бы эти правила, то с высокой долей вероятности вы отберете к себе в команду неплохих ребят.
А дальше необходимо выдать кандидату тестовое задание. Я бы рекомендовал давать задачу, которая реально существует и несет пользу для проекта. Не какой-то уже закрытый кейс, не вопрос, на который вы уже знаете ответ, а что-то новое. Так вы проверите мотивацию, степень инициативы, вовлеченность и уровень самостоятельности человека. Если начнет искать ответ на вопрос сам — чудно, вам по пути. Если начнет “мумить” и спрашивать, что ему делать, как и в какой программе — ищите нового, этот так и будет отнимать у вас время. Вам нужен человек, который будет предлагать решения, пусть они будут неправильными в первое время, но для инди в начале важнее инициатива и желание развиваться. Ну и следите за тем, чтобы не давать непосильных задач. Если только вы не хотите завалить кандидата на старте.
Онбординг
В какой-то момент людей становится много, а материалов в проекте, с которыми нужно знакомить каждого, — все больше. Поэтому руководителю понадобится заместитель / помощник / новый PM, который возьмет на себя эти обязанности. Этот момент легко определить по тому, что вы не успеваете заниматься созданием продукта и увеличением его ценности.
Когда мы переросли порог в 14 человек, я перестал успевать заниматься менеджментом, онбордингом новичков, контролем за изготовлением билда, обсуждениями геймдизайнерских решений, маркетингом и всем тем, что требовало моего внимания. В этот момент продюсер привел в нашу команду Машу. Почти за полгода она успела отладить процессы онбординга, создала велкомтаск в нашем тасктреккере, сформировала на Confluence кадровую папку и другое. Можно сказать, что благодаря появлению отдельного ПМ-а, к весне 2020 года мы смогли вырасти почти до 30 человек.
Машу в нашей команде уже сменил Жора, который успешно встроился в действующую систему, и продолжает ее развивать.
Ищите себе ПМ-а, когда почувствуете, что захлебываетесь в администрировании.
Напоследок — небольшой лайфхак от команды Rummy Games. Опытным путем мы выяснили, что людям легче работается в парах. Нужно обмениваться идеями, опытом, освоенными технологиями, мнением. Очень трудно делать это одному, самим с собой. А когда появляется напарник, вам обоим легче и интереснее творить свою магию. Повышается вовлеченность и интерес к происходящему, ускоряется появление результатов по текущим задачам проекта, общий набор экспириенса и левелапы.
Период, который я обозрел: апрель 2019 — июнь 2020 года.
Резюме:
прежде чем увеличивать команду, разработайте процедуры ввода, сопровождения и вывода людей;
после того, как вас станет больше 10, задумайтесь над поиском человека, который возьмет на себя все кроссфункциональное взаимодействие в команде, кадровые вопросы, администрирование;
доверяйте новичкам, отдавайте им работу. Вы не сможете тащить все сами, функции и задачи необходимо делегировать;
культивируйте рабочую атмосферу. Вы делаете проект совместно, уважайте друг друга и поддерживайте. Если человеку нужен отдых, отпустите его на несколько дней. В конечном счете это пойдет на пользу проекту;
доверяй, но проверяй. Никого, сколько бы вы ему не доверяли, нельзя оставлять в свободном плавании. Постоянно нужно корректировать курс и наводить фокус. Иначе вы будете делать разные игры, а не одну.
Атмосфера взаимного доверия, уважения и регламентированность базовых процессов приведет вас к тому самому ощущению общего дела, чего-то большого и совместного. К тому, что может развиваться и расти. Это одна из основ нематериальной мотивации.
P.S. я бы вполне мог сделать из этого поста полноценный лонгрид, так как не написал и третьей части по этому вопросу. Но у нас впереди еще много тем, а также запуск лайв-шоу по нашей разработке, так что еще не раз поделюсь с вами чем-то из этой области.
Приложение
План постов:
Как мы собирались. 28.09.2020 (ссылка)
Как попали на первую конференцию. 05.10.2020 (ссылка)
Как начали планировать разработку. 12.10.2020 (ссылка на предыдущую часть)
Как набирали команду. 19.10.2020
Как шли на вторую выставку. 26.10.2020
Как заводили новые знакомства. 02.11.2020
Как и зачем меняли прототип. 09.11.2020
Как работали в период пандемии. 16.11.2020
Как «увольняем» людей и как принимаем новых. 23.11.2020
Как общаемся с инвесторами и издателями. 30.11.2020
Как и зачем ставим процессы и базовые пайплайны. 07.12.2020
Как обеспечиваем тимбилдинг. 14.12.2020
Как управлять всем процессом разработки. 21.12.2020
Какие особенности инди-удаленки. 28.12.2020
Как и зачем продолжать расти. 04.01.2021
Я буду актуализировать этот список с каждым новым выпуском. Есть предложения, комментарии и пожелания по темам? Пишите мне. Могу дополнять существующий план или изменять его.
Дополнительные ссылки и материалы:
автор в FB: ссылка
наш проект в Steam: Saturated Outer Space
копия нашего велкомтаска: ссылка.
Читай также
Лучшие комментарии
Наконец-то работодателю не нужно рассказывать о том, какая ты активная личность и в свободное время бегаешь марафоны, рисуешь углём, учишь китайский и летаешь на параплане))) Понятно, что вы не нанимаете людей в полном смысле слова, но мне было интересно прочитать ваш опыт, спасибо)