Бенч є вже цілком природним явищем для будь-якої ІТ компанії, оскільки невеликі перерви в окремих розробників та навіть цілих команд між завершенням одного проєкт і початком наступного трапляються постійно. Але чи можемо ми просто змиритись з цим явищем? Не зовсім.

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

Якщо підрахувати, яку кількість коштів компанія витрачає під час бенчу, особливо тривалого та неконтрольованого, стає зрозумілим, що бенч може призвести до значних фінансових збитків. Як з цим боротись та чи можливо побороти взагалі — розкажемо у сьогоднішньому дописі. 

Чому Виникає Бенч Та “Хто в Цьому Винен”?

Існує цілий ряд причин виникнення бенчу. Часто таке явище виникає через внутрішні процеси — мала кількість проєкт, неефективна робота сейлзів(Sales)/відділу маркетингу з залучення нових клієнтів, неоптимізована стратегія підбору персоналу. Проте, є й такі фактори, які виникають з незалежних від компанії причин.

Сезонність

Зазвичай, найбільше обертів ІТ індустрія скидає влітку, адже на цей час припадає досить сильний спад бізнес-активності серед замовників (та й відпустки ніхто не відміняв). Тому влітку можуть потрапляти на бенч не лише окремі розробники, але й цілими командами.

Багато короткострокових проєктів

Велика кількість короткострокових проєктів зазвичай означає дві речі: 1) вони швидко закінчуються та 2) складно точно оцінити якими будуть перерви між ними. Тому IT компаніям вигідніше працювати з великими проєктами, бо це означає, що вся команда буде зайнята довший проміжок часу.

Неправильне планування

Це стосується як розкладу реалізації проєктів, так і планування об’ємів продаж для сейлзів. У випадку коли відсутнє планування реалізації проєктів, з’являється багато прогалин у часі між проєктами та, як наслідок, бенч. У другому випадку відсутність чітко поставлених задач до Sales призводить до того ж самого.

Незаплановане закриття проєкту

Ситуації, коли замовник раптово припинив проєкт також трапляються. Таке можливо, якщо у клієнта змінилися плани, щодо подальшого розвитку, або просто немає бюджету для подальшої співпраці. На пошук нового проєкту потрібно буде витратити якусь кількість часу і не завжди це відбувається швидко.

Як Бенч Впливає На Діяльність Компанії

З бенчем складається наступний парадокс: звільняти розробника після завершення проєкту не доцільно, адже тоді не буде кому працювати над новими проєктами. До того ж рекрутинг нових кадрів часто означає часові та фінансові втрати; з другого боку бенч — це прямі збитки компанії.

За словами Андрія Хомина, СМО TechcarrotHUB: “Бенч не є корисним для компанії загалом, бо фактично означає не лише простої в роботі деяких працівників, але й втрачені бізнес-можливості для компанії в цілому”.

Бенч завжди має вплив не лише на компанію, але й на розробників, які не залучені до виробничих задач. Основними ризиками тривалого бенчу для компанії є:

Зростання витрат

Слід пам’ятати, що бенч — це не тільки заробітна плата спеціалістів, але й втрачені прибутки для компанії. Якщо за місяць під час виконання проєкту один розробник генерує компанії дохід в $5,000 з яких $3,000 це оплата праці, а $2,000 — прибуток, то за той самий період під час бенчу компанія втрачає не тільки на зарплатні, але й недоотримує кошти. 

Погіршення внутрішньої атмосфери в колективі

Більшість розробників хоче використовувати свої навички, а не заповнювати час адміністративною роботою, рутинними задачами, очікуючи, коли ж, нарешті, розпочнеться новий проєкт. В той самий час, працівники, які в цей час зайняті у проєктах, починають думати, що вони так само можуть опинитись на бенчі. Це все негативно впливає на настрої в команді.

Ризик втрати кадрів

Чим довше розробники лишаються без діла, тим більша ймовірність того, що вони почнуть шукати нових можливостей за межами компанії. Бенч не може тривати вічність — це розуміє як компанія, так і команда. Тому, якщо в компанії немає довгострокових проєктів є можливість, що розробники залишать компанію.

Застій у розвитку

Компанії з високим відсотком бенчу поступово зупиняються у розвитку через плинність кадрів, та недостатню кількість роботи для своїх штатних розробників. Усі фінанси, які мали б витрачатись на розвиток бізнесу та залучення нових проєктів йдуть на оплату праці розробників, яких відправили “на бенч”.

Тепер давайте розглянемо наслідки тривалого бенчу для працівників:

Зменшення заробітної плати

За відсутності проєктної роботи розробник отримує лише мінімальний рейт, тоді як на проєктах оплата праці вища. Логічно, що через це у людини виникне бажання почати шукати нову роботу з вищою оплатою.

Втрата компетенцій

Коли розробник протягом довгого часу не підтримує або не розвиває свої компетенції, він втрачає набуті навички, а швидкість його роботи знижується. Частково проблему можна вирішити навчанням персоналу під час бенчу, та залученням його до внутрішніх проєктів.

