Чек-лист: как мотивировать команду разработчиков

Hola, Amigos!

На связи тимлиды компании по заказной разработке Amiga Артем Салеев и Руслан Ревель. Мы руководим командами по разработке более 5 лет. Поэтому знаем, какой бы сложный проект ни был, самое главное — это команда. Важно правильно ее собрать и правильно ее мотивировать, поэтому в этой статье мы поделимся своим опытом, как мы мотивируем команду.

Мы поделимся личным опытом, как сами не финансово мотивируем команду на великие подвиги. «-Купи хлеб. -Дай денег. -А с деньгами любой дурак может». Ну, вы поняли :)

Согласно исследованию Stack Overflow 2020, 75% разработчиков либо находятся в активном поиске работы, либо открыты для новых возможностей. В качестве причин программисты назвали:

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

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

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

Заказчик только в некоторых ситуациях приходит с требованием по стеку. Поэтому именно в заказной разработке у нас «развязаны руки» в выборе стека и технологий, чего обычно не бывает в продукте.

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

К нематериальной мотивации относятся:

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

У нас бывают «технические дни» как способ обучения — это совместные встречи, где общение происходит в формате обучения. То есть, разработчик кодит, а тимлид объясняет базу и теорию. Это повышает вовлеченность в процесс разработки, увеличивает доверие между командой и тимлидом, помогает справиться со сложными задачами.

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

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

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

Общение можно разделить на офлайн и онлайн. Т.к. большая часть команды не находится в Москве, мы придумали несколько способов поддержания связи:

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

Так начинающие разработчики включаются в вопросы, о которых раньше даже не задумывались. Тут польза для всех:

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

А что вы применяете в своей работе, чтобы мотивировать разработчиков?