Хмельницький часто залишається поза увагою, коли мова заходить про українські технологічні хаби. Однак саме тут сформувалося мислення Андрія Попика – людини, яку знають за здатність вибудовувати надійні системи там, де інші бачать лише хаос. Його підхід до проєктування не вкладається у стандартні кар’єрні рамки, а тяжіє до глибинного аналізу завдань і пошуку рішень, що витримують перевірку роками. Він не орієнтується на тимчасові тренди, натомість фокусується на архітектурі, яка дозволяє бізнесу спати спокійно навіть під час пікових навантажень.
Раннє захоплення технікою та перші спроби програмування
Андрій Попик народився і виріс у Хмельницькому в родині, де технічна література з’являлася частіше за художню. Батько працював інженером-радіомеханіком, що автоматично створило середовище, насичене платами, осцилографами та паяльниками. У віці дванадцяти років він уперше розібрав старий комп’ютер, щоб зрозуміти, чому той постійно зависає. Проблема виявилася в перегріві процесора, але цей досвід запустив ланцюг подій, які визначили його подальший шлях. Замість ігор його цікавили алгоритми роботи операційної системи та те, як машина обробляє команди.
Програмувати він почав із мови Pascal, копіюючи приклади із посібників, які приносив батько. Уже через рік він писав прості утиліти для автоматизації розрахунків у шкільному фізичному гуртку. Однокласники просили допомогти з налаштуванням модемів, а він тим часом вивчав асемблер, бо йому було мало високорівневих конструкцій. Така допитливість сформувала здатність дивитися на систему знизу вгору – від заліза до бізнес-логіки, що пізніше стало його професійною візитівкою.
Перший серйозний збій, який він спричинив сам собі, стався, коли він випадково затер завантажувальний сектор жорсткого диска, намагаючись написати власний завантажувач. Цей випадок навчив його, що архітектурні помилки коштують надто дорого, і краще сім разів подумати перед тим, як щось змінювати на низькому рівні.
Освіта та перші серйозні замовлення
Вступ до Хмельницького національного університету на факультет комп’ютерних наук був логічним продовженням його захоплень. Проте академічна програма швидко перестала задовольняти потребу в реальних проєктах. Уже на другому курсі він почав шукати замовлення на фрилансі, беручись за верстку сайтів і прості скрипти на PHP. Перші гроші прийшли від виконання завдання з автоматизації експорту товарів для місцевого магазину, що торгував автозапчастинами. Тоді він уперше зіткнувся з потребою не просто написати код, а зрозуміти бізнес-процес замовника, який сам до кінця не усвідомлював, як усе має працювати.
Університет дав не так знання, як середовище для обміну ідеями. Він зібрав невелику команду з трьох однодумців, разом вони запустили сервіс для моніторингу цін на продукти в місцевих супермаркетах. Проєкт не став комерційно успішним, але навчив працювати з базами даних під навантаженням і вирішувати конфлікти в коді, коли кілька людей одночасно додають новий функціонал. Саме в цей період він зрозумів цінність систем контролю версій і почав вимагати їх використання в усіх спільних проєктах.
Робота з розподіленими командами та старт великих проєктів
Після отримання диплому Попик не поїхав до Києва чи Львова, хоча пропозиції були. Він обрав віддалену роботу в продуктовій компанії, яка займалася фінтех-рішеннями для європейського ринку. Цей досвід став переломним, бо вимагав не лише технічної майстерності, а й уміння спілкуватися англійською, аргументувати архітектурні рішення перед замовниками, які не завжди розуміли технічний бік питання. Він швидко перейшов від позиції розробника до технічного ліда, координуючи роботу команди з п’яти осіб, розкиданих по різних країнах.
Одним із найскладніших завдань стало проєктування платіжного шлюзу з обробкою понад 500 транзакцій на секунду в пікові години. Система мала бути стійкою до відмов і водночас гнучкою для інтеграції з десятком банків-еквайрів. Попик наполіг на мікросервісній архітектурі з асинхронною обробкою черг на базі RabbitMQ, що дозволило ізолювати критичні компоненти й уникнути каскадних збоїв. Проєкт було здано на три місяці раніше запланованого терміну, а замовник отримав систему, яка без значних модифікацій пропрацювала п’ять років.
Створення власних продуктів і підхід до управління ризиками
Накопичивши досвід у фінтеху, Попик вирішив запустити власний продукт – інструмент для автоматизації логістичних процесів малого бізнесу. Ідея виникла зі спостереження, як місцеві перевізники в Хмельницькому втрачають гроші через неефективне планування маршрутів. Разом із партнером він розробив систему, яка враховувала пробки, погодні умови та пріоритетність замовлень, скорочуючи час доставки в середньому на 22%. Продукт не став масовим, але приніс розуміння ринку та навчив працювати зі зворотним зв’язком від реальних користувачів, які іноді не могли пояснити, чого саме їм не вистачає.
У цей період сформувався його підхід до ризиків, що базується на кількох ключових принципах:
- обов’язкове резервування критичних вузлів на рівні інфраструктури;
- автоматичне тестування всіх змін перед розгортанням;
- документування не лише коду, а й причин вибору тієї чи іншої архітектурної моделі;
- постійний моніторинг аномалій у реальному часі;
- формування плану відновлення для найгірших сценаріїв;
- регулярний перегляд технічного боргу як окреме завдання спринту.
Роль менторства та розвиток локальної IT-спільноти
З часом Попик почав помічати, що багато початківців у Хмельницькому стикаються з проблемами, яких можна уникнути, маючи нормального наставника. Він ініціював серію відкритих воркшопів на базі місцевої бібліотеки, де пояснював базові речі про роботу з Git, налаштування CI/CD та написання чистих тестів. Зустрічі швидко переросли в постійний мітап, що збирав до 60 учасників щомісяця. Для міста, де до цього не існувало регулярних технічних подій, це стало справжнім проривом.
Паралельно він консультував кілька локальних стартапів, допомагаючи вибудовувати процеси розробки з нуля. Його головна вимога до команд – чесність із собою щодо технічних обмежень. Він часто повторював: “Краще визнати, що поточна архітектура не витримає зростання, ніж героїчно латати дірки вночі напередодні релізу”. Саме ця теза стала неформальним девізом спільноти, що сформувалася навколо нього.
Етапи професійного розвитку Андрія Попика
| Період | Основний напрямок | Ключові технології | Особливості підходу |
|---|---|---|---|
| Ранні роки | Вивчення низькорівневих мов та апаратних принципів | Pascal, Assembler | Фокус на розумінні роботи пристрою на рівні архітектури |
| Університетський | Фриланс-проєкти та командна робота | PHP, SQL, JavaScript | Впровадження Git як стандарту для спільних розробок |
| Фінтех-період | Високонавантажені платіжні системи | RabbitMQ, Docker, мікросервіси | Асинхронна обробка і резервування критичних вузлів |
| Власні продукти | Логістичні сервіси для малого бізнесу | Node.js, React, MongoDB | Глибоке занурення у бізнес-вимоги замовника |
Сьогодні діяльність Попика виходить за межі окремих проєктів. Він свідомо залишається в Хмельницькому, доводячи, що глибока технічна експертиза не потребує столичного офісу. Його приклад стимулює місцевих розробників не шукати щастя деінде, а будувати кар’єру там, де вони виросли. Поєднання фінтех-досвіду, викладацької активності та власних продуктів формує навколо нього екосистему, в якій знання передаються не через формальні лекції, а через спільну роботу над реальними задачами. Спостерігаючи за тим, як змінюється місцева IT-спільнота, можна сказати, що вплив однієї людини здатен трансформувати цілий сектор, якщо в її діях поєднуються глибокі знання, послідовність і готовність ділитися напрацюваннями без огляду на конкуренцію.
About the Author
