Опрос: портрет украинского ИТ-специалиста. Уже собрано 7800 анкет

Что такое Attrition и почему это важно для вашей компании

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

Первым, кто использовал термин War of Attrition (война на истощение), был китайский генерал, стратег и философ Сунь-Цзы. Дословно определение — «Война на истощение» звучит как разновидность стратегии, в которой воюющие стороны пытаются выиграть войну, изматывая своего врага за счет непрерывных потерь в личном составе и материальных средствах.

Вы спросите, какое отношение имеет военная терминология к IT?

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

Что это напоминает вам?

Правильно! Это как раз и есть эволюция стратегий ведения IT-бизнеса.

Мог кого-либо напрягать высокий Attrition при T&M лет 10 назад? Конечно же нет!

Заказчик оплачивает любого предложенного вами исполнителя! Ваша задача сводится просто к тому, чтобы восполнение ресурсов происходило максимально быстро. Ну чем не «Война на истощение»? Изматываем Заказчика до состояния, когда он снимает с себя последнюю рубашку! Все! Цель достигнута! Война выиграна!

Если задать любому IT-менеджеру вопрос о возможности применения T&M в современных условиях, то в ответ вы услышите, что эта модель сегодня становится небывалой антикварной роскошью. И что на сегодня условия рынка диктуют новые правила и выигрывает битву тот у кого... Правильно! Техническое, технологическое и тактическое превосходство.

А что же с Attrition в современных моделях?

Кто-то усматривает в этом явлении приток «свежей крови» в коллектив, а кто-то панически боится сводок, где появляется отрицательный баланс в project resources report. Правы и те, и другие.

Остается ответить на вопрос, где та граница, за которой Attrition перестает быть управляемым и приносит колоссальные убытки, а порой приводит бизнес к стагнации и банкротству.

Идея оценить потери от Attrition возникла у меня после разговора с CFO одной из крупных компаний.

Я задал простой вопрос:
— А как ты оцениваешь в своей компании Attrition? И сколько ты теряешь в год?

Ответ поразил!
— Attrition — это очень плохо! Я предполагаю, что мы теряем много!

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

То ли CFO мне попался не профессиональный, то ли баланс у него был настолько хорош, что париться о каком-то там Attrition ему действительно не было необходимости. Не удовлетворившись полученным ответом, я решил попробовать оценить влияние Attrition на revenue проекта и компании в целом.

Итак, начнем!

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

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

Зеленая ракета! Поехали! Спринт за спринтом! Итерация за итерацией! Все идет, как по маслу! И вдруг, по непонятной причине, программист Иванов кладет вам на стол Заявление!

Опустим причины, по которым Иванов принял такое решение (это не наша тема).

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

  • Все время, пока кресло исполнителя пустует, вы теряете. Величина потерь равна произведению времени на расчетную прибыль, получаемую от конкретного исполнителя. Кто-то закладывает этот параметр, как абсолютное значение (например 4$ в час на каждом разработчике), а кто-то предпочитает некий % от себестоимости разработчика.
  • Для того чтобы восполнить потерю, вам необходимо задействовать свои и сторонние HR-ресурсы (ректрутинговые агентства, Job-сайты).

Все эти затраты понятны и имеют четкие показатели.

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

  • Итак, перед Вами заявление Иванова. Естественно Вы предпринимаете усилия, чтобы удержать его. Хорошо, если Вы находите компромисс, и он остается в компании (в 90 случаях из 100 — это пересмотр его ЗП, что не может не сказаться на прибыльности проекта в целом). А если Иванов все-таки уходит?

    Мой Вам совет: отпускайте Иванова как можно быстрее и максимально быстро ищите замену! Он уже всеми мыслями на новой работе, и выкладываться на проекте он не станет! И Ваши затраты в виде заработной платы и операционных расходов не покроются объемом выполненной работы, а следовательно, вы также понесете убытки.

    Расчет таких потерь будет выглядеть так:
    Например, производительность увольняющегося уменьшается до 70% расчетной, но при этом вы продолжаете нести расходы на прежнем уровне. Если ваша прибыль лежит на уровне 20-30% от себестоимости разработки, то в лучшем случае вы будете иметь 0% прибыли, а в худшем −10%.

Итак, Иванов ушел, и вы ищете ему замену. Кандидат, за кандидатом, собеседование за собеседованием! И вот тут еще один коварный пункт:

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

Идем дальше!

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

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

    Давайте изобразим этот процесс в виде графика:



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

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

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

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

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

Но и это еще не все. Не забываем про условия Fixed price проекта!

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

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



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

Есть еще несколько пунктов, о которых можно было бы говорить, но они играют куда более скромную роль.

И не забывайте, что остается еще и риск, что новый сотрудник не сможет сработаться с командой и спустя 2-3 месяца покинет компанию.

Как видите, на самом деле увольнение сотрудника обходится компании весьма дорого!

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

47 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Починали за

Attrition
закінчили утриманням людини.

мой опыт мне подсказывает, что с точки зрения договоренности с заказчиком надо просто уходить от фиксед костов всегда, как только можно, либо делать такой запас, который позволит искать нового человека в более менее безубыточном ключе. Еще вариант — кушать слона маленькими кусочками, 2-3 недельными спринтами, и выделить скоуп и деливери каждого спринта в какие-то отдельные deliverables, таким образом что вы на момент 3 спринта 1 и 2 уже сдали и забыли. Это даст более безопасную ситуацию. С точки зрения стандартов разработки — CMMI не зря придумали, хотя конечно некоторых крайне утомляют «отчеты про репорты» — ну я не о том, в общем, хорошо, если кто-то еще, например, тимлид, будет в курсе проекта, и все по гиту чтобы шло, и желательно хотя бы минимальные коменты в коде и баг-трекере , тогда будет меньше неприятных неожиданностей. Вообще уход разработчика с проекта — это всегда эпик фейл. каждый раз какая-то фигня.

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

Никита,
Если бы в графике отражалась прибыль, то безусловно кривая ушла бы в минус. Потом пересекла бы «0», а уж затем приблизилась к прежнему уровню в конце срока адаптации.
Мы говорим о производительности.
Она либо есть, либо равна «0». :)

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

>

Принимаем допущение, что его производительность растет линейно до желаемого уровня за время адаптационного периода.
learning curve

Добавлю:

Как правило, адаптация сотрудника происходит на протяжении 2-3 недель. Потом становится ясно — или он дальше будет работать, или с ним прощаться. У каждого статистика разная. Я стараюсь всеми возможными способами помочь ему поверить в себя, подсказать, подтолкнуть, но когда я вижу что-то типа «меня не вставляет», «а почему меня не поставить на другой проект» и т.д. то с таким прощаюсь, так как я с ним работать не смогу.

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

Так, что потеря приблизительно составляет 1-1.5 месяца.

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

Джуны смотрят на текущее место работы чтобы набраться опыта и через год свалить на лучший рейт если тут не предложат.
Миддлы работают и заодно ищут куда-бы прыгнуть на сеньерское место + 1 500уе сверху.

Всегда нужно иметь людей про запас и не жалеть их, а то кто Вас пожалеет когда он скажет Вам: «Знаешь, я не хочу больше тут работать, мне дали +500 и даже отрабатывать 2 недели не буду, делай что хочешь»

Ну а Вы директор, Вам все шишки, Вам же вся и прибыль :)

Удачи:)

Работникам как правило наплевать что будет с компанией, тем более джунам, за редким исключением.
Может, добавите, что компания в сотрудниках души не чает — печеньками кормит и ЗП повышает? А бизнесы создаются, чтоб кормить сотрудников, а не владельца?

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

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

Наплевательское отношение оно обоюдное. И искать крайнего это цинизм.
Если человеку наплевать на работу, тоесть на большую часть своей жизни и частично свое будущее, то на это есть причины(а не изза плохой погоды).
Конечно если сказать человеку счас ты получаешь 2куе и через 5 лет будешь получать стокаже и будешь тем же девом. Разумеется он положит.
Люди растут и развиваются, меняются их приоритеты и жизненные пути и все это нужно оценивать и понимать.
А если в компании всем наплевать на компанию, то хреновая это компания.

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

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

Вы меня улыбаете) На ЗП не все дороги сходятся.
Как погазывает статистика после планки ЗП в 7к уе людям све больше и больше на нее наплевать и все больше они ценят окружение и условия труда(например работать не 8 часов а 4, ходить не в костюме а в шортах и футболке и т.п.)

А ЗП последний фактор ухода из компании.
Зачастую люди уходят когда их не слышат(об этом писал здесь http://habrahabr.ru/post/165425/). Уходят когда их обидели, когда им скучно(а менеджер не видет или ему пофиг). Люди уходят из личных причин в первую очередь. Поверте моему опыту, у меня нет ни одного человека который бы просто ушел ради +500-1000уе.
Да и я не далеко ушел, мне часто предлагают ставки на порядок выше, но мне нравится там где я сейчас работаю и это меня держит. А вот если бы не нравилось то я бы ушел даже при ставке в минус 500уе и был бы доволен(что не раз было на моем веку).

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

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

Статья не о том!
Важно иметь инструменты для оценки и управления таким явлением, как Attrition.
Все остальные аспекты увольнения сотрудника в данном случае вторичны.

Не совсем наверно понимаю ваш комент.

Ну мы вроде и не о сиськах разговаривали?)

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

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

Ну начнем с того, что

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

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

А если учесть, что за плечами такого парня стоит команда разработчиков, тестеров, то потери могут быть весьма печальными!

вменяемый менеджер
А сколько в процентном соотношении вменяемых и невменяемых?)

Так це не архітектор ))) А людина, яка не знаю, що архітектура без документації — ніщо. І такого треба гнати в шию до того, як він сам захоче звільнитись.

Во-во. Это шарлатан а не архитектор.

громадной легаси системы без всякой документации?

кто же вам виноват
— Attrition — это очень плохо! Я предполагаю, что мы теряем много!

You can able tell junior devops by they are believe thing are exist which are both important and not is measured.

twitter.com/...951464227422208

Кстати. На эту тему есть шикарная книжка — How to Measure Anything.

Мой Вам совет: отпускайте Иванова как можно быстрее и максимально быстро ищите замену! Он уже всеми мыслями на новой работе, и выкладываться на проекте он не станет! И Ваши затраты в виде заработной платы и операционных расходов не покроются объемом выполненной работы, а следовательно, вы также понесете убытки.
И это правильно

Это не правельно.
Правельно: Не допускайте ситуации когда Иванов уйдет.
Не начатая война — выигранная война.

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

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

Отпускать надо таких людей, незаменимых не бывает.

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

Скажу вам ИТшник со стажем, заменить ИТшника очень сложно. Потому что есть миллиард факторов который вы никогда не учтете. А если еще и учесть что не дай бог вы могли его обидеть, то тут вообще могут быть очень серйозные проблемы(которые нередко стоили компаниям миллионы. Достаточно вспомнить случай с True = False).

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

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

Пословица:"Относись к людям так же как и ты хочешь чтоб они к тебе относились" тут не работает.

Ну а Ваши слова лишь подтверждают то, что у Вас еще остались моральные принципы.

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

Если же у вас весь колектив моральных уродов, то тогда стоит задать вопрос вашему HR манагеру, какого собственно он делает.

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

Профит.

Дмитрий, браво. Первая толковая статья за год минимум !

К тому моменту, когда Иванов положил заявление на стол, да — решить вопрос могут только деньги. Но согласитесь, что до этого Иванов явно пробовал и другие варианты.
Военная доктрина, тем более древняя — не применима к бизнесу созидания. Да, многие находят сходство. И это сходство — РИСК

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

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

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

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

:)
Этот вопрос немного не в плоскости статьи. Я делал оговорку, что:

(это не наша тема)
Из опыта скажу, что сталкивался с такими случаями, и не один раз.
Чисто в качестве совета могу сказать, что все надо считать!
Оцените, сможете ли вы «перебить» предложение конкурента и насколько это повлияет на маржинальность проекта и на сколько ценен работник.
Собственно для принятия такого решения я и делал оценки, приведенные в этой статье.

Пардон, что сразу не уточнил — речь идет именно о случаях, когда «перебивать» заведомо не рентабельно

А как бороться с Тайфунами???

Сейчас не крепостное право! Пристегнуть Иванова к батарее, чтобы он работал «за хлеб и воду» вы не сможете.
Да и Вы сами ответили на вопрос :

«перебивать» заведомо не рентабельно
Отпускайте и ищите максимально быстро замену!
Пристегнуть Иванова к батарее, чтобы он работал «за хлеб и воду» вы не сможете.

А жаль :-)

Вот и к тому, что не на всякий риск можно заранее заложиться.

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

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

Если перекупают со спредом больше 500уе, то это значит что та контора где он работает просрала его повышение. Хотели секономить, а хороших спецов мало и на этом сыграла другая контора.
Средняя рыночная ЗП для средних рыночных спецов. Вон машина в среднем 30к уе стоит, но вы ведь не будете требовать эту же машину прокачаную для стритрейсинга за ту же цену. Хороший спец должен получать хорошо и даже больше хорошо, что бы вот таких случаев не было.
В любом случае переманивание специалиста это провтык управления и только(ибо собственно это их круг задач и ответственности).

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

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

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

Подписаться на комментарии