Какова нормальная текучесть кадров среди разработчиков и влияет ли она на продуктивность?

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

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

Для меня такая текучесть кадров безумна, и я думаю, что что-то не так в самом отделе. Во всяком случае, это мой инстинкт. Я вижу, что это вызывает много задержек при адаптации разработчиков и так далее. Но мой друг-разработчик в команде говорит, что «нам повезло, что они продержались так долго». Он был здесь всего 6 месяцев и спросил о процессе для рекомендаций.

Я в Торонто, Канада, если кто-то спрашивает.

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .
Я хотел отредактировать это, в частности заголовок, поскольку он на самом деле не соответствует приведенным ниже ответам, но я не уверен, чего вы на самом деле хотите здесь достичь. Просто для того, чтобы подтвердить, является ли эта скорость оборота безумной? Или вы тоже хотите выяснить, как найти первопричину/решить проблему?
Знает ли ваше руководство, что оно существует не для того, чтобы заставлять людей соблюдать сроки, а для того, чтобы сделать все, что в их силах, чтобы помочь людям работать оптимально, чтобы уложиться в сроки? Я думаю, проблема в том, что ваш менеджер думает, что он может просто сидеть и ждать, пока вы увязнете в проблемах, вместо того, чтобы на самом деле заниматься управлением, чтобы помочь вам. Проблема не на стороне разработчика.
Выходные интервью. Что они говорят? Это даст вам ответы, которые вам нужны.
@Lilienthal Это было причиной моего близкого голосования. Вопрос, заданный в заголовке, слишком конкретен, чтобы дать надлежащий ответ на вопросы и ответы, и собрал кучу интересных ответов на смежные вопросы, не затрагивая тот, который был задан.

Ответы (10)

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

Ваша текучесть кадров кажется мне безумной. Это больше, чем я ожидаю от агентов колл-центра. Если вы действительно имеете в виду, что вам нужно найти 35 сотрудников, чтобы поддерживать постоянный уровень из 25 активных разработчиков, у вас будет коэффициент колебаний 140%. Должно быть где-то между 10 и 20%. (В 2017 году в ИТ-секторе я обнаружил, что общий уровень текучести кадров составляет 16% в Германии и (2) 18% в США в 2016 году.)

и влияет ли это на производительность?

Да, это сильно влияет на продуктивность. Просто быстрая и грязная приблизительная оценка:

  1. Ваши новые разработчики должны изучить технологический стек, процесс разработки, бизнес-требования и т. д. Допустим, это занимает половину их времени в течение первых 6 месяцев (100%-0% в линейной регрессии). Это примерно 3 потерянных месяца.

  2. Правильная рабочая атмосфера, командная динамика и организация офиса могут сильно повлиять на производительность разработчиков — согласно некоторым исследованиям (1), в 10 раз!

Таким образом, если ваш средний разработчик остается только около 8,5 месяцев, сначала обучаясь, а затем быстро демотивируясь, ваша команда из 25 человек имеет примерно такую ​​же производительность, как счастливая и профессиональная команда из 2-3 разработчиков!


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

Любой бизнес, который считает людей расходным материалом, навредит себе!

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


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


(1) Как объясняется в книге «Peopleware» Тома де Марко и Тимоти Листера.

(2) https://www.glassdoor.com/employers/blog/turnover-retention-rates/

(3) Статья в блоге о потере таланта, спасибо @Josh Johnson.

