Роль СТО — визначати напрямок технологічного розвитку компанії та приймати стратегічні рішення щодо його змін. Спершу ви обираєте інструменти, намагаючись передбачити їхній подальший розвиток. Вирішуєте, чи варто переходити на інший стек, якщо продукт потребує змін. А також щоразу, коли злітає та чи інша перспективна технологія, думаєте, чи інтегрувати її, чи залишити все, як є. Олександр Ковальчук, співзасновник та СTO компанії Cargofy, вважає, що кожен такий вибір схожий на гру в рулетку. Під час CTO fwdays’24 він поділився уроками, які його команда винесла з цієї гри, і пояснив, як відрізнити цінні інновації від ризикованих експериментів. Публікуємо найцікавіше з його виступу. Олександр також створив платформу Pomich.org, яка на початку війни допомогла евакуювати тисячі людей.
> Усі грають у рулетку
> Рулетка для стартапу: коли можливі ризиковані ставки
> Експерименти з технологіями: шукаємо баланс
> Історія фейлу. Що робити, коли ставка не зіграла
> Проєкт «Pomich»: від ідеї до запуску за декілька днів
Усі грають у рулетку
Чи можливо обрати одну надійну технологію, яка ніколи не підведе, і зупинитися на цьому? На жаль, такий підхід може стати великою помилкою. Залишаючись на одній технології, ми ризикуємо опинитись із застарілим стеком, що вже не підтримується, і максимум, на що можна розраховувати, — це рідкісні патчі.
Наочні приклади — Microsoft Silverlight та Adobe Flash, які домінували на ринку у 2010-х. Більшість браузерних відеоплеєрів, зокрема YouTube, працювали на Flash, адже HTML, CSS та JavaScript не могли забезпечити необхідний функціонал. Існувала безліч ігор, написаних на Flash, він ідеально працював з векторною графікою та 3D. У той час, коли HTML, CSS та JavaScript у кожній версії браузера працювали по-різному, Flash виглядав всюди однаково — це була просто знахідка! Silverlight, зі свого боку, позиціонувався як корпоративна альтернатива десктопним програмам із можливістю роботи у вебі.
Однак обидві технології зрештою зникли з різних причин. А компанії, що побудували свої системи винятково на них, залишилися із продуктами, що не підтримувались. Уявіть собі, що для доступу до своєї CRM-системи вам потрібно використовувати віртуальну машину з Windows 7 або XP та старим Internet Explorer. На жаль, це реальність для багатьох компаній, особливо у Європі та США. В принципі, так працювати можна, але тільки не якщо ви — технологічна компанія. Тому якщо бачите, що ваша базова технологія починає менше підтримуватися, з неї активно йдуть розробники, варто почати шукати альтернативу.
В Україні є свій сумний приклад — російський софт 1С, з 2014 року знаходиться під санкціями. До того фактично весь український бізнес був побудований на цьому продукті. З уведенням санкцій компанії мусили шукати нові рішення. Проте багатьом це було не під силу — надто багато різної інфраструктури навернуто зверху на 1С, і в результаті «виколупати» його вже не вийде. Компаніям доводиться повністю переписувати стару платформу без будь-якого профіту, витрачаючи величезні ресурси. Тоді в них виникає питання: чи не вийде так, що технологія, на яку ми переїдемо, також зникне за 5-10 років? Правда в тому, що навіть найнадійніший фреймворк може зникнути чи втратити актуальність через зовнішні фактори. Тому важливо постійно стежити за розвитком інструментів і бути готовими до змін.
Рулетка для стартапу: коли можливі ризиковані ставки
Для стартапу вибір правильної технології може стати перевагою. Нові рішення зазвичай базуються на покращенні тих, що вже існують, і, обравши їх на ранніх етапах, стартап розвивається разом із технологією. Наприклад, коли з’явився React, це був простий інструмент для зручного рендерингу HTML. Із часом він отримав додатковий функціонал, і ті, хто почали з ним працювати на старті, здобули значну експертизу, розвиваючись паралельно.
Схожа історія трапилася у нашої команди та Laravel. Спершу ми використали його для кількох невеликих проєктів, і він зарекомендував себе добре. Тоді Laravel став основним фреймворком для поточного проєкту. Водночас ми постійно оцінювали його розвиток і були готовими перейти на щось інше за потреби. На момент вибору топ PHP-фреймворків був іншим, і сьогодні з тих часів «вижив» лише Symfony. Laravel, хоч і не був у топі, за пів року почав зростати. Нині разом із Symfony він став «королем» PHP-фреймворків, а наша ризикована ставка себе виправдала.
Екосистема технологій постійно змінюється. Важливо стежити за новими підходами, мовами програмування та фреймворками, які можуть виявитися ефективнішими. Стартапи не обтяжені великою кількістю легасі, тому можуть дозволити собі швидко змінити технологію. Також часто на стадії MVP продукти зазнають кардинальних змін. Це — ідеальний момент для того, аби переглянути свій стек та зробити нову ставку.
Один із найкращих способів їхнього тестування — експерименти на невеликих масштабах. Для цього можна взяти функціонал, який легко ізолювати, і винести його в окремий сервіс.
Такі експерименти можна проводити на пет-проєктах, але тоді вони не дають повної картини. У реальному проєкті завжди є тиск змін: бізнес може вимагати переписати, перекрутити чи адаптувати частину функціоналу під нові вимоги. Такий стресовий сценарій є справжнім тестом для стійкості обраної технології. Саме так ми тестували Laravel, і він показав себе надійним.
Такі пошуки нагадують відоме дослідження з мишами, які шукали шлях до їжі через лабіринт із пастками. Миші, які досягли успіху протягом перших спроб, згодом продовжували долати труднощі, навіть якщо часто падали. Ті ж, хто спочатку не зміг дістатися мети, втрачали мотивацію і припиняли спроби. Так само компанії мають ігнорувати невдачі та не боятися пробувати нові підходи. Залишаючись на надійній, але застарілій технології, можна втратити темп та відстати від конкурентів. Рішенням є постійний моніторинг і відкритість до нових рішень.
Експерименти з технологіями: шукаємо баланс
Після успішного досвіду з Laravel ми продовжили активно експериментувати з іншими технологіями. Один із таких експериментів стосувався переходу на Vue.js. На початку ми використовували jQuery для лендингів і Angular для кабінету користувача, з яким було чимало проблем. Ми вирішили спробувати Vue.js, переписавши лише один компонент. Це дало змогу поступово впроваджувати новий фреймворк, замінюючи компоненти один за одним.
На той момент підтримка Vue.js була дуже обмеженою. Наприклад, WebStorm навіть не підсвічував синтаксис, і ми змушені були працювати через Sublime. Однак з часом ситуація покращилася: Vue продовжив розвиватися, команда нарощувала експертизу, і фреймворк став важливою частиною нашого стека.
Фронтенд вдосконалювався разом із розвитком проєкту завдяки поступовій зміні інструментів для збирання:
Grunt — перший збірник, що допомагав автоматизувати базові задачі, однак його продуктивність була обмеженою.
Gulp — наступний етап, який забезпечив пришвидшення завдяки потоковій обробці файлів.
Webpack забезпечив модульність, динамічне завантаження компонентів і кращу продуктивність. Проте, коли проєкт виріс до десятків тисяч компонентів, Webpack став занадто повільним.
Vite суттєво скоротив час збирання та прискорив роботу в Dev-середовищі.
Останнім часом ми тестували Turbo від Vercel, але значних переваг він не дав, тому залишилися на Vite.
Кожен перехід дозволяв нам покращувати продуктивність і адаптувати систему до нових викликів, щоби наступний «переїзд» був простішим.
Водночас варто знайти баланс та не вдаватися в крайнощі — не кидатись на нові неперевірені технології, але й не закриватись у своїй «бульбашці». Команда, яка постійно переїжджає на новий стек, не може розвиватися та поглиблювати експертизу. Вона залишатиметься на експериментальних проєктах, не маючи змоги побудувати велику компанію. З іншого боку, якщо закритись від світу, можна не помітити, що команда безнадійно відстала. На жаль, інструкції про досягнення такого балансу не існує. Я відчуваю його інтуїтивно. Приймаючи рішення, буде корисно поставити собі такі питання:
Чи є нагальна потреба у зміні стека?
Чи дасть переїзд відчутний профіт?
Чи сильно відстає фреймворк, який ми використовуємо зараз?
Історія фейлу. Що робити, коли ставка не зіграла
Не всі експерименти з новими технологіями вдаються, і це нормально. Один із найбільших провалів був пов’язаний із впровадженням навігації в MapBox. Наша команда розвивала логістичний продукт для транспортних перевезень. Одним з каркасів був мобільний застосунок, в якому перевізники відмічають точки, куди вони приїхали, завантажують фотографії документів та вантажу, а також замовник відстежує пересування. Цей застосунок передає локацію, синхронізується з сервером, отримує пуш-сповіщення. Якось ми подумали: якщо він завжди в активному режимі, чому б нам не додати туди навігатор для перевізників?
До цього ми використовували MapBox як дешевший аналог Google Maps, який добре працював для відображення карт і кастомізації. Проте на той час не існувало готових рішень з навігації, які відповідали б нашим потребам. У випадку з Waze чи Google Maps — SDK ми отримати не могли. Отже, довгий час спостерігали, чи не зʼявився на ринку інструмент, який допоможе нам реалізувати цю фічу. Зрештою MapBox анонсували про запуск Navigation SDK у бета-версії, і ми були чи не першими, хто спробував його інтегрувати.
Важливий нюанс: оскільки ми робимо навігацію для далекобійників, маршрут має прокладатися з урахуванням певних барʼєрів: низьких мостів, де зможе проїхати вантажівка, наявність спеціальних стоянок, а також місць для ночівлі водіїв. Ми втілили усі ці фічі, які добре працювали. Але згодом MapBox вивів SDK із бети та оголосив ціну: $5 за кожного користувача незалежно від кількості поїздок. У нас було чимало водіїв, проте деякі могли проїхати лише один раз за місяць. Якщо сплачувати за кожного з них по 5$, підтримка цієї фічі обходилася б нам у $7 000 на місяць. Це була зависока ціна за функціонал, який був не core-бізнесом, а скоріше приємною плюшкою для збільшення лояльності водіїв.
Якийсь час ми намагалися домовитися про оплату за маршрути, але отримали відмову. У підсумку ми «випиляли» навігатор із застосунку — це була ставка, яка не зіграла. Витративши чимало ресурсів, важливо було не продовжувати вкладати ще більше у глухий кут. Експерименти — важливі, але потрібно бути готовим визнати невдачі й не триматися за рішення, яке не приносить користі.
Проєкт «Pomich»: від ідеї до запуску за декілька днів
На початку повномасштабного вторгнення ми опинилися перед викликом: клієнти, які раніше використовували нашу логістичну платформу, залишились без перевізників і не могли перевезти склади або евакуювати людей. Декілька днів підряд без сну ми працювали в режимі хакатону, щоби створити MVP проєкту «Pomich» — це волонтерська платформа для швидкої координації гуманітарних перевезень. Саме в той момент ми інтегрували декілька експериментальних технологій.
Тоді ми будували окремо фронтенд на Vue.js та бекенд на Laravel. У нас не було часу, щоби створювати API та потім синхронізуватися. Тому ми спробували фреймворк Inertia — він дозволяє створювати вебзастосунки, де бекенд напряму керує рендерингом фронтенд-компонентів без потреби в окремому API. Він тоді щойно зʼявився в бета-версії, значно спростив нам завдання. Якби не постійний моніторинг нових інструментів, ми про нього не дізналися б. Як наслідок — не змогли б запуститися так швидко і почати рятувати людей. Спершу платформа підтримувала лише вантажні перевезення, але згодом ми додали функціонал для евакуації людей. Система дозволяла вводити кількість людей, контактні дані й оперативно з'єднувати їх із перевізниками.
Обізнаність у нових інструментах може зіграти на руку в будь-який момент: наприклад, з вами захотів працювати великий клієнт, а для цього потрібно додати якийсь функціонал. Або через те, з чим стикнулися за останній рік усі технологічні компанії — стрімкий розвиток ШІ. Те, на скільки команда готова швидко реагувати на нові вхідні дані, дозволить компанії як мінімум вижити, а як максимум швидко набрати оберти та обігнати конкурентів.
Отже, технологічна рулетка — це гра, якої не уникнути, тому варто навчитися в неї грати. У нашому випадку виграшною стала така стратегія:
Моніторинг новинок. Постійно відстежуйте, що з’являється на ринку, та на якому етапі розвитку знаходяться технології з вашого стека.
Експерименти. Тестуйте нові інструменти на невеликих сервісах та перевіряйте в робочих умовах.
Шукайте баланс між стабільністю та новаторством.