Зростання загального розслаблення працівника

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

Як Ефективно Керувати Бенчем

Існує певна норма працівників, яких компанія здатна тримати на бенчі відносно безболісно для себе. В середньому показник бенчу до 5% (відносно всього штату працівників) вважається цілком нормальним. В деяких випадках він може збільшуватись до 10% і вище з наступних причин:

  • через залежність компанії від одного-двох клієнтів;
  • через різке припинення співробітництва з замовником або браком у нього коштів на подальшу розробку;
  • через спад попиту на конкретну технологію та неможливість швидко переорієнтувати бізнес.

За словами Андрія “Ефективно та безболісно управляти бенчом можна в рамках 5%. Якщо цифра переходить цю межу або різко стрибає — це знак, що треба щось міняти в підходах до продажів чи процесах компанії”.

В деяких випадках бенч може сягати 30% і така ситуація потребує негайного реагування, оскільки досить відчутно б’є по бізнесу. Порівняти її можна з гасінням пожежі, причому, в короткостроковій перспективі проблему можна вирішити досить швидко, але це не є гарантією того, що ситуація не повторюватиметься знов і знов.

Шукати системні шляхи розв’язання проблеми бенчу варто вже на тому етапі, коли бенч досягає 10%, адже за відсутності важелів та інструментів керування даним явищем, цифра може збільшуватися вдвічі, та навіть втричі, і в кінцевому випадку матиме катастрофічні наслідки для компанії.

Шляхи ефективної оптимізації бенчу

  • Аутстафінг. Це є одним з найпоширеніших способів оптимізації бенчу. Проте слід брати до уваги, що зазвичай компанії віддають своїх працівників на субпідряд за дуже низьким рейтом. Таке вирішення проблеми дозволяє певний час утримувати досить високий відсоток бенчу з одного боку, проте з іншого, не є вигідним для бізнесу в довгостроковій перспективі.
  • Внутрішнє навчання. Навчати команду, організовувати курси для розробників, розширювати стеки технологій — наприклад за напрямком fullstack — і надалі реалізовувати їх у внутрішніх та клієнтських проєктах є досить ефективним шляхом подолання бенчу.
  • Реалізація власних проєктів. Оптимізація бенчу таким шляхом є не зовсім типовою, проте дуже ефективною. Якщо дозволити розробнику використовувати внутрішню перерву для роботи над власним проєктом в рамках корпоративного підприємства, можна не тільки змотивувати працівника, але й отримати новий продукт для компанії. 
  • Залучення працівників для вирішення челенджів бізнесу. Розробників, які не залучені на проєктах можна об’єднати в команди які прийматимуть участь в брейнштормах та воркшопах, пов’язаних з розв’язання стратегічних задач компанії. 

Декілька Лайфхаків, Які Допоможуть Краще Контролювати Бенч

Наостанок пропонуємо кілька корисних порад та інсайдів, які допоможуть зробити бенч контрольованим явищем:

  • Слідкуйте за трендами ринку і вчасно адаптуйте власний стек технологій.
  • Розвивайте hard/soft skills у ваших працівників. Виховуйте у розробників звичку вивчати нові технології та розширювати експертизу.
  • Намагайтесь продавати довготермінові проєкти, оскільки в короткотермінових проєктах завжди більший ризик виникнення раптового бенчу. В довготермінових є запас часу та ресурсів для прийняття вчасного рішення.
  • Добре мати пул не термінових задач, проєктів, якими можна зайняти розробників у разі виникнення бенчу.
  • Дуже добре налагоджувати та розвивати партнерські відносини з іншими компаніями та в разі потреби залучати працівників на такі проєкти.
  • Допомагає робота з платформами для залучення розробників на проєкті.

Повна Відмова Від Бенчу: Чи Це Можливо?

“Бенч є своєрідним стимулом для пошуку максимально ефективних способів організації сервісного ІТ бізнесу. Подолати його повністю навряд чи можливо, проте ефективно з ним працювати — цілком!” — каже Андрій.

Деякі сервісні та аутстафінгові компанії все ж таки намагаються повністю відмовитись від бенчу. Робити це можна шляхом припинення співпраці з розробником або командою в цілому одразу після завершення проєкту з подальшим наймом у разі, коли з’явиться новий проєкт.

В цьому випадку компанія дійсно уникає бенчу, проте разом із тим ризикує втратити якісних та перевірених спеціалістів. То що ж робити у такому разі? Як за короткий термін знайти якісну команду для свого проєкту? Це можливо завдяки TechcarrotHUB.
TechcarrotHUB — спільнота, яка допоможе вам з більш ніж 3000 перевірених розробників підібрати ідеальних виконавців з необхідною експертизою під ваш проєкт. Долучайтесь до TechcarrotHUB та протестуйте всі можливості платформи вже сьогодні, щоб вже завтра бути готовим до втілення у життя проєкту будь-якої складності!

Залишити відповідь