Вы, вероятно, можете уменьшить это количество, потому что команда из 2-3 разработчиков может общаться более эффективно, чем 25.
+1 за требования к обучению и т. д. И прекрасная возможность упомянуть еще одну книгу: «Мифический мужской месяц». Вы никогда не сможете узнать, сколько разработчиков и сколько времени уходит на разработку [внедрение какого-либо программного обеспечения], если вы постоянно поручаете выполнение этой задачи новым разработчикам. Просто подумайте о том, как должна выглядеть документация , когда вы пытаетесь добиться успеха при таком большом обороте!
Чтобы добавить к вашему ответу, есть дополнительные расходы, связанные с тем, что с таким большим количеством разработчиков кодовая база, вероятно, выглядит дерьмово (поскольку не было бы возможности координировать всю эту работу). Даже если проблемы с управлением будут решены, создается впечатление, что все проекты придется выбросить в мусорное ведро и начать с нуля, чтобы каждый новобранец не бежал в панике. И чем дольше они будут откладывать решение управленческих проблем, тем выше будут будущие затраты.
@Alexander Ваша ссылка очень интересна, но в ней говорится о «нормальном» старом коде, протестированном и работающем в течение некоторого времени. И эмпирическое правило означает, что это чаще всего верно, не всегда. Стоимость рефакторинга следует сравнивать со стоимостью невозможности удержать ни одного разработчика более чем на несколько месяцев. Я знаю, что не стал бы трогать кодовую базу ОП палкой даже за двойную зарплату.
@Echox: Что бы я сделал, если бы это была моя компания, я бы оставил команду работать как есть. В то же время я бы получил хорошего IT-менеджера с полномочиями построить удаленную команду из 3-4 человек. Затем я начинал давать им одну задачу за другой в порядке важности, пока мне больше не нужна была первоначальная команда.
Следует ли рассматривать разработчиков как агентов колл-центра в том смысле, что их можно легко заменить?
@MapleLeafsFan: Это то, что вы узнали из моего ответа? Извините, я немного в шоке! никто не должен считаться легко поддающимся обмену. По крайней мере, если вы хотите иметь здоровый бизнес. Некоторое время работал здесь, в Германии, в колл-центре и занимался статистическим анализом. Замена агента обошлась нам примерно в 10 000 евро, поэтому сокращение колебаний было реальной целью экономии денег. Замена программиста, безусловно, будет стоить вам от 50 000 до 300 000 в зависимости от зарплаты, квалификации и времени в компании. Так что, помимо того, что это вредно для производительности, это чертовски дорого!
@MapleLeafsFan Нет. Нет, не должны. К сожалению, такое отношение, по-видимому, распространено среди некоторых менеджеров и само по себе является основным индикатором других токсичных отношений и практик на рабочем месте.
@MapleLeafsFan не для большинства операций; компании потеряли много денег, пытаясь сделать вид, что экспертиза не требуется. Они ближе к дипломированным профессионалам, таким как юристы и бухгалтеры, даже если эта профессия не зарегистрирована. Есть причина, по которой Google платит своим разработчикам несколько сотен тысяч долларов.
Ваш ответ в порядке, но также хорошо знать, что Германия несколько специфична, когда речь идет о средней продолжительности пребывания людей на работе. Нет, я не смотрел статистику, но работал в нескольких странах, и нигде люди так не осуждают смену работы, как в Германии.
@BigMadAndy У вас есть эмпирические доказательства в поддержку вашего утверждения? Я работаю 25 лет в Германии в сфере информационных технологий. Я никогда не сталкивался с тем, что на это не одобряют — кроме смены работы, которая осуждается повсюду, по крайней мере, если вы верите в ответы на многочисленные вопросы по этой теме здесь.
@BigMadAndy Я финансирую число для США в размере 18%, что примерно соответствует моему диапазону и, вероятно, во многом объясняется общими законами о занятости в США по сравнению с типичным 3-месячным периодом уведомления в немецких контрактах.
Процесс, когда хорошие сотрудники уходят на более зеленые пастбища, оставляя менее талантливых сотрудников с меньшими перспективами, называется эффектом Мертвого моря brucefwebster.com/2008/04/11/…
@JoshJohnson Спасибо! Не знаю этого термина. Посмотрим, может быть, добавим в ссылки.

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

Это абсолютно не проблема текучести или разработчиков. Это токсичная среда и, как следствие, неправильная проблема с PM!! Это должно быть исправлено как можно скорее, чтобы проект можно было спасти .

Менеджер хочет больше разработчиков, так как все новички в кодовой базе.

Закон Брукса (спасибо @Benjamin, но я использовал другую ссылку) доказывает, что лучшее, что вы можете сделать, чтобы убить проект, — это нанять больше сотрудников, ложно полагая, что это компенсирует накопленные вами задержки.

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

Позвольте мне добавить знаковую цитату о том, что происходит в вашей компании.

Если сегодня забеременеют 9 женщин, через 9 месяцев у вас родится 9 детей, а не 1 ребенок через месяц.

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

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

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

По моему опыту, некоторые проекты по политическим или маркетинговым причинам просто не могут позволить себе отсрочку.

