Буває у вас таке? Відбувається якась подія — і ви раптом розумієте, що вона змінює саме ваше сприйняття реальності. Щось клацає всередині, і світ, який здався знайомим, починає виглядати інакше. Ви помічаєте новий тренд, відчуваєте, як змінюється повітря навколо, і, можливо, вам це не до вподоби. Але у певний момент розумієте: опиратися марно, бо реальність уже змінилася, і єдине, що залишається — прийняти її такою, якою вона стала.
Про ці моменти прозріння, прийняття і внутрішніх зрушень — наша нова стаття.
Клієнт приніс нам “майже готовий” проєкт на доробку. Точніше — те, що здавалося готовим: інтерфейс працює, кнопки натискаються, звіти рахуються. Lovable згенерував 90% коду за “пару тижнів”. Решта — “дрібні доопрацювання, з якими AI не впорався”.
Типова ситуація: фаундер вирішив спробувати AI-інструмент — і в нього навіть вийшло. Ймовірно, він уже підрахував, скільки грошей заощадив. А в коді все як завжди: суцільний технічний борг, архітектури — рівно настільки, наскільки дозволяє обраний фреймворк, шари коду накладені один на одного в
Як оцінити невизначеність: від експертного чуття до керованого знання
Під час оцінки програмних проєктів вендор завжди стикається з однією і тією ж проблемою: частина майбутньої роботи лежить у зоні невідомого. Нові інтеграції, незнайомі API, архітектури, з якими команда ще не працювала — усе це створює невизначеність, яка ускладнює формування точних оцінок. Замовник очікує конкретних цифр, а розробник не має достатньо даних, щоб ці цифри обґрунтувати. У результаті виникає спокуса або завищити буфер “на всяк випадок”, або, навпаки, занизити оцінку, щоб виглядати конкурентно.
Але невизначеність — це не синонім некомпетентності. Це лише відсутність інформації. І завдання зрілої команди полягає не в тому, щоб вгадати тривалість роботи, а в тому, щоб системно заповнити інформаційні прогалини і зробити оцінку обґрунтованою.
Коли spike уже запізно
Багато інженерних практик пропонують боротися з невизначеністю через дослідницькі задачі — spike stories. Такий підхід справді працює, коли проєкт уже запущений, і команда може виділити день-два на перевірку гіпотези.
Але на етапі пресейлу, коли клієнт лише описує ідею або майбутню систему, spike перетворюється на дороговартісну інвестицію без гарантій, що контракт узагалі відбудеться.
Тому в пресейлі важливо не розробляти, а зрозумітиЧитати далі
Дослідницькі ІТ-проєкти проти класичних: уроки та практики від ІнтерЛінк
У світі ІТ ми звикли до класичних проєктів: є вимоги, дизайн, архітектура, терміни й чіткі релізи. Але дослідницькі проєкти працюють за іншою логікою. Їхня мета — не стабільність, а відкриття нового: алгоритмів, методів, моделей. Тут важливі експерименти, гіпотези, метрики та знання, які накопичуються навіть у випадку «негативних результатів».
Урок 1. Багато експериментів дорівнює багато точок входу
Дослідницький код часто стартує з десятків скриптів і ноутбуків, кожен з яких відповідає за окремий експеримент чи спробу. Це природно, бо пошук нових рішень вимагає паралельної перевірки ідей. Проте хаотичність зростає дуже швидко, і без організації проєкт перетворюється на «кладовище скриптів».
Практика: розділяти структуру репозиторію на src/, notebooks/, experiments/, додавати README до кожної папки, а завершені напрацювання переводити в модулі.
Урок 2. Намір коду зникає з часом
Часто через кілька місяців уже неможливо згадати, навіщо писався той чи інший скрипт. Контекст губиться, а повторне використання стає болючим.
Практика:
- вести «лабораторний журнал» (notion/obsidian/wiki), де кожен експеримент описується: мета → налаштування → спостереження → висновки;
- залишати короткий header-коментар у скрипті з датою, автором і наміром.
Урок 3. Фіксація результатів важливіша за постійну оптимізацію
У дослідницькій роботі часто трапляється: «оптимізували» модель — і вона стала працювати гірше. Проблема в тому, що початковий варіант ніхто не зафіксував. Відновити його через місяць неможливо.
Практика:
- використовувати системи трекінгу експериментів (MLflow, Weights & Biases, Neptune);
- зберігати не лише код, але й артефакти: дані, метрики, середовище;
- додавати до кожного експерименту коротке резюме «що зроблено, що вийшло, що далі».
Урок 4. Ідеї треба фіксувати, навіть якщо вони «сирі»
Дослідницький проєкт — це не лише експерименти, а й постійний потік ідей. Проблема: через кілька тижнів складно згадати, яку гіпотезу ми обговорювали і чому її відклали.
Практика:
- мати простий інструмент для швидкої фіксації
Як ми розв’язали задачу, яка не мала технічного рішення
- oleksii
- 31st Июл 2025
- KT sessions
- off
Ми в ІнтерЛінк створювали систему бронювання сервісів із можливістю миттєвої купівлі. На перший погляд, задача здавалася типовою. Проте з перших же спроб стало очевидно: стандартний підхід не спрацює.
Чому так складно просто «забронювати»
Щоб підтвердити замовлення, потрібно виконати послідовно декілька кроків:
- перевірити, чи доступний сервіс на обране клієнтом вікно часу (3 секунди),
- забронювати його у провайдера (5 секунд),
- провести оплату на наш рахунок (5–10 секунд),
- підтвердити бронювання у провайдера (ще 5 секунд).
У найкращому випадку — 18 секунд. У реальному світі — ближче до 25.
Коли ми завершили базову реалізацію, з’ясувалося: прискорити цей процес технічно неможливо. Ми перепробували варіанти оптимізації, розглядали зміну послідовності дій, але кожен альтернативний сценарій або створював фінансові ризики для нашої компанії (наприклад, оплачувати замовлення до бронювання), або ламав логіку бізнесу.
Коли проблема не в швидкості, а в тиші
На етапі брейнштормів команда зробила важливе спостереження: користувачі рідко обурюються самою тривалістю процесу. Проблема — у відсутності зворотного зв’язку. Якщо система просто показує повідомлення типу “Booking is in progress…” і нічого більше не відбувається — користувач втрачає довіру. А отже — і покупку.
Це стало поворотним моментом. Ми переформулювали задачу: нам не потрібно пришвидшувати процес, якщо ми зможемо зробити його зрозумілим і передбачуваним.
Прозорість як інструмент довіри
Ми змінили інтерфейс і розбили процес на чіткі етапи з миттєвою зворотною реакцією:
- Перевіряємо доступність часу — Ура, час доступний.
- Бронюємо сервіс — Супер, бронь підтверджено.
- Проводимо оплату — Чудово, гроші отримано.
- Оформлюємо підтвердження — Готово, усе працює.
У підсумку той самий технічно складний і довгий процес перетворився на спокійний, зрозумілий і приємний досвід для користувача. Ніхто не скасовував купівлю. Ніхто не жалівся. А ми — не ризикували нічим.
Що варто винести з цього кейсу
Користувачі не проти чекати — якщо
Історія зародження ІТ в Черкасах
- Ірина Чернишова
- 23rd Июн 2020
- Проекти
- 0 Comments
Як все починалось
Перші ПК в Черкасах почали з’являтися у великих компаніях, таких як Азот та Фотоприлад на початку 1980-х років. Нові верстати з ЧПУ були останнім словом техніки і були чимось на кшталт чуда. Програмісти тих часів вважалися як мінімум вченими і працювали з перфокартами. Практично ніякої комп’ютерної літератури на той час не існувало і базову інформацію про програмування звичайним обивателям можна було почерпнути лише з журналу “Наука та Життя”. Та навіть таким статтям відводили 2-3 сторінки (наприклад список команд сучасної тоді мови програмування Basic). Роль комп’ютера зазвичай зводилася до найпростіших операцій та навчання програмуванню. Мережі були великою рідкістю. Про комп’ютерні класи в школах ніхто не чув, а придбати комп’ютер додому було великою розкішшю, та й користь від такої покупки була сумнівна. Любителі могли торкнутися програмування, використовуючи програмовані калькулятори.
СССР, середина 80-х. Починається перебудова. Військові заводи в рамках конверсії починають масово переходити на виробництво товарів народного споживання. Горбачов особисто керує крупними проектами та відправляє своїх людей (наприклад Рауфа Аблязова) у різноманітні регіони союзу. Так у Черкасах зароджуються два ключових підприємства, які створять передумови для розвитку ІТ індустрії – це завод Ротор та НДІ Аккорд. В Черкаси разом зі своїми сім’ями переїздять цілі колективи спеціалістів з Москви та Ленінграду. Вони налагоджують виробництво комп’ютерів ZX-Spectrum під назвою Робік (Ротор), які на той час продаються в єдиному місці в Черкасах – Будинку Торгівлі. Ці ж самі спеціалісти в майбутньому і почнуть розробку ПЗ (Аккорд) для різноманітних потреб.