Автономія замість черги на погодження: Антон Асеєв, CEO Sharkscode, про масштабування технологічної компанії
На думку підприємця, швидкість виконання втрачає сенс, якщо результат потім тиждень лежить у черзі на апрув
Зростання технологічної компанії швидко показує, наскільки гнучко в ній влаштоване управління. Рішень стає дедалі більше, тож команди починають чекати погоджень довше, ніж працювати. Антон Асеєв, CEO IT-компанії SharksCode, розповідає, як зберегти швидкість на масштабі завдяки автономії команд і чому для цього керівнику доведеться переглянути власну роль.
- Чому з ростом компанії з'являється бюрократія?
- Її рідко хтось впроваджує свідомо. Десь стається прикра помилка і після неї з'являється додаткова перевірка, щоб ситуація не повторилася. За рік-два виявляється, що для запуску дрібної фічі потрібні підписи трьох людей, двоє з яких у відпустці. Бюрократія маскується під турботу про якість, хоча здебільшого захищає керівника від дискомфорту невизначеності.
- Як зрозуміти, що компанія вже потрапила в цю пастку?
- Найпростіший маркер видно в календарі, де синки й узгодження забирають більше часу, ніж сама робота. Другий сигнал помітний у чатах, коли розробник пише «чекаю апрув» і спокійно перемикається на інше завдання. Компанія тоді рухається зі швидкістю найзавантаженішої людини в ній. Ця людина зазвичай сидить на самому верху.
- Що ви вкладаєте в поняття автономії команди?
Це право команди ухвалювати рішення у своїй зоні відповідальності без попереднього дозволу згори. При цьому команда несе відповідальність за результат і вміє пояснити логіку рішень. Автономію часто плутають із вседозволеністю, хоча вона вимагає набагато чіткішої структури. Людям потрібно розуміти межі власної зони відповідальності та критерії, за якими оцінюватимуть результат.
Тут доречна аналогія з футболом. Під час гри ніхто не біжить до бровки питати тренера, чи можна віддати пас. Гравці ухвалюють рішення за секунди, бо добре знають план і свою роль у ньому.

- Як визначити, які рішення команда може ухвалювати самостійно?
- Найзручніше оцінювати кожне рішення за ціною можливої помилки та за тим, наскільки легко її виправити. Більшість щоденних рішень у продуктовій розробці відкотити нескладно, тож команда має діяти сама й швидко. Кожен день очікування тут коштує дорожче за потенційний промах.
Інша справа з рішеннями, які складно скасувати, наприклад, вибір архітектури на кілька років уперед або великі фінансові зобов'язання. Тут розумно залучити ширше коло людей. На практиці таких рішень небагато, тож для всіх інших зайві ланки погодження можна сміливо прибирати.
- Багато керівників бояться віддавати контроль. Що допомагає подолати цей страх?
- Контроль через погодження дає скоріше ілюзію безпеки. Керівник фізично не може глибоко вникнути в кожне рішення, тому часто підписує його, побачивши лише верхівку. Я раджу замінювати контроль на вході прозорістю на виході. Команда ухвалює рішення сама й коротко фіксує його логіку. Керівник у той час отримує загальну картину й втручається лише тоді, коли помічає системну проблему.
- Як змінюється роль CEO в такій моделі?
- Вона зміщується від диспетчера до архітектора. Керівник вибудовує систему, у якій хороші рішення народжуються без його участі. Насамперед він формулює цілі так, щоб будь-хто в команді міг звірити з ними власне рішення. Окремої уваги потребує культура, де про помилки говорять відкрито й без пошуку винних. Людина, яка боїться покарання за невдалий експеримент, знову почне приходити по дозвіл на кожен крок.

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