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

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

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

Гости:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#какделаютигры #кди #опыт