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

Рынок разработчиков — это рынок кандидатов. Хорошие разрабы нужны всем, и за ними идет настоящая охота. Компании готовы на многое, чтобы привлечь/удержать технарей: предлагают им достойные зарплаты, хороший офис, экстравагантные «плюшки». Но они все равно ходят угрюмыми и при первой же возможности сбегают к конкурентам.

Что вообще этим разработчикам нужно, и как исправить ситуацию?

Денежная мотивация — не вечный двигатель

В сфере ИТ текучесть кадров одна из самых высоких на рынке: в среднем сотрудник работает на одном месте 3,6 года, в больших компаниях — на 30% дольше. А разрабов поколения Z и вовсе можно сравнить с колобками, которые постоянно перекатываются с места не место.

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

Пишу для CIO/CTO/CDTO. Процессы, персонал, мотивация и другие не технические особенности работы ИТ-руководителей. https://t.me/vroderabotaetno

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

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

Нет возможностей для развития — разрабы сбегут

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

  • Низкую зарплату (65%).
  • Желание осваивать перспективные технологии (39%).
  • Стремление улучшить баланс между работой и отдыхом (36%).
  • Желание найти новые возможности для роста и лидерства (35%).

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

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

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

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

«Куда ты лезешь? Это не твоя зона ответственности. Жми себе на кнопки и помалкивай!»

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

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

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

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

«Идеи, которые я транслировал, не воспринимались ни моим непосредственным начальником, ни вышестоящим руководством. В ответ на все предложения я слышал: "Куда ты лезешь, это не твоя зона ответственности", "Это дорого", "Мы ничего объяснять не будем". Например, у меня было 4 продукта, из которых я должен был выбрать один. Я видел их плюсы и минусы, анализировал, каким софтом пользуются конкуренты, лидеры индустрии. Я предлагал выбрать дорогое, но эффективное решение с большой бэкграунд-экспертизой, которое позволяло сделать функциональную СППР, упростить работу персонала, инженеров. Да, это было дорого, но удобно, надежно и перспективно! Но компания пошла своим путем, ничего мне толком не объяснив. Так я перестал понимать цель проекта, разочаровался в принимаемых руководством решениях, продукте да и в работе в целом».

«Сгоревшие» разработчики и желание уволиться

Результаты исследования «Моего круга» показывают, что уже в молодом возрасте (25-35 лет) большинство разработчиков сталкивается с профессиональным выгоранием. Только 25% «сгоревших» сотрудников сохраняет свое место работы, остальные — меняют компанию.

Профессиональное выгорание — совокупность негативных эмоций, связанных с работой. У айтишников оно развивается примерно так:

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

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

Во время пандемии COVID-19 многим компаниям пришлось диджитализировать бизнес-процессы, и на плечи программистов легла дополнительная нагрузка. По данным Checkmarx, во время пандемии 46% разработчиков сталкивается с жесткими дедлайнами, 56% — с возросшим объемом работы. Все это приводит к увеличению числа «сгоревших» разрабов, а значит и к повышенной текучке кадров.

«Мой комфорт разработчика»: как технари выбирают новую компанию?

Агентство Signal by ONY провело исследование среди российских разработчиков и выяснило, что их запросы к новому работодателю можно разделить на 6 групп. Это основные факторы, влияющие на выбор инженеров.

1. Условия

У каждого разработчика свои запросы к условиям работы (зарплате, соцпакету, формату сотрудничества). Но, начиная с 2020 года, большинство программистов стремится работать удаленно. И дело здесь не только в пандемии COVID-19, но также в желании улучшить work/life balance — баланс между работой и личной жизнью.

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

«Мой комфорт разработчика — это высокая зарплата, ДМС, полная удаленка с первого дня работы, отсутствие принудительной вакцинации от COVID-19. Блокирующим фактором был мутный бонус. Например, в одной компании зарплата меня устраивала, но работодатель делил ее на оклад и премию. Я понимал, что премия — это рычаг давления на меня, и в случае каких-либо проблем с компанией, я могу ее не получить. К таким рискам я был не готов».

2. Оргструктура: вертикальная/горизонтальная иерархия

Запрос некоторых разработчиков — работа в компании с горизонтальной системой управления (холакратией), в которой полномочия, ответственность за принятие решений распределяются среди всех сотрудников и отсутствует связка «руководитель-подчиненный».

Холакратия — баззвордом в мире IT-бизнеса. В Силиконовой долине на горизонтальную систему управления перешли такие гиганты как Medium, Zappos. В России ее внедрили группа компаний Neti, сеть супермаркетов «ВкусВилл», банк «Точка».

3. Команда

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

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

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

4.Культура общения

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

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

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

5. Технологии

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

6. Продукт

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

«Для меня важно работать в компании, которая создает полезный продукт. Например, я отказался от собеседования в конторе, которая занималась коллекторской аналитикой. Такая работа не соответствует моим внутренним ценностям. Моя миссия — помогать людям, а не взыскивать с них долги».

Рекомендации работодателям

Как удержать разработчиков:

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

Как привлечь разработчиков:

  • Развивайте технологический бренд. Размещайте информацию о своих технологиях, задачах в блоге компании, мессенджерах, на сайтах для программистов.
  • Работайте над описанием вакансий. Что-то вроде: «Мы — крутая компания, бросай все и иди к нам, если кодишь на Java» — не прокатит. В вакансии нужно четко указывать задачи, обязанности, рабочие инструменты.
  • Общайтесь с соискателями на равных, не игнорируйте их вопросы.
  • Если у вас перспективный стек, крутые проекты, полезный продукт, рассказывайте об этом на собеседовании.
  • Внедряйте/поддерживайте удаленный формат работы.

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

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

Пишу для CIO/CTO/CDTO. Процессы, персонал, мотивация и другие не технические особенности работы ИТ-руководителей. https://t.me/vroderabotaetno

0
191 комментарий
Написать комментарий...
Какой-то никнейм

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

Знаем мы эти дедлайны: спланировал спринт, взяли на 20 сторипоинтов каждому, а потом "ой, баг на проде, срочно надо пофиксить, ой аналитика поменялась, ой ну мы же уже заказчику закоммитились на объём спринта надо сделать" (в банке было именно так) и 20 превращаются в 40, а разработчик превращается в ищущего работу ибо нах такой менеджмент

Ответить
Развернуть ветку
Семён Горбунков

Контролировать сроки надо всегда. Иначе заказчик получит срыв сроков в самом конце и будет потом слушать сбивчивые объяснения, почему так получилось.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Илья Осипов

Ну вы из крайности в крайность. Сроки контролировать-то все равно надо, просто упарываться до стояния над душой тоже не хорошо.

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

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

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Илья Осипов

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

Значит, от неё зависит принятие каких-то решений, распределение бюджета и так далее.

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

Поэтому на самом деле сроки там все равно есть. И их все равно нужно соблюдать. Условно, отчёт "во что мы как компания должны вложиться в 2022 году" устареет и будет не нужен, если сделать его к 2023.

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

Если вы делаете что-то без сроков, то это обычно что-то, что никто не ждёт и никому не нужно.

Ответить
Развернуть ветку
Семён Горбунков

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

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

Если мы говорим про проект, то проект это само по себе мероприятие с кучей неопределенностей. Вчера вы пилили проект, сегодня случилась СВО, а завтра ваше железо превратилось в тыкву, потому что условный Oracle отозвал лицензии, все облака перекрыли доступ, потому что невозможно провести платежи и прочие риски, которые невозможно предугадать.
Почитайте "Чёрного лебедя" Н.Талеба, чтобы понимать, что все эти прогнозы и расчеты иллюзорны.
Сроки по большей части нужны для создания той самой иллюзии, что все под контролем.

Ответить
Развернуть ветку
Семён Горбунков

Вы об управлении проектом вообще что-нибудь знаете? Управление рисками проекта? Вы знаете, как A380 создавался? Почитайте или посмотрите, оцените масштаб, так сказать. И подумайте, возможна ли реализация задачи без проектирования сроков.

Ответить
Развернуть ветку
Семён Горбунков

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

Ответить
Развернуть ветку
188 комментариев
Раскрывать всегда