Результати пошуку

Genesis збільшить кількість освітніх та інвестиційних можливостей для технологічних бізнесів із країн Центральної та Східної Європи. Для цього компанія обʼєднує стартапи та глобальні компанії-партнери в одну екосистему — TRMNL4 (Термінал фор). Проєкт сфокусований на двох напрямах: T4.Programs — освітні програми з розвитку та масштабування технологічних бізнесів. T4.Community — спільнота, що обʼєднує фаундерів та інвесторів. Серед партнерів проєкту — big tech компанії Meta, Amazon Web Services, Deel, Zendesk. У нетворку — понад 40 венчурних фондів, які інвестують у стартапи з регіону ЦСЄ та за його межами, зокрема, ffVC, Market One Capital, SMOK Ventures, Presto Ventures та інші. «У Genesis зародилися успішні українські технологічні продукти світового рівня — Jiji, BetterMe, Headway. Для українського ринку ми вже створили унікальну бізнес-екосистему, і хочемо продовжувати обмінюватися своєю експертизою з підприємцями Європи. Наш новий проєкт TRMNL4 стане платформою можливостей для розвитку IT-бізнесів, обміну практичними знаннями та нетворкінгу», — коментує Артем Копанєв, COO Genesis. Прикладом навчальних програм для фаундерів в межах TRMNL4 є StartUp Academy, яку Genesis разом із Meta реалізує з 2021 року. За цей період у програмі взяли участь понад 120 стартапів, а сім із них залучили інвестиції на суму від $100 000 до 1 млн доларів після проходження програми. Зокрема, це компанії Bloomcoding, Inputsoft, EasySales, QuickShippersi. Другим напрямом TRMNL4 є T4.Community — закрита спільнота, що нині налічує понад 100 фаундерів із різних країн Європи, зокрема, України, Польщі, Чехії, Румунії, Грузії, Литви, Естонії та інших. «Усі можливості від TRMNL4 є безоплатними. Однак взяти участь у програмах чи спільноті можуть лише наймотивованіші — для цього потрібно пройти попередній відбір. Наша мета — обʼєднати дійсно амбітних підприємців із Центрально-Східної Європи та надати ресурси для якісного зростання: нетворк, бізнес-контент, доступ до найкращих фондів, що інвестують у СЕЕ, та чесний фідбек від колег і наших експертів», — коментує Тетяна Ладанова, TRMNL4 Lead. До кінця 2023 року команда TRMNL4 планує запустити серію відкритих онлайн-подій від TRMNL4, а також готується до нового сезону Genesis StartUp Academy together with Meta в наступному році. Більше про проєкт — на сайті TRMNL4.

Вибір сервісно-орієнтованої архітектури для застосунку дає чимало переваг: легка підтримка, стійкість, швидкість розробки та адаптивність системи до змін. Водночас її побудова повʼязана із низкою викликів та потенційних проблем, вирішити які може правильний оркестратор. Сай Прагна Етікайла, Tech Lead в Twilio, поділилася досвідом роботи з асинхронними архітектурами. На конференції Software Architecture fwdays'23, що відбулася у вересні в офісі Genesis, вона розповіла, як побудувати систему, яка працюватиме безперебійно, її можна буде масштабувати та додавати нові фічі або процеси без надзусиль. Що таке сервісно-орієнтована архітектура Сервісно-орієнтована архітектура (SOA, service-oriented architecture) — це популярний архітектурний шаблон для створення програмних застосунків на основі окремих модулів. Асинхронною називають SOA, в якій кожен сервіс є автономним і виконує окреме завдання. Якщо синхронна система надсилає запит і чекає негайної відповіді, то в цьому дизайні комунікація між сервісами цього не потребує. Це означає, що клієнт може надіслати запит і перейти до інших завдань, не чекаючи відповіді. Візьмемо до прикладу застосунок із доставки їжі. Після розміщення замовлення клієнту не потрібно чекати, поки ресторан приготує їжу, щоби продовжити користуватися застосунком. Він може вивчати меню чи робити замовлення в інших ресторанах. Коли його замовлення буде готовим або доставленим, він отримає сповіщення. Можливість надсилати запит і отримувати відповідь у невизначений час відображається в асинхронній SOA. Виклики побудови асинхронної SOA Створення асинхронних сервісно-орієнтованих архітектур повʼязано із низкою потенційних проблем. Управління станом У вищезгаданому прикладі команді буде складно підтримувати та керувати станом кожного окремого процесу. Після того, як користувач розмістив замовлення, воно проходить різні стадії: підтверджується, готується, а потім доставляється. Кожен із цих етапів є незалежною подією, деякі відбуваються одночасно з іншими. Тому точне керування станом кожної події в цих розрізнених процесах — виклик. Уявіть, що програма доставки показує, що замовлення тільки підтверджено, а насправді воно вже готове до відправки. Це може призвести до плутанини та потенційного невдоволення клієнта. На зображенні нижче — приклад того, як може виглядати архітектура такої керованої подіями (event-driven) системи. Щоразу, коли відбувається подія, вона запускатиме нову операцію. Тож, по суті, замість послідовності кроків, система виконує окремо події X, Y та Z, насправді не розуміючи послідовності етапів, які відбуваються в системі доставки їжі. Відмовостійкість Якщо під час замовлення їжі платіж було відхилено, або ресторан не отримав сповіщення про замовлення, це може спричинити зупинку всього процесу. Отже, важливо подбати про механізми ефективної обробки помилок, які зроблять систему більш відмовостійкою. Наприклад, система може повторити невдалу операцію або сповістити користувача про проблему та запропонувати повернутися на крок назад. Трасування та моніторинг системи У системі доставки їжі, скажімо, Uber Eats, залучено багато частин, наприклад застосунок для клієнтів, ресторанні системи, застосунок партнерів з доставки та серверні служби. Коли справа доходить до відстеження певного процесу або вузьких місць у продуктивності, це схоже на пошук голки у стозі сіна. Наприклад, клієнт повідомив, що не отримав свою їжу, хоча програма показує, що вона доставлена. Без належного відстеження неможливо визначити, де процес пішов не так — під час приготування їжі в ресторані чи транспортування кур’єром? Можливість якісного моніторингу системи має вирішальне значення для швидкого виявлення проблем. Ремонтопридатність Асинхронні системи за своєю природою є складними. Оскільки вони розвиваються та масштабуються, з часом їхня складність лише зростає. Припустимо, ви хочете додати функцію пріоритетної доставки для преміумклієнтів. Якщо система спроєктована погано, це може вплинути на численні компоненти та служби й потребуватиме численних доопрацювань. Завдання ремонтопридатності полягає в тому, щоби забезпечити можливість легкої модифікації, розширення та масштабування систем без збоїв у роботі та надмірних зусиль. Щоб уникнути всіх перелічених проблем та забезпечити легке масштабування асинхронних систем, команди використовують системи оркестрації. Як оркестрація розв'язує проблеми асинхронної SOA Оркестратори — потужні інструменти, які впорядковують асинхронні системи й забезпечують їхню ефективність, надійність і масштабованість. Вони діють як центральні координатори, які керують усіма процесами. Подібно до диригента в оркестрі, вони забезпечують виконання завдання у відповідний час і в правильній послідовності. Розберемо, як оркестратори допомагають подолати вищезазначені проблеми. Відстеження станів та керування послідовністю У наведеному вище прикладі архітектури ми побачили, що система не розуміє справжньої послідовності етапів замовлення, приготування та доставки їжі. Таким чином, у граничному випадку події можуть виконуватися не в тому порядку, якого очікуємо. Це відбувається, коли кінцевий автомат (State Machine) отримує подію, в якій, наприклад, база даних перебуває в стані A, а не в стані Y. Він не знатиме, як з цим впоратися, і просто ігноруватиме її. Обробки подій вручну несуть величезні витрати на розробку, адже щоби внести зміни в один конкретний стан, вам потрібно знати всю базу коду, переглянути всю послідовність, щоби зрозуміти, що граничні випадки враховані. Оркестратори використовують попередньо визначені робочі процеси або послідовність завдань, які відповідають різним етапам доставки. Механізм визначає порядок, у якому має виконуватися завдання, а також будь-які залежності чи умови між ними. Підтримуючи цей організований потік станів, оркестратори усувають хаос і будь-які потенційні невідповідності в переходах між станами. Вони також гарантують, що всі сторони, від внутрішніх команд до користувачів матимуть точну та своєчасну інформацію про статус замовлення. Якщо на попередньому графіку ми бачили систему, повністю керовану подіями, то тепер оркестратори дбають про послідовність усіх подій. Автоматична обробка помилок та підвищення відмовостійкості Оркестратори мають вбудовані механізми, які обробляють помилки та підвищують надійність системи. Наприклад, якщо під час замовлення виникає помилка з платежем, інструмент автоматично повторює невдалу операцію або застосує стратегію резервного копіювання, щоби дати системі час для розв'язання проблеми. Це дозволяє їй працювати безперебійно у разі виникнення неочікуваних помилок. Ви можете задати необхідну конфігурацію — вказати кількість спроб чи час очікування відповіді системи. Наприклад, якщо клієнт замовив піцу, а його платіжна система не відповідала протягом двох годин, немає сенсу продовжувати замовлення. Широкі можливості моніторингу системи Інструменти оркестрації дозволяють налаштувати моніторинг складних асинхронних систем, щоби кожен процес був видимим та простежуваним. У такий спосіб команді значно легше виявляти вузькі місця та усувати проблеми. На прикладі з доставкою їжі завдяки оркестраторам ви можете відстежувати, скільки замовлень було відкрито та обробляється в поточний момент. Полегшення ремонтопридатності та адаптивності Одним із завдань підтримки асинхронних систем є внесення змін або додавання нових фічей без порушення роботи всієї системи. Оркестратори надають чіткі та засновані на коді флоу, які дозволяють швидко збирати базову інфраструктуру проєкту. Це полегшує розуміння та модифікацію системи, дозволяє швидко вносити зміни або запроваджувати нові фічі, а сама система може розвиватися та адаптуватися до нових вимог. Розширення продуктивності розробки Абстрагуючи складність асинхронних систем, оркестратори забезпечують високорівневу модель програмування. Так розробники можуть зосередитися на бізнес-логіці та основних функціональностях програм, які насправді приносять цінність, а не потопають через проблеми інфраструктури. Все це прискорює процес розробки та скорочує час виходу на ринок. Керування станом, моніторинг, відмовостійкість, зменшення видатків та можливість швидко додавати нові фічі, про які ми говорили вище, — все це оркестратори забезпечують «з коробки». Інструменти для оркестрації Існує багато систем оркестрації, кожна з яких має унікальні функції та переваги. Деякі з них мають відкритий вихідний код, інші — open-source з керованими рішеннями, деякі — закритий вихідний код. Розглянемо найпопулярніші з них. Apache Airflow. Популярний гнучкий оркестратор із відкритим кодом, у якому задачі та їхній порядок описуються з допомогою Python. Apache Airflow підходить для завдань дата-інжинірингу, конвеєра даних та сценаріїв, де кроки робочих процесів можуть часто змінюватися. Інструмент має активну спільноту та широку підтримку плагінів. Argo. Нативний оркестратор від Kubernetes, який було розроблено для хмарних середовищ. Argo використовує потужність K8s для керування робочими процесами та забезпечення їхньої гнучкості та відмовостійкості. Кожен крок у робочому процесі Argo розглядається як контейнер. Цей інструмент підходить командам, які вже використовують Kubernetes і потребують масштабування. Temporal. Простий та надійний оркестратор з відкритим кодом. Існує декілька SDK для цього інструменту: ви можете описати свій робочий процес як код на Java, .NET, Go чи PHP. Такий підхід корисний, якщо у вас є складна бізнес-логіка, яка має багато розгалужень. Наприклад, в службі доставки їжі можна описати таку функцію: якщо кур’єр повідомляє про поломку автомобіля, треба негайно скасувати замовлення, повідомити про це клієнта та повернути йому гроші. Temporal має вбудовану обробку відмов й переривання, чудово керує робочими процесами зі збереженням стану, пропонує керований хмарний сервіс. AWS Step Functions. Повністю керований оркестратор, який надають Amazon Web Services. Він спрощує оркестрування складних багатоетапних програм за допомогою візуальних робочих процесів. У цьому інструменті вони визначені не як код, а за допомогою кінцевого автомата Amazon (The Amazon States Language). Step Functions легко інтегрується з іншими службами AWS, пропонує відмовостійкість і простоту використання, що дозволить розробникам створювати надійні та масштабовані програми. Отже, обираючи оркестратор робочого процесу, враховуйте такі фактори, як складність завдань, вимоги до масштабованості, інтеграцію з наявною інфраструктурою та зручність програмування. Кожен інструмент пропонує унікальні функції та переваги, але зрештою усі вони дозволяють розробникам створювати стійкі, масштабовані та підтримувані програми.

Жовтневий дайджест присвячуємо вакансіям для фронтенд-розробників, яких активно шукають компанії з екосистеми Genesis. У списку ви знайдете можливості попрацювати над розробкою продуктів, якими користуються мільйони юзерів у всьому світі — від утиліт для продуктивності до платформи з вивчення іноземних мов. Обирайте релевантну вакансію та долучайтесь до команди топперформерів. Front-end Developer В SUITSME з екосистеми Genesis шукають фронтенд-розробника, який має від трьох років досвіду за спеціальністю. Майбутній співробітник SUITSME має розбиратися в розробці CMS-систем, вміє використовувати Vue.js 2, знається на Typescript, REST API, Axios, HTML5/CSS та Git. Його основними завданнями на проєкті буде впровадження нових функцій в CMS для підтримки наявного функціонала, написання документації для власного коду тощо. В команді від нього очікуватимуть активної участі у житті й розвитку продукту, цікавості або й пристрасті до ігор та геймдеву. Досвід роботи з Figma, C# та AWS буде перевагою. Front-end Developer Universe – компанія, що створює утиліти для продуктивності, якими користуються 50 млн юзерів у 180 країнах світу. Нині компанія розвиває новий вебпродукт у ніші розробки й конвертації документів, до команди якого шукають фронтендера. Він працюватиме над запуском SEO-напрямку нового продукту: адаптуватиме моделі даних у Strapi, встановлюватиме та налаштовуватиме нові плагіни для CMS, взаємодіятиме з командою дизайнерів та верстатиме готові дизайни з Figma тощо. Серед вимог до кандидата: мінімум один рік комерційного досвіду, знання React.js, розуміння клієнт-серверної архітектури, розуміння семантики та структури HTML-сторінки. Front-end Developer Компанія OBRIO з екосистеми Genesis створила і розвиває один з найпопулярніших у своїй ніші астрологічний застосунок Nebula. Нині продуктом користуються близько 30 млн юзерів у всьому світі. OBRIO відкрила позицію фронтенд-девелопера в growth-команду. Якщо ви фронтендер із широкою експертизою в React.js та Next.js, відмінними знаннями Typescript і JavaScript, досвідом розробки Redux від одного року, ця вакансія точно вас зацікавить. В OBRIO ви будете покращувати наявні вебпродукти, створювати нові функції для них та інтегрувати різні аналітичні системи тощо. В межах цих задач співпрацюватимете із продуктовими командами та QA-фахівцями. Front-end Team Lead Вакансія для фронтендерів із лідерськими навичками та досвідом управління командами. Компанія Boosters шукає фронтенд-тимліда для одного зі своїх продуктів — платформи для вивчення іноземних мов Promova. Наразі кількість завантажень застосунку сягнула 10 млн. Амбітна ціль компанії — досягти статусу «єдинорога» в наступні п’ять років. Лідер команди фронтендерів налаштовуватиме процеси та підходи до фронтенд-розробки продукту, вирішувати складні технічні, стратегічні та архітектурні питання, взаємодіятиме з декількома продуктовими командами, братиме участь у розробці нових фічей тощо. Від кандидата на цю посаду очікують від одного року аналогічного досвіду, вміння працювати із TypeScript, React, Redux, Next.js, CSS Modules; а також з monorepo, npm library publishing, webpack, babel configuration. Якщо ви маєте релевантний досвід та готові розвивати фронтенд-фахівців і цей напрям, впроваджувати ефективні та новітні технічні рішення разом з лідами інших гільдій, сміливо надсилайте своє резюме. Що почитати про фронтенд-розробку? Що дратує Front-end Developer: 7 болів від розробника в Genesis Growth Про те, що найбільше дратує фронтендерів, у традиційній рубриці нашого блогу розповів Олесь Марола, Front-end Developer у Genesis Growth Team. Необхідність працювати під тиском, підтримувати чистий код у проєктах, складність яких постійно зростає, та інші актуальні проблеми фронтендерів — у матеріалі. 8 міфів про фронтенд. Спростовує Front-end Developer в OBRIO Хтось вважає, що мікрофронтенд — це універсальне рішення. Хтось — що нативні застосунки завжди будуть зручнішими за веб. Фронтендер з OBRIO Микола Носенко вважає, що все вищезазначене — міфи. Ми розпитали Миколу про ці та інші стереотипи у фронтенд-спільноті та детально розказали про те, чому вони існують та як їх спростовують. 15 найкращих книг із JavaScript для розробників усіх рівнів Шорт-ліст з 15 найкращих книг для тих, хто працює із JavaScript. Корисні джерела для себе тут знайдуть як джуни, так і сеньори. Про переваги й недоліки кожної з цих книг розповіла Марія Образцова, фронтенд-розробниця з компанії Universe.

Мова програмування Java — досить широка технологія, яка використовується в багатьох сферах розробки, включаючи веб, серверні та мобільні застосунки, ігри тощо. На Java часто пишуть складні проєкти, які передбачають роботу з великими кодовими базами, масштабування, оптимізацію й управління ресурсами, що потребує спеціалізованого досвіду. Водночас ця технологія має надзвичайно велику і складну екосистему бібліотек, фреймворків та інструментів. Залежно від специфіки компанії, співбесіди на посаду Java Developer можуть проходити за різними сценаріями. Павло Димитрієв, Tech Lead Solidgate, партнерської компанії Genesis, поділився підходом до інтерв’ювання Java Developer різних грейдів. Він пояснив, чому компанія відмовилася від стандартного списку питань на користь персоналізованого підходу; як перевіряють розуміння теорії у джунів, наскільки глибоко мідли знайомі з технологією, та чому у підготовку до інтервʼю з сеньйором варто інвестувати додатковий час. > Чому в Solidgate відмовилися від стандартного алгоритму співбесіди > Питання для Junior Java Developer > Питання для Middle Java Developer > Питання для Senior Java Developer Чому в Solidgate відмовилися від стандартного алгоритму співбесіди Раніше в українській фінтех компанії Solidgate ми інтерв’ювали кандидатів за стандартним списком питань. Як більшість проєктів, у такий спосіб ми прагнули оптимізувати підготовку та проведення технічних інтервʼю. Проте цей підхід мав очевидні недоліки: часом ми проводили по пʼять співбесід на день, та іноді не розуміли, кому з кандидатів запропонувати офер. Бувало, що чотири з п’яти кандидатів давали правильні відповіді, але статистично неможливо, щоби кожен з них підходив компанії. В цьому полягає ключова проблема: людина може відповісти на всі питання, але не буде продуктивною на проєкті та не пройде випробувальний період. Цілком імовірно, що найбільш ефективним міг би бути той пʼятий, хто відповідав гірше, адже шаблонні запитання заганяють в рамки й не допомагають зрозуміти людину, її зацікавленість, мотивацію та досвід. Відсіювати людей на випробувальному етапі — неефективно, тому ми змінили фокус на персоналізований підхід. Його цінність полягає в тому, що ми дивимося на кожного кандидата з точки зору того, чи підійде він нам в тій конфігурації, з його інтересами, навичками, досвідом. До таких співбесід складніше готуватися, адже вони проходять за різними сценаріями. Проте такий досвід значно цікавіший для обох сторін. Навіть якщо кандидат не отримав офер, він чітко розуміє причину. Це не викликає в нього обурення, як у випадку зі стандартним списком: «я відповідав правильно, а мене не взяли». Навпаки, ми отримуємо позитивний фідбек, що це був цікавий і корисний досвід, не зважаючи на результат. Індивідуальні співбесіди — поширений підхід у продуктових компаніях, яких цікавить довгостроковий найм. Отже, ми сформували такі принципи інтервʼю для Java Developer: Junior Java Developer — теоретичні питання з акцентом на розуміння, пошук областей програмування, які викликають найбільший інтерес та захоплення у кандидата. Middle Java Developer — питання про технології, з якими працював кандидат, оцінка того, наскільки глибоко він занурювався в них. Senior Java Developer — питання про досвід та досягнення, занурення в кейси, щоби оцінити участь кандидата в тих чи інших проєктах. Нижче я розповім про співбесіди з кожним грейдом окремо, наведу приклади та кейси. Питання для Junior Java Developer Джуніор — це спеціаліст, який вже має теоретичні знання, вміє закривати певні задачі та приносити цінність проєкту. У таких спеціалістів є досвід, але його мало, тому найперше, що має зрозуміти інтервʼюєр, — як швидко джуніор може стати мідлом. Для цього є дві передумови: певна теоретична база, зокрема обовʼязкове розуміння, як це працює і для чого потрібно, та зацікавленість спеціаліста. Я вибірково проходжуся такими темами: Computer Science, алгоритми та структури даних, Java Core, мережі, бази даних, патерни та принципи програмування, знання інструментів (Git, Docker, AWS, Spring тощо). По кожній із них я ставлю декілька питань та намагаюся упевнитися, на скільки кандидат розуміє теорію та як її застосовувати на практиці. Щоби підготуватися до співбесіди, важливо не просто «зазубрити» відповідь. Я завжди намагаюся отримати пояснення, які проблеми вирішує та чи інша технологія чи підхід (дуже добре, якщо відповідь включатиме конкретні приклади). Це розуміння є обовʼязковим і стосується кожного теоретичного питання. Наприклад, про SOLID питають на всіх співбесідах. Я прошу пояснити своїми словами, у чому ці принципи полягають, і найголовніше — для чого їх потрібно знати? 20 років тому розробники писали код без усіх цих принципів, і він працював, тож навіщо ускладнювати собі життя? Навіть не маючи в цьому досвіду, джуніор має розуміти, для чого це потрібно, інакше не буде інвестувати свій час у те, щоби тренуватися писати за цими принципами. Розповідаючи про патерни рефакторингу та проєктування, кандидат має пояснити, які завдання вони вирішують та яким проблемам запобігають. Говорячи про методи та алгоритми сортування, цінніше не те, скільки кандидат їх перелічить, а чи розуміє він, чому їх так багато? Чому розробники не оберуть один найкращий? Будь-який з цих методів та алгоритмів працює, але який обрати залежно від задачі? Коли ми говоримо про принцип інверсії залежностей (dependency inversion), якщо кандидат відкриє чужий код, як зрозуміти, чи застосовувався в ньому цей принцип? За якими критеріями він це визначить? Про рівень зацікавленості кандидата завжди говорить те, чи вивчав він додатково книжки з програмування. Наприклад, ми спілкуємося про хеш-мапи. Розробник вже зміг пояснити, як це працює і для чого потрібно. Далі я наводжу кейс нетривіальної проблеми: уявімо, що в хеш-таблиці сталося багато колізій і її ефективність деградувала. Чи можна цю проблему мінімізувати певними діями? Часто кандидати пропонують досить цікаві життєздатні рішення. Але найбільший бал від мене отримає той, хто помітить, що навіть в стандартній реалізації продуктивність не падає нижче логарифмічної та пояснить, чому це саме так. Це свідчить про те, що кандидат не полінувався полазити по стандартній колекції, розібратися, почитати щось на кшталт Герберта Шилдта чи Брюса Еккеля. Це означає, що в нього є інтерес до технології. Нижче наведу теми та приклади запитань. Але, як і для інших грейдів, немає двох однакових інтервʼю з Junior Java Developer, кожна співбесіда проходить індивідуально. Якщо прямо зараз ви готуєтеся до технічного інтервʼю, рекомендую продивитися питання та оцінити, чи розумієте ви, для чого це знати. Java Core 1. Назвіть основні принципи ООП. Як вони проявляються в Java? 2. Поясніть своїми словами, як працює кожен з принципів і для чого потрібен? 3. Як зрозуміти, що той чи інший принцип реалізований в коді? 4. Розкажіть про основні поняття ООП — клас, обʼєкт, інтерфейс? Чим вони відрізняються? 5. Що таке конструктор у Java? 6. Які класи не наслідуються від Object? 7. Що таке Local Variable та Instance Variable? У чому відмінність? 8. Заміщення методу (method overriding) — що це та як працює? 9. Що таке default method в Interface? 10. В чому різниця між String, String Builder та String Buffer? 11. Що таке ключове слово final та як його використовувати? 12. Що таке mutable / immutable? 13. Що таке wrapper classes у Java? 14. Java Development Kit (JDK) — що це? 15. Що таке Java Runtime Environment (JRE) і як використовується? 16. Що таке HashSet та HashMap у Java? Чим відрізняються? 17. Які модифікатори доступу в Java вам відомі? Як вони впливають на доступність класів і методів? 18. Які основні принципи автоматичного управління пам'яттю використовуються в Java? 19. Які є основні засоби обробки винятків у Java, і як вони використовуються? 20. Що таке потоки (threads) в Java? Як працює багатопотоковість в Java? 21. Як працює синхронізація потоків? Які методи для цього використовують? 22. Чи можна обмінюватися даними між потоками? 23. Як використовувати серіалізацію і десеріалізацію в Java для роботи з об'єктами та зберігання даних? Computer Science 24. Що таке алгоритм? Які властивості хорошого алгоритму? 25. Які основні структури даних знаєте? Дайте приклади використання кожної з них. 26. Які алгоритми сортування ви знаєте? Чим вони відрізняються один від одного? 27. Як визначити, який алгоритм сортування буде найбільш ефективним в різних ситуаціях? 28. Що таке рекурсія? В яких випадках вона корисна при написанні програм? 29. Як працює алгоритм пошуку в ширину (BFS) і пошуку в глибину (DFS)? Дайте приклади їх використання. 30. Як ви розумієте поняття «Big O notation»? Як це впливає на ефективність алгоритмів? 31. Які основні принципи мемоізації в алгоритмах і для чого вона використовується? Патерни та принципи 32. Які основні категорії патернів проєктування вам відомі, і які принципи вони втілюють? 33. Що таке DRY (Don't Repeat Yourself) принцип і чому він важливий у розробці програмного забезпечення? 34. Яким чином принцип YAGNI (You Aren't Gonna Need It) сприяє покращенню ефективності розробки? 35. Що означає SOLID, і які основні принципи цього набору принципів ви використовували? 36. Як ви розумієте принцип KISS (Keep It Simple, Stupid)? Як він допомагає створювати більш зрозумілий і підтримуваний код? 37. Яким чином принцип Separation of Concerns допомагає забезпечити модульність і обслуговуваність коду? 38. Які основні патерни структурного типу вам відомі (наприклад, Adapter, Decorator) і як вони використовуються? 39. Як ви розумієте патерн MVC (Model-View-Controller)? як він допомагає розділити логіку програми в архітектурі вебзастосунків? 40. Які патерни оптимізації коду вам відомі? 41. Які ви знаєте патерни рефакторингу? Яким чином вони можуть покращити кодову базу та зменшити технічний борг? Бази даних 42. Що таке реляційна база даних? Які основні реляційні бази даних вам відомі? 43. Що таке нереляційна база даних? Які сценарії використання для них існують? 44. Як працює індексування в базах даних? Як це впливає на швидкодію запитів? 45. Що таке транзакція в базах даних? 46. Як вибирати дані з бази в Java за допомогою JDBC? 47. Що таке ORM (Object-Relational Mapping)? Які його переваги при роботі з базами даних в Java? 48. Які є стратегії оптимізації запитів до баз даних? В чому полягає lazy loading? Мережі 49. Що таке IP-адреса? які основні типи IP-адрес вам відомі? 50. Як працює протокол TCP/IP? 51. Що таке HTTP і HTTPS, і в чому різниця між ними? 52. Які типи атак на мережеву безпеку вам відомі, і як можна захиститися від них? 53. Що таке NAT (Network Address Translation)? 54. Як працює HTTP-сесія? як зберігається стан між запитами на вебсервер? 55. Які існують інструменти та техніки для моніторингу й аналізу мережевої активності? 56. Розкажіть про концепцію клієнт-серверної архітектури. Які основні ролі відводяться клієнту та серверу в такій архітектурі? 57. Які протоколи комунікації існують для взаємодії між клієнтом і сервером? Інструменти 58. Які переваги використання контейнерів Docker порівняно з віртуалізацією? 59. Як створити контейнер? Чим він відрізняється від образу Docker? 60. Як зібрати образ? 61. Які є команди Docker для роботи з контейнерами (створення, запуск, зупинка, видалення)? 62. Які основні налаштування Docker-контейнера і Dockerfile? 63. Як ви розумієте мережеву конфігурацію Docker? Які інструменти використовуються для зв'язку контейнерів? 64. Як ви зберігаєте дані й робите резервні копії в Docker-контейнерах? 65. Як ви розумієте оркестрацію Docker? Які існують інструменти для керування великої кількості контейнерів? 66. Що таке система керування версіями? 67. Що таке гілка в Git? Які основні операції з ними ви використовуєте? 68. Як ви вирішуєте конфлікти під час злиття гілок в Git і які інструменти Git ви використовуєте для цього? 69. Як ви використовуєте команду git rebase? У чому різниця між нею і командою git merge? 70. Як створити та застосувати теги в Git і для чого вони використовуються? 71. Що таке .gitignore файл і як його налаштувати для виключення файлів та каталогів з репозиторію? 72. Як організувати безпеку Git-репозиторію? Як би ви відреагували на можливі загрози? 73. У чому переваги фреймворку Spring для розробки Java-застосунків? 74. Як ви розумієте інверсію управління (IoC), і в чому її важливість в Spring? 75. Що таке Dependency Injection, як це реалізується в Spring? 76. Як створити й налаштувати Spring Bean? Для чого це потрібно в застосунку? 77. Як ви використовуєте аспекти (Aspects) і анотації в Spring? 78. Які основні типи конфігурації Spring-застосунків? 79. Як працює механізм транзакцій в Spring і як його налаштовувати? 80. Що таке Spring Boot і які переваги він надає для розробки мікросервісів? 81. Як ви розумієте Spring Security і якими засобами він надає захист? 82. Поясніть, як працює хмарна інфраструктура AWS. 83. Чи знайомі ви з інструментами моніторингу, журналізації, аудиту? Питання для Middle Java Developer Коли ми проводимо співбесіду кандидата рівня Middle, в першу чергу нас цікавить глибоке розуміння технологій та цікаві підходи. Якщо він має чимало досвіду, акцент ставимо саме на ньому, а теоретичні запитання відходять на другий план. Навіщо такого кандидата запитувати про відмінності алгоритмів сортування, якщо у нього є досвід та досягнення, розмова про які дасть значно більше розуміння? Теми для розмови — такі ж як і в Junior, але у кожному питанні ми намагаємося зануритися глибше — технології, проблеми та обмеження, моделювання ситуації, коли виникає проблема, потенційні шляхи вирішення. Для чого це потрібно? Часто кандидати додають у резюме навичку володіння технологією, ознайомившись з нею лише на базовому рівні. Натомість нам цікаво, яких результатів вдалося досягти з нею, як її застосувати, які цікаві рішення знайти. Фактично технологія — цеглина, з якої можна побудувати сарай або вишуканий будинок. На цьому етапі я дізнаюся, що може побудувати кандидат. Приклад заглиблення в тему про реляційні бази: Як катили та застосовували міграції? Які інструменти обирали? Чи використовували інструмент Liquibase? З якими проблемами чи обмеженнями стикнулися? Чого не вистачає в цьому інструменті, на вашу думку? Що б ви додали? Якщо кандидат відповідає, що проблем не було, це свідчить про те, що інструмент використовувався лише на базовому рівні, тому він ці обмеження просто не зустрів. А базовий — це не рівень мідла. Приклад розмови про Postgres: Чи стикалися ви з такою проблемою: є таблиця, індекс; ми виконуємо запит, який має використовувати індекс, але він цього не робить. Чому не працює — невідомо. Як би ви розв'язували цю проблему? Якщо кандидат справді працював з Postgres, і робив щось більше, ніж базова вичитка за ID, дуже ймовірно, що він вже стикався з подібною проблемою. Якщо ні — то цікаво дізнатися, з чого б кандидат почав розвʼязувати її. Уявімо, що три кандидати дають різні відповіді: №1: «Подивлюся план запитів та планувальник, документацію за ними» — людина рухається в правильному напрямку. №2: «Якщо індекс не застосовується, значить, технологія не дуже, подивлюся в бік MongoDB» — переводити проєкт на нову технологію, коли ти можеш просто пофіксити проблему за 10 хвилин, — погана ідея. №3: «В плані запитів я подивлюся та проаналізую певні значення в записах» — це вже вказує, що людина мала певний досвід і розуміє проблему. Додаткова важлива тема для мідла — моніторинг застосунку. Наприклад, уявімо, що ми задеплоїли проєкт, у якому крутиться 500 сервісів. Як перевірити, що цей проєкт працює? Як відстежувати, що сьогодні він працює так само добре, як учора? Які є інструменти, практики, підходи, щоби моніторити цей «зоопарк»? Як можна їм керувати? Якщо з цих 500 сервісів, нам потрібно змінити 30 (викатити нові версії). Як це зробити одночасно, щоби не втратити трафік і у клієнтів все працювало в той час, як ми щось змінюємо? Також додаються питання з безпеки. Ми працюємо з платіжними даними за стандартом PCI DSS, що передбачає максимальний рівень безпеки. Якщо кандидат має в цьому досвід — це великий плюс. Питання для Senior Java Developer Сеньйор-спеціаліст — це людина, яка безпосередньо бере участь у стратегічних сесіях, плануванні, у виборі технологій. У нього є велика експертиза у різних питаннях та широкий досвід. Імовірно, він уже зіткнувся зі всіма підводними каменями та наступив на всі можливі граблі. Він бере відповідальність за свої рішення та проєкт або якусь його частину, не просто пише якісний код, а дивиться на цей процес з точки зору бізнесу. Плануючи цілі, він не розділяє їх на технічні та бізнесові — усі його рішення привʼязані до бізнес-завдань. При цьому він може не керувати командою, а бути самостійною бойовою одиницею, максимально зануреною в домен. Якщо на технічній співбесіді питати в сеньйора про шаблони рефакторингу чи принципи SOLID, можна здобути репутацію дивної компанії: ми спілкуємося з фахівцем, який вже 15 років в індустрії, а ми ставимо питання, наче на іспиті в школі. Тому до такої співбесіди слід готуватися заздалегідь, вивчаючи досвід та навички кандидата. Зазвичай я вивчаю CV, роблю background-check, дивлюся посилання на репозиторій GitHub, LinkedIn тощо. Наприклад, на GitHub-репозиторії ви побачили тестовий проєкт для компанії, якої немає у CV. Значить людина проходила співбесіду, можна про це спитати — чим закінчилося, чому не пішли? Іноді можна отримати дуже цікаві відповіді, які дають зрозуміти, як людина приймає рішення, які має пріоритети у пошуку роботи. Також я завжди питаю про значущі результати, досягнення, що вдалося реалізувати, чим ви пишаєтесь, що приємно згадати. З його відповіді можна ставити додаткові питання і заглиблюватися вглиб експертизи, проблем, викликів, з якими стикався кандидат. У відповідях людини ми також шукаємо рівень участі у проєктах. Тому що можна мати 15 років досвіду, але залишатися мідлом — сильним скіловим спеціалістом. Усі питання про досвід стосуються не стільки хард-скілів, а скоріше, чи «метчиться» людина з нашою командою. Наприклад, цього року я запамʼятав мінімум трьох кандидатів, які були дуже крутими технічними спеціалістами, яким ми вирішили не робити офер, бо вони не підходили за іншими параметрами. Такі люди попрацювали б у нас рік і пішли. Краще довше шукати людину, яка прийде на багато років, — довгостроково це більш перспективно. Так само і для кандидата: триваліший пошук «своєї» компанії кращий за співпрацю з проєктом, де він не зможе реалізувати свій потенціал.

