Від стартапу до великої організації – цей шлях проходять багато компаній. І разом із новими можливостями з’являються нові виклики: від управління сотнями людей до збереження корпоративної культури.
Проте таке зростання завжди супроводжується серйозними викликами. Компанія ризикує втратити свою початкову культуру, ключових виконавців і приглушити ініціативність через надмірну формалізацію процесів. Рішення про масштабування зазвичай ухвалює керівництво, а втілювати такі рішення буде середня ланка менеджменту: проєктні, HR-менеджери та керівники відділів.
У партнерському матеріалі з SharksCode його команда ділиться, як зробити так, щоб зміни працювали, а не викликали саботаж.
Зміст
Причини опору змінам
«Коли команда зростає у шість разів за рік, стає зрозуміло – старі методи управління вже не працюють. Тут критично важливо планувати й шукати баланс між новими правилами та потребами людей. Без прозорості й чесного діалогу зміни не сприймаються, а отже, не працюють. І саме завдяки залученню команди ми змогли пройти через ці трансформації без хаосу», – каже Станіслав Андрєєв, СОО ІТ-компанії SharksCode.
Часто спроби оптимізувати процеси, підвищити передбачуваність і впорядкувати релізи зустрічають опір з боку команди. Розробники можуть вважати нові правила перешкодою для основної роботи – написання коду, тестування та швидкого реагування на задачі.
Опір змінам – природна реакція. Люди бояться невідомого та можливих негативних наслідків: «А якщо нові процеси виявлять мою низьку ефективність?» або ж «Зараз критичний реліз, немає часу на нові правила».
На думку Станіслава Андрєєва, для подолання такого опору адміністративний тиск зайвий. Необхідно:
- проводити індивідуальні зустрічі (1:1) і збирати зворотний зв’язок;
- ідентифікувати повторювані проблеми та ключові болючі точки;
- демонструвати команді, що тут враховується думка кожного та кожної;
- пов’язувати запропоновані зміни з реальними потребами команди;
- пріоритезувати найважливіші процеси, які мають максимальну цінність.
Замість нав’язування потрібен діалог, прозорість і аргументоване пояснення користі кожної зміни.
Більше інформації про SharksCode можна переглянути на сайті за посиланням.
Роль внутрішніх лідерів
Масштабні зміни неможливо провести зусиллями лише одного менеджера.
«Потрібні “амбасадори змін” – люди з авторитетом у команді, які готові підтримати ініціативу. Це можуть бути техліди, що втомилися від хаотичних інцидентів на продакшені, або DevOps-інженери, які прагнуть стабільності», – зазначає Михайло Білоус, Project Manager SharksCode.
На думку Михайла, важливо не лише залучити таких людей, а й активно включати їх у розробку нових процесів, давати їм свободу, щоб вони адаптували правила під реальні потреби команди, і, звісно, підтримувати.
Амбасадори змін мають стати справжніми партнерами, а не інструментом маніпуляції. Вони можуть бути фасилітаторами на ретроспективах, ініціаторами нових ритуалів і першими, хто тестує зміни. Їхній авторитет допомагає команді сприймати зміни як власну ініціативу, а не примус згори.
Прозорість і поступовість
Зміни не можна впроваджувати одномоментно. Різкі трансформації призводять до вигорання менеджера та дестабілізації команди.
Михайло Білоус поділився кількома практичними порадами, які допомагають уникнути вигорання:
- Розробіть Roadmap змін.
- Візуалізуйте етапи та дедлайни: наприклад, через простий Gantt Chart.
- Ставте SMART-цілі: конкретні, вимірювані, досяжні, релевантні, з термінами виконання.
Поступовість і зрозумілий план дій допоможуть утримати баланс між інтересами клієнта, команди та компанії.
Метрики та результати
Будь-які зміни мають бути підкріплені конкретними результатами:
- збір метрик: наприклад, «новий формат документації зекономив 40 годин комунікації на місяць»;
- опитування команди для оцінки впливу ініціативи;
- презентація результатів після кожного завершеного етапу.
Все, що не вимірюється, не має тривалого ефекту. Регулярна демонстрація успіхів і прогресу допомагає команді бачити реальну користь змін.
Кейс Михайла з попереднього місця роботи: впровадження Atlassian і перехід на Agile
«У 2019 році дві продуктові команди, які я супроводжував, працювали без єдиної системи управління: завдання надходили хаотично через месенджери, Excel, Trello та усні домовленості. Планування базувалося на дедлайнах і інтуїції, QA тестували без формалізованих сценаріїв. Замість радикальних змін я почав зі збору зворотного зв’язку. Поступово ми впровадили Jira, налаштували Scrum і Kanban, створили Confluence для документації та онбордингу нових співробітників», – розповідає Михайло Білоус, Project Manager SharksCode.
Через два місяці швидкість спринтів (Sprint Velocity) зросла на 25%, кількість інцидентів у продакшені значно скоротилася, і команда почала ініціювати власні покращення. Ключовим фактором стало не впровадження конкретного фреймворку, а побудова довіри між менеджментом і командою.
Запорука успіху в цьому процесі – це насамперед питання довіри. Якщо команда бачить сенс у змінах, то й трансформації проходять природно.
Зміни не завжди приймаються відразу, але прозорість, поступовість і відкритий діалог із командою дозволяють замість опору отримати взаємодію та ефективну співпрацю.
SharksCode продовжує динамічно зростати та запрошує нові таланти до команди. Зокрема шукають QA Manua інженера, Senior Swift Developer, SOC ANALYST. Детальніше про актуальні вакансії — за посиланням.
Це партнерський матеріал. Інформацію для цього матеріалу надав партнер.
Редакція відповідає за відповідність стилістики редакційним стандартам.
Замовити матеріал про вас у форматі PR-статті ви можете тут.
Повідомити про помилку
Текст, який буде надіслано нашим редакторам: