Інституції в ІТ: Як масштабувати систему, а не хаос

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Привіт, DOU! Я Роман Поботін, Lead AQA / SDET із понад 10-річним досвідом. За цей час я бачив десятки компаній, що проходять той самий шлях: від драйвового стартапу на трьох людей до великої розробки, де хаос масштабується разом із командою.

Типова картина: компанія наймає людей, створює департаменти, призначає лідів. Але замість зростання продуктивності з’являється «комбінаторний вибух» комунікацій. Розробники скаржаться: «З цим QA працювати легко, а з іншим — постійні проблеми». Менеджери питають про реліз і чують: «Залежить від обставин...». На будь-яке запитання про процеси звучить сакральне: «Ну, так історично склалося».

Ця фраза — маркер того, що в компанії немає структури. Там просто натовп інженерів в одному Slack-каналі. У цій статті розберемося, у чому фундаментальна відмінність між «групою людей під лідом» та справжньою Інституцією.

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

Дисклеймер: У цій статті ми говоримо про суть, а не про назви. У вашій компанії може не бути «департаментів», а лише команди. Важливо інше: чи побудована ваша робота на системних процесах, чи все тримається на «авторських» практиках та незамінних людях. Матеріал не знецінює індивідуальний підхід, а показує, чому при масштабуванні інституції стають критично важливими для виживання.

У будь-якій ІТ-компанії існують дві паралельні реальності.

1. Формальна структура. Те, що намальовано в Miro: департаменти, схеми в Confluence, Scrum-гайд та посадові інструкції.
2. Реальна система (інституції). «Правила гри», за якими насправді приймаються рішення о 18:00 у п’ятницю, коли дедлайн дихає в спину. Те, що вважається «нормою» на практиці.

Правда в тому, що компанія працює не за структурою — вона працює за інституціями.

Що таке інституція (ELI5)

Уявіть, що ви хочете побудувати будинок. Ви можете найняти майстра, який тримає всі розміри в голові (це «просто відділ», де все тримається на одній людині). Якщо він захворіє — будівництво зупиниться.

Інституція — це коли ви впроваджуєте креслення, стандарти вимірювання та автоматичні конвеєри. Це система, яка «змушує» будинок будуватися правильно, навіть якщо завтра ви заміните всю бригаду будівельників на нову. Інституція не виникає сама по собі — це свідомо збудована мережа правил та обмежень, яка замінює випадковість на передбачуваність.

Інженерний сенс інституції

Інституція — це стабільний патерн поведінки, який відтворюється системою знову і знову.

Моя формула: Інституція — це коли напрямок продовжує працювати на тому самому рівні якості, навіть якщо замінити всіх людей.

Це «публічний API» вашого відділу. Ви робите запит — і отримуєте передбачуваний результат незалежно від того, хто сьогодні натискає на кнопки.

Чому документація не дорівнює системі

Багато менеджерів вірять: «Ми написали Quality Policy, тепер у нас є інституція». Це ілюзія. Люди не «читають і виконують» — вони адаптуються через:

• Спостереження: як поводяться ліди насправді?
• Підкріплення: що реально заохочується (якість чи швидкість «на костилях»)?
• Повторення: які патерни спрацювали минулого разу?

Якщо в Wiki написано «Quality First», але в реальності дедлайни важливіші, а на баги заплющують очі — ваша реальна інституція: «Швидкість > Якість». І жоден документ цього не змінить.

Темна сторона: Негативні інституції

Більшість проблемних компаній страждають не від відсутності інституцій, а від наявності «поганих» інституцій. Інституція сама по собі — нейтральна, вона просто стабілізує поведінку. Але якщо стабілізується шкідлива поведінка (це називають path dependence), система починає працювати проти себе.

Типові шкідливі інституції в ІТ:

• Інституція «Automation для галочки»: Тести пишуться, бо «треба», але результатам ніхто не довіряє. Впливу на якість — нуль.
• Інституція «Не висовуйся»: Проблеми не піднімаються, щоб не «псувати статистику». Це виглядає як стабільність, а насправді — деградація.
• Інституція «Hero Culture»: Все тримається на сильних людях, пожежі гасяться вручну. Це виглядає як сильна команда, але насправді — відсутність системи.

