ДЕ ЛАМАЄТЬСЯ РІШЕННЯ
Управління проєктами, дисципліна і комунікація в компанії на високому рівні. Робота йшла системно. Стратсесії давали сильні напрямки і проєкти запускались.
Але в процесі, частина рішень змінювалась по ходу реалізації, зростала кількість узгоджень і зустрічей, практично завжди, після 3-5 тижнів з’являлась внутрішня напруга і команда витягувала проєкти за рахунок ресурсу, а не структури.
Це давало нормальний для ринку результат, але не той, на який розраховував власник.
Запит від власника і СЕО був наступним: «Чи можна перебудувати команди під реалізацію так, щоб проєкти проходили стабільно, в строки і без виснаження після, а не «витягувались на нервах».
Звичайно, важливо було підвищити і % реалізації як метрику.
ЯК МИ ЗАЙШЛИ В ЦЕЙ ПРОЦЕС
Фокус в роботі зосередили на команді, через яку проходила більшість реалізацій (6 людей).
Далі:
командний скан реакцій і рішень під різними типами тиску
короткі індивідуальні сесії (≈20 хв) з кожним учасником + уточнення, завдяки якому тиску вони найчастіше «ламаються» під піковим і максимальним навантаженням
Замість розповсюдженої моделі розуміння загальної поведінки, це дало точну картину конкретних зон збою у кожного учасника
Після цього, три багатокрокових сценарія у різних конфігураціях (нейтральний сценарій – сценарій з їхнього ринку – сценарій, ідентичний реальному проєкту).
І ключове. Сценарії і ролі підбирались під слабкі типи тиску кожного учасника, точно в точку, де починається зсув. Кожен фіксував власні реакції, без фідбеку та обговорень.
Ми одразу заводили людей у їхню зону збою, а не моделювали комфорт.
Через 3 дні, на розборі, команда самостійно зібрала механіку і алгоритми проходження складних відрізків на етапі реалізації.
Щоб зафіксувати і керувати змінами, прийняли і ввели окремі KPI по поведінці команди в моменті тиску:
кількість додаткових зустрічей після прийнятого рішення
частоту перегляду вже погоджених рішень
точки появи напруги (по тижнях і етапах)
тип тиску, який впливає на команду
швидкість повернення до конструктивної роботи після піку
Окремо:
де рішення починає «зсуватись»
на якому типі тиску команда втрачає темп
Замість загального відчуття «процес ускладнюється» з’явилась точна мапа втрат ефективності. Стало видно, де виникають зайві зустрічі, чому переглядаються рішення, на яких етапах накопичується напруга та хто і під яким тиском змінює хід реалізації.
ЯК ЦЕ ВПЛИНУЛО НА РЕЗУЛЬТАТ
З’явилась карта тисків. Стало видно:
хто стабільний у дедлайнах, але «просідає» в міжкомандній взаємодії
хто тримає структуру, але відкатується в момент тиску часу
де вмикається захист
де – атака
де команда втрачає темп
Наприклад:
Сильний керівник проєктів при тиску часу починав перезбирати рішення, а не прискорював рух.
Інший, навпаки, тримав час але втрачав позицію у взаємодії між підрозділами.
В моменті це виглядало як робочий процес, а фактично – змінювало хід реалізації.
Команда отримала корегування та розгорнуту «дорожню мапу», як саме їм рухатись під тисками та в моменти невизначеності саме в цій конфігурації учасників.
KPI стали основою для управління в процесі. CEO і команда почали фіксувати тип тиску в моменті, стали розуміти, де починається зсув і вчасно змінювати конфігурацію взаємодії
РЕЗУЛЬТАТ
Старт впровадження швидше на 3 тижні
Перші пікові тиски пройдені без зриву
Після 5-го тижня відсутність мікроконфліктів
Напруга залишилась у робочому діапазоні
Проєкт завершено в строки
Команда не «вигорала» в процесі
Ефективність: 85% замість 60–65%. Різниця в 16% виявилася зоною впливу зовнішніх факторів.
ЕФЕКТ ДЛЯ БІЗНЕСУ
Скорочення зайвих зустрічей і переглядів рішень звільнило управлінський ресурс команди. У перерахунку, стало менше:
повторних обговорень
«повернень» до вже прийнятих рішень
залучення керівників у мікроузгодження
Це означало більше часу на ключові задачі, менше втрат швидкості в процесі і, головне, стабільніший темп реалізації без перевантаження.
Для команди з 6 керівників це еквівалентно вивільненню ~40-60 годин управлінського часу на місяць
Ефективність зросла за рахунок того, що зникли втрати в моменті, де тиск змінює рішення, а не за рахунок інтенсивності, на яку частіше за все намагаються тиснути, виснажуючи людей.
Після цього STANLAB залучений як партнер для роботи з командами під тиском перед ключовими етапами змін і масштабування.
Розібрати логіку змін: