«Когда человек развивается, продукт тоже становится лучше»: как растить разработчиков

Текстовая версия 345 выпуска подкаста «Как делают игры».

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

Гости:

  • Вячеслав Бородинов, Lead Unity Developer, Playtika
  • Эльдар Гусейнов, Technical Lead, Playtika

Ведущие — Сергей Галёнкин (Director of Publishing Strategy, Epic Games) и Михаил Кузьмин (Marketing Director, tinyBuild).

Послушать выпуск можно на сайте КДИ, в Apple Podcasts, Google Podcasts, Spotify.

Знакомство с гостями

Вячеслав Бородинов в разработке игр больше шести лет. Работает в сфере мобильных игр. Первый проект — карточная коллекционная игра, которую он самостоятельно делал под Android, iOS и ПК. После этого он поработал в нескольких студиях как Unity-разработчик. Последний год с лишним он работает в компании Playtika на позиции ведущего разработчика.

Эльдару Гусейнову 31 год, последние 11 лет он занимается разработкой, десять из них работал на аутсорсинговую компанию, одну из топ-5 крупнейших компаний Минска. Они разрабатывали банковское ПО, ПО, связанное со страхованием, с корпоративной или финансовой структурой США. Несколько раз приходилось летать в США, чтобы решать вопросы и просто познавать американскую корпоративную культуру.

При этом Гусейнов всегда увлекался разработкой игр — в свободное время он сделал несколько игр: одну на Android, другую на платформе WebGL. Последние пять лет он работал как техлид и непосредственно занимался развитием разработчиков.

Рост разработчиков, что это и зачем

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

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

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

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

Ещё есть внутренние причины, почему человек хочет развиваться. Многим становится скучно на текущих проектах, поэтому им хочется расти: брать на себя больше ответственности или познавать новые технологии, расширять или углублять свои знания. А ещё люди развиваются по материальной причине. Уровень знаний специалиста коррелирует с уровнем зарплаты, которую компании готовы ему платить. Часто люди, которые хотят больший доход, тоже понимают: нужно развиваться, чтобы требовать от рынка большей компенсации.

Как человек узнаёт, что надо развиваться

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

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

Приведу пример: когда самолёт вылетает из Вашингтона в Сиэтл, если он на один градус сбивается в начале, он долетает уже в Ванкувер. Так же и здесь: если бы Васю скорректировали в начале… Например, после онбординга мы заметили, что Васе не хватает каких-то знаний. Начинаем закрывать белые пятна специалиста. Если это не работает — уже другой вопрос, как вести себя с человеком, который сам понимает, что работает плохо, но выводов из этого не делает. Можем начать строить менторинг-планы.

Эльдар Гусейнов, Technical Lead, Playtika

Галёнкин добавил, что во многих компаниях есть перформанс-ревью, раз в полгода-год, когда приходит метрика на человека. А иногда человек сам приходит и говорит, что ему нужно подучиться в какой-то отрасли или подтянуть язык. Это разумный подход к развитию. Часто люди сами хотят развиваться, не всегда нужно ждать, когда коллеги замечают.

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

Согласен, должен быть конкретный менеджер, чтобы пообщаться с человеком и выявить, где сложности и над чем хотелось бы поработать. «Плохой код» — расплывчатое понятие. Что человеку нужно подтянуть, чтобы код был лучше? Это как минимум десяток дисциплин. Нужен другой такой же инженер или руководитель, который может подсказать, на что обратить внимание.

Сергей Галёнкин, Director of Publishing Strategy, Epic Games

Как работодателю начать решать проблему

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

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

Как работнику начать решать проблему

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

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

Эльдар Гусейнов, Technical Lead, Playtika

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

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

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

Как ставятся цели по развитию

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

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

Навык, достижимость цели, её длительность

Я могу категоризировать цели. Это сам навык, который вы будете развивать. Это достижимость — если вы ставите недостижимые цели, значит, эту цель можно убить. И третье — длительность: могут быть как краткосрочные, так и долгосрочные цели.

Вячеслав Бородинов, Lead Unity Developer, Playtika

Краткосрочные — от одного до трёх-четырёх месяцев. Долгосрочные — год. Больше года — реже: уже через год всё может измениться, чаще всего в этом нет смысла. Долгосрочные цели могут себе позволить только большие компании: как минимум на год у них есть представление о том, что они будут делать.

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

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

Мониторинг софт-скиллов

По словам Гусейнова, софт-скиллы нужно измерять, как и хард-скиллы. Освоение софт-скилла должно состоять из частей, которые можно измерить и понять, что человек действительно идёт к выполнению цели.

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

Бородинов добавил, что цель должна быть измеряемой. Конечная цель для хард-скиллов, например — уменьшить количество комментариев на код-ревью. Для измерения софт-скиллов можно собирать фидбек из команды. Можно сказать сотруднику: «Твои коллеги стали отзываться о тебе в среднем лучше, и у тебя осталась вот такая проблема». Это работает не так хорошо, как с хард-скиллами, но фидбеки от коллег тоже достаточно показательны: они говорят, насколько коллегам комфортно работать с разработчиком.

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

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

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

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

В течение полугода-года вы уже будете понимать силы разработчика, его загруженность и заинтересованность в собственном развитии. Всегда нужно быть гибким и корректировать план по конкретному человеку. Всегда нужно учитывать именно желание человека, без этого никуда.

Может стоит давать человеку рабочие таски, совместимые с его развитием?

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

Вячеслав Бородинов, Lead Unity Developer, Playtika

На обучение тратится огромное количество сил и энергии — иногда даже больше, чем на основную работу.

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

Вячеслав Бородинов, Lead Unity Developer, Playtika

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

Почему мы не подбираем ежедневные задачи, которые связаны с развитием человека? Во-первых, такое происходит, и происходит само по себе. В некоторых командах даже практикуется такая вещь, как «или плыви, или утони» — когда дают огромные задачи для новичков и так проверяют, насколько они с этой задачей справятся.

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

Эльдар Гусейнов, Technical Lead, Playtika

Также важно учитывать, что джунов и мидлов нужно учить по-разному.

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

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

Эльдар Гусейнов, Technical Lead, Playtika

Бородинов считает, что в компании должно быть чёткое определение: что такое джуниор-разработчик, что такое мидл-разработчик, потому что в каждой компании понимание разное. Иначе получатся спартанцы: кто выжил, тот выжил, а остальных увольняют на испытательном сроке. Определение должно быть конкретным и понятным. Иначе начнутся разночтения. Одни будут думать, что дают джуниору задачу на мидла, и наоборот.

В Playtika мы не используем гриды для оценки специалистов. Мы оцениваем по скилл-матрицам, где мы видим какие-то белые области и заполняем их.

Люди, которые хотят в чем-то развиваться, должны понимать практическое применение этого навыка. Глупо развиваться в чём-то, что тебе никогда не пригодится. Все мы учились в университетах и критиковали «ненужные предметы». Так и в работе: если мы хотим развить человека, а он сам не понимает, зачем ему это знание, это странно и глупо.

Эльдар Гусейнов, Technical Lead, Playtika

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

Как давать фидбек

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

Эльдар Гусейнов, Technical Lead, Playtika

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

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

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

Эльдар Гусейнов, Technical Lead, Playtika

Как к фидбеку должен готовиться лид

По словам Бородинова, важно, чтобы человек хотел получить фидбек. Он не обязательно ему понравится, но он должен его получить. Важно учитывать не только фидбек коллег и задачи проекта, но и желание, куда хочет развиваться сам разработчик. Нужно делить 50/50. 50% целей — желание самого разработчика, если они есть. 50% — требования самого проекта.

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

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

Кто, как и как часто должен давать фидбек

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

Важно просто в само начале выстроить коммуникацию. 20 минут с ним поговорить: «Привет, я твой техлид, ты можешь ко мне обращаться по таким-то вопросам. Если у тебя проблемы в текущем моменте — можем их обсудить». Если вы поможете человеку решить какие-то проблемы, он вам больше доверится. У вас выстроятся доверительные отношения — это наиболее важная часть, потому что потом человек сам придёт к вам с какими-то проблемами.

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

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

Вячеслав Бородинов, Lead Unity Developer, Playtika

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

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

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

Эльдар Гусейнов, Technical Lead, Playtika

Документируйте итоги бесед

По словам Бородинова, хорошая практика — хотя бы минимально документировать итоги больших бесед в виде какого-то письма. В ситуации, когда у вас 15 разработчиков, вы будете забывать информацию о каждом, и максимум помнить имена и какие-то яркие моменты, когда они сделали что-то либо очень хорошо, либо очень плохо. Вы не запомните пограничные ситуации. Поэтому стоит писать какие-то follow-up и письма.

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

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

Когда это происходит в моменте, когда мы специально сидим и общаемся, и человек понимает, что это время выделено специально под него — состояние серьёзности хотя бы выше нуля. В момент еды человек расслабляется и сконцентрирован не на разговоре, если давать фидбек в этот момент — тебя не будут воспринимать серьёзно.

Вячеслав Бородинов, Lead Unity Developer, Playtika

Как определять задачи на пути к цели

Гусейнов делит разработчиков на три группы. Теоретик — человек, который любит изучать теорию, читать про фреймворки и подходы, наверняка любит «Хабр». Практик — человек, который без применения навыка не видит в нём смысла. Мыслитель — человек, который любит подумать, сравнить подходы, обсудить решение, сравнить с тем, что уже применяется в проекте. Если у вас есть возможность построить персональный менторинг-план, и вы знаете, к какому типу человек ближе, вы можете построить путь достижения скилла, используя задачи, коррелирующие с типом человека.

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

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

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

Так вы получаете рост разработчиков — они имеют большее количество навыков, вследствие этого могут придумывать более правильные и элегантные решения, соответственно, качество кода и архитектуры в целом растёт. Это и повышение качества продукта, и повышение качества кода. В том числе — повышение качества документации на проекте: если документация написана сухим языком без конкретики, её неинтересно читать.

Когда разработчик понимает, что компания в него вкладывает ресурсы, это повышает лояльность человека: он понимает, что здесь о нём беспокоятся. Это невероятно важно, особенно сейчас, когда у разработчиков огромное количество предложений. И важно не только чтобы человек развился, но и чтобы он оставался развитым. Отсюда можно вывести проблему: «Мы развили человека, а потом он хочет уходить, всё было напрасно?». Увеличивая лояльность, вы снижаете риск, что человек уйдёт в ближайшей перспективе.

И последний момент — вы разгружаете других людей на проекте. Не только продакт-менеджера, но и техлида и других разработчиков. Почему? Техлид сможет тратить меньше времени на код ревью и выдачу фидбека. Если в какой-то момент фидбек становится не нужен, потому что человек и так выполняет все цели на проекте на 100%, это тоже добавляет свободного времени у лида и проджект-менеджера. Меньше нужно объяснить, что что-то плохо, меньше на это нужно тратить времени, меньше проблем с человеком.

В продуктовых компаниях есть такая категория разработчиков как продуктовые разработчики. И очень тяжело научить человека относиться к коду так, что им будет пользоваться кто-то ещё. Есть категория разработчиков, которые просто написали код, выкатили его, и на этапе QA или уже продакшена там нашли кучу багов. И потом оказывается, что разработчик просто нажал кнопку «запустить», всё запустилось — а дальше уже разберутся. Если же разработчик сильно вовлечён в собственный код, то такого не произойдёт.

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

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

Поскольку наша позиция — лид, то если кто-то из наших людей работает плохо — скорее всего, это мы недорабатываем. Мы их не доразвили, не закрыли какое-то белое пятно, не предотвратили что-то. В таком случае правильнее сказать, что техлид — плохой менеджер или плохой лид. Чтобы достигать результатов, надо развивать людей, делать их эффективными специалистами. В таком случае нужно заниматься развитием, менторингом, коучингом. Помимо того, что мы будем достигать результатов, мы будем ещё и повышать лояльность людей к компании, их Retention. Тут мы имеем win-win. Развивая людей, мы достигаем успеха как лиды и растём как технические специалисты.

Эльдар Гусейнов, Technical Lead, Playtika

Бородинов отметил, что если есть какая-то дополнительная система подкрепления с материальной стороны — это очень хорошо. Человек будет понимать, что при достижении определённых целей он не только будет лучше делать свою работу и вырастет на рынке как специалист, но и внутри компании он также будет поощрён за свои навыки. Это требует титанических усилий, и если это будет дополнительно подкреплено — это может дать значительную прибавку к мотивации.

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

Эльдар Гусейнов, Technical Lead, Playtika

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

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

Если человек просто попросил, а ты повысил — это немножко странно. Важно, чтобы учитывались навыки, которые «можно пощупать»: у человека повысились показатели. Количество закрытых задач в JIRA не берём, они обычно ни о чём не говорят. Если будет чёткая связь — это даст дополнительный буст к мотивации.

Вячеслав Бородинов, Lead Unity Developer, Playtika

Гусейнов отметил, что это относится как к хард-скиллам, так и к софт-скиллам.

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

Эльдар Гусейнов, Technical Lead, Playtika

Какие могут возникнуть проблемы

Проблемы могут быть разные. Человек может не воспринимать фидбек. Он может сказать: «Да, я согласен». Но проходит две недели — и ситуация повторяется, и так каждый раз, человек не показывает прогресса, а иногда происходит регресс.

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

Нужно вернуться к тому, как мотивировать разработчика: если это дополнительно материально подкреплено, и объясняется, как это влияет на проект — это сильно меняет отношение разработчиков к целям.

Либо человек не понимает, как ему развиться. Вы не объяснили, с какой стороны подойти и что нужно сделать. Тогда вы конкретно должны показывать, что нужно сделать. И важна измеряемость. Сильно помогает, если человек в процессе работы сам задаёт в голове вопросы: «А должно ли быть это здесь?», «А могу ли я зайти со стороны?». Здесь важно понимать: если человек не воспринимает фидбек, это не значит, что он не хочет. Обычно у проблемы другие корни.

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

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

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

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

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

Если не вкладываться в развитие работников

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

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

Эльдар Гусейнов, Technical Lead, Playtika

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

Если нет времени на обучение

В таком случае нужно договариваться с руководством. Люди могут не понимать, какие это принесёт плюсы компании: до них просто не донесли мысль. Допустим, вы начали инициативу без взаимодействия с проджект-менеджерами и директорами. Чаще всего это проблема отсутствия коммуникации. Нужно её настроить, объяснить: «У нас такие-то проблемы, мы их решим, потому что начнём развивать разработчиков, и ещё вдобавок мы получим рост лояльности и улучшение HR-бренда компании». Если это донести, чаще всего это сразу воспринимается хорошо.

Важно презентовать конкретные плюсы и преимущества, которые за этим последуют. Но нужно объяснить, что это требует огромных вложений при подготовке: нужно построить культуру, построить процесс. И самое главное — чтобы все технические лиды и проджект-менеджеры понимали, зачем это нужно. Иначе все будут концентрироваться только на своих показателях, а не на разработчиках.

Важно, чтобы это учитывались всеми командами и самой компанией, и особенно — чтобы закладывалось время. Должно быть оговорено, что, допустим, «10% времени мы закладываем на то, чтобы человек занимался индивидуальным саморазвитием».

Даже если у вас компания из 20 человек, вы тоже можете построить такой процесс у себя. Он даже будет эффективнее: у вас не будет множества согласований с менеджерами, достаточно обговорить с одним-двумя проджект-менеджерами и основателем компании. И вы намного раньше начнёте получать преимущества уже внутри компании. Плюс для маленькой компании это особенно актуально — найти сильных разработчиков тяжело, и если у вас будет взрощенные внутри сильные разработчики, они с большей вероятностью у вас останутся.

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

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

Вопросы от аудитории

Можно ли вырастить хорошую команду из дилетантов?

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

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

Сергей Галёнкин, Director of Publishing Strategy, Epic Games

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

Как студии борются с текучкой кадров?

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

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

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

По каким чекбоксам должен пройти специалист?

Это опять про матрицу. Строить конкретный рост по уровням — это не очень хорошо. Плюс вы сегрегируете людей внутри компании. Матрица навыков обычно состоит из огромного количества навыков, которые совершенно по-разному влияют на проект. Таким образом, люди никак не разделяются. Можно честно сказать: «У вас разный опыт, и у тебя такие плюсы, у тебя такие». На основе матрицы можно представить чёткий план развития человека и говорить, какие навыки наиболее критичны на проекте, а какие можно развивать более плавно и постепенно.

Вячеслав Бородинов, Lead Unity Developer, Playtika

Какие навыки важнее развивать и в каком порядке?

Гусейнов рассказал, что всё зависит от конкретной профессии.

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

Эльдар Гусейнов, Technical Lead, Playtika

Как определить потенциал роста нового сотрудника?

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

Бородинов отметил, что есть ещё один навык — это аналитические способности. Если человек на интервью отвечает на какие-то вопросы, точно не зная ответа, но рассуждая — это иногда говорит о том, что он будет заинтересован в копании, развитии.

Мы задаём вопрос: «Как бы вы сделали такую-то игру». Если человек накидает кучу идей и расскажет, почему он это выбрал — будет показательно. Мы смотрим не только технические части, но и то, как человек решает проблемы. Программисты чаще всего не знают, что им делать дальше, им нужно принять решение. Это самая важная часть любого программиста — чтобы, принимая решение, он мог выбрать из нескольких вариантов, а не был заточен под какой-то один способ.

Вячеслав Бородинов, Lead Unity Developer, Playtika

Стоит ли смотреть на возраст соискателей?

Нет. Возраст ни о чём не говорит. Человек в возрасте 40+ может быть точно с таким же живым умом, как человек в возрасте 20+, который подойдет вашему стартапу или компании.

В одном из прошлых наших выпусков гость привел хороший аргумент. Когда люди старше 40 или 50 приходят на джунов — да, у них обычно хард-скиллы на уровне джуна, но софт-скиллы более продвинутые, потому что человек уже успел поработать. Такие джуны быстрее вырастают в мидлов и лидов: за счёт софт-скиллов они имеют преимущество перед молодым поколением.

Сергей Галёнкин, Director of Publishing Strategy, Epic Games

Что лучше: сеньор с синдромом утёнка или обучаемый джун?

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

Что лучше: отношения «учитель-ученик» или самообучение?

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

Как обучать новых сотрудников без документации?

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

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

0
3 комментария
ANDRAMIR

Ладно, только гости не имеют отношения к игровой индустрии здорового человека, представляю какие кадры они нанимают

Ответить
Развернуть ветку
Oleg Khobotov

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

Ответить
Развернуть ветку
Mad Stuntman

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

Ответить
Развернуть ветку
Читать все 3 комментария
null