Інженерна культура – важкий люкс для Big Tech чи гнучка система для стартапів?

Поняття інженерної культури асоціюється здебільшого з історіями Netflix, Spotify чи інших глобальних компаній. Водночас Deloitte вважає, що гнучка інженерна культура є недооціненим важелем впливу та конкурентною перевагою для стартапів. Як цей підхід вирішує щоденні болі технічної команди, на якому етапі краще імплементувати та з чого почати, Mind розповів CTO OBRIO Антон Водолазький.

Що таке інженерна культура

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

• Як ми пишемо код? Яких стандартів дотримуємося?
• Як його тестуємо? Чи автоматизуємо процеси? Хто відповідає за якість коду?
• Як приймаємо рішення?
• Як навчаємось і розвиваємось?

Серед розробників існує низка упереджень щодо інженерної культури. Зокрема, вважається, що вона:

1. Вбиває швидкість розробки. Її часто асоціюють із бюрократією, надмірною документацією, суворими стандартами та повільними циклами затвердження змін.
2. Передбачає лише вибір технологій та інструментів. Розробники часто забувають, що інженерна культура також стосується комунікації, командної роботи та зворотного зв'язку.
3. Не підходить стартапам. Вони мають бути гнучкими та швидкими, тому інженерна культура з чіткими процесами та стандартами добре працює лише у великих компаніях.
4. Обмежує креативність. Розробники побоюються, що впровадження стандартів коду, процедур або автоматизованих процесів стає перешкодою для творчості та експериментів.
5. Вимагає великих ресурсів, часу та зусиль, які краще витратити на розробку продукту.
6. Означає повну автоматизацію – від тестування до деплою (розгортання продукту на сервери або в хмару), тому не кожна команда готова до складної інфраструктури та має відповідні знання.

Складнощі в підтримці коду, низька якість продукту та швидкість розробки, демотивована команда та складнощі з масштабуванням – як будь-яку з цих проблем можна вирішити з допомогою правильної інженерної культури?

Які болі інженерів вирішує інженерна культура?

Кейс №1. Вічний пінг-понг пул-реквестами (запит на внесення змін у коді, PR)

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

Як це вирішити: чіткі стандарти код-рев’ю. Наприклад, домовитися, що стилістичні моменти перевіряються автоматично, а коментарі зосереджені на логіці. Вітається формат «suggestion-based» – якщо є кращий варіант, запропонуйте конкретне рішення. SLA на рев’ю (максимальний час, протягом якого дається фідбек) – 24 години.

Кейс №2. Чий баг?

Проблема: одну фічу доручають кільком людям, а коли QA знаходить баги, визначити відповідального неможливо.

Як це вирішити: вводиться принцип «one owner per task», коли є відповідальний за кожну фічу, який веде її від початку до продакшену. Також інженерна культура може запровадити традицію відкритості в команді, де помилки не приховують, а розбирають і роблять висновки без пошуку винних.

Кейс №3. Неконтрольований технічний борг

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

Як це вирішити: усі «костилі» документуються в беклозі з пріоритетом на виправлення. У кожному спринті виділяється час на рефакторинг або плануються «боргові» спринти.

Кейс №4. Неефективний менеджмент пріоритетів

Проблема: менеджмент змінює пріоритети кожні три дні, тому команда або нічого не встигає, або сидить у режимі очікування.

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

Кейс №5. Що по документації?

Проблема: люди пишуть код так, ніби ніколи не підуть із компанії, а за рік виявиться, що всі архітектурні рішення лишилися в голові колишніх співробітників.

Як це вирішити: регулярне оновлення документації у процесі роботи, а не постфактум.

З цими проблемами хоч раз стикався кожен розробник. Запропоновані рішення реалізувати цілком можливо, якщо вся команда домовиться виконувати певні правила. Це і є варіація інженерної культури, яку може запровадити кожна компанія.

Як це працює в Big Tech?

Правильна інженерна культура може дати рішення не тільки щоденним болям розробників, але й розв'язувати критичні бізнес-проблеми. Розглянемо історії кардинальних змін у компаніях.

Netflix

Спершу Netflix був компанією, яка відправляла DVD-диски поштою, а інженерна культура не відрізнялася від типового e-commerce. Перехід на стримінг змусив їх змінити все.

Найголовніше – побудова мікросервісної архітектури замість моноліту та впровадження культури «Freedom & Responsibility», яка дала інженерам більше свободи для інновацій.

Google

