Приховані підводні камені вибору технологічного стеку: посібник для технічних директорів

Рівень невдач у проектах з впровадження технологій для підприємств є досить вражаючим: приблизно 70% з них не є успішними через неправильний вибір стеків. Лідери у сфері технологій зазвичай тяжіють до нових архітектур та новітніх інструментів, але такі рішення часто призводять до значних технічних боргів та дорогого перепрограмування систем. Найпоширеніші помилки є передбачуваними: зосередження уваги на модних технологіях, а не на узгодженні з бізнесом, ігнорування необхідності підтримувати систему з часом та вибір інструменту, який не відповідає знанням команди. Такі помилки призводять до дорогого вдосконалення, вузьких місць у продуктивності та депресії команд розробників. Аналіз представляє реальні випадки, коли проекти були зірвані через неправильні рішення в області технологій, і визначаються причини технологічних невдач. На основі практичних прикладів ми пропонуємо практичні рамки, які можуть допомогти лідерам у сфері технологій приймати обґрунтовані рішення, що відповідають цілям бізнесу, використовують сильні сторони команди та забезпечують сталий ріст.

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

Привабливість популярних технологій

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

Невисловлене технічне обслуговування Підсумок

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

• Тестування
• Виявлення та виправлення помилок
• Налаштування продуктивності
• Тестування сумісності
• Рефакторинг
• Обслуговування клієнтів
• Документація

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

Невідповідність можливостей команди

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

• Стрімкі криві навчання
• Повільніші цикли розробки
• Вищі показники дефектів
• Низька якість реалізації

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

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

Складність мікросервісів у простих додатках

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

Обмеження продуктивності в ігрових додатках

Ігрова компанія протестувала React Native для створення високопродуктивної мобільної гри, що створило непереборні технічні труднощі для графічно інтенсивних досвідів. Хоча React Native мав переваги в кросплатформенній розробці, він по суті не мав продуктивних можливостей для підтримки високоскладних ігрових вимог. Команда розробників виявила, що продуктивність потоку JavaScript була значно знижена. Незважаючи на те, що React Native заявляє про здатність забезпечувати щонайменше 60 кадрів в секунду, додаток постійно пропускав кадри під час використання складних анімацій та взаємодій. Діагностика продуктивності показала, що будь-який процес, що вимагає більше 100 мс, створює затримку для користувача. Ці обмеження були згубними для ігор, що вимагали більш складної фізики або рендерингу. Команда намагалася оптимізувати нативні модулі, але основна невідповідність інструменту та потреба все одно залишалися. Хоча React Native дозволяє розробляти на різних платформах, використовуючи лише один набір коду, це стало менш важливим, коли кінцевий продукт не міг навіть відповідати мінімальним стандартам продуктивності.

Вразливості масштабування баз даних у фінансових додатках

Фінансовий фінтех-додаток був запущений зі старою монолітною базою даних SQL і спочатку працював добре. Але з ростом обсягів транзакцій система не змогла забезпечити необхідну продуктивність і масштабованість. Затримки та запізнення в пакетній обробці зробили аналітику в режимі реального часу практично неможливою. Головною помилкою технічного директора було те, що він не передбачив потреби в масштабуванні обробки фінансових даних. Дизайн бази даних не був розроблений для підтримки:

• Горизонтальне масштабування
• Методи балансування навантаження
• Пікові обсяги транзакцій

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

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

Невідповідність складності бізнес-технологій

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

• Уповільнення роботи додатків через велику кількість шарів
• Ускладнюється через численні передачі
• Ненадійний, оскільки кожен рівень має різні режими відмови

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

Технічний борг і рефакторинг

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

Слабкі сторони документації та адаптації нових співробітників

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

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

Визначте обсяг продукту

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

• У короткострокових продуктах швидкі системи розробки (наприклад, MEAN або Firebase) забезпечать швидкість і гнучкість
• Для довгострокових систем зосередьтеся на модульних, підтримуваних архітектурах, які не потребуватимуть значного переписання

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

• Вибирайте технології, з якими ваші інженери вже знайомі, у разі тиску з боку термінів поставки
• Заздалегідь плануйте використання сумісного з майбутніми версіями стека, але виділіть час на аудит коду, адаптацію та навчання

Враховуйте зовнішні вимоги

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

Оцініть довгострокову стійкість

Те, що є стійким сьогодні, завтра може виявитися слабким. Шукайте:

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

Продуктивність та операційна складність

Вибір стека передбачає компроміс:

• Модель масштабованості: Чи можна масштабувати горизонтально, додаючи більше екземплярів, чи ви обмежені вертикальним масштабуванням з монолітом?
• Продуктивність під навантаженням: деякі стеки краще підходять для одночасного виконання транзакцій і є легкими (наприклад, Node.js), а інші краще підходять для виконання транзакцій з важкими транзакційними процесорами (наприклад, Spring Boot)?
• Складність операції: чи ваша команда надійно впроваджує та підтримує операцію, чи це якась операція на межі рентабельності, яку ви впроваджуєте?

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

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

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

• Короткострокові вимоги та довгострокові перспективи
• Навички команди та потреби бізнесу
• Інноваційність та стійкість

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