также известный как en.wikipedia.org/wiki/Brooks%27s_law -> добавление рабочей силы в поздний программный проект делает его более поздним
Пример с фермой не подходит. В условиях корона-кризиса немецким фермерам не хватает обученных сборщиков урожая из Восточной Европы. Обучение немецких студентов или безработных, которые могут уйти через месяц (из-за тяжелой работы), отнимает у фермеров много времени. Поэтому некоторые фермеры не хотят нанимать неподготовленных сборщиков урожая из Германии. По крайней мере, в отношении спаржи и клубники это так. Я не знаю, влияет ли это на сбор урожая яблок... . В любом случае: сельское хозяйство - плохой пример ;-)
@daniel.neumann: Думаю, я бы защищал сравнение с сельским хозяйством. Предположим, что сборщики урожая обучены, а не полностью необучены. Тот, кто может собрать спаржу на одной ферме, может быть продуктивным в течение дня на другой. Но даже опытные, обученные программисты будут иметь примерно 6 месяцев времени на ввод в эксплуатацию, чтобы работать продуктивно в другом магазине программного обеспечения.
Это хороший ответ. К сожалению, ошибочное представление о том, что добавление дополнительных людей означает ускорение отложенного проекта, невероятно распространено в ИТ, а также в других функциональных областях/отраслях.
«Забеременею сегодня 9 женщин» — поверьте мне, я пытаюсь. Это сложнее, чем кажется!
@DanielR.Collins Вы должны сравнить обученных сборщиков спаржи с обученными сборщиками клубники ;-) . Но, конечно, сроки обучения сборщиков меньше.
«Проект» из учебников — это A unique and unrepeatable resource demanding set of complex tasks that has novelty and risks [...]. Фермерство — это не проект, вождение поезда — это не проект (но требует квалификации и сертификации), управление воздушным судном — это не проект (требуется квалификация для типа самолета), программное обеспечение — это всегда проект

Если вы теряете их в 8 месяцев, они решают уйти в 6.

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

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

Но мой друг-разработчик в команде говорит, что «нам повезло, что они продержались так долго».

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

Что касается того, вредит ли проекту высокий отток разработчиков, то последние 8 месяцев я работаю исключительно на одной системе. Другой разработчик проекта работает здесь уже год. Проекту 4 года. По моим оценкам, 1/4 проделанной мной работы так или иначе дублируется, поскольку мы не знали, что функциональность уже создана. Достаточно проблематично для вас?

«Держу пари, он сам ищет работу». Не нужно делать ставки, в вопросе говорится: «Он здесь всего 6 месяцев и спросил о процессе для рекомендаций » .
Такой отличный момент. Если оценить нормальное время выхода на производительность примерно в 6 месяцев, это приводит к возможности того, что абсолютно никто не выполнял никакой продуктивной работы в последнее время. Интересно: эта команда когда-либо производила какие-либо результаты?
@BenVoigt Я совершенно не смог прочитать следующую строку. Да он уже на выходе...
@DanielR.Collins, мои друзья в банках поспешили быстро ввести код, поэтому я подозреваю, что ответ положительный, но ... Они не дали мне много подробностей о коде, но другой друг работает младшим сотрудником в компании, и они есть веб-страница, которая загружает 160 вызовов API, поскольку никто не удосужился что-либо консолидировать. Так что я подозреваю, что они просто отправляют что угодно.

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

Отлично, ваша проблема имеет огромное значение, и вам нужно ее решить. А в чем твоя проблема? Оборот — это симптом, а не проблема.

У вас проблемы с культурой.

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

  1. Вам нужно немедленно устранить враждебное или токсичное поведение.
  2. Определите своих самых высокопоставленных людей. Они заслуживают доверия? Они уважительны? Как они поднимают настроение окружающим? Если вы не можете ответить на эти вопросы положительно, то это ваша первая точка решения. Они должны быть выровнены в социальных навыках, лидерстве и сопереживании. Если они не будут, их необходимо заменить.
  3. Прислушайтесь к болевым точкам. У ваших индивидуальных участников будет МНОГО жалоб. Свяжите их вместе в общие точки процесса и используйте это, чтобы определить улучшения процесса, которые облегчат эту боль.
  4. Отделите людей от проблемы. Опишите проблему тому, кто понятия не имеет, о чем вы говорите. Не используйте имена; использовать только роли. Если вы не можете отделить человека от проблемы, проблема и есть человек .

Отлично, вы начали налаживать процесс. А как насчет людей?

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

  1. Как выглядят ваши программы обучения?
  2. Какие существуют стимулы для продвижения?
  3. Как вознаграждаются успешные действия?
  4. Как люди привлекаются к ответственности за ошибки?
  5. Как их работа становится ценной?

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

А как насчет токсичных/злых людей?

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

  1. Вы должны слушать их. Услышать их проблемы. Помогите им обойти их. Это требует времени. Это требует поощрения.
  2. Соедините их со сверстниками. Объясните им, как их поведение влияет на окружающих. Ожидайте от них лучшего. Скажите им, что это неприемлемо и что вам нужна их помощь.
  3. Найдите их ценности и помогите им достичь их. Если у клиента есть работа, сделайте все возможное, чтобы помочь ему в этом. Если это взаимодействие с другими областями организации, найдите возможности, чтобы это произошло.
  4. Выявите их токсичное поведение и сразу же примите меры, как только это произойдет. Не надо забивать людей. Просто дайте понять, что вы смотрите и ожидаете лучшего.

Вау, здесь есть чем заняться. Я проблема?

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

  1. Будьте максимально честны и открыты со своими людьми.
  2. Руководству необходимо поддерживать сплоченное и консолидированное сообщение.
  3. Руководство должно уважать их индивидуальный вклад и делать все возможное, чтобы поднять его.

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

Пока культура не будет исправлена, люди будут продолжать уходить, а текучесть кадров будет оставаться на эпическом уровне.

Если бы я еще не работал с отличной командой, я бы работал на вас в мгновение ока.
@psaxton - Спасибо, я ценю это.
Думаю, у меня совсем другое понимание toxic people. На мой взгляд, существует огромная разница между людьми, которые злятся/жалуются/критикуют/... и людьми, которые на самом деле вредны для окружающей среды. Работа с жалобщиками на самом деле может завоевать их лояльность и помочь вам значительно улучшиться как организации (или как личности). Однако на самом деле токсичных людей (а их немного) просто необходимо удалить.
@fgysinreinstateMonica: Если вы не можете перевоспитать токсичного человека или не хотите вкладывать в него необходимые усилия, то - Да, это абсолютно правильно. Если у вас есть роскошь времени и немного терпения, токсичного человека можно реабилитировать, и во многих случаях этого человека можно вернуть к значимому источнику ценности. Существует также оценка стоимости, чтобы решить, стоит ли конечная стоимость самих инвестиций. Стоит ли попытка реабилитации больше или меньше, чем поиск замены? Откровенно говоря, есть люди, для которых эти вложения не окупятся.

Вам нужно 35 человек в год, чтобы сохранить 25 вакансий.

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

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

Влияет ли это на производительность? Какая производительность? Я бы не ожидал, что там вообще будет какая-то производительность. У вас есть новички, которые должны сначала изучить окружающую среду, и нет никого опытного, кто мог бы их научить. Отсутствие продуктивности у новых людей и снижение производительности у не совсем новых людей в течение четырех месяцев. Затем, когда они почти готовы выполнять какую-то работу, предыдущее поколение уходит, и нужно учить следующее поколение. Как только это будет сделано, им надоест, и они уйдут. Никакой работы не делается.

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

35 человек на 25 мест не означает, что они заменяют ВСЕХ. У них легко может быть ядовитый сотрудник(и), который останется с очень плохим управлением.
@DarkMatter: Если они не заменяют всех каждые 8 ​​месяцев, они заменяют половину команды каждые 4 месяца. Это вряд ли делает его лучше.
Я ожидаю, что у них есть ядро ​​из 6-12 токсичных сотрудников, недееспособное руководство, и новым людям требуется 2-3 недели, чтобы понять, насколько это плохо, и несколько месяцев, чтобы найти новую работу. Так что да, «лучше» — не то слово, но, вероятно, так оно и есть.

Пока нет идеального ответа на вопрос «Что такое нормальный оборот с разработчиками?» (это будет варьироваться от компании к компании, и все люди разные), я бы сказал, что большую часть времени разработчики будут стараться оставаться в одной компании по крайней мере 2 или 3 года, если они могут.

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