Обʼєктно-орієнтоване програмування — найпоширеніша парадигма в розробці. Про цю концепцію знає кожен девелопер, а про застосування принципів питають на кожній співбесіді, проте в комʼюніті є чимало помилкових упереджень на цю тему. Чи можна розробити якісну підтримувану архітектуру без ООП? Якою була початкова ідея ООП та наскільки вона трансформувалася у сучасній розробці? Що не так з інкапсуляцією та як не ускладнити код надмірними інтерфейсами? Дмитро Гринець, co-CEO та співзасновник компанії PlantIn з екосистеми Genesis, спростував найпоширеніші міфи. PlantIn — застосунок-помічник для догляду за різними видами рослин з використанням ШІ. > ООП гарантує якість коду > Початкова концепція ООП була сильно перекручена > Бізнес-потреби заважають будувати якісну ООП-архітектуру, зокрема на етапі MVP > Задля безпеки системи потрібно інкапсулювати дані та методи з усіх класів > Інтерфейси спрощують тестування, підтримку коду та забезпечують консистентність > ООП застаріло, прийшов час для нової парадигми МІФ №1 ООП гарантує якість коду. Тільки з цією парадигмою можна розробити архітектуру і підтримувати її, не витрачаючи зайвих ресурсів ООП вважається найбільш зрозумілою та простою парадигмою програмування. Функціональний та процедурний методи побудовані на функціях, які обробляють дані без збереження стану. ООП орієнтоване на об'єкти, які мають стан і поведінку, що відповідає природному способу мислення людини. Це дає спеціалістам цілісну картину продукту, який вони створюють, значно спрощує розробку і розуміння коду. Загальна ідея ООП полягає в полегшенні взаємодії різних частин коду, можливості перевикористовувати їх, не змінювати те, що непотрібно, та фокусуватися на головному, наприклад, що виконує певний клас чи функція. Водночас ООП не є магічною формулою, яка автоматично розв'язує всі проблеми програмування. Спагеті-код можна створити будь-якою мовою чи парадигмою — написати погано структуровані класи, що некоректно працюють з даними, чи використати функцію, яка має побічні ефекти або виконує безліч різних дій. Так само хороша архітектура можлива з будь-якою парадигмою. Є чимало прикладів якісних програм, написаних за допомогою С — популярною раніше процедурною мовою, з якою розробники чудово справлялись і будували класні системи. Отже, жодна парадигма програмування не гарантує якості та не звільняє від помилок. Це лише інструмент, використання якого залежить від розробника та його досвіду. МІФ №2 Початкова концепція ООП була сильно перекручена Чимало розробників переконані, що від початкової концепції ООП, коли об'єктам надсилаються повідомлення, які також є об'єктами, залишився лише виклик методу, що принципово мало відрізняється від процедурного програмування. Певне спрощення концепції справді відбулося — і це цілком природно. Метод зʼявився як експериментальна концепція у 1960-х роках — в часи, коли код писали на перфокартах. Принципи ООП дозволили швидше створювати складніші системи та знизити поріг входу до програмування. З того часу зʼявилося безліч мов, фреймворків, напрямів програмування, стрімко розвинулися технології. Сьогодні принципи ООП набули ширшого застосування і водночас використовуються менш прискіпливо. Наприклад, принцип наслідування з часом відійшов на другий план, давши дорогу композиції, і вже досить рідко можна зустріти в коді багаторівневу структуру наслідування. Розробники нерідко застосовують принципи ООП помилково. Наприклад, фокусуються на викликах розрізнених методів, які можна було просто написати функціями. Тобто в коді немає поточного стану обʼєкту, взаємодії чи, скажімо, інкапсуляції. Виходить, це простий виклик функції, який можна було б написати й без ООП. Невірне застосування принципів ООП трапляється часто, але це залежить передусім від розробників. Сама концепція ООП не змінилася — метод залишається важливим у сучасному програмуванні, розвивається та адаптується до нових викликів і потреб. МІФ №3 Бізнес-потреби заважають будувати якісну продуману ООП-архітектуру, зокрема на етапі MVP Бізнес і справді не хвилює, яка парадигма використовується в коді, як побудована архітектура чи структура класів, чи якою є технічна реалізація бізнес-ідеї. Проте це не є проблемою, адже програмування покликане розв'язувати завдання бізнесу, а не навпаки. Отже, інженери мають побудувати архітектуру, враховуючи обмеження та цілі компанії. Етап MVP — створення першого версії продукту з обмеженим функціоналом. Його мета — швидко протестувати гіпотезу, не витрачаючи багато ресурсів. Звідси сформувалося упередження, що на цьому етапі немає часу та можливості заморочуватися питаннями архітектури. Якщо ідея злетить, код можна переписати. Найвідоміший успішний кейс — Slack, який було переписано з нуля. Проте часто підхід переписування буває невдалим: можна витратити чимало часу, а новий код міститиме нові помилки та проблеми. Тому ефективніше рішення — подбати про якісну архітектуру на етапі MVP та надалі допрацьовувати її, і переписуючи лише окремі фрагменти. Насправді досвідченому розробнику не так складно написати якісну продуману архітектуру на етапі MVP з першого разу. МІФ №4 Задля безпеки системи потрібно інкапсулювати дані та методи з усіх класів Інкапсуляція — один з найскладніших принципів, який часто застосовують неправильно. Основна проблема полягає в тому, розробники часом занадто ускладнюють її, ховаючи усе, що бачать. Їхній мотив — подбати про безпеку, зокрема проєктів з чутливими даними. Тоді посилання на дрібні інкапсульовані обʼєкти розростаються вибуховими темпами, та інкапсуляція виглядає як навала незграбних взаємопереплетених методів, що викликають один одного. Якщо складність інкапсуляції двигуна платіжної системи ще можна виправдати, то надмірне використання в інших кейсах лише погіршує код. Визначаючи ступінь інкапсуляції розробник має балансувати між безпекою та гнучкістю. Для малих та простих об'єктів може бути прийнятним більше відкритого доступу до даних і методів, але важливо зберігати інкапсуляцію там, де це необхідно для забезпечення цілісності та безпеки програми. Якщо коректно застосовувати цей принцип, він не ускладнить код та не заважатиме доступу до даних і методів класів. МІФ №5 Інтерфейси завжди спрощують тестування, підтримку коду та забезпечують консистентність Фактично є два підходи до інтерфейсів в ООП: або їх взагалі не використовують, або застосовують всюди, де тільки можна. В чому їхній сенс, та чи потрібні вони в коді — поширена тема для дискусій серед розробників. Інтерфейси є важливою концепцією в об'єктно-орієнтованому програмуванні. Це елемент абстракції, який визначає набір методів без їхньої конкретної реалізації. Інтерфейс вказує, які операції можуть бути викликані для об'єктів, але не накладає обмежень на саму реалізацію методів. Вони мають конкретне завдання, і їх потрібно застосовувати тоді, коли розумієш, що у процесі роботи з цією частиною коду, може зʼявитися необхідність змінити реалізацію. Наприклад, спосіб кешування обʼєктів: зараз ми кешуємо у пам'ять програми, а згодом можемо робити це через Redis. Цю проблему можна передбачити, використавши інтерфейс взаємодії. Тоді зміна реалізації буде безболісною, а кінцеві користувачі цього навіть не помітять. Водночас це зручно розробнику: працюючи з кодом, він не фокусується на конкретній організації кешування, а планує загальну реалізацію, яку потім можна змінити в будь-який час. Якщо ж певна реалізація не буде змінюватися, писати інтерфейс немає сенсу. В Java та її фреймворку Spring все пишеться через інтерфейси — кожен клас та сервіс, який ти використовуєш. Якщо їхня реалізація не змінюється протягом десятиліть розробки цієї програми, в чому тоді полягав сенс? Це просто марне витрачання часу і коду. МІФ №6 ООП застаріло, прийшов час для нової парадигми У 2015-2020 роках періодично зʼявлялася низка критичних статей відомих науковців та розробників — Річарда Столмана, Едсгера Дейкстри, Алана Кея та інших. Вони детально описували, що не так з ООП у сучасному програмуванні та наводили переваги інших парадигм. Ймовірно, це було спробою розширити межі комʼюніті, змінити домінування ООП-first мов та привернути увагу до альтернативних технологій. Це мало сенс, адже сьогодні люди часто приходять в ІТ, випадково обирають ООП-мову, та перше, про що вони дізнаються на лекції — що таке ООП. Потім вони починають програмувати та навіть не знають, що існують інші парадигми, які насправді в певних ситуаціях працюють ефективніше. Наприклад, для завдань Machine Learning чи Data Science ООП взагалі не підходить. Проте зміни домінування ООП так і не відбулося. Насправді нові парадигми зʼявляються не так часто. В останні десятиліття класична наука про інформацію (Computer Science), коли науковці займалися фундаментальною теорією, розробкою мов та систем, перейшла до суто практичного застосування. Розробкою нової парадигми зараз глобально просто не займаються. Можливо розвиток ШІ призведе до появи нового методу. Як варіант — трансформується саме поняття парадигми та конкретної мови, і розробники ставитимуть завдання звичайними словами, або зміниться саме поняття програми. Варто памʼятати, що ООП може інтегруватися з іншими парадигмами програмування для створення більш потужних і гнучких програмних рішень. Ця парадигма може існувати поруч і взаємодіяти з функціональним, реактивним, процедурним та іншими методами програмування. Вибір конкретної парадигми або їх комбінації залежить передусім від потреб проєкту та завдань, які ви намагаєтеся вирішити.

Під час зародження українського продуктового IT розробники могли самі закривати аналітичні завдання. Зараз так уже не вийде — роль аналітика стала однією з ключових у розвитку IT-продукту. Чи виходити на новий ринок? Чи додавати нову кнопку на екран онбордингу? Чому юзери йдуть з продукту на 3 день? Усі ці проблеми допоможе вирішити хороший аналітик. Утім, працюючи над проблемами продукту, кожен з них стикається з низкою викликів. Про найпоширеніші з них розповів Олександр Логутов, Business Analyst у Headway, партнерській компанії Genesis. Олександр працює з напрямом B2B — шукає оптимальні рішення щодо розвитку Headway для бізнесу та підтверджує їх ефективність цифрами та даними. Уявіть, що вам щодня потрібно розв’язувати логічні задачі — і займатися лише цим. Приблизно такий вигляд має робота аналітика: він заглиблюється в нові ніші, досліджує потенціал та ефективність запусків проєктів, перевіряє ідеї. Шукати інформацію та порівнювати дані — це кропітка праця, яка вимагає системності, уваги та об’єктивності. Бувають об’ємні запити стейкхолдерів, пов’язані, наприклад з тим, яку фічу треба додати в продукт для ефективнішого Value Proposition, або скільки часу та ресурсів може піти на розробку подібної фічі. Тоді аналітик працює над ними тижнями. Навіть якщо людина любить робити ресерчі, то вигоріти за таких умов дуже легко. Коли стратегія розвитку компанії трансформується, завдання бізнес-аналітика — вивчити і новий ринок, і прямих та непрямих конкурентів, і різні когорти користувачів. Аби провести якісне дослідження, фахівець повинен мати знання у різних доменах. Наприклад, потрібно з’ясувати, що саме відштовхує користувачів від продукту, або як краще взаємодіяти користувачами, які цікавляться версією для бізнесу. Тоді бізнес-аналітику треба стати продакт-аналітиком — і розібратися у відповідних метриках та даних. Або розглянемо, наприклад, маркетинг. Якщо аналітик не працює безпосередньо в маркетинговій команді, то це не його зона відповідальності, однак аналіз попиту чи конкурентів у новій ніші вимагає його залучення, і, відповідно, занурення у сферу. Наприклад, нещодавно один зі стейкхолдерів запропонував розробляти готові «книжкові клуби» для B2B-клієнтів. Перед тим, як впроваджувати ідею у життя, я маю дослідити ринок, і зрозуміти, чи потрібна подібна послуга. Ресерч ще триває, однак вже зараз є показники, які підтверджують, що гіпотеза може спрацювати у Tier-1 країнах. Наприклад, п’ять мільйонів американців є учасниками офлайнових книжкових клубів, а ще 40 мільйонів обговорюють прочитане онлайн. Інший приклад — кількість компаній, які вже пропонують таке рішення та їхній приблизний дохід на рік. Тут йдеться саме про нові ніші, з якими аналітик не зіштовхувався раніше. Наприклад, команда ухвалила рішення розвивати SEO-напрям. Звучить логічно: самостійно знайдений у Google продукт зацікавить юзерів більше — й компанія одержить вмотивованіших користувачів. Однак перед презентацією ідеї аналітик має обґрунтувати, чому бізнесу потрібен SEO-менеджер із зарплатнею приблизно $1500 та інструменти просування на $500 щомісяця, а ще — спрогнозувати, чи окупляться ці витрати в майбутньому, й чи справді органічний трафік принесе більш релевантних лідів. Щоби надати справді об’єктивне рішення, аналітик має швидко та ретельно розібратися у новій ніші: з’ясувати, як працює оптимізація у пошуковиках, переглянути дослідження інститутів чи великих консалтингових компаній, як-от McKinsey & Company, з’ясувати, наскільки більше користувачів для B2B SaaS-продукту принесе органічне просування. Навіть якщо він упевнений у доцільності гіпотези, її все одно спочатку тестують. У прикладі з SEO це означає, що команда знаходить статті, що можуть добре спрацювати в пошуку, оптимізує їх мінімальною кількістю зусиль, а потім відстежує результати. Аналітиків часто долучають до нових запусків на початку, тому від якості їхньої роботи залежатиме те, наскільки надійним вийде продукт чи фіча, або наскільки успішним буде бізнес у новій ніші. Вартість запуску на новому ринку може коштувати десятки, а то й сотні тисяч доларів, тож невірна чи неперевірена гіпотеза бізнес-аналітика обійдеться компанії дуже дорого. На щастя, в моєму досвіді не було аж настільки вартісних факапів. У Headway загалом існує правило: кожну помилку варто сприймати як урок. Так, подібний урок може коштувати дорого, але якщо він дозволить виявити прогалини у плануванні чи гіпотезах, знайти нові шляхи для розв'язання проблеми, то витрати цілком виправдані. Якщо ідеї неуспішні, надзвичайно важливо повернутися на початок та розібратися в причинах. На психологічному рівні це може бути складно: коли ти уже повірив у гіпотезу та довго нею займаєшся, відмовлятися від початкового бачення буває складно. Однак подібна практика дуже корисна для майбутніх проєктів, оскільки допомагає уникнути аналогічних помилок. Під час ґрумінгів з командою ідея А може легко перетворитися в комбінацію ідей А і Б. Тому і результат тесту потім може вийти не таким, як очікувалося. Наприклад, ви з командою проєктуєте лендинг для B2B-продажів і додаєте до нього Calendly — сервіс, який дозволяє швидко забронювати вільний слот для дзвінка. Клієнту потрібно залишити своє ім’я, електронну пошту — і час заброньований. Усе дуже просто. Однак під час обговорень з’являється інша ідея: запропонувати залишати ще й назву компанії та посаду. Наче непогано, однак подібне питання — досить особисте. Людину може відштовхнути необхідність залишати персональну інформацію. Ймовірно, вона зайшла на лендинг подивитися демо, а натрапила на повноцінний онбординг, — а це може погано впливати на конверсію. Подібні ризики варто враховувати. У такому випадку аналітик має брати на себе відповідальність і переконувати, чому краще робити інакше або тестувати спочатку перший варіант. Як аргумент можна наводити те, що сильні гравці на ринку послуговуються іншими підходами. Я дуже люблю робити ресерчі й вірю, що перед будь-яким запуском треба підтвердити гіпотезу аргументами й цифрами. Поки роблю дослідження, можу настільки впевнитися у життєздатності гіпотези, що ризикую втратити об'єктивність, яку не маю втрачати. Після погляду стейкхолдерів ідею можуть забракувати, навіть якщо вона підкріплена цифрами. Причини можуть бути різними. Одна з них — більш відповідна експертиза інших членів команди. Наприклад, біздеви багато спілкуються з клієнтами, тож можуть знати більш дієві підходи. Інша причина — на тестування гіпотези потрібно багато ресурсу, але його доцільніше спрямувати на інші бізнес-завдання. Бізнес-аналітик допомагає ухвалювати рішення різним командам та напрямам, тож часто тестує багато гіпотез паралельно. Наприклад, одночасно із завданнями від продуктової команди я можу взяти в роботу прохання перевірити ідею запуску SEO-напряму від маркетологів або перспективи імейл-маркетингу від біздевів. Окрім цього, є щоденні завдання або ті, які треба робити щомісяця, як-от же аналіз конкурентів — і за ними теж потрібно стежити. Через це виникає розфокус і деякі деталі можуть губитися. Щоб зменшити цей біль аналітики використовують класичні методи планування канбан і скрам, а також інструменти Notion та Synx. Якось ми вирішили протестувати механіку квізу для B2B-клієнтів. Цей інструмент класно працює у B2C, тож ми вирішили спробувати його і в іншій бізнес-моделі — попри те, що ідея виглядала суперечливо. У B2B-продуктах зазвичай не користуються подібними підходами, тож ґрунтовно підтвердити ідею цифрами не вдалося. Втім, вирішили спробувати. Я не можу сказати, що гіпотеза спрацювала погано, але не так добре, як ми очікували. Підхід підняв охоплення, кількість реєстрацій на дзвінок збільшилася, але їхня якість впала, а кількість покупок суттєво не змінилася. Зараз ми вирішили трохи змінити механіку цієї ідеї. Тому я завжди за те, щоб максимально обґрунтовувати кожну тезу цифрами. Звісно, якщо це можливо. Обов’язки бізнес-аналітика можуть різнитися від компанії до компанії. Для певних позицій комунікація необхідна, адже фахівці працюють безпосередньо з клієнтами та розробляють рішення для них. Тоді аналітик частково виконує завдання проджект-менеджера: розбирається у клієнтських вимогах, формує ТЗ та передає його розробникам. Бувають напрями, де комунікація некритична — коли аналітики, наприклад, шукають нові стартапи або ніші для інвестування. Тоді вони приділяють більшість часу саме ресерчу. Однак вміння спілкуватися потрібне в будь-якому разі. По-перше, у кросфункціональній команді аналітик постійно спілкуватиметься з продакт-менеджерами, маркетологами, дизайнерами тощо. По-друге, купу корисної для роботи інформації, фахівці одержують саме від професійного нетворкінгу — і мають уміти зробити так, аби люди хотіли ділитися з вами інсайтами про продукт. Особисто мені нескладно спілкуватися, однак бувають періоди, коли я втомлююся від обговорень. Тоді я беру перерву на два-три дні, та займаюся тільки документацією та ресерчами.

Нещодавно Genesis Academy провела черговий відкритий освітній тиждень Genesis Growth Week. Протягом сімох лекцій від С-level фахівців генезійських та партнерських компаній усі охочі дізнались про кейси запуску, успіхів та невдач цифрових продуктів. Нотатки про найцікавіші секрети зростання IT-бізнесів — в новому матеріалі блогу. 5 принципів UX зрілості, що допомагають будувати продукти №1 у світі ПРИНЦИП №1 Досліджуйте конкурентів Це дасть вам розуміння ринку: ніша, основні гравці, їх продукти, цінність, що вони несуть юзерам, досвід їх користувачів. Розуміння ринку дає картину того, де конкурентів буде багато, а де щільність продуктів у ніші нижча — де червоний і голубий океани. Окрім цього, дослідження сильних та слабких сторін конкурентів дасть вам змогу робити свій продукт кращим та вирізнятись з-поміж інших на ринку. ПРИНЦИП №2 Будуйте дизайн-процес Дизайн-процес — це те, як ми створюємо і покращуємо наші продукти. Ось так виглядає дизайн-процес в нашій компанії: У нас з’являється класна ідея, яку ми хочемо затестувати. Ми дизайнимо, паралельно щось кодимо, запускаємо, дивимося, чи є product market fit, чи зводиться у нас юніт-економіка. Далі або робимо нову ітерацію, або півот, або — в найгіршому випадку — нічого не робимо. В цьому процесі ми завжди працюємо над розв'язанням чітко сформульованої проблеми, і в результаті генеруємо рішення. Зазвичай це користувацька проблема, вирішення якої зможе допомогти бізнесу рости. Якщо ви послухаєте, про що говорять в продуктових командах в Headway, то найчастіше звучить питання: «Яку проблему ми вирішуємо?». Це класне питання, яке я раджу вам задавати дуже часто, особливо коли ви відчуваєте, що дизайн-процес десь загальмував. ПРИНЦИП №3 Взаємодійте Як запобігти ситуаціям, коли різні члени команди працюють над одним процесом паралельно, а не спільно? Наприклад, продакт-менеджер і продакт-дизайнер починають окремі користувацькі дослідження. З досвіду Headway: найголовніше, що треба зробити — відповісти на питання, хто що робить. Для цього ми декомпозували цінність, яку доносимо користувачу, на три складові: життєздатність продукту, реалізація нових рішень і бажаність його серед користувачів. За кожну з них відповідає конкретний фахівець, що знає, якими питаннями він опікується. Це дозволяє кожному вносити свою частку до створення цінності продукту. ПРИНЦИП №4 Ви — не ваші користувачі Ми ніколи не дізнаємось, про що думає юзер і як він користується нашим продуктом, якщо ми в нього не запитаємо. Окрім юзабіліті-тестування, який є складовою нашого дизайн-процесу, ми проводимо ще загальні дослідження, які дають нам краще розуміння наших користувачів. Все, що пов'язане з отриманням інсайтів від користувачів, називаємо користувацькими дослідженнями. Це аналіз звернень у сапорт, дослідження відгуків на продукт: як позитивних, так і негативних, й інші інструменти. ПРИНЦИП №5 Проповідуйте UX В цьому випадку я маю на увазі, що розповідати, ділитись інформацією та запитувати про користувацький досвід — це важливо. Коли я доєднався до Headway, в моїй команді було чотири людини. Я почав «проповідувати» UX, напевно, з першого дня. Я постійно наполягав на проведенні користувацьких досліджень, інтерв’ю, і казав, що кожна людина в нашій компанії прямо чи опосередковано працює на покращення користувацького досвіду, чим би вона не займалась. Як ловити хвилю технологій, щоби покращувати свій продукт. Кейс із практики PlantIn Найголовніша проблема, з якою до нас приходять користувачі, це те, що у них хвора рослина, і вони не знають, як її лікувати, не розуміють, що з нею трапилось. Від початку у нас у застосунку було два можливі варіанти розв'язання цієї проблеми: індикатор хвороб на основі ML та консультації з експертами. ML-індикатор допомагав виявляти базові хвороби й давав основну інформацію про догляд, про типи шкідників та способи їх усунення тощо. Але проблема була в тому, що цей інструмент дуже загальний і не здатен скласти індивідуальний план для кожної рослини, бо вони всі дуже різні, бувають різні стадії хвороб і багато інших відмінностей. Експерт із ботаніки може скласти детальний план догляду, проте на це піде декілька днів, а за цей час з рослиною може статись що завгодно. Тому ми шукали якийсь проміжний інструмент, який був би достатньо швидким і точним для складання мінімально релевантного плану догляду за конкретною рослиною. Одного дня наш ML-розробник натрапив в мережі на нову статтю про модель міні-GPT-4, яка начебто поводить себе, як ми б і хотіли: може за фотографією рослини скласти мінімальний план для того, аби її вилікувати. Враховуючи, що про ChatGPT та інші ШІ-асистенти вже говорили всі навкруги, нам треба було максимально швидко реалізувати цю фічу, поки її не реалізували конкуренти. Так у нас з'явився інструмент AI Expert Help, в якому штучний інтелект оперативно складав план з догляду за рослиною одразу після запиту. Що ми взагалі не очікували — це отримати листа від Apple, в якому компанія писала, що їм сподобався новий інструмент і вони запропонували його опублікувати в окремому розділі в AppStore. В результаті ми дійсно ми були зафічерені в Німеччині, Нідерландах, Іспанії. Ми абсолютно впевнені в тому, що якби ми робили все повільніше, то не сталося б ні нової функції, ні фічерингу в AppStore. Застосунки з використанням різних форм AI з’являються нині щодня, швидкість реалізації фіч у цій ніші — надвисока. Цей кейс навчив нас ловити тренди в момент, коли злітають, не гаяти часу і швидко реалізовувати ідеї. Як вирости вдвічі за допомогою диверсифікації гео У 2022 році ми в Impulse почали диверсифікацію за різними географіями: поступово розширились до 48 країн. Нині вже можемо сказати, що це допомогло нам вирости в декілька разів. ROAS (показник рентабельності витрати на рекламу) виріс утричі, LTV — у 2,5 раза, а дохід на рекламу в застосунку — в 1,4 раза. Як підготуватися до тестування нових гео? Перш за все, треба визначитись, навіщо ми хочемо тестувати ту чи іншу країну. Другий пункт – це формування критеріїв валідації вашої гіпотези. Тобто ви сформували гіпотезу, вам потрібно розуміти, які метрики ви будете аналізувати, з якими бенчмарками будете порівнювати ті чи інші показники вашої воронки, наприклад. Третій крок — це оцінка своїх ресурсів і оцінка ресурсів команди. Важливо зрозуміти, чи маєте ви необхідні технічні умови для тестування нової країни. Тобто, чи локалізований додаток на цю країну, чи адаптовані та перекладені креативи, чи перекладені тексти, чи достатньо у вас в команді людей і часу, скільки грошей з маркетингового бюджету ви можете витратити на тестування тощо. Процес В середньому ми тестуємо від п’яти до десяти адаптованих креативів на локалі в день. Приблизно місяць ми тестуємо нову географію і за цей період можемо вже зробити більш-менш провалідовані висновки про те, чи спрацювала країна в плюс, чи в мінус, чи варто її далі крутити, чи варто зупиняти, чи заробляємо ми на ній, чи ні. Коли починаємо тестувати, зазвичай використовуємо стратегію lowest cost. Вона допомагає нам швидко прийняти рішення, що є вкрай важливим на етапі тестування, особливо якщо ми тестуємо якусь нову країну і не знаємо, які результати вона нам покаже. Зазвичай на етапі тесту заходить до 4% всіх креативів. Ринковий бенчмарк — до 3%. Як аналізувати тести? Головні критерії аналізу тестів — ціна за цільову дію та позитивний ROAS. Наприклад, в нашому випадку один з головних критеріїв – це CPA, вартість покупки в застосунку. Проте у різних застосунків може бути різна цільова дія: встановлення додатку, конкретна покупка або група покупок. Це залежить від того, як налаштована аналітика. Також ми аналізуємо CTR, тобто показник того, скільки користувачів натисли на рекламу з усіх, хто її побачив. Треба враховувати, що середній CTR може відрізнятися у різних локалях, і це нормально. Як працює R&D, що запускає понад 100 MVP на рік Життєвий цикл ІТ-продукту складається із шести етапів. До достатньо для функціонування доходить умовно 0,001 % команд. Ми тестуємо чимало ідей, перш ніж зʼявиться та, яка дозволить нам дійти до кінця. Нижче — детальніше про кожний з етапів. ЕТАП №1 Дослідження Аналізуємо тренди: куди інвестують найбільші венчурні фонди, де зʼявляються нові гравці та починають швидко зростати, що відбувається в дотичних нішах. Інформація із цих джерел зводиться в єдину систему, і через призму експертизи ми вирішуємо, де будемо найефективнішими з наявними ресурсами. Важливою складовою є дослідження користувачів — не потенційних, а реальних. Знайдіть клієнтів схожих продуктів та поговоріть із ними про їхній досвід. ЕТАП №2 Реліз MVP Визначившись із нішею та ідеєю для стартапу, команда переходить до наступного етапу — створення і релізу MVP, щоби перевірити гіпотезу та ухвалити рішення, чи розвивати продукт далі. У R&D-центрі Genesis кожне друге дослідження переходить до етапу релізу MVP. Ця конверсія — досить висока, завдяки системним якісним дослідженням та широкій мережі нетворкінгу. Якщо взяти до розрахунку взагалі всі ідеї на ринку, які генеруються під час неформального спілкування, то загальна конверсія вийде менш як 1%. ЕТАП №3 Досягнення позитивної юніт-економіки Юніт-економіка — це фінансова модель, яка показує рентабельність бізнесу на основі одного юніту (користувача). Позитивною називають модель, коли один юзер протягом усього терміну «життя» в застосунку приносить компанії більше грошей, ніж вона витратила на його залучення. Зазвичай до цього етапу доходить 10% проєктів. ЕТАП №4 Вихід на прибутковість Головне завдання цього етапу — стабілізувати бізнес-модель. До кроку №4 доходить 1% стартапів. Це означає, що коли ви звели всі доходи та видатки, у вас вийшов плюс. ЕТАП №5 Масштабування Тут потрібно знайти одиницю зростання та зрозуміти, як із нею працювати. ЕТАП №6 Публічна корпорація Під цим терміном маються на увазі не тільки компанії, які стали публічними, але й ті бізнеси, які досягли цього рівня в межах прибутків. До цього етапу доходять лише 0,001% стартапів. Повні записи лекцій Genesis Growth Week та презентації спікерів можна переглянути за лінком.

Міністерство цифрової трансформації України та Асоціація IT Ukraine презентували каталог Incredible Tech, до якого увійшли 96 перспективних продуктових ІТ-компаній та 31 успішний український ІТ-продукт. Цей документ стане інструментом для просування української ІТ-екосистеми на міжнародному ринку. Серед інших у каталог увійшли застосунок Keiki від однойменної компанії, Avrora від компанії Boosters та Headway від однойменної партнерської компанії Genesis. Окрім цього, в каталозі також представлена платіжна платформа Solidgate, ще один партнер Genesis. «Зараз увага світу прикута до України через повномасштабне вторгнення росії. Натомість ми хотіли б показати, що Україна — це не лише війна, а й Батьківщина крутих ІТ-рішень для бізнесу й людей. За допомогою цього каталогу ми хочемо, щоб весь світ дізнався, що Україна створює круті, якісні ІТ-продукти, якими можуть користуватися великі корпорації, будь-який бізнес по всьому світу», — зазначив заступник Міністра цифрової трансформації України Олександр Борняков. До каталогу увійшли компанії, які працюють у різних напрямах, — від оборонних технологій та державних цифрових продуктів до Legal tech і Health tech. Це українські компанії та ІТ-продукти, що мають українську реєстрацію, українця-засновника та офіс чи представництво в Україні. Відбір компаній здійснила незалежна експертна рада, у складі якої — представники Мінцифри, засновники, СЕО tech-компаній та інвестори.

Новий матеріал рубрики Genesis Crew, де ми розповідаємо історії розробників з насиченим та цікавим професійним життям. Цього разу публікуємо історію Антона Водолазького з компанії OBRIO з екосистеми Genesis. Він пройшов шлях від iOS-розробника до СТО, і зараз відповідає за технічну частину астрологічного застосунку Nebula. До цього Антон встиг попрацювати в стартапі, в сервісній компанії, й навіть розробив власний Health&Fitness-продукт. В інтерв'ю для блогу Genesis Антон розповів, як обрав для себе iOS-розробку, чому його продукт не злетів, та які виклики чекають на новоспечених CTO. Про вибір iOS та перші місця роботи На другому курсі університету я потрапив до США за програмою Work&Travel. Тоді я навчався на інженерній спеціальності й уже мав базові знання у С++, Java, вмів працювати з базами даних. Однак справді новим світом у розробці для мене став iOS. На перші, зароблені у США, гроші, я купив собі MacBook, тож зміг писати простенькі програми під свій четвертий iPhone. Це сприймалося як магія — все, що накодив, можна одразу побачити на телефоні. Хоча тоді продукція Apple саме набирала популярність, ресурсів для вивчення iOS-розробки було вкрай мало. Книги та курси доводилося вишукувати скрізь. У 2017-2018 роках українські технологічний бізнес активно набирав обертів. Особливо динамічно розвивалися електронна комерція, фінтех та мобільні застосунки. Комунікація все більше переходила на девайси, тож всі вчилися розробляти чати та інструменти для онлайн-замовлень. А ще — опановували Bluetooth. Тоді якраз стався бум девайсів — ламп, годинників, фітнес-браслетів та інших пристроїв — які дистанційно підключалися до iPhone. Втім програмувати під iOS можна було лише на Objective-C. На моїй першій роботі виявилося, що уже вийшла перша версія Swift, тож потрібно було опанувати ще і її. Спочатку я працював у продуктовому стартапі, який розробляв застосунок для захищених дзвінків. Це був мій перший, доволі складний комерційний проєкт, адже для нього, окрім iOS-розробки, доводилося розбиратися з мережами та шифруванням. Тоді вперше почув про технологію VPN — ще до того, як вона стала аж такою масовою. Далі перейшов в сервісну компанію. Вона не просто займалася фічами, а робила для замовників повноцінні застосунки різного спрямування. Таксі, доставка їжі, соцмережа для власників домашніх тварин, електронні ваги — на одну таку апку йшло від одного до декількох місяців. З цікавого — застосунок для оренди квартир, фішка якого була в тому, що користувач, знаходячись на вулиці, міг навести камеру на будь-який будинок і побачити плашку з інформацією про доступні для оренди квартири. Ми реалізували такий застосунок ще до того, як iOS став офіційно підтримувати технології доповненої реальності. Згодом я приєднався до іншої аутсорс-компанії, Yalantis, яка працювала з Tier-1 ринками, як-от США, Австралія, Європа тощо. За деякий час я став помічником тимліда та почав менторити менш досвідчених колег. Втім, коли ти доростаєш до певного ґрейда, то розумієш: завдання стали однотипними, викликів менше, а проєкт, над яким ти працював рік, може померти за два дні. Я зрозумів: час робити свій продукт. Про власний продукт та перехід у Genesis У 2017-18 роках найбільш перспективною нішею здавалася Health&Fitness. За час роботи аутсорсі я зробив дуже багато подібних апок, тож знав, як все працює. Зібрав команду — до неї входили бекенд-розробник, дизайнер та контент-менеджер — й за чотири місяці застосунок із планами персональних тренувань був готовий. Настав день Х, продукт запустили в App Store — і нічого не відбулося. Його завантажували, але користувачів було настільки мало, що ні про яку юніт-економіку навіть не йшлося. Я спробував забустити процес, запустивши рекламу на Facebook. Але не допомогло: трафік йшов, але івентів у застосунку було мало, тож відстежити бодай якісь показники не вийшло. Згодом я продав цей застосунок. На порозі уже був COVID-19, я готувався до переходу на позицію Software Architect на основній роботі, але працювати з продуктом було набагато цікавіше. Тому я вирішив приєднатися до продуктового бізнесу, адже я прагнув розумітися не лише на розробці, але і на маркетингу, аналітиці та інших ключових речах. Обрав п’ять найкращих компаній, відправив резюме — і уже за два дні отримав офер від Genesis. Тут одне з найкращих середовищ для розвитку в розробці продуктів, зокрема мобільних застосунків. Про це свідчать і рейтинги App Store з продуктами компаній екосистеми у топах різних категорій. Про кар’єрний шлях до CTO OBRIO Раніше я відповідав лише за мобайл. Тепер — за усю технічну частину. Рішення, які ми з командою ухвалюємо, впливають і на аналітику, і на контент, і на маркетинг. Це зовсім інший масштаб. До того ж як Head of Engeneering я мав чітку зону відповідальності та іноді працював «руками», а як CTO — займаюся плануванням та стратегією, яку маю доносити до команди. Структурно вона складається з декількох функціональних підрозділів. У деяких з них є тимліди, але не у всіх: десь відділ зовсім маленький, десь людина ще доростає до керівної посади, а десь ми у пошуку відповідного кандидата. До напрямів, з якими я працюю, додався ще й фронтенд, а це означає необхідність заглиблювати у новий напрям, більшу кількість чекпойнтів та спілкування. Як СТО, я допомагаю команді з вирішенням технічних питань, вибору технологій та підходів з якими будемо працювати, синхронізувати процеси та мітинги. Коротко кажучи, зробити так, щоб і мобайл, і веб працювали злагоджено, швидко й масштабовано. Nebula — складний продукт з погляду монетизації. Джерел декілька: це і реклама, і підписка, і персональні чати. Останнє — це, мабуть, найскладніша фіча. З чатами працюють і юзери, і експерти платформи, відповідно, першим нараховуються кредити для оплати, а другим — хвилини роботи, які впливають на рівень зарплатні. Щоби грамотно спроєктувати технічну частину й зробити так, щоби платформа працювала без збоїв для обох сторін, потрібно врахувати багато нюансів. Я став СТО відносно нещодавно, і, можна сказати, ще вчуся керувати командою такого масштабу. Я переконаний, що мікроменеджмент — це не ефективно, а в команді варто будувати максимально довірливі відносини: давати людям можливість генерувати ідеї та самостійно ухвалювати рішення. Тоді кожен відчуватиме, що його думка цінна та важлива. Водночас це працює з фахівцями рівня middle, а от джуни потребують більше уваги, менторства та підтримки. Багато знань та підходів я здобув у своїх минулих керівників та СЕО OBRIO. Обмін знаннями — це частина культури OBRIO, тож ми часто спілкуємося, організовуємо лекції та воркшопи, заглиблюємося у нові для себе напрями. Про різницю між роботою у продукті, аутсорсі й стартапі У стартапі ви, найімовірніше, працюватимете з одним продуктом та робитимете усе — від написання коду до внесення правок у дизайн та вигадування тексту на екран онбордингу. Це класний досвід для занурення в бізнес-процеси, але на початку кар’єри, ймовірно, буде складно: у маленькій команді без досвідченого ментора чи керівника важко розвиватися далі. Все, про що ви дізнаєтеся, залежить лише від допитливості. Аутсорс дає змогу попрацювати над кількома різноманітними проєктами. Мені пощастило, що до Genesis я потрапив у подібну компанію, адже я зміг познайомитися з багатьма технологіями та командами. У великих аутсорс-бізнесів є чіткі ґайди, як зростати до тієї чи іншої позиції, а процеси зрозумілі. Відповідно, шлях до кар’єрного підвищення доволі прозорий. Ключове в роботі з продуктом — це відповідальність та здатність впливати. QA, фронтенд, DevOps — будь-хто може запропонувати ідею для нової фічі, і до неї прислухаються, якщо є аргументи. Зворотний зв’язок від користувачів видно майже одразу — і це дуже мотивує. Крім того, великі продуктові бізнеси також мають злагоджені процеси, й, відповідно, зрозумілу структуру та шляхи зростання. У новачка, скоріше за все, будуть ментор, менеджер, buddy тощо. Якщо говорити безпосередньо про Genesis, то я не знаю, де ще стільки інвестують у навчання. Кілька внутрішніх шкіл (я навчався у двох з них — бізнес та менеджмент), ком’юніті, різні мітапи — це частина робочого середовища. Навіть більше — іноді обмін досвідом з іншими компаніями екосистеми навіть додають до OKR. Зараз в Україні доволі висока культура IT-фахівців — багато компаній, курсів, ком’юніті із висококласними фахівцями, процеси та проєкти організовані на високому рівні. Коли я починав, все було інакше: менше компаній, особливо продуктових, менше досвідчених фахівців, не такі глибокі знання технологій. Навіть враховуючи повномасштабне вторгнення та скорочення об’ємів найму, пропозицій для роботи все одно достатньо. Багато людей думають: «В IT дуже складно, ця сфера не для мене». Однак це стереотип: я знаю купу крутих історій, коли люди ставали QA- чи DevOps-інженерами після багаторічної праці в іншій сфері, хоча були впевнені, що не розберуться в новому напрямі. Але усе реально, якщо знайти релевантні ресурси (більшість з них безкоштовні) та професіоналів, які готові ділитися досвідом. Приєднатися до команди OBRIO: DevOps Engineer; Front-end Developer; QA Engineer; Data Engineer.

31 жовтня 2023 року розпочнеться навчання на Venture DeepDive — це поглиблений курс про венчурний капітал, який організовує Genesis у партнерстві з найбільшими інвестиційними фондами країни. Курс зацікавить насамперед інвестиційних менеджерів, аналітиків, досвідчених фахівців зі сфер фінансів та консалтингу, а також топменеджерів інших галузей, що хочуть розумітися на інвестиціях в IT-продукти. Творці курсу об’єднали досвід і напрацювання представників українського венчурного ринку країни та великих технологічних бізнесів. Програму розробили представники Genesis разом із венчур-білдером SKELAR, технологічними компаніями Propertymate, Liki24, Awesomic, а також провідними інвестиційними фондами Horizon Capital, Flyer One Ventures і TA Ventures. «В оновленому курсі про венчурні інвестиції ми зібрали практичний досвід засновників стартапів, партнерів інвестиційних фондів та топменеджерів Genesis. Прагнемо поділитися ним з досвідченими фахівцями з різних сфер — фінансів, консалтингу, аудиту тощо. Розвиваючи напрям навчання спеціалістів рівнів Senior та Middle, ми сприяємо розвитку української ІТ-екосистеми — а це, у довгостроковій перспективі, впливає на становлення всього ринку», — говорить Олексій Ніщик, Education Operations Director в Genesis. Навчання триватиме дев’ять тижнів у змішаному форматі: програма передбачає онлайн-лекції та нетворкінг в офлайні. Серед тем, які розглядатимуть на курсі: — як працює ринок венчурного капіталу; — інструменти для аналізу ринку; — відмінності між венчурними фондами та венчур-білдерами; — монетизація диджитал-продуктів; — due diligence та оцінка стартапу; — процес фандрейзингу; — юніт-економіка у різних бізнес-моделях; — побудова команди у стартапі. Щоп’ятниці проводитиметься заняття у форматі case study. Учасники обговорюватимуть успішні кейси, наприклад, зростання стартапів Liki24 та Propertymate, історію участі кофаундерів Awesomic у всесвітньовідомому бізнес-інкубаторі YCombinator, також про підготовку бізнесу до IPO розповідатиме старший партнер інвестиційного фонду Horizon Capital. Участь у Venture DeepDive безоплатна, однак, щоб потрапити на навчання, потрібно пройти відбір. Він складатиметься з онлайн-тестування, завдання у форматі кейса та співбесіди. Зареєструватися для участі можна до 30 вересня. Форма для подання заявки, детальна програма та інформація про викладачів — на сайті за посиланням.

Genesis — це українська компанія, 90% співробітників та керівників якої від початку повномасштабного вторгнення залишаються в Україні. Майбутнє компанії, як і майбутнє більшості українських бізнесів, залежить від якості освіти та рівня випускників університетів. Аби конкурувати з найбільшими світовими лідерами, потрібно мати освіту, рівень якої не поступається світовому. Співзасновник і СЕО Genesis виступив із лекцією на внутрішньому мітапі для генезійців в межах Internal Education Week. Володимир Многолєтній розповів, чому Genesis приділяє багато уваги освіті та скільки і в які освітні напрями інвестує. В цій колонці ми зібрали найважливіші тези з виступу Володимира. Навіщо ми інвестуємо в освіту? IT-компанія — це насамперед люди. Крута IT-компанія — це висока щільність талантів на один квадратний метр. Якщо вам вдалося зібрати в компанії багато талантів, то з певного моменту ця спільнота буде допускати до себе лише фахівців такого ж високого рівня. 80% успіху керівника — це вміння наймати й утримувати талановитих людей. Якщо СЕО зібрав і зміг утримати круту команду, то його життя стає досить простим, і вивільняється купа часу для інших задач: стратегії, фандрейзингу, IPO тощо. Тут вже кожен обирає сам. В мене є певний підхід до найму, який дозволив зробити Genesis успішною компанією. Передусім я шукаю людей, що здатні системно мислити та системно приймати рішення. За моїми спостереженнями, 80% таких людей — вихідці зі STEM, тобто зі студентів, що вивчали фундаментальні науки. Маю зазначити, що знаю багато талановитих людей, які закінчили гуманітарні університети, але більшість «системників» — це саме випускники технічних спеціальностей. Освіта навчила їх системно мислити або покращила природний талант. Вона навчила їх таких механізмів прийняття рішень, що вони можуть стати успішними у будь-чому: від науки до вирощування квітів. Я за першою освітою — ядерний фізик, за другою — економіст. Не займаюся нині ні тим, ні іншим, проте навички, що дала мені моя академічна освіта, дуже допомагають в бізнесі й зараз. Ми прагнемо побудувати системну компанію, яка буде значно більшою, ніж є нині, і тому нам важливо мати доступ до талантів із сильним освітнім бекграундом. Системна людина з якісною освітою та хорошим трек-рекордом роботи в інших компаніях, скоріше за все, швидко «приживеться» в Genesis. Саме тому ми вже не перший рік інвестуємо в освіту в індустрії та в Україні загалом на стратегічному рівні. Що саме ми робимо? Якщо розглянути економіку традиційних університетів в Україні, то найперша фундаментальна проблема, що впадає в очі — їхня збитковість. Ба більше, це ще й неможливість стати прибутковими у майбутньому. Саме тому я маю тверде переконання, що ми як компанія маємо працювати з університетами й допомагати їм. У Genesis є низка проєктів, які охоплюють пряму співпрацю з найкращими університетами в країні. Ми регулярно інвестуємо кошти у реновацію освітніх просторів, у спільні школи, проєкти, спільні лекції, допомагаємо безпосередньо викладачам. Щорічно ми інвестуємо у напрям роботи з університетами приблизно $1 млн. Ще один важливий напрям — Всеукраїнський курс «Створення та розвиток IT-продуктів». Його ідея виникла, коли ми зрозуміли, що можемо працювати не лише з топовими ЗВО, а й зі студентами регіональних університетів. Так, ми не можемо туди поїхати з лекціями, проте можемо створити диджитал-формат для них. Тож ми оцифрували лекції й створили курс про продуктове IT, який викладачі в регіонах можуть імплементувати у свою програму. Наразі цей курс пройшли вже понад 10 000 студентів по всій країні, а 1000 викладачів готові інтегрувати його в освітній процес. Наш план на майбутнє — 30 000–50 000 студентів на рік, які опановуватимуть курс. Для нас цей проєкт — інвестиція у майбутнє IT-індустрії в Україні. Непринципово, чи прийдуть потім ці студенти працювати в Genesis. Якщо вони доєднаються до української IT-спільноти та працюватимуть із цифровими продуктами у будь-якій українській компанії, це означатиме, що наші зусилля не були марними. Третій напрям інвестицій — це Genesis Academy, екосистема наших освітніх проєктів: профільні школи за різними напрямами, курси й інтенсиви. Основна мета — розповісти учасникам, які вже мають фундаментальну освіту, як працює продуктова компанія. Нині в нашій екосистемі й поза нею є багато талановитих фаундерів та СЕО, які свого часу закінчили ці школи. Це, до прикладу, фаундерка BetterMe Вікторія Рєпа, засновниця Keiki Інна Максименко та інші. Унікальний проєкт в освітній екосистемі — Startup Academy together with Meta. Свого часу компанія Meta, з якою ми тісно співпрацюємо, запропонувала нам зробити спільний проєкт для стартапів, аби навчати майбутніх фаундерів тому, як будуються та масштабуються великі IT-компанії. Нині це єдиний приклад подібної освітньої колаборації в Україні. Інвестиції чи благодійність? Щороку ми виділяємо бюджет на освітні програми, враховуючи, що повернення інвестицій в тому чи іншому вигляді нам принесуть від 30% до 50% освітніх ініціатив. Що це може бути? По-перше, ми прагнемо генерувати талановитих фахівців, аби залучати їх до Genesis. По-друге, нам важливо, аби про компанію та її продукти знали на ринку. Відповідно, близько половини всього, що ми робимо у сфері освіти — це благодійність, від якої ми не очікуємо жодних повернень інвестицій. Це, наприклад, Всеукраїнський курс зі створення IT-продуктів, стартап-академія та інші. В Україні є 300 000 фахівців, які зараз працюють в ІТ. Чому вони працюють в цій індустрії? Тому що українці успадкували непогану базу технічної освіти. Ми маємо розвивати й підтримувати IT-освіту в Україні, аби наша індустрія продовжила існувати й рости. Якщо дивитися з цього боку, то наша благодійність — не зовсім благодійність, а віра в те, що якісна освіта неодмінно зростить майбутні покоління талантів.