У 2000-х Google стикався з нестабільністю сервісів через швидке зростання. Рішенням стало створення SRE-команд (Site Reliability Engineering), де розробники й інфраструктурні інженери працюють разом. Тоді ж зʼявилися метрики для контролю надійності (SLA, SLO, SLI), автоматизація стала обов'язковою частиною культури, почала розвиватися культура інженерного лідерства: багато технічних рішень приймають не керівники, а інженери, які пропонують ідеї та обґрунтовують їх.

Amazon

Інженерна культура компанії була заточена під підтримку великої монолітної системи, але під час масштабування це стало вузьким місцем. Рішенням став перехід до мікросервісної архітектури, впровадження принципу «You build it, you run it» (інженери відповідають не лише за код, а й за його підтримку в продакшені), а також посилення автономії команд.

Meta

Раніше компанія використовувала принцип «Move fast and break things» (рухайся швидко і ламай речі), але потім він еволюціонував у «Move fast with stable infra» (рухайся швидко, але з надійною інфраструктурою). І хоча це був жарт Марка Цукерберга на одній із презентацій, культура Meta справді змінилася. Зараз компанія заохочує експерименти, швидкі ітерації та вміння швидко виправляти помилки, щоб залишатися стабільними.

Microsoft

Раніше компанія була відома як «Know-it-all», мала закриту культуру, де домінувала конкуренція між командами. Це гальмувало інновації. Після приходу Сатьї Наделли компанія змінила підхід на «Learn-it-all» (постійне навчання замість жорсткої експертності). Microsoft став активно використовувати опен-сорс, зменшив бюрократію, а інженери почали працювати в гнучкіших командах.

Чи потрібна інженерна культура стартапу?

Історії побудови інженерної культури в BigTech-компаніях надихають, але жодна з них не може бути застосована повторно – вони розв'язували конкретні бізнес-проблеми.

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

• зберегти гнучкість: маленькі стартапи можуть змінювати процеси швидше, адаптуючи їх під нові виклики;
• зберегти фокус на важливих аспектах: культура має підтримувати специфічні цілі компанії (наприклад, швидке досягнення MVP чи фокус на інноваціях), а не сліпо слідувати за великою корпоративною моделлю;
• оптимізувати ресурси: у стартапах культура має підтримувати зменшення бюрократії, максимальну продуктивність, швидку комунікацію.

Це дозволить стартапу реагувати на виклики та ефективно масштабуватися в міру зростання.

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

1. Коли компанія починає активне наймання, з'являється потреба у структурі, стандартах і чітких процесах, побудові правильної комунікації та координації.
2. Масштабування потребує не лише фінансових ресурсів, а й належної інженерної бази. Культура, яка включає стандарти, документацію, комунікацію та постійне поліпшення процесів, дозволяє компанії адаптуватися до зростання.
3. Коли компанія починає працювати зі складнішими технологіями й архітектурними рішеннями, важливо створити базу для правильної інтеграції, їх підтримки та розвитку.
4. Сильна інженерна культура допомагає залучати таланти та створювати робоче середовище, де хочеться працювати.

Як це працює в OBRIO?

В OBRIO ми будуємо інженерну культуру, що базується на кількох ключових принципах.

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

Автономність та відповідальність – кожна команда має автономію в ухваленні рішень. Це підвищує рівень відповідальності та мотивації інженерів. Вони відчувають, що можуть безпосередньо впливати на розвиток продукту.

Прозора комунікація та зворотний зв'язок – відкритість у спілкуванні й регулярний зворотний зв’язок є основою ефективної роботи. Це допомагає швидко виявляти та розв'язувати проблеми.

Культура експериментів – заохочення ініціативності та підтримка експериментів. 

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

З чого почати: поради

1. Визначте базові цінності та дайте відповіді на запитання: що для вас важливо в комунікації в команді? Як ви знаходите баланс між швидкістю та якістю розробки? Як експериментуєте та запроваджуєте нові технології?
2. Сформулюйте чіткі правила, які стосуються код-рев’ю (критерії щодо стилістики й архітектури, безпеки та продуктивності), а також роботи з технічним боргом, беклогом, документацією, онбордингом.
3. Визначте, хто в команді за що відповідає, як різні ролі взаємодіють між собою, як приймаються рішення.
4. Подумайте про розвиток команди: у який спосіб ви ділитеся знаннями, чи може кожен співробітник розвиватися?
5. Усі нові правила та процеси – стосуються всієї команди, тож і керівники мають так само змінювати підходи та звички.

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