Що таке 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, безумовно, треба. Усвідомлення глибини проблеми через фінансові втрати дасть вам реальні важелі для утримання пресонала в майбутньому.

Опубліковано: 14/01/13 @ 01:39
Розділ Різне

SEO Блог

Що таке Attrition і чому це важливо для вашої компанії

Рекомендуємо: