Не технарь, но знаю, что здесь водятся технари, поэтому и спрашиваю здесь. Я являюсь относительно новым специалистом по подбору персонала и поиску талантов в банке, где нам постоянно приходится нанимать больше разработчиков, и недавно меня перевели в этот проект. Всего у нас около 25 разработчиков, и нам нужно привлекать 35 человек в год.
Найм стал проектом, потому что группа страдает от задержек с проектами и потому что старший менеджер накричал на менеджера технической группы за то, что он не может сдать проекты вовремя. Это вызвало жалобу, и, поскольку менеджер — женщина, а старший менеджер — мужчина, эту проблему с криками необходимо решить. Менеджер хочет больше разработчиков, так как все новички в кодовой базе.
Для меня такая текучесть кадров безумна, и я думаю, что что-то не так в самом отделе. Во всяком случае, это мой инстинкт. Я вижу, что это вызывает много задержек при адаптации разработчиков и так далее. Но мой друг-разработчик в команде говорит, что «нам повезло, что они продержались так долго». Он был здесь всего 6 месяцев и спросил о процессе для рекомендаций.
Я в Торонто, Канада, если кто-то спрашивает.
Какова нормальная текучесть кадров среди разработчиков
Ваша текучесть кадров кажется мне безумной. Это больше, чем я ожидаю от агентов колл-центра. Если вы действительно имеете в виду, что вам нужно найти 35 сотрудников, чтобы поддерживать постоянный уровень из 25 активных разработчиков, у вас будет коэффициент колебаний 140%. Должно быть где-то между 10 и 20%. (В 2017 году в ИТ-секторе я обнаружил, что общий уровень текучести кадров составляет 16% в Германии и (2) 18% в США в 2016 году.)
и влияет ли это на производительность?
Да, это сильно влияет на продуктивность. Просто быстрая и грязная приблизительная оценка:
Ваши новые разработчики должны изучить технологический стек, процесс разработки, бизнес-требования и т. д. Допустим, это занимает половину их времени в течение первых 6 месяцев (100%-0% в линейной регрессии). Это примерно 3 потерянных месяца.
Правильная рабочая атмосфера, командная динамика и организация офиса могут сильно повлиять на производительность разработчиков — согласно некоторым исследованиям (1), в 10 раз!
Таким образом, если ваш средний разработчик остается только около 8,5 месяцев, сначала обучаясь, а затем быстро демотивируясь, ваша команда из 25 человек имеет примерно такую же производительность, как счастливая и профессиональная команда из 2-3 разработчиков!
Редактировать из-за комментариев: некоторые рабочие места имеют более высокую естественную текучесть кадров. Как правило, это низкооплачиваемая, низкоквалифицированная работа. Эти рабочие места часто берутся людьми до тех пор, пока у них не будет чего-то лучшего, например, студентами и т. д. Это не значит, что это где-то хорошо. Замена работника всегда стоит денег и, как правило, ухудшает качество и производительность!
Любой бизнес, который считает людей расходным материалом, навредит себе!
Если вы поговорите об этом с руководством, иногда полезно выразить это в денежном выражении. Помимо расходов на подбор персонала, вы также постоянно вкладываете деньги в профессиональное развитие и изучение предметной области каждого сотрудника. Это человеческий капитал компании. Как только сотрудник увольняется, вы теряете эту инвестицию. Это примерно то же самое, что не менять масло в автопарке вашей компании, а вместо этого ломать автомобили и заменять их каждые полгода. Вы можете легко потерять миллионы таким образом!
Кроме того, вы не хотите получить нулевую флуктуацию. Небольшой приток новых идей — это хорошо, и не все люди будут соответствовать команде на все времена. Опасно то, что в такой токсичной рабочей среде вы, вероятно, теряете хороших людей и оставляете только тех, кто не может найти лучшую работу или нашел способ продолжать получать зарплату, при этом дистанцируясь так далеко от компании, в которую они берутся. мало интереса к своим целям (они ушли в отставку внутри). (3)
(1) Как объясняется в книге «Peopleware» Тома де Марко и Тимоти Листера.
(2) https://www.glassdoor.com/employers/blog/turnover-retention-rates/
[...] группа страдает от задержек проектов и из-за того, что старший менеджер накричал на менеджера технической группы за то, что он не может сдать проекты вовремя, и это вызвало жалобу, и потому что менеджер - женщина, а старший менеджер мужчина, эту проблему с криком нужно решить.
Это абсолютно не проблема текучести или разработчиков. Это токсичная среда и, как следствие, неправильная проблема с PM!! Это должно быть исправлено как можно скорее, чтобы проект можно было спасти .
Менеджер хочет больше разработчиков, так как все новички в кодовой базе.
Закон Брукса (спасибо @Benjamin, но я использовал другую ссылку) доказывает, что лучшее, что вы можете сделать, чтобы убить проект, — это нанять больше сотрудников, ложно полагая, что это компенсирует накопленные вами задержки.
Каждый новый сотрудник является новичком в кодовой базе, и всем нужно наращивать темпы.
Позвольте мне добавить знаковую цитату о том, что происходит в вашей компании.
Если сегодня забеременеют 9 женщин, через 9 месяцев у вас родится 9 детей, а не 1 ребенок через месяц.
В рамках управления проектами добавление новых ресурсов требует приостановки действия существующего ресурса (кодирования) для обучения новых сотрудников. Это немедленно приводит к задержке проекта, что противоречит ожиданиям вашего менеджера.
Страдающий проект не получит дополнительных ресурсов, особенно в индустрии программного обеспечения: он просто пострадает от новых сотрудников. Я не собираюсь быть намеренно грубым, но звучит так, как будто ваш менеджмент пришел из мира сельского хозяйства и фермерства, где вы можете нанять новый комбайн за одну ночь.
В конце концов, ваша текучка безумна, потому что у проекта есть проблемы с управлением. Я не могу вдаваться в подробности стратегии исправления, но, безусловно, пересмотр сроков был бы моим первым выбором. И, в конце концов, в этот момент проект настолько критичен, что его нужно спасти или убить.
По моему опыту, некоторые проекты по политическим или маркетинговым причинам просто не могут позволить себе отсрочку.
A unique and unrepeatable resource demanding set of complex tasks that has novelty and risks [...]
. Фермерство — это не проект, вождение поезда — это не проект (но требует квалификации и сертификации), управление воздушным судном — это не проект (требуется квалификация для типа самолета), программное обеспечение — это всегда проектЕсли вы теряете их в 8 месяцев, они решают уйти в 6.
Я предполагаю, что большинство людей уходят на другую работу. Обычно требуется некоторое время, чтобы найти другого, который ищет неполный рабочий день и предполагает, что они несколько избирательны. Скажем, месяц, если они хороший разработчик. Добавьте еще месяц, чтобы получить зарплату в ожидании начала новой работы. Это делает решение уйти в 6 месяцев.
Ваши разработчики в основном дают ему испытательный срок, а затем решают перейти в другое место.
Но мой друг-разработчик в команде говорит, что «нам повезло, что они продержались так долго».
Он комментирует вашу компанию, а не рынок разработчиков в целом. Бьюсь об заклад, он сам ищет работу.
Что касается того, вредит ли проекту высокий отток разработчиков, то последние 8 месяцев я работаю исключительно на одной системе. Другой разработчик проекта работает здесь уже год. Проекту 4 года. По моим оценкам, 1/4 проделанной мной работы так или иначе дублируется, поскольку мы не знали, что функциональность уже создана. Достаточно проблематично для вас?
Когда вы задаете вопрос, становится ясно, что вы знаете, что у вас проблема с текучестью кадров. Это не новая информация. Многие ответы были ориентированы на воздействие и описание затрат, которые несет такой оборот. Это действительно отличная информация, и ни одна из них не поможет вам это исправить.
Отлично, ваша проблема имеет огромное значение, и вам нужно ее решить. А в чем твоя проблема? Оборот — это симптом, а не проблема.
У вас проблемы с культурой.
У вас есть люди, которые не доверяют и не уважают друг друга, и их явно не поощряют к этому. Хотя статистика показывает текучесть кадров в организации, сколько у вас людей, проработавших в ней более 5 лет? Это могут быть некоторые из ваших проблемных зон. Каковы ваши планы развития? Как ваши менеджеры среднего звена повышают уровень ваших индивидуальных участников? Каков их путь к сочувствию к своим сверстникам?
Отлично, вы начали налаживать процесс. А как насчет людей?
Люди вообще хотят чувствовать себя нужными и ценными. Они хотят, чтобы их работа была важна для кого-то другого. Они хотят стать лучше в том, что они делают, и они хотят иметь возможность делать больше. Они достигают этого через своих менеджеров и руководителей.
Вы должны быть в состоянии ответить на эти вопросы очень убедительно. Если вы не можете, то ваши люди уходят, потому что компания не ценит их так, как они хотят, чтобы их ценили.
А как насчет токсичных/злых людей?
Многие люди скажут вам, что их нужно уволить. Многие люди готовы отказаться от них. Кто-то, кто злится или расстраивается, показывает вам, насколько он заботится о вас. Они могут не заботиться о правильных вещах в данный момент, но они заинтересованы в том, что они делают, и в том, кем они являются на своем месте. Я призываю вас не разочаровываться в этих людях. В прошлом я инвестировал в своих токсичных личностей, и это окупилось огромными дивидендами. Эти люди стали одними из моих лучших исполнителей.
Вау, здесь есть чем заняться. Я проблема?
Вы просто можете быть. Возможно, они не доверяют компании или руководству. Если вы занимаетесь управлением, очень важно определить это. Очень часто это происходит из-за того, что сообщения руководства не соответствуют действиям руководства. Часто это просто восприятие неуважения, которое приходит с разделением информации.
Слуга-лидерство всегда работало на меня. Если ваши отдельные участники считают, что работа руководства выполняется на их благо, они горы поднимут. Это требует честности. Это требует веры. Если ожидается, что люди будут вести себя в соответствии с более высокими стандартами, их лидеры должны служить примером этого стандарта. Если вы хотите, чтобы ваши отдельные участники были уважительными и чуткими, тогда вы должны быть уважительными и чуткими. Если вы хотите, чтобы они усердно работали, вы должны усердно работать. Вы будете культивировать культуру, которую заслуживаете, а не культуру, которую хотите.
Пока культура не будет исправлена, люди будут продолжать уходить, а текучесть кадров будет оставаться на эпическом уровне.
toxic people
. На мой взгляд, существует огромная разница между людьми, которые злятся/жалуются/критикуют/... и людьми, которые на самом деле вредны для окружающей среды. Работа с жалобщиками на самом деле может завоевать их лояльность и помочь вам значительно улучшиться как организации (или как личности). Однако на самом деле токсичных людей (а их немного) просто необходимо удалить.Вам нужно 35 человек в год, чтобы сохранить 25 вакансий.
Даже с самой скучной и не приносящей удовлетворения работой, какую только можно вообразить, вы в конце концов должны остаться с кучей людей, которым на это наплевать и которые будут счастливы приходить утром, уходить вечером и забирать свои деньги в конце рабочего дня. месяц.
Вы этого не сделали. Это означает, что ваша работа не просто не привлекает людей, есть что-то, что активно отталкивает их. Два босса сексуально домогаются всех без исключения? Фактическое насилие на рабочем месте? Отвратительный запах в офисе, который заставляет меня думать о мертвых людях под половицами? Должно быть что-то подобное. 140% отсева — это просто ненормально.
Влияет ли это на производительность? Какая производительность? Я бы не ожидал, что там вообще будет какая-то производительность. У вас есть новички, которые должны сначала изучить окружающую среду, и нет никого опытного, кто мог бы их научить. Отсутствие продуктивности у новых людей и снижение производительности у не совсем новых людей в течение четырех месяцев. Затем, когда они почти готовы выполнять какую-то работу, предыдущее поколение уходит, и нужно учить следующее поколение. Как только это будет сделано, им надоест, и они уйдут. Никакой работы не делается.
Вам предстоит тяжелая работа. Я бы сказал, что вам нужно от восьми до десяти настоящих профессионалов с хорошей зарплатой, которые справятся, несмотря ни на что. Им нужно дать полную свободу действий, чтобы противостоять любым препятствиям (например, если генеральный директор кричит на них, чтобы физически удалить его или ее, не опасаясь последствий). Со свободой рук для принятия решений по развитию (на случай, если у вас идиотский менеджмент, который не может сохранять цели неизменными в течение недели).
Пока нет идеального ответа на вопрос «Что такое нормальный оборот с разработчиками?» (это будет варьироваться от компании к компании, и все люди разные), я бы сказал, что большую часть времени разработчики будут стараться оставаться в одной компании по крайней мере 2 или 3 года, если они могут.
Это хорошо смотрится в резюме, у вас есть время изучить предмет и построить хорошие отношения с людьми. Через 2 или 3 года вы можете сменить работу, чтобы получить хорошую прибавку к зарплате, и пойти работать над новыми проектами с более новыми технологиями.
Если разработчик не задерживается больше года, значит, что-то его не устроило. Уход так скоро может навредить его карьере:
Так что я бы сказал, что любая компания с оборотом менее года делает что-то очень, очень неправильно. Но тогда ответы Даниила и usr-local-ΕΨΗΕΛΩΝ дают лучшие объяснения по этому вопросу.
Если вам нужно нанять 35 разработчиков в год, чтобы заполнить 25 вакансий, ваш средний разработчик останется на 8,6 месяца. То есть, действительно, безумно коротко.
Такие показатели текучести кадров могут иметь огромное влияние на производительность. Этому способствуют несколько факторов:
На другую часть вашего вопроса, а именно «Какова нормальная текучесть кадров среди разработчиков», ответить гораздо сложнее. Так что я сделаю своего рода рамочный вызов: не спрашивайте, какова нормальная скорость, спросите, какой вы хотите, чтобы ваша скорость была и как ее достичь. Ваша компания отличается от любой другой компании, поэтому ваш ответ может отличаться от нормы. Есть даже некоторые редкие обстоятельства, когда высокая текучесть кадров вообще не проблема.
Уведомление! В основном это мнение основано. Может быть подвержен предвзятости «анекдотических свидетельств», основанных на моем собственном опыте и моих знакомых. Более объективные предположения находятся в разделе «Резюме».
Я хотел бы опубликовать ответ с совершенно противоположной точки зрения.
Вы упомянули, что это банк или другое финансовое учреждение. Вполне нормально, что у них может быть токсичная рабочая среда и большая текучесть кадров. Взамен они предлагают немного более высокую заработную плату. Я не знаю почему. Может быть, у некоторых банкиров до сих пор испорченное мышление, что они могут получить все через деньги, или просто банковский бизнес такой прибыльный.
Расскажу немного свою историю. Работаю в банковской сфере недолго (всего 4 месяца). Это было вскоре после учебы, потому что они набирали студентов через какой-то рынок вакансий , организованный в моем университете.
Я могу сказать, что эта зарплата была довольно внушительной, но она не предлагала должности, на которой я мог бы развивать свои навыки так, как хотел, а окружающая среда была немного токсичной. Это заставило меня изменить свои планы. Я решил найти работу с более низкой зарплатой, но с большими возможностями для изучения новых инструментов/технологий программирования и с дружественной рабочей атмосферой.
Но некоторые из моих друзей остались в этой компании, и им это понравилось. Им нравилась зарплата, и они просто привыкли к напряженному рабочему месту.
Я также встретил некоторых людей, которые сменили работу с моей нынешней на мою прошлую компанию, и им это нравится больше. Невероятно, но у каждого свои предпочтения, с которыми трудно спорить.
Краткое содержание
Подводя итог, можно сказать, что высокая текучесть кадров может быть неплохой вещью при определенных условиях:
Учтите, что у вас есть несоответствие между тем, что вы просите людей сделать, и тем, как вы нанимаете и делаете вещи. Технология, как правило, не является мягкой наукой. Если вы попросите невозможное, люди уйдут. Итак, убедившись:
Чего люди, не привыкшие к технической работе, не понимают, так это того, что на самом деле ничто не может точно подготовить вас к работе. Кроме выполнения этой работы. Теперь очень трудно оценить, сколько времени вам потребуется, чтобы стать продуктивным. Но также трудно выполнить задачу, которая с вашей точки зрения является бесконечно большой.
Поэтому очень важно, чтобы у вас действительно был старший разработчик, чья работа состоит в том, чтобы разбивать задачи на управляемые части. И это действительно звучит так, как будто вы потеряли весь свой координационный талант, так что никто не вводит новых людей в курс дела.
Решение, вероятно, не в увеличении количества людей, а в его уменьшении. Вы не можете просто вкачивать новых разработчиков в бесконечном темпе. Они просто лишат возможности работать эффективно тех немногих, кто может эффективно работать.
Другой может быть постоянно перегружен изменением масштаба. Работники должны знать, что они что-то делают. Таким образом, они должны быть в состоянии взять кусок работы и сделать этот кусок работы. Выполнение чанка должно быть подтверждено.
То, что чанк теперь считается устаревшим, не является ошибкой рабочих. Это вина руководства. Работник выполнил часть, которую он намеревался сделать, и это должно быть правильно. Например: это не вина маляра, если стена офиса зеленая, когда вы попросили его покрасить в зеленый цвет. Хотя, возможно, вы уже после того, как он начал рисовать, решили, что он должен быть розовым. 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-месячный мини-проект, чтобы заново настроить культуру и немного восстановить доверие.
DarkCygnus
Лилиенталь
Чапз
ндм13
Майлз