Что такое 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% рабочего времени сотрудника.
Есть еще несколько пунктов, о которых можно было бы говорить, но они играют куда более скромную роль.
И не забывайте, что остается еще и риск, что новый сотрудник не сможет сработаться с командой и спустя
Как видите, на самом деле увольнение сотрудника обходится компании весьма дорого!
Безусловно, приведенные данные не являются догмой и для каждого проекта и каждой компании допущения и процентные ставки должны быть свои. Считать потери от Attrition, безусловно, надо. Осознание глубины проблемы через финансовые потери даст вам реальные рычаги для удержания пресонала в будущем.
Все про українське ІТ в телеграмі — підписуйтеся на канал DOU
49 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.