AS/MX story
Published on January 6, 2026
Речі, які трапляються з нами у дитинстві або в юності часто формують наш світогляд на все життя.
Хочу вам розказати сьогодні одну історію, яка була зі мною на початку карʼєри програміста і здається визначила те, як для мене виглядає розробка продукта.
Рік 2001 (+-)
Компанія, де я працюю, виконує різні контракти для УЗ (Укрзалізниця), створюючі різної складності застосунки чи утілити.
Залізниця тих часів ще в процесі міграції з мейнфрейм-архітектури часів пізнього совка, з величезним мейнфреймом і "тупими" терміналами на касах продажу, на більш сучасну архітектуру -- теж з мейнфреймом, але вже на більш сучасній платформі IBM і з переходом на TCP/IP стек.
Міграція на TCP/IP це було з одного боку питання коштів (дешевий стек, купа стандартних рішень на ринку), а з іншого і політичний теж, бо стара архітектура побудована в Москві і доступу до її змін чи апгрейду фактично немає.
Anyway.
У когось з наших директорів (?) виникла геніальна ідея - створити "проміжну" ланку між легасі-мережею на X.501 і новим TCP/IP, який буде конвертити трафік в обидві боки і дозволяє будувати нову мережу без обмежень старих протоколів.
Назвали цей виріб Access Server & Multiplexer. Або AS/MX.
Ідея дійсно крута, яка знімає цілу пачку головних болей УЗ.
Продано. Контракт підписано. Тепер залишилось їх зробити.
Про виробництво не буду розповідати, я цим не займався. А от писати софт доручили команді з двох людей - "ветерану" Майку, задача якого була побудувати stripped-down Linux distribution і мене-"перспективного джуніора", щоб писати бізнес-логіку.
Я вже колись розповідав про проєкт перекладу тексту на квитках УЗ українською, який по суті був першим апплікейшном для цієї платформи. По суті це був просто рос-укр "словник" і скрипт на Python/Lua (?) який читав транзітний трафік між касою і мейнфреймом і підмінював слова, коли бачив відповідь "друк квитка".
Дуже вдало, бо без цієї платформи ця задача була б х10 разів складніша і більш ризикована.
Але історія не про це, а про "уроки" і "світогляд".
Отже.
1/ Програмісти в ролі продактів це нормально
Не було у нас на цьому проекті продакта чи бізнес аналітика чи навіть проджект менеджера. Щоб зʼясувати вимоги замовника чи зібрати фідбек я брав тестовий юніт AS/MX і їхав до Львова, де власне був перший запуск.
2/ Маленькі команди це круто
Фактично софтверною частиною займалися лише ми вдвох. Так, у нас був технічний керівник, який іноді приходив з запитаннями і якому ми показували проєкт на ревʼю, але таких проєктів у нього було півтори десятки і закопуватися в кожний часу не було.
QA? Ха-ха.
"Протестимо на продакш".
Мені здається самі відсутність великої кількості проміжних ланок (замовник-PM-dev-QA-something) допомогла нам запустити проєкт так швидко, протягом тижнів. А це бтв було критично бо термін "запуску" українізації визначала постанова Верховної Ради і вони там не сильно заморачувались технічними питаннями й feasibility, як власне й зараз. :)
3/ Risky projects are for veterans
Це власне не я, а Друкер, але суть не міняється.
Мій напарник був досвідчений розробник, у якого вже були за плечима кілька успішно реалізованих проектів і (важливо!) довіра керівництва. Якщо я б напартачив, мою роботу зробив би хтось інший, але принаймні критична частина проєкту буде зроблена.
"Якщо ця задача в принципі doable я вірю, що він (вона) знайде рішення" - це те, що ви хочете на старті (важливого) проєкту.
4/ Шукай класних людей і тримайся за них, якщо знайшов
Цей проєкт ми здали і здається був потім ще один, але десь за рік я з цієї компанії пішов. Бо не отримав адекватної, на мою можливо завищену самооцінку, винагороди.
Рівень зарплат в "айті" (ніхто тоді це так не називав) на початку 2000х був не захмарним, але рівень талантів в тій компанії був на висоті. Може це повʼязано, хз.
Для мене було трохи шоком, коли я пізніше шукав роботу або шукав людей, наскільки в середньому нижче були їх рівень, мотивація та work ethics.
Мій колишній керівник пізніше став R&D Director українського офісу Samsung, а мій напарник - Senior Technical Fellow в канадському QNX (real-time OS для automotive).
Якщо ти знайшов класну людину, то за неї треба триматися. І зробити так, щоб вона не пішла. Часто це гроші, але зовсім не обовʼязково. Це може бути нові челеджі, певна посада або шось зовсім інше.
5/ No shortcuts
Зараз популярні поради як "хакнути" кар`єру, зарплату, ринок і тд. Такий контент класно розсходиться бо його приємно читати і шарити. Відкрив рота, а тобі туди вареники застрибують.
Але на тому проєкті (та й на інших) ми багато працювали. Буквально дім-робота-дім. І цей досвід і звички потім дуже мені допомогли зі стартом ДОУ і Djinni.
There are no shortcuts.