Найнеприємніша правда: хороші люди в поганих інституціях дають поганий результат. І навпаки: середні люди в хороших інституціях дають стабільно нормальний результат.

Пастка героїзму: чому «надзусилля» вбивають систему

Ми часто плутаємо лідерство з інституцією. Фраза «у нас сильний QA Lead, тому все летить» звучить як комплімент, але для архітектора систем це тривожний сигнал. Якщо успіх проекту залежить від конкретної людини, а не від процесу — у вас немає інституції. У вас є лише персональний контроль та ентузіазм.

Героїзм — це завжди компенсація відсутності системи. Справжня інституція починається там, де якість стає «дефолтним» налаштуванням. Інженер працює добре не тому, що за ним стежать, а тому, що сама архітектура роботи (через автоматичні обмеження в CI, культуру рев’ю та стандарти) просто не дає йому зробити погано.

Героїзм як високовідсотковий кредит

Ми схильні романтизувати овертайми та нічні релізи, сприймаючи їх як прояв лояльності. Проте з точки зору системного інжинірингу «рятування проекту» техлідом, який не спав добу — це вирок.

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

• Маскування системних дефектів. Герой, що «викладається на 200%», стає живою латкою на дірявому процесі. Менеджмент перестає бачити проблему, бо «результат є». В результаті причина пожежі не усувається, а наступного разу знадобиться ще більше героїзму, бо система продовжує деградувати.
• Помилка втомленої людини. Інженер на 12-й годині роботи перетворюється на «генератора багів». Уявна економія часу на дедлайні пізніше обертається потрійними витратами на стабілізацію та гасіння пожеж уже на проді.
• Токсична незамінність. Хвалячи за овертайми, ми заохочуємо культуру, де знання тримаються в одній голові. «Герой» стає єдиним вікном у систему, створюючи критично високий Bus Factor. Це робить компанію заручником однієї людини, а саму людину — заручником хаосу.

Нове визначення професіоналізму

Наднормова праця — це не ознака відданості. Це маркер поганого планування або повної відсутності інституцій.

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

Головна ілюзія зростання: Більше людей != Більше результату

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

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

1. Кожна фіча — новий старт. Нові правила, нові конфлікти. Ви щоразу платите за синхронізацію часом і нервами. Немає накопичення ефективності.
2. Результат залежить від везіння. Попався сильний інженер — фіча злетіла. Попався слабший — все сиплеться.
3. Локальна оптимізація. QA має свої правила, Backend — свої. При взаємодії починається тертя, бо у них немає «спільної мови».

Як «розшити» це вузьке місце

Згідно з Теорією обмежень, локальна оптимізація окремого відділу — ворог системи. Сильні організації будують інституції поверх ролей. Це не про те, «як працює QA». Це про те, «як ми всі працюємо». Це єдина мова: одна Definition of Done, одна модель якості, одна культура прийняття рішень для всіх команд.

Простий тест: Чи є у вас інституція?

• Тест на Bus Factor: Якщо вас прибрати завтра — що зламається? Якщо «майже все» — ви і є система. Якщо «нічого критичного» — у вас є інституція.
• Тест на сумісність: Якщо інженера перевести в іншу команду, чи працюватиме він за тими самими стандартами без зайвих пояснень?
• Тест на «ДНК результату»: Чи можете ви впізнати роботу вашого департаменту, не дивлячись на автора? Якщо якість результату — це лотерея залежно від виконавця, у вас немає системи.

Висновок: Час ставати інженером систем

Масштабування — це перехід від «людей як системи» до «системи, що працює через людей». Бо якщо ваша система не працює без конкретних «зірок» — у вас немає системи.

Ваш наступний крок:

Не пишіть нову Wiki. Подивіться на свою команду і знайдіть, де «ламається підкріплення». Де ви винагороджуєте героїзм замість стабільності? Де шкідлива поведінка залишається без наслідків? Хороша система має робити правильні речі найпростішим шляхом, а шкідлива — максимально болючими.