Ідея про те, що системи програмування мають базуватися на конкретній предметній області, здається очевидною, проте коли розробник Ерік Еванс зібрав докупи усі патерни, методи та нюанси подібного підходу, вийшла ґрунтовна фундаментальна праця на півтисячі сторінок. Він назвав нову розробницьку філософію Domain-Driven Design (DDD) або предметно-орієнтоване проєктування. У цьому матеріалі ми з’ясовуємо, що таке DDD, чи актуальна методологія зараз, які основні концепції варто знати перед тим, як з нею працювати, які переваги та недоліки є у запропонованого Евансом підходу. Розібратися у предметно-орієнтованому проєктуванні нам допоміг Андрій Попов, Back-end Tech Lead в AMO, одній з компаній екосистеми Genesis. Андрій керує бекенд-командою у проєкті з розробки застосунку в галузі Health&Fitness. Загалом він має більш ніж десятирічний досвід в IT, працював в нішах Education та Betting, де зокрема застосовували концепції предметно-орієнтованого дизайну. Що таке DDD, і чому він потрібен у сучасній розробці Domain-Driven Design — це підхід до розробки, відповідно до якого створення систем програмного забезпечення базується на домені, тобто на предметній області, в якій працює компанія. Таких доменів може бути один або декілька — залежно від комплексності конкретного бізнесу. Прикладом бізнесу, де поєднано кілька доменів, може бути великий ecommerce-проєкт, залізниця, пошта, фінансова організація тощо. У великих проєктах часто буває так, що розробники концентруються тільки на тій частині бізнес-логіки, з якою вони безпосередньо працюють. Через це виникає низка труднощів. Окремі члени команди не бачать повну картину того, що відбувається в коді, і, відповідно, не можуть врахувати специфіку системи, не бачать найбільш вдалі архітектурні рішення, й фокусуються на цікавих з точки зору розробки, але другорядних з точки зору бізнесу завданнях. DDD допомагає ці проблеми усунути. Предметно-орієнтоване проєктування передбачає, що кожен у команді має цілісне уявлення про код, про домен та про бізнес-процеси. Цього досягають, зокрема, завдяки моделі предметної області, яку розробляють на початку, та єдиній мові, якою комунікують всі стейкхолдери. Тоді й розробники, і бізнес мають однакове бачення системи — і необхідність у постійній синхронізації та ґрумінгах зникає. Важливо, що DDD — це не конкретна технологія чи методологія. Це набір правил та підходів, які полегшують процес розробки. У сучасному програмуванні все більше девелоперських команд відмовляється від монолітів на користь мікросервісів — і DDD стає їм у пригоді: допомагає визначити межі кожного мікросервісу, основні концепції, агрегати та пов’язану з ними бізнес-логіку. Завдяки цьому розробники мають змогу зробити більш структурний та масштабований код. У предметно-орієнтованому проєктуванні є два рівні — тактичний та стратегічний. Розберемося з основними поняттями для кожного з них. Основні поняття DDD У основі терміну лежить поняття предметної області (domain) — це галузь, у якій працює організація. На початку в особливостях цієї галузі може бути важко орієнтуватися, однак з часом усі залучені до проєкту розбираються в усіх нюансах. Втім, створити всеохопну модель будь-якого складного бізнесу не вийде, тому в доменах виділяють subdomains — предметні підобласті, що ранжуються відповідно до їхньої фактичної функціональності. Субдомени дають змогу швидше визначити різні частини предметної області, необхідні для вирішення конкретного завдання. Серед них виділяють змістове ядро (core domain) — найбільш важливий субдомен. По суті, це унікальна ціннісна пропозиція, яка вирізняє конкретний бізнес. Саме на ній мають фокусуватися найкращі розробники та саме у неї слід спрямовувати найбільше інвестицій — адже core domain напряму впливає на отримання прибутку та успіх бізнесу. Натомість деякі інші аспекти бізнесу є важливими, але не ключовими. Тоді їх відносять до службової підобласті (supporting subdomain). Більшість таких юнітів мають спеціалізацію. Якщо ж її немає, а підобласть потрібна для всього бізнесу — вона називається неспеціалізованою (generic subdomain). Одна з найважливіших концепцій доменно-орієнтованого проєктування — це ubiquitous language або усеохопна мова. Фактично, це набір термінів для конкретної команди, в створенні якого беруть участь усі дотичні до проєкту люди — програмісти, експерти предметної області, аналітики тощо. Структурним одиницям коду, таким як класи, методи, змінні чи назви, присвоюють конкретні назви, які базуються на моделі домену. Завдяки цьому код стає чітким та зрозумілим для всіх. «Єдина термінологія, якою оперують бізнес і команда розробки, дозволяє усувати прогалини у взаєморозумінні. Наприклад, зараз ми в AMO ми робимо застосунок для тренувань. У нас не імплементовано DDD у чистому вигляді, однак є деякі технічні елементи концепції з тактичних патернів. Крім того, ми ввели Ubiquitous Language, наскільки це було можливо. Так, кожен має точно знати, що значить тренування, з чого воно складається тощо. У теорії створити та імплементувати таку мову просто, одна на практиці цей процес доволі складний. Потрібна людина, яка буде стежити за її застосуванням. Ідеально, якщо це людина, яка працює на перетині розробки та бізнесу, наприклад, дата- чи бізнес-аналітик», — каже Андрій Попов. В межах предметної області сенс певного терміна або поняття може відрізнятися. Існує певна межа — і за нею поняття єдиної мови набувають конкретного контекстного значення. Така межа називається обмеженим контекстом (bounded context). Це ще одна критично важлива характеристика DDD, яка полягає в тому, що на різних рівнях проєкту можуть використовуватися декілька моделей зі своїми єдиними мовами. Завдяки bounded context зв’язки між моделями зменшуються — і це теж запобігає складному та заплутаному коду. Bounded Context дозволяє дублювати моделі в різних командах, щоб кожна могла вільно змінювати цю модель у себе, незалежно від іншої. Тактичний рівень DDD Аби реалізувати специфічний bounded context, на тактичному рівні використовують низку шаблонів. На відміну від стратегічного моделювання, яке фокусується на загальному управлінні бізнесом, такі шаблони використовують для ітеративної розробки. Сутності (entity) використовують, коли потрібно змоделювати унікальні поняття, або ті, що відрізняються від інших об’єктів у домені. Їх можна визначити за певним ключовим атрибутом або комбінацією атрибутів, що не залежать від інших характеристик. Якщо ж для об'єкта не важлива індивідуальність, і для його визначення достатньо власних атрибутів, його вважають об'єктом-значенням (value object). Їх легше створювати та підтримувати, тому розробники намагаються використовувати об’єкти-значення частіше, ніж сутності. Значні зміни в стані домену відображають події (domain event). Вони використовуються для передачі змін і запуску дій між різними частинами системи. Модулі (module) можуть бути організовані навколо конкретних концепцій домену та містять класи, функції чи компоненти, що відповідають за обробку логіки та даних, пов'язаних з конкретною концепцією предметної області. Агрегат або сукупність (aggregate) — це кластер пов’язаних між собою сутностей та об’єктів значення, які розглядаються як єдине ціле. Вони забезпечують узгодженість та цілісність змін у своїх межах. Фабрики (factory) існують, щоби відтворювати інші об’єкти, а сховища (repository) надають інтерфейс для доступу та керування агрегатами. У яких випадках потрібен DDD DDD призначене для створення моделей доменів зі складною бізнес-логікою. Це означає, що найкраще концепція підійде для вузьких специфічних ніш — наприклад, фінтех або e-commerce. «Канонічне предметно-орієнтоване проєктування містить дуже багато понять, патернів та підходів. Використовувати їх усі у стартапі або проєкті, запущеному з нуля, важко й не доцільно», — коментує Андрій Попов. Коли команді варто обирати перехід на DDD? Наприклад, якщо це складна ніша з багатьма окремими сутностями. «Раніше я працював саме над таким проєктом. DDD імплементували з нуля, оскільки ніша передбачає багато складних для розуміння сутностей. Потрібно було пильно стежити за правильністю термінології, тому ми зробили окрему сторінку з глосарієм, де було пояснення багатьох специфічних для ніші понять. Була навіть відповідальна людина — бізнес-аналітик, який транслював вимоги конкретно під цю область, а програмісти намагалися писати код відповідно до бізнес-правил», — говорить Андрій Попов. Як імплементувати DDD у себе в проєкті Імплементувати методологію може бути складно. На цьому шляху є декілька челенджів. «Найперше — розробникам може бути банально нецікаво працювати з новою концепцією. Буває так, що термінологію прописує бізнес-команда — і технічним фахівцям потрібно до неї звикати. А означає, що треба повністю змінювати стиль роботи, і витрачати додаткові час та енергію на щось іще, окрім написання коду. З іншого боку — перехід на нові правила може не цікавити сам бізнес, бо на це потрібно виділяти час, ресурс, призначати відповідальну особу, яка буде за всім стежити», — підкреслює Андрій Попов. Однак, з часом DDD перестає уповільнювати роботу команди й тільки полегшує розробку. «Нещодавно ми запустили ще один проєкт в ніші Health and Fitness. Мене призначили лідом, дали невеличку команду. Я одразу вирішив, що ми будемо використовувати глосарій з термінологією, інакше буде плутанина і люди не розумітимуть, що і як влаштовано в коді. Поки що тільки цим словником важко обмежуватися, адже під час написання абстракцій чи алгоритмів все одно доводиться щось додумувати. Втім, ми уже маємо певний каркас, завдяки якому розробники та бізнес краще одне одного розуміють. Це, знову таки, не канонічне предметно-орієнтоване проєктування — здебільшого ми послуговуємося суто технічними речами, такими як фабрики, репозиторії, сервіси, доменні моделі тощо. Однак подібний підхід все одно покращує чистоту коду, й сам процес розробки стає комфортнішим», — розповідає розробник. Переваги DDD покращує чистоту та структурованість коду; розробники та бізнес говорять однією мовою — що дозволяє уникнути хаосу та плутанини; архітектура точно відображає бізнес (предметну область) та враховує його специфічні особливості; автономна робота над різними частинами системи забезпечує кращу масштабованість; у великих проєктах з кількома технічно незалежними командами DDD чітко декларує способи їхньої взаємодії; компоненти та бібліотеки, які створюють у межах DDD, можна використовувати у майбутніх проєктах — що заощаджує час розробників. Недоліки DDD на початку DDD суттєво уповільнює робочий процес; розробникам чи бізнесу можуть не подобатися нові правила, що призведе до опору та конфліктів; ускладнення коду (якщо до нього «притягнути» зайві пункти методології); збільшення кодової бази через специфічні технічні рекомендації; DDD вимагає залучення кваліфікованих експертів предметної області та досвідчених розробників, тому може бути ресурсомістким; деякі інструменти та фреймворки можуть не вписуватися в принципи DDD, а це ускладнить реалізацію функціонала. DDD для кар’єри Розробникам рівня сеньйор з амбіціями стати тимлідами точно корисно мати в резюме рядок про знання принципів DDD, говорить Андрій Попов. Не факт, що ці знання згодяться у роботі, оскільки не всі (навіть великі) проєкти застосовують DDD. Однак обізнаність у цьому підході покаже і рівень досвіду, і менеджерські амбіції. «Будь-які додаткові знання стануть плюсом. А якщо людина прагне до керівної посади, їй варто розумітися не лише на технічних патернах, а й на стратегічних речах, зокрема, комунікації між командами та бізнесом. Втім, на початку кар’єри краще присвятити час заглибленню у технічні нюанси розробки обраною мовою», — уточнює Андрій. Корисні матеріали Весь теоретичний матеріал з DDD зібраний у трьох канонічних виданнях — синій, червоній та зеленій книзі. Синьою книгою називають працю Еріка Еванса «Предметно-орієнтоване проєктування: структуризація складних програмних систем». Еванс — основоположник концепції DDD, тож у книзі він ґрунтовно пояснює, як включити ефективне доменне моделювання у розробку ПЗ. Автор не описує конкретні технології, пропонуючи натомість підходи, інструменти та методи, які полегшать розробку ПЗ у складних доменах. «Цю книжку варто прочитати хоча б тому, що це першоджерело знань про DDD. Однак не розраховуйте, що буде легко: вона доволі специфічна, я зміг дочитати її лише з третього разу», — каже Андрій. «Новачки навряд чи зможуть одразу застосувати методології, про які пише Еванс. А от якщо ви розробник зі значним комерційним досвідом та працювали з великими замовниками у незнайомій для вас царині — то ця книга точно стане в пригоді». Червона книга — це «Реалізація методів предметно-орієнтованого проєктування», яку написав Вон Вернон. На відміну від попереднього «підручника», де описуються фундаментальні принципи DDD, у виданні американського архітектора програмного забезпечення є більш практичні поради. Він із самого початку знайомить читачів з проблемами реальної розробки й показує, як їх вирішити за допомогою методів та шаблонів DDD. Зелену книгу, «Предметно-орієнтоване проєктування: найголовніше», також написав Вон Вернон. З усіх трьох вона найпростіша для сприйняття. По суті, це короткий довідник з основними концепціями DDD та простими прикладами з досвіду Вернона, на яких видно переваги підходу. Загалом, DDD — це, швидше, звід рекомендацій, ніж суворий набір правил. Тимліди технічних команд можуть обирати лише деякі рекомендації з цього підходу — і процес не поламається. Але навіть декілька інструментів предметно-орієнтованого проєктування дадуть змогу простіше допрацьовувати, змінювати та тестувати застосунок у майбутньому.