Если разработчик не задерживается больше года, значит, что-то его не устроило. Уход так скоро может навредить его карьере:

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

Так что я бы сказал, что любая компания с оборотом менее года делает что-то очень, очень неправильно. Но тогда ответы Даниила и usr-local-ΕΨΗΕΛΩΝ дают лучшие объяснения по этому вопросу.

Есть статистика по среднему обороту в определенной сфере. Это можно было бы рассматривать как "нормальный"
Это будет зависеть от области, размера компании, опыта рекрутов, страны ... Может быть, кто-то найдет статистику оборота младших разработчиков в банках в Торонто (а это как раз ситуация ОП), но я чувствую, что мой ответ дает достаточно хорошее среднее значение.
Если средний показатель по отрасли составляет, скажем, 15%, а у вас около 20%, вы можете сказать, что это выше нормы — возможно, это объясняется региональными или демографическими различиями или, что более вероятно, культурой компании. Кроме того, откуда вы взяли, что OP нанимает только младших разработчиков?
Я сам выступаю в качестве разработчика. Я считаю минимум 2 года работы в компании. Единственный раз, когда я уходил раньше, это когда компания не могла меня поддерживать (одна закрылась, у другой не было работы для меня), единственные другие причины, по которым я бы ушел до этого, это если бы это была действительно враждебная или токсичная рабочая среда, или если что-то произошло в моей личной жизни.
@Daniel Это не написано, но я предположил, что опытным людям легче замечать токсичные компании и избегать их. Кроме того, я чувствую, что мы потратили слишком много слов на введение в одно предложение к моему ответу. Вы не согласны с оценкой в ​​2 или 3 года? Вы хотите что-то добавить?
@Echox Я хочу проголосовать за этот вопрос, поскольку он подчеркивает точку зрения сотрудников. Но просто неправильно говорить, что нет «нормального» для колебания в моем понимании английского слова, как в (нормальный = соответствующий стандарту; обычный, типичный или ожидаемый.). Я бы также сказал, основываясь на эмпирических данных и опыте, что 2-3 года могут быть типичными для первой работы, но средний показатель по отрасли находится в диапазоне 5-7+ лет.

Если вам нужно нанять 35 разработчиков в год, чтобы заполнить 25 вакансий, ваш средний разработчик останется на 8,6 месяца. То есть, действительно, безумно коротко.

Такие показатели текучести кадров могут иметь огромное влияние на производительность. Этому способствуют несколько факторов:

  • В зависимости от сложности проекта и его опыта разработчику требуется от нескольких недель до нескольких месяцев, пока он не достигнет своей максимальной производительности, потому что он должен привыкнуть к существующей кодовой базе, стилю программирования своего соразработчика, стандартам компании, внешним комплектующие и прочее как таковое. Чтобы упростить математику, предположим, что онбординг занимает 2 месяца, а разработчик остается на 8 месяцев. Через 2 года это 6 месяцев адаптации. Вы бы сэкономили 4 месяца адаптации, если бы он остался на 2 года.
  • Остальной команде тоже нужно привыкнуть к новому разработчику. Это включает в себя все, что вам нужно знать по причинам управления проектами: Насколько он быстр? Насколько он компетентен? Он хорошо общается? У него есть особые потребности? Без всей этой информации управление проектом будет основываться на шатких предположениях.
  • Высокая текучесть кадров усугубляет некоторые типичные проблемы разработки программного обеспечения, такие как плохие процессы или плохая документация. Если каждый знает, чего от него ждут, и знаком с кодовой базой, то эти пункты по-прежнему важны, но по ним можно пойти на компромисс. Если вы сделаете это в среде с высокой текучестью кадров, каждый из множества новых разработчиков потратит много-много часов своего (и чужого!) времени, пытаясь понять, как все работает и что именно он должен делать.
  • Знания теряются, и поэтому их нужно приобретать заново. «О, вам нужно знать, как интегрировать X и Y? Ну, Дейв сделал это 2 года назад, он копался в спецификациях в течение месяца. Он ушел, как и все, с кем он когда-либо говорил об этом. переделайте. Здесь вы можете найти спецификации...".
  • Гораздо сложнее найти процессы, которые работают для вашей команды, потому что ваша команда — очень изменчивая вещь.

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

Уведомление! В основном это мнение основано. Может быть подвержен предвзятости «анекдотических свидетельств», основанных на моем собственном опыте и моих знакомых. Более объективные предположения находятся в разделе «Резюме».

Я хотел бы опубликовать ответ с совершенно противоположной точки зрения.

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

Расскажу немного свою историю. Работаю в банковской сфере недолго (всего 4 месяца). Это было вскоре после учебы, потому что они набирали студентов через какой-то рынок вакансий , организованный в моем университете.

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

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

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

Краткое содержание

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

  • Они набирают огромное количество молодых рабочих, в основном выпускников.
  • У них есть эффективный процесс адаптации и учебные пособия, обновленные и готовые к использованию. Обычно работники, проработавшие в течение среднего или короткого промежутка времени, и новички обучаются только что принятым на работу более молодым коллегам. Ветераны сосредоточены на своих важных задачах. Их беспокоят только в случае необходимости.
  • Большинство сотрудников, покинувших компанию, — это люди, проработавшие там менее 1 года.
  • Люди, которые вписываются в конкретную рабочую среду, остаются в ней годами.
  • Люди, которые получили конкретные и важные знания в области/бизнесе, обычно остаются в компании. Они обычно мотивированы более высоким повышением / продвижением по службе.
Итак, вы только что начали работать и имеете опыт работы в одном конкретном банке , и вы готовы высказывать суждения не только о банковской работе в целом, но и о том, что люди, берущиеся за эту работу, должны быть мотивированы жадностью. . Боже. Моя жена работает в банке, и здесь царит самая непринужденная атмосфера. У меня есть друзья, работающие программистами в банках, и они говорят, что это довольно скучная культура.
Я согласен с @Kevin в том, что организации Fintech сильно различаются по своей среде и культуре. Некоторые из них очень спокойные и действительно отличные места для работы. Другие - аквариумы с акулами.
Буах, я работал в нескольких отраслях и определенно не назвал бы банковское дело худшим. Также трудно обобщать такие вещи, как культура. Когда-то я работал в одной и той же компании в двух странах, и культура была очень разной (я знаю эти две страны достаточно хорошо, чтобы понять, что различия в корпоративных культурах не были основаны на культурных различиях между странами).

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

  1. Что ожидания, возлагаемые на ваших разработчиков, реалистичны.
  2. Чтобы у ваших работников было достаточно времени для выполнения этих задач.

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

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

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

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

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

Люди могут уйти просто потому, что ваш процесс не работает.

Я работал в ряде компаний в нескольких странах; по моему опыту, разработчики обычно рассчитывают остаться на должности 2-3 года; затем они ищут продвижения по службе или уходят. В большинстве компаний, где я работал, годовая текучесть кадров составляла около 20%; мы могли бы уменьшить это, увеличив финансовое вознаграждение, улучшив возможности карьерного роста и найдя интересные проекты для людей, над которыми они могли бы работать.

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

У вас тоже есть проблема порочного круга.

Senior management have high, possibly unrealistic expectations.
They put pressure on middle management to deliver against those expectations.
Middle management tries what they can; adding more developers (thus bumping into Brooks' law), and then shouting.
Shouting leads to reduced morale among the team.
Reduced morale reduces productivity - unhappy people don't work as hard.
Reduced morale causes people to leave, which also reduces productivity.
Growing the team leads to a reduction in productivity through recruitment efforts, and Brooks' law.
Reduced productivity further increases the gap between expectations and output.

Промыть и повторить...

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

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

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

Лучший известный мне способ разорвать порочный круг — это найти способ изменить ожидания и поставить перед разработчиками достижимую цель. Однажды я унаследовал подобную ситуацию, и мы договорились, что вместо того, чтобы беспокоиться о полном 18-месячном объеме проекта, мы выберем трехмесячный временной горизонт и договоримся, что мы можем сделать в эти сроки. Мы согласовали набор результатов «должен/должен/не будет» между руководством и разработчиками и согласовали пути решения проблем, поднятых разработчиками («требования недостаточно хороши», «мы никогда не получаем полезной обратной связи», «в офисе слишком шумно») и т. д. Мы использовали этот 3-месячный мини-проект, чтобы заново настроить культуру и немного восстановить доверие.