Станіслав Андрєєв: Ефективне управління матричними командами в SharksCode

Матричне управління: нові виклики для команд

Матрична модель управління стає все популярнішою серед компаній, але разом із вигодами вона приносить і нові проблеми. Чи може стати ефективною, коли проєктні та функціональні керівники одночасно змінюють пріоритети одного співробітника? 🔄 Станіслав Андрєєв, COO SharksCode, ділиться думками про те, як узгоджувати навантаження та ухвалювати рішення в умовах багатозадачності. Від конфліктів через несумісні завдання до важливості спільного планування — daвайте розберемося в нюансах матричного управління. 📊

Хто ухвалює рішення в такій ситуації, як узгоджувати навантаження та чому регламент сам по собі не допоможе — пояснює COO SharksCode Станіслав Андрєєв.

У який момент матричне управління починає заважати роботі?

Зазвичай це помітно за чергою невеликих конфліктів. Уявімо розробника, якого проєктний менеджер просить завершити функцію до релізу. Функціональний керівник того самого дня планує для нього роботу над якістю коду. Обидві задачі можуть бути обґрунтованими. Проблема виникає, якщо ніхто з керівників не бачить повного навантаження людини й не знає, хто може змінити пріоритет. Тоді спеціаліст починає сам домовлятися з менеджерами, хоча це управлінське рішення.

Які рішення варто закріпити за проєктним керівником, а які — за функціональним?

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

Що робити співробітнику, якщо два менеджери дали несумісні завдання?

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

Як зафіксувати правила без великого регламенту?

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

Як запобігти прихованому перевантаженню спеціалістів?

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

Хто має оцінювати результат і ухвалювати кадрові рішення?

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

За якими ознаками зрозуміти, що модель потребує змін?

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

Чи всім компаніям потрібна матриця?

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

Джерело: https://focus.ua/uk/economics/772541-stanislav-andryeyev-coo-sharkscode-upravlinnya-matrichnimi-komandami