Доброго времени, Хабр!
Сначала немного представлюсь. Меня зовут Сергей. В IT я уже более 13 лет из них в GameDev уже более восьми. Так вышло, что до написания статьи на Хабр дошел только сейчас. И дошел только благодаря подписчикам моего небольшом канала по разработке игр в telegram.
Так получилось что к одному из моих постов читатели задали очень много хороших вопросов. Спрашивали они о том что поменялось за этот год, как выглядели собеседования на позицию технического менеджмента и CTO в GameDev. Когда я начал отвечать количество текста становилось все больше и больше. Поэтому пришла мысль оформить все это в отдельную статью. Надеюсь, что материал окажется кому-то интересным, а может даже полезным.
"Кто такой CTO в GameDev?"
СТО (Chief Technology Officer) человек который несет всю ответственность за технологическое развитие продукта. Именно на его плечи ложится:
Выбор тех. стека
Дать добро на применение тех или иных архитектурных подходов
Начать изучение новых перспективных для продукта технологических решений - R&D
Оценка стоимости для компании и для продукта изменений или фичей
Достижения целей бизнеса через технические задачи
Ответственность за риски и инциденты по технической части
Отмечу пару моментов:
1. В крупных компаниях СТО может отвечать не за всю студию, а только за отдельных продукт или даже часть его. Например в Playrix на одном крупном продукте может быть сразу их несколько
2. Существует разделение на Европейский тип СТО и СТО в представлении “наших” компаний. В европейском понимании СТО редко, а скорее почти никогда не пишет код. В “нашем” представлении руку к коду игры придется прикладывать везде и часто. Мне довелось поработать на позициях обоих видов.
"Как этот год отразился на проектах, что поменялось?"
Этот год вышел странным. За него я сменил больше мест работы чем когда-либо до этого. Начался он с того, что закрылся проект который мы с командой вели к софтлончу. Не побоюсь сказать, что вся команда горела проектом и за 2 года мы сделали очень много. Да, были ошибки, которые стоили нам времени, каждый наш патч мы видели улучшения как метрик, так и качества игры. У вас конечно сразу будет вопрос: "Почему же тогда закрыли?". Тут ответ в датах и деталях, случилось то, что случилось в феврале, а все наши инвестиции были не из РФ. Я искренне благодарен всей нашей команде за то, что они делали и терпели мои(порой завышенные) требования к качеству игры. Если вы читаете это, спасибо.
Дальше впервые довелось оказаться в американской Pay to Earn студии. Штат 150+ человек. Одновременно около 10 проектов. Интересная позиция и звучала она солидно - Vice President of Engineering. Когда представляли на собеседованиях меня, каждый раз цепляло слух, уж слишком серьезно, а хотелось с кандидатом говорить чуть проще, чтобы понять что он хочет и донести что хочется получить от него. Из этой студии уже ушел я сам, спустя 2 месяца, положив себе в багаж страшные и не очень истории о процессах.
Впервые в этом году был уволен одним днем с позиции СТО без предупреждения и разговоров, потому что посмел честно говорить о том, какой текущий статус проекта и какие шаги я вижу, чтобы исправить ситуацию. После моего ухода в команде остались ребята, которых туда привел и они шли по составленному плану, даже после ухода. Могу немного себя утешить, что сам путь позволил сделать проект лучше, даже после ухода.
Впервые меня убеждал сисадмин, что он не даст серверному программисту, которого мы нанимаем, требуемое железо. Он же реализовывает сервер, а серверному программисту не нужна мощная машина. Cерверные разработчики никогда не разворачивают у себя локально окружение. Поэтому мальчик Технический Директор иди и проси дядю CEO, чтобы он дал разрешение. Я бы хотел, чтобы это было моим преувеличением ситуации, но аргументы почти дословные.
Впервые поработал с крупным паблишером из Вьетнама над мобильным мультиплеерным survival проектом. Скажу, что восточная специфика есть и общаться азиатскими командами нужно не так как с европейскими. Очень ценный опыт. Проект решили заморозить по решению заказчика. "Круг замкнулся. Год начался заморозкой одного проекта и заканчивается тем же уже на другом"
Впервые очень много общался с паблишерами и инвесторами. Ранее этот опыт был, но тут совсем другая плотность. Мы небольшой командой сделали за очень короткий срок техническое демо. И вот с ним и презентацией проекта начали ходить искать тех, кто заинтересуется. Мы прекрасно понимали, что демо не выглядит как "финальный" продукт, но как верт срез механик и за 1.5 месяца и демонстрация сил команды он достойно показывает себя. В сухом остатке получили следующее:
"Давайте купим трафик и проверим метрики" - на вертикальный срез и тех демо. Я и без закупки мог предсказать метрики
"Покажите, что команда уже выпустила из успешных проектов" - мы понимали что как студия мы noname и только наш рабочий опыт за плечами, да стартапы
"Слишком большой бюджет, а вы можете сделать это, но за стоимость леденца и за 3 месяца?"
"Мы прекратили финансировать русские команды"
"Такое нельзя сделать за 1.5 месяца, вы обманываете"
"Вы видимо чей-то готовый проект взяли за основу или из асетов собрали?"
"Мы вас не знаем, кто вам нас порекомендовал?" - очень много решает знакомство, как и везде, так и у нас в gamedev
"Извините, но полностью закрыли направление финансирования новых проектов"
Ничего - самый частый ответ
"Много ли вакансий вакансий в GameDev на тех. менеджерские позиции сейчас?"
Условно можно разделить обилие вакансий эту позицию до Мая 2022 и после. В начале года мне пришлось искать новое место и количество предложений было крайне большим. На протяжении 2 месяцев каждую неделю было по 2-3 собеседования. После мая, студии с которыми я общался начали закрывать свои двери или как минимум удаляли все вакансии. Связанно это были с событиями конца февраля.
Где-то к середине Мая 2022 волна последствия докатилась до GameDev. К концу Мая я узнал, что 3 студии, где проходил собеседование, закрылись окончательно.
До ноября 2022 я работал над мультиплеерным мобильным survival проектом под издательством крупного паблишера из Вьетнама, проект к сожалению в настоящий момент заморожен. Это стало причиной вновь оказаться на рынке в поисках нового места. Резюме было открыто и на hh, и на linkedin. Для сравнения количество просмотров в Апреле/Мае на HH в день было порядка 8+, с начала ноября редкостью был сам факт просмотра резюме кем-либо. Количество уже состоявшихся собеседований с начала ноября - 3. Скажу откровенно, что из этих 3 собеседований, 2 состоялись по причине того, что среди знакомых узнали, что вновь открыт для предложений, а не магия linkedin или hh.
"Как проходят собеседования на позицию технического менеджмента?"
С определенного момента для себя я понял, что собеседование это почти всегда тот или иной вариант “самодурства”. Каждый всегда подстраивает процесс этот под себя. И не важно ляжет ли в основу собеседования методология проведения интервью или нет. Чаще всего при собеседовании на позицию CTO может быть несколько этапов:
Общение с HR
Техническое собеседование
Общение с менеджментом продюсером проекта / CEO / CPO / всеми вместе
Каждый из этапов в конкретной компании может отличаться как и их порядок. Выделю несколько интересных случаев, с которыми сталкивался:
Обратное интервью. Когда менеджменту понравилось все, что я говорю и был пройден тех. этап. Ребята предложили провести общение/собеседование с моей стороны команды разработки. Чтобы и познакомиться и понять с кем придется работать чуть больше, услышать их мнение на то что и как происходит в компании. Прошло отлично, для себя я этот опыт отметил как очень хороший вариант и крайне полезный.
Техническое интервью у компании которая профессионально занимается проведением интервью технических специалистов разного уровня. Должен отметить, что 2 человека, которые меня собеседовали оказались крайне профессиональны. Вопросы которые они задавали были не просто “общими”, а захватывали компетенции, которые относятся к роли на которую идет собеседование.
Самым недавним событием стало собеседование за партией в League of Legends. Разговоров про непосредственно работу во время игры не было, было неформальное общение с целью узнать что за человек, с которым придется много взаимодействовать.
Почти всегда, если у компании есть иностранные заказчики, то был момент общения на английском языке
"Что спрашивают на позицию технического менеджмента?"
При собеседовании программиста важны в первую очередь его hard-скилы, т.е его умение непосредственно программировать, реализовывать системы, решать задачи, а soft-скилы должны быть, но компании могут оценивать их по разному. Когда же проходишь собеседование на СТО умение донести свою точку зрения, описать почему были приняты те или иные решения становится очень критичным.
Если у компании есть технических этап, то вопросы на нем не сильно отличаются от вопросов на серьезном собеседовании senior/lead programmer. Отличает часто их только отсутствие ограничения по темам, спрашивать могут все от render pipeline до теории графов. Возможность часть из вас удивится достаточно глубоким техническим вопросам, которых часто больше чем менеджерских. Тут я напомню, что в русскоговорящем сегменте gamedev CTO почти всегда пишет код.
Дальше будет список вопросов, на которые приходилось отвечать за этот год. Постараюсь выбрать как самые частые, так и те, что чем-то зацепили:
Опыт, что и как было сделано, какие проблемы были и как решались?
Какой тех. стек приходилось изучать и как много плотно с ним работать?
Как ставились процессы работы в команде на прошлом месте?
Как измерять эффективность команды?
Почему прошлые проекты не зашли?
Какие инструменты использовались, чтобы достигать поставленных бизнес целей?
Приходилось ли увольнять людей, сколько, почему?
Что в команде могло стать причиной для увольнения?
Как сделать техническую команду мечты?
Как мотивировать людей лучше работать для выпуска в срок?
Как бы ты организовал работу/архитектуру вот такой-то игры?
Как бы ты организовал технологический рост скила людей в команде?
Пара замечаний от себя
1. На этой позиции обязательно надо понимать, что за все технические проблемы/кризисы/риски именно ты тот, кто несет ответственность. Надо уметь обрабатывать инциденты и никогда нельзя отпускать ситуацию.
2. Ошибки были, есть и будут. Ошибки это отлично в том случае когда можно их обработать и стать лучше. Сразу уточню, это не значит что их не нужно сводить к минимуму, проводить подготовку, R&D и т.д. Все меры по подготовке позволят избежать фатальных ошибок, вернуть продукт из которых уже не всегда возможно.
3. Инциденты должны быть обработаны, причины их осознаны и нужные задачи поставлены, чтобы они не повторились.
4. Почти никогда нельзя нырять с головой в технологии ловя кураж, как это вы могли делать будучи программистом. Надо помнить, что перед вами не только технологии, но и игра как продукт. А перед продуктом ставятся бизнес цели и сроки.
5. Компромиссы неизбежны. Вам нельзя делать идеальные решения, нужно искать золотую середину, которая позволит продукту конкурировать и становиться лучше. Все должно быть подчинено пониманию приоритетов. Правильно задавать себе вопрос насколько новая фича, которую хотят получить от разработки стоит в реализации? Хорошо спрашивать у геймдизайнеров и продюсеров, на какие метрики повлияет фича и на сколько? Думать о том как сделать, чтобы процесс создания фичи/патча/контента становился дешевле с технической точки зрения.
6. Внимательно следите за качеством инструментария вашей игры. Если где-то рутина начинает побеждать, обязательно проверьте нельзя ли удешевить процесс поставив его на пайплайн инструментария.
7. Всегда будьте в курсе статуса и состояния игры. Даже если на вашей позиции вы уже не будете писать код, то знать: как реализованы фичи, какие при этом были потрачены ресурсы, какой перфоманс показывает игра, какие текущие метрики и показатели и т.д.
8. Стоит знать тех с кем вы работаете, кого наняли в команду разработки. Это не значит, что нужно стать “своим человеком”, нет. Это значит что рук у вас самих не хватит на все. А значит вы должны доверять своей команде, чтобы она стала надежной опорой. И вы знаете их сильные и слабые стороны.
9. Приходя на существующий проект, который уже разрабатывается какое-то время - никогда, не начинайте сразу ужасаться тому в каком он состоянии и пытаться переписать все, обвиняя попутно команду в некомпетентности. Моя практика показывает, что проведя начальный аудит получится составить намного более цельное представление о том с чем придется работать и почему оно сейчас в текущем статусе, а главное начать поиск ответа на вопрос: “Как лечить основные боли проекта так, чтобы он не перестал получать регулярные патчи”.
На этом все. Всех с Новым годом.
