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

Що робити з Legacy-системою, яка вже багато років не підтримується, а в команді майже не залишилося людей, які б памʼятали нюанси та edge-кейси розробки 15-річної давнини?  Владислав Поздняков , Software Engineer в MacPaw, який має понад 10 років досвіду в Back-end розробці, поділився кейсом міграції такої системи. Команда працювала над нею близько року, обробляючи величезні обʼєми даних: створили понад 12 млн нових активаційних ключів, перенесли дані понад 4,5 млн користувачів і згенерували понад 7 000 ордерів для реселерів з 7,5 тисячами рідім-кодів.  Під час конференції PHP fwdays'24  він розповів, з якими викликами та проблемами зіткнулася команда, а також як підготуватися та мінімізувати ризики. Переказуємо найцікавіше з виступу Владислава. Legacy, про яку всі забули Близько 15 років тому в MacPaw була написана система ліцензування та активації застосунків. Вона містила інформацію про продукти та користувачів, певну логіку платежів, обробку підписок, валідацію ліцензій, активації та навіть окремий функціонал для реселерів. Вона була написана на PHP 5 з базою даних MySQL. Крім того, у ній знайшовся такий екзотичний на сьогодні інструмент як Gearman, про який раніше я тільки читав і ніколи не зустрічав на практиці.  Команда, що розробляла цю систему, давно була перекинута на інші проєкти. Протягом багатьох років цей продукт майже не підтримувався, що призвело до накопичення великого технічного боргу. Крім того, за цей час у нас зʼявився дещо подібний сервіс зі схожим функціоналом, а підтримувати дві системи було неефективно. Отже, ми вирішили припинити підтримку Legacy та перенести всі активації та ліцензії в новий сервіс. Існує два основних підходи до міграції Legacy-систем. Перший — це поступова міграція, де ми відокремлюємо окремі функціональні частини старої системи та переносимо їх у нові сервіси. Так можна одночасно продовжувати бізнес-розробку, але така міграція може тривати дуже довго. Другий підхід, — його обрала наша команда, — це створення нової системи, яка б повністю замінила Legacy. Переваги очевидні: можна швидше рухатися, врахувати помилки, впроваджувати нові технології. Проте такий підхід потребує більше уваги інженерів, тому поєднувати міграцію з бізнес-розробкою може бути складно.  Нова система була побудована на більш актуальному стеку: PHP 8, Symfony, Postgres, Redis, Docker, RabbitMQ. Ми також впровадили патерн CQRS (Command Query Responsibility Segregation) та архітектуру Onion, адаптовану під наші потреби. І що найважливіше — навколо цієї системи сформувалася сильна команда розробників, готова до викликів. Спершу ми створили план добровільної міграції користувачів. Ідея була така: коли вони активуються в системі своїм старим ключем, ми пропонуємо їм перейти у нову систему та заохочуємо додатковими бенефітами. Проте отримали умову від менеджменту — користувачі взагалі не мають помітити змін.  Намалювавши поверхневий пайплайн, ми знайшли рішення, як перенести всі ліцензії, активації та продукти в автоматичному режимі. Щоби оцінити естімейти, ми почали розбиратися, як налаштовані процеси у старій системі та структура даних. Для цього навіть досліджували версії застосунків, що не оновлювалися 5-6 років на старих ноутбуках, дивилися, які протоколи спілкування та версії API там використовуються. Також писали стос скриптів, щоби перевірити, які взагалі ліцензії та продукти ще актуальні, а у яких термін дії вже закінчився.  У результаті ми зробили поверхневу оцінку кожного етапу та сформували оптимістичний та песимістичний прогнози за естімейтами. Результат буде десь посередині, думали ми. Проте менеджмент затвердив оптимістичний варіант, і ми почали міграцію. Міграція. Початок Першим завданням було підняти новий сервіс та API-активації, які працювали б з мігрованими ліцензіями. Проблема полягала в тому, що принципи активації продуктів у старій та новій системі відрізнялися. В одній з них користувач отримував ключ після покупки, в іншій – просто логінився через акаунт.  Частина застосунків мала 15-річну історію. Проте якщо користувач придбав пожиттєву ліцензію, ми не можемо припинити підтримку цього продукту, яким би старим та незручним він не був. Фактично цими продуктами могло користуватися дуже обмежене коло людей, але щоби уникнути юридичних ризиків, ми мали створити новий сервіс для збереження ключів і API для активації, що підтримувало б старі продукти.  Крім того, що Legacy-система була написана старими підходами, часом з ігноруванням важливих принципів, там використовувався один endpoint. Він всередині визначав, яка це дія — активація, деактивація чи перевірка на актуальність, а також який протокол спілкування використовується в різних версіях застосунків (їх було близько пʼяти). Ми мали розібратися в цьому, розділити на окремі логічні частини й зберегти повну функціональність. Під час розбору цього Legacy у нас сталося перше вигорання розробника, але ми продовжили.  Поєднуємо дані між двома системами Наступний етап полягав у тому, щоби зіставити дані між двома системами. Це виглядало досить непросто, оскільки між старою та новою системою була низка структурних відмінностей. У Legacy була така сутність, як ключ. Ордер міг бути частиною реселерського пакету і містити декілька продуктів (бандл) або один, а також був прив’язаний до користувача. Під цей ордер створювався ключ, в якому були дані активації та все інше. У новій системі ми працювали з окремим продуктом. Кожен з них мав свій план, SKU, і був прив’язаний до інформації про оплату та ліцензії. Отже, нам потрібно було вирішити дві відмінності:  привʼязка ліцензії до користувача, а не ключа; відсутність поняття «бандл» продуктів у новій схемі. Для цього ми створили схему, яка дозволила нам зіставити старі продукти з новими ліцензіями відповідно до типу та прив’язати до користувачів. Якщо користувач не існував у новій системі, ми його створювали, якщо ж був — прив’язували до наявного облікового запису. Також ми зберегли можливість посилатися на старі ключі для активації, пов'язуючи їх із новими ліцензіями. Будуємо пайплайн перенесення даних  Наступним кроком стало створення пайплайну перенесення даних. Він складався з окремих етапів, кожен з яких відповідав за перенесення певної сутності. Пайплайн було загорнуто в транзакції, щоб у разі помилки можна було відкотити зміни та відновити роботу. У міру запуску ми стикнулися з edge-кейсами, які не врахували від початку. Нам доводилося працювати з уривками знань про те, що відбувалося у цій системі раніше.  Міграцію ми запускали через Symfony Messenger, піднявши окремий пул воркерів, який можна масштабувати незалежно від основної системи. Як це працює: ми створюємо команду, яка ініціалізує перший меседж у Command Bus ( кількість таких меседжів відповідає кількості воркерів). Потім передаємо, який саме бандл хочемо мігрувати. Він звертається до бази Legacy, резервує ордер для подальшої обробки й переносу. Далі запускається пайплайн і проходить всі необхідні етапи. Після відпрацювання меседж надсилається повторно, щоби воркер міг перевірити, чи є новий ордер для резервування. Таким чином, процес повторюється автоматично. Якщо нового ордеру немає, воркер виходить з циклу і надсилає повідомлення в Slack про завершення роботи. Такий напівручний режим потрібен був нам, щоби контролювати, що переносити та в якій кількості. Наприклад, щоби не виникало ситуації, коли в пʼятницю ввечері ми запускаємо міграцію важливого складного бандлу і розгрібаємо проблеми на вихідних. Перенос трафіку Ми не могли вносити зміни у Legacy-продукт, а також не могли бути впевненими, що всі користувачі працюють з останньою версією продукту чи SDK. Тому ми вирішили фактично підмінити домен, який раніше дивився на Legacy, і перенаправити його на новий сервіс. Ендпоінти та респонси збігалися, а самим процесом можна керувати через Ops-команду. Такий перехід можна було здійснити на нашій інфраструктурі з мінімальним часовим лагом.  Проте ми не могли перемкнути весь трафік в один момент, оскільки під час міграції частина даних залишалася в старій системі, а інша вже була перенесена в нову. Для цього ми створили проксі, який перевіряє кожен ключ: якщо він вже в новій базі — дані обробляються новою системою, якщо ні — проксі передає запит до Legacy-сервісу. Також ми додали Full Proxy Mode, який обробляв весь трафік, який приходив на ендпоінт. Це допомогло мінімізувати навантаження на нову базу даних на ранніх етапах міграції та дозволяло швидко перемкнутися у разі виникнення критичних проблем. Налаштування проксі зробили максимально простим: через змінні середовища у конфігах, з можливістю швидкого перезапуску сервісу. Тестування: нові пригоди Нові фічі та API для активації продуктів тестувалися відносно просто, хоча були певні труднощі зі старими програмними ліцензіями. Найскладнішим виявилося тестування самої міграції даних через відсутність чітких вимог та велику кількість накопичених edge-кейсів. Щойно ми зʼясовували, що базовий флоу працює, виявлялося, що в якоїсь ліцензії все налаштовано по-іншому. Ми намагалися протестувати якомога більше різних бандлів, планів, комбінацій та виправити більшість мінорних кейсів. Але попри всі зусилля, ми не могли бути впевненими на 100%, що покрили всі можливі варіанти. Водночас змігрувати базу в 12 мільйонів ордерів заради тесту — сумнівна задача. Тому ми просто дійшли до етапу, коли стартувати міграцію було вже не страшно. Щоби впевнитися, що система здатна впоратися з очікуваним трафіком, ми провели тестування навантаження. Отже, ми були готові до Дня Х.  Запуск міграції та перше падіння  Ми обрали поетапний підхід, починаючи з міграції найстаріших і найменш актуальних продуктів. Так можна було відстежувати проблеми, перш ніж переходити до більш критичних і популярних продуктів. Загалом процес йшов добре. Ми фіксили мінорні кейси, іноді доводилося зупиняти міграцію, щоби виправити баги, оптимізувати запити чи прискорити систему. Через це процес трошки затягувався, але система працювала стабільно, і ми поступово розганялися.  Закон Мерфі для девелоперів виглядає так: якщо щось має масштабно «впасти», то це обовʼязково трапиться в суботу ввечері. На той момент ми мігрували один з найбільш актуальних продуктів з новими ліцензіями та високим навантаженням. Все почалося з того, що в пʼятницю в RabbitMQ почали зростати меседжі. «Ми просто не масштабували деякі з воркерів повʼязаних сервісів», — подумали ми та додали воркери і ресурси інфраструктури. Нам здалося, що проблема вирішена. Проте за ніч кількість меседжів різко зростає, і все падає.  Що сталося: у нас є сервіс, який відповідає за нотифікації про зміни в системі для аналітики, процесингу на бекендах тощо. Проєктуючи нову систему, ми вирішили, що ця інформація дуже важлива, тому використовувати брокер повідомлень ризиковано. Ми згадали, що в Symfony Messenger є транспорт — Doctrine, отже вирішили скласти ці дані в базу і використовувати її як сторедж для воркера. Все працювало, але сталося так, що міграція збільшила навантаження настільки, що ми за 2 тижні згенерували в 7 разів більше івентів, ніж за попередні пів року в продакшені.  Це призвело до зростання локів, а масштабування воркерів тільки погіршило ситуацію. Ми знайшли оптимальну кількість, щоби черга поступово розгрібалася, і в спокійному режимі перейшли з Doctrine на Rabbit як транспорт. Це вдалося зробити невеликими змінами в конфігах. Проблему було вирішено.  Згодом міграцію було завершено, і ми перейшли в режим стабілізації. Чи можна говорити про Happy End? Загалом вважаю наш досвід позитивним: ми справилися, хоч і неідеально. Враховуючи, що для нас це був повний Black Box, результат можна вважати успішним. Адже все що нас не вбиває, додає рядок у CV.    Головні уроки Ставте за мету не створювати Legacy. Ми часто потрапляємо у пастку «давайте зараз зробимо швидко, а потім виправимо, як треба». Правда полягає в тому, що до цього «потім» майже ніколи не повертаєшся.  Множте естімейти . Коли працюєте з системою, яку не знаєте досконально, закладайте додатковий час на те, щоби в ній розібратися. У нашому випадку оптимістичний сценарій варто було множити у 2,5-3 рази.  Валідуйте технічні рішення з іншими інженерами . Колеги можуть оцінити вашу задачу свіжим поглядом та помітити потенційні ризики. Адаптуйте процеси . Іноді краще відмовитися від ідеальної архітектури та піти на компроміси. Наприклад, ми дозволили собі робити прямі конекти з одного сервісу до всіх необхідних баз. Це був одноразовий функціонал, і писати повноцінні API та тести до них зайняло б набагато більше часу.  Не робіть великі зміни в командах чи проєктах під час і одразу після такого проєкту . По завершенню міграції команда може мати певні завдання для допрацювання. Наприклад, у нас досі не завершені деякі тікети. Тому краще не тиснути на команду новими проєктами, а дати їй час.

У вересні 2024 року стартап у сфері нерухомості Rentberry заявив  про залучення у Серії A $90 млн з оцінкою компанії у $1 млрд. Українське інвестиційне комʼюніті поставило під сумнів таку високу оцінку Rentberry. 11 вересня у коментарі виданню Mind засновник стартапу Олексій Любинський сказав , що оцінка в $1 млрд складена «з  урахуванням юзерів, покриття ринку та виручки в цьому році ». При цьому у березні 2023 року в розмові з тим же медіа Любинський повідомляв , що «команда готується до раунду у $30 млн з оцінкою у $100млн».  Цей кейс створює прецедент на ринку українських стартапів, тому ми разом з принципалом фонду Horizon Capital Денисом Сичковим розібралися, як формується оцінка бізнесу, чи можна її штучно підвищити та чому не завжди варто довіряти інформації від компаній.  Як оцінити компанію Акції публічних компаній торгуються на біржі. «Будь-яка людина може купити акції Apple або інших корпорацій», — підкреслює Денис. Хтось хоче їх купити, хтось готовий їх продати, ринок формує ціни, і в кожен момент часу зрозуміло, скільки коштує ця компанія, адже на публічних лістингах відображається  інформація щодо кількості акцій і останніх транзакцій за ними.  Більшість компаній у світі — приватні. Наприклад, в Genesis є обмежена кількість акціонерів. Оцінка такої компанії вимірюється в результаті останнього раунду інвестицій. Припустимо, Horizon Capital заходить як інвестор в компанію A, і в рамках цього раунду її оцінка 100 млн грн. В наступному раунді заходить інший інвестор і купує 10% компанії за 15 млн грн, тоді оцінка компанії складає 150 млн грн (вона виросла). Можливий й down-round, якщо у наступному раунді 10% купують за умовні 9 млн грн. У випадку, коли жодної транзакції з капіталом цієї компанії ще не відбулось, або якщо з моменту останнього раунду інвестицій пройшов значний час, можлива теоретична оцінка.  Для розуміння Денис порівнює механіку публічних ринків із сервісом «Авторіа». Якби «Авторіа» викладали всю історію транзакцій автомобіля, то можна було б визначити, що BMW 3-ка 2020 року коштує у середньому $X тис. Для оцінки компанії ви знаходите бізнеси, що схожі на неї за темпами зростання, індустрією, географією та іншими показниками. Уявімо, що Samsung не є публічним. Тоді для визначення його оцінки ми можемо порівняти Samsung та Apple. Припустимо, показник EBITDA ( Earnings before Interest, Taxes, Depreciation and Amortization, обсяг прибутку до вирахування витрат за відсотками, сплати податків та амортизаційних відрахувань. — ред.)   Apple дорівнює 100, а у Samsung EBITDA = 50, значить, теоретично вони вдвічі менші за Apple. Якщо компанія швидко зростає, вона дорожче. Є купа факторів, що впливають на оцінку. І тут з'являються мультиплікатори. Що ви маєте знати про мультиплікатори  Мультиплікатори — це показники оцінки публічних компаній до їх фінансових чи операційних показників. Це може бути виручка, товарообіг, прибуток, кількість користувачів, тощо. Як зазначає Денис Сичков, вони, зазвичай, forward-looking (враховують майбутні очікування — ред.) . За даними консалтингової компанії PwC, є чотири основні показники, за якими оцінюють  стартапи: Показник Enterprise Value (вартість компанії / підприємства) відображає загальну вартість компанії, враховуючи й її ринкову капіталізацію, і боргові зобов’язання. Його використовують для порівняння компаній у межах однієї галузі. Якщо ми жили б в ідеальному Всесвіті, компанія коштувала б стільки грошових потоків, скільки вона згенерує за весь час існування (продисконтованих під вартість капіталу).  «Припустимо, я відкрив ларьок з шаурмою, який сьогодні продає на 20 000 грн на місяць, потім я додам картоплю, буду продавати на 30 000 грн плюс інфляція упродовж 25 років. За ці роки, припустимо, він мене принесе чистий грошовий потік (чистий прибуток) у розмірі 3 млн грн. Але цінність коштів за 25 років зміниться, тому ми маємо врахувати фактор дисконтування. Уявімо, що 100 грн через 25 років — це близько 20 грн сьогодні. Відповідно, щороку ми застосовуємо цей коефіцієнт і розуміємо, що зараз ця МАФ коштує близько 1 млн грн», — наводить приклад Денис. На жаль, подібні моделі складно побудувати, тому люди спрощують — використовують мультиплікатори, роблячи припущення, що публічні інвестори зробили DCF (Discounted Cash Flow, метод оцінки бізнесу, подібний до мультиплікатора прибутку — ред.) , і компанія коштує стільки, скільки має в ідеалі. Але тут варто врахувати і фактор емоцій, і те, що ми не знаємо, якими будуть грошові потоки через десятки років.  За словами Дениса, в цілому компанія коштує стільки, скільки за неї готові заплатити. Щоб визначити, чи компанія переоцінена, орієнтуються на common sense. Наприклад, 2021 року Grammarly оцінили   у $13 млрд. Їх продажі на той час, за інформацією Дениса, складали менше $100 млн, але інвестори вірили, що ШІ-рішення зростатимуть завжди. Щоб виправдати таку оцінку, компанія має дуже швидко зрости і почати генерувати багато грошей.  Нагадаємо, Rentberry є збитковою — минулого року її виторг склав $0,5 млн за $4,8 млн чистого збитку. Про це пише  український Forbes, посилаючись на фінансову звітність для Комісії США з цінних паперів і бірж. Анонімний учасник інвестринку у коментарі для AIN додав , що навіть якби Rentberry купили WeWork (цю угоду стартап анонсував раніше), вартість платформи складала б удвічі менше $1 млрд. Ці аргументи ще раз підкреслюють, наскільки відірваною від реальності є оголошена мільярдна оцінка.

У 2023 році платформа GitHub об'єднувала понад 100 млн юзерів — це 1,5% всіх користувачів глобальної мережі. Щодня GitHub відвідує близько 14 млн користувачів і створюється близько 130 000 нових проєктів. Проте у цьому морі репозиторіїв не так легко знайти справжні перлини. Ми поспілкувалися з Максимом Березанським, Tech Lead в Keiki з екосистеми Genesis, про те, як знайти найкращі репозиторії, що можуть суттєво покращити робочий процес і пришвидшити розробку проєктів. Максим поділився своїми фаворитами та розповів про критерії, якими керується при виборі корисних інструментів для розробки. Сім репозиторіїв, на які варто звернути увагу  Перейти до репозиторія Опис:  легкий і простий у використанні фреймворк для побудови інтерфейсів користувача, який спрощує розробку інтерактивних вебдодатків. Його основна мета — забезпечити зручність і продуктивність для розробників. Чим він корисний:  є чудовим вибором для новачків і досвідчених розробників завдяки його інтуїтивності та легкості в освоєнні. Він забезпечує простий спосіб створення інтерактивних інтерфейсів з мінімальними налаштуваннями. Приклади використання:  «Раніше я використовував React, але після знайомства з Vue я більше не хочу повертатися назад. Цей фреймворк дозволяє значно швидше і простіше працювати з фронтендом. Також його б я рекомендував для швидкого старту», — каже Максим. Переваги: Простота освоєння. Гнучкість для роботи над різними проєктами, від малих додатків до великих систем. Велика кількість інтеграцій та плагінів. Недоліки: Попри всі переваги, Vue.js менш поширений у великих корпоративних середовищах порівняно з React чи Angular. Це може вплинути на вибір компанії, якщо їхня екосистема вже налаштована на інші фреймворки. Vue.js має відносно менший набір корпоративних інструментів та підтримки, що може ускладнити інтеграцію у великих проєктах із специфічними вимогами. Перейти до репозиторія Опис: це потужний фреймворк для Vue.js, який забезпечує повний інструментарій для створення сучасних вебзастосунків. Він спрощує процес розробки завдяки вбудованим модулям, зокрема для SEO-оптимізації, серверного рендерингу та інтеграції з API. Чим він корисний:  дозволяє швидко створювати динамічні інтерфейси та вебзастосунки, зосереджуючи увагу на продуктивності та зручності для розробників. Особливо корисний у проєктах, де важлива SEO-оптимізація і серверний рендеринг (SSR), що робить його відмінним вибором для контентних і маркетингових сайтів. Приклади використання:  «Ми використовуємо Nuxt для побудови всього фронтенду. Він ідеально підходить для складних проєктів, адже дозволяє структурувати код і керувати модулями за допомогою готових рішень. Це дуже зручно та економить час при роботі над великими проєктами», — каже Максим. Переваги: Швидка інтеграція з Vue.js. Підтримка SSR (серверного рендерингу), що покращує SEO. Модульна архітектура з великою кількістю готових модулів (наприклад, для автентифікації або кешування). Вбудована підтримка маршрутизації, Vuex і автоматичної генерації сторінок. Недоліки: Nuxt.js може стати занадто складним для новачків у Vue.js, особливо через велику кількість налаштувань та модулів. Це може спричинити затримки в розробці для тих, хто тільки починає працювати з фреймворком. Підтримка більш складних функцій, таких як SSR (server-side rendering), може збільшити час компіляції та вимагати додаткового досвіду в налаштуванні серверних рішень. Перейти до репозиторія Опис:  це інструмент для керування безсерверною архітектурою, який дозволяє швидко та зручно деплоїти серверлесс-функції на різні хмарні платформи, такі як AWS Lambda, Google Cloud, Microsoft Azure тощо. Чим він корисний:  ідеальний для тих, хто хоче розробляти масштабовані серверлесс-застосунки без необхідності керувати інфраструктурою. Serverless значно спрощує деплой та управління серверлесс-функціями, дозволяючи зосередитися на коді та бізнес-логіці. Приклади використання:  «Ми використовуємо Serverless Framework для бекенду, оскільки він значно спрощує роботу з деплоєм AWS Lambda. Це зручно, особливо коли потрібно швидко впроваджувати зміни», — додає Макс. Переваги: Підтримка різних хмарних платформ (AWS, Azure, Google Cloud). Можливість легко масштабувати та деплоїти серверлесс-функції. Мінімізація витрат на інфраструктуру, оскільки оплата відбувається за використання. Недоліки: Вартість використання Serverless Framework може різко зрости через неправильне налаштування або недостатню оптимізацію функцій. Це може призвести до неефективного використання хмарних ресурсів. Висока залежність від постачальників хмарних сервісів, таких як AWS, Google Cloud і Azure. Якщо сервіс постачальника змінюється або виходить з ладу, це може створити непередбачувані ризики. Перейти до репозиторія Опис:  це опенсорс headless CMS, що дозволяє розробникам створювати гнучкі та кастомізовані API для управління контентом. Цей інструмент зручний як для малих, так і для великих проєктів. Чим він корисний:  дозволяє легко керувати контентом, створювати API та інтегрувати CMS із фронтендом, що робить його ідеальним вибором для проєктів, де потрібно гнучке керування контентом без обмежень. Приклади використання:  «Strapi дозволяє швидко створювати API і кастомізувати їх для проєктів різного рівня складності. Ми плануємо його використовувати для керування контентом у різних вебзастосунках, бо він дуже гнучкий. Цей репозиторій — мій особистий фаворит», — розповідає Макс. Переваги: Підтримка різних баз даних (PostgreSQL, MongoDB, MySQL тощо). Простий інтерфейс для адміністрування контенту. Легке налаштування кастомних API. Недоліки: Strapi, хоча й пропонує велику кастомізацію, може бути важким для масштабування на великих проєктах із великою кількістю користувачів та API. Продуктивність може страждати, якщо Strapi не оптимізовано для високого навантаження. Підтримка TypeScript все ще в розробці, що може бути суттєвою проблемою для команд, які покладаються на строгі типи в коді. Перейти до репозиторія Опис:  один із найпопулярніших стилістичних гайдів для написання JavaScript-коду, який допомагає підтримувати читабельність і організованість коду в команді. Чим він корисний:  забезпечує стандартизацію коду у великих командах, допомагаючи розробникам слідувати єдиним правилам написання коду, що знижує кількість помилок і підвищує продуктивність. Приклади використання:  «Це гайд ми використовуємо для підтримки єдності стилю коду у команді. Завдяки йому наш код стає чистим і легким для читання», — ділиться Максим. Переваги: Відмінна документація та чітко визначені правила стилю коду. Підтримка найкращих практик для роботи з JavaScript. Недоліки: Досить складний у впровадженні на вже існуючих проєктах з нерівномірним стилем коду. Велика кількість правок може призвести до збоїв у роботі проєкту або ускладнити його підтримку. Airbnb Styleguide не є універсальним рішенням для всіх проєктів, і його суворі вимоги можуть конфліктувати з уже встановленими правилами стилю в команді. Перейти до репозиторія Опис:  сучасний інструмент для збірки проєктів на базі Vue.js, React або інших фреймворків. Він забезпечує миттєвий запуск проєктів та швидке оновлення модулів під час розробки. Чим він корисний:  значно прискорює процес розробки завдяки швидкій збірці та миттєвому оновленню, що робить його чудовим вибором для розробників, які шукають альтернативу Webpack. Приклади використання:  «Ми використовуємо Vite для швидшої збірки наших Vue.js проєктів. Це значно економить час на великих проєктах», — зазначає Макс. Переваги: Миттєвий запуск і швидке оновлення. Простота у використанні, особливо для Vue.js та React. Легка інтеграція з TypeScript. Недоліки: Хоча Vite і швидкий для нових проєктів, на старих проєктах з великою кількістю залежностей інтеграція може бути проблематичною, особливо якщо використовуються специфічні плагіни або налаштування Webpack. Наразі для Vite доступно менше плагінів, ніж для Webpack, що може обмежити можливості кастомізації та розширення на великих проєктах. Перейти до репозиторія Опис:  сучасний ORM для роботи з базами даних, який надає зручний API для взаємодії з SQL базами даних. Він дозволяє зручно працювати з даними і знижує складність при написанні SQL-запитів. Чим корисний:  спрощує роботу з базами даних, зменшуючи кількість коду та забезпечуючи автоматичну синхронізацію моделей з базою даних. Він чудово підходить для швидкої розробки з фокусом на продуктивність. Приклади використання:  «Prisma значно спрощує роботу з базами даних, зменшуючи ручне написання SQL-запитів. Він надає простий інтерфейс для взаємодії з даними», — ділиться Максим. Переваги: Інтуїтивний API для роботи з базами даних. Автоматична генерація моделей на основі бази даних. Недоліки: Prisma обмежений у своїй підтримці деяких специфічних типів запитів SQL, що може бути проблемою для розробників, які працюють з дуже специфічними або складними базами даних. На великих проєктах з нестандартними вимогами до баз даних Prisma може не пропонувати достатньо гнучкості для кастомізації запитів та обробки даних. Складності конфігурації для роботи з serverless бекендом (для коректної роботи з serverless можуть знадобитися додаткові зусилля). Як обрати репозиторій?  «Раніше я міг додати будь-який репозиторій, не звертаючи увагу на баги, але тепер ставлюсь до вибору набагато ретельніше», — зауважує Максим. При виборі репозиторія він пропонує керуватися кількома ключовими критеріями: Офіційність джерела . Якщо мова йде про SDK до певного інструменту, важливо, щоби репозиторій був офіційним від розробника сервісу. Це гарантує актуальність та надійність коду. Наприклад, для роботи з Google Ads SDK важливо обирати саме офіційну версію. Кількість зірок на GitHub . Популярність репозиторія, відображена в кількості зірок, часто вказує на те, що більше людей вже використовували цей інструмент. Це може свідчити про виявлення та вирішення більшої кількості багів. Кількість тижневих завантажень в NPM . Частота завантажень у NPM (для Node.js) також є важливим індикатором активності й популярності репозиторія. Більше завантажень означає, що інструмент активно використовується в спільноті. Розмір залежностей та можливість оптимізації . На це треба звертати увагу, щоб уникнути перевантаження проєкту зайвим кодом.

OpenAI впровадила нову функцію пошуку в реальному часі в ChatGPT Вона відкриває  доступ до найсвіжішої інформації для платних користувачів і незабаром буде доступна безкоштовним користувачам. Раніше можливості моделі були обмежені на рівні знань до 2021-2023 років, але тепер з підтримкою Bing та інших пошукових технологій ChatGPT може надавати актуальну інформацію прямо в процесі розмови.  Під час попереднього тестування керівник пошукового проєкту ChatGPT, Адам Фрай, продемонстрував можливості нової функції, використовуючи приклади пошуку новин про акції Apple та ресторанів в Сан-Франциско. У цих випадках модель надавала інтерактивні графіки з інформацією про акції та карти з рекомендованими закладами, де користувач міг уточнювати деталі за допомогою подальших питань, наприклад, знаходячи «більш невимушені» ресторани.  Нова функція побудована на основі GPT-4o — спеціально налаштованої моделі GPT-4, яка об’єднує можливості Bing та власні пошукові алгоритми OpenAI. Оригінальна версія функції була протестована з 10 000 користувачів як прототип під назвою SearchGPT, що вперше став доступний у липні,   пише  видання The Verge.  Python став найпопулярнішою мовою на GitHub  Про це йдеться у звіті Octoverse 2024, який опублікувала  платформа. Це зростання пов'язане з активним використанням Python у розробці штучного інтелекту та машинного навчання. Збільшення кількості розробників, які працюють з генеративним ШІ, сприяло підвищенню популярності Python.  У звіті згадали ще декілька важливих тенденцій ринку:  Розширення спільноти розробників. Кількість девелоперів на GitHub досягла 100 мільйонів, що свідчить про глобальне зростання інтересу до програмування та співпраці в межах відкритого коду. Збільшення внесків у відкритий код. У 2024 році було створено понад 52 млн нових відкритих проєктів, а розробники здійснили понад 413 млн внесків.  Розвиток інфраструктури як коду (IaC). Темпи використання мова HashiCorp Configuration Language (HCL) зростали найшвидше цього року на GitHub, що говорить про підвищений інтерес до автоматизації розгортання та управління інфраструктурою. Meta представила NotebookLlama Це відкрита  побудована на базі моделей Llama альтернатива інструменту Google NotebookLM. Подібно до NotebookLM, NotebookLlama створює самарі розмов у стилі подкастів із завантажених текстових файлів. Хоча результат роботи NotebookLlama виглядає більш «механічним» порівняно з аналогом від Google, цей інструмент відкриває доступ до технологій, що лежать в основі таких продуктів, і надає розробникам гнучкість для його вдосконалення.  NotebookLlama базується на мовних моделях сімейства Llama, доступних онлайн, і цікаво, що його архітектура розроблена для роботи не лише з великими моделями, але й з найменшими з Llama. Це дозволяє використовувати інструмент на більш доступному обладнанні, що робить його зручнішим для широкого кола користувачів. ЄС оголосив про початок розслідування діяльності TEMU   Причина — побоювання, що китайська платформа електронної комерції платформа не лише продає нелегальні товари, але й використовує дизайн, що викликає залежність у користувачів. Згідно з повідомленнями Європейської комісії, існує підозра, що платформа не забезпечує належних заходів для попередження поширення заборонених товарів на ринку ЄС. До переліку потенційно нелегальних продуктів, що продаються на TEMU, належать лікарські засоби, іграшки та косметика. Попри те, що Temu періодично видаляє незаконні товари, вони швидко з'являються знову, що, на думку представників ЄС, свідчить про недостатню ефективність чинних механізмів контролю. Розслідування стало можливим завдяки нещодавно ухваленому європейському Закону про цифрові послуги (Digital Services Act), що встановлює суворі вимоги до захисту безпеки користувачів і дозволяє ЄС накладати штрафи до 6% від світового обороту компанії у разі порушення, повідомляє  видання WIRED. Представник TEMU в інтерв'ю виданню зазначив, що компанія інвестує у вдосконалення своєї системи дотримання вимог безпеки і планує повністю співпрацювати з регуляторами ЄС. Україна запускає «пісочницю» для стартапів, що працюють із ШІ та блокчейном  Це середовище  дозволить  компаніям тестувати свої продукти під контролем держави, отримуючи експертні консультації та рекомендації для розвитку. Цей інструмент розрахований на стартапи з різних галузей, включно з охороною здоров’я, аграрним сектором, біотехнологіями та обороною. Щоби взяти участь, стартапи подаватимуть заявки через сайт  Фонду розвитку інновацій. У разі відповідності вимогам, компанія проходить етап узгодження дослідницького плану, після чого продукт аналізують фахівці. Програма триватиме два роки, до кінця 2026 року, з перспективою стати постійним інструментом підтримки інновацій.  Раніше Міністерство цифрової трансформації презентувало дорожню карту з регулювання штучного інтелекту, яка допоможе українським компаніям підготуватися до ухвалення закону-аналога AI Act Європейського Союзу. Це сприятиме інтеграції України до європейського цифрового простору та підвищенню конкурентоспроможності українського бізнесу на глобальних ринках.

Стартап Wantent , який за допомогою нейромереж аналізує реакцію глядачів на відеоконтент, запустили 2019 року. Засновник та CEO Wantent Олексій Шалденко — доцент, кандидат технічних наук, викладає в Київському політехнічному інституті вже 10 років і називає себе академічною людиною. Ми поспілкувались із ним про технології, які застосовує компанія, клієнтів та кейси Wantent, а також про акселераційні програми, які можуть допомогти українському стартапу залучити кошти та партнерів. Wantent — платформа, що за допомогою нейромереж розпізнає і аналізує реакцію глядачів на відеоконтент. Вона працює на основі розроблених командою моделей глибинного навчання (deep learning). Під час запуску частину команди стартапа складали колишні студенти Олексія. Нині вони захистили дисертації і самі викладають — навколо стартапу утворилась наукова школа. Зараз в команді стартапу 15 фахівців. Серед них — розробники, ШІ-інженери, дизайнери, тестувальники, продажники. Нещодавно до Wantent доєдналася Head of Client Operations, що раніше працювала з Disney, Marvel та Paramount.  Wantent консультує виробників та провайдерів відеоконтенту — від рекламних роликів і трейлерів до серіалів і документальних фільмів. Стартап підбирає аудиторію (тобто глядачів) для тестування відеоконтенту (якщо в клієнтів немає власної), аналізує сприйняття роликів глядачами, а потім надає рекомендації з покращення контенту. Серед клієнтів — Publicis Groupe, 1+1 Media, «ПриватБанк», Starlight Media.  Як працює аналіз реакцій аудиторії на контент у Wantent Основні показники, які вимірює Wantent, — емоційне залучення, увага, емпатія глядачів до того, що відбувається на екрані. Моделі розпізнають 20 емоцій і чотири типи глядацької уваги. Також у проєкта є власна методологія оцінки довготривалого (понад одну хвилину — ред.) контенту: визначають, наприклад, характеристики персонажів, сюжетні лінії, аналізують діалоги, гумор, рівень агресії тощо. Всі дані, які використовуються для тренування моделей, валідують когнітивно-поведінкові психотерапевти та інші фахівці, — для цього у стартапа є окремий внутрішній застосунок.  Нині у фокусі Wantent — США (близько 90% клієнтів). Також вони працюють з Бельгією, Британією, Україною, Казахстаном, країнами Балтії, і виходять на ринки Франції і Польщі. Платформа має 7 локалізацій (англійська, українська, нідерландська, польська, казахська, латвійська, іспанська), а також іноземних партнерів, що, за словами фаундера, дозволяють залучити аудиторію для тестів контенту з будь-якої країни. Як зазначає фаундер, інші компанії у ніші аналізу відеоконтенту  — Realize, Affectiva, Pilotly, — лише дата-провайдери, що не аналізують дані з перегляду самостійно і не надають детальні рекомендації з його покращення.  Як Wantent працює з контентом для дітей і підлітків Стартап також аналізує контент для дітей у трьох вікових категоріях: 2-5, 4-6, 8-12 років. Як зазначає Олексій, класичні фокус-групи для дітей не працюють, тому робота побудована іншим чином. Спочатку батьки відповідають на запитання дослідників, потім діти переглядають контент, а далі можливий фоллоуап — додаткові запитання для батьків.  Для дітей у наймолодшій вікової групі важливі показники рівня агресії, адже занадто жорстокий контент може вплинути на поведінку дитини після перегляду. Діти віком 2-5 років не сприймають сарказму та іронії. У дорослому контенті, на відміну від дитячого, більший фокус на сюжетній лінії та побудові емоційного зв'язку з головними героями.  Через NDA Wantent не може розповідати про реалізовані кейси, але розкриває, що серед них є й соціальні проєкти для великих ринків. Зокрема, реалізована кампанія з соціальної  реклами в США. «Ми працювали з агенцією у Вашингтоні, з якою познайомились на конференції. Це була локальна кампанія, спрямована на допомогу підліткам Вашингтону, що постраждали від сексуалізованого насилля. В процесі роботи вдалося підвищити довіру до інформації та голосу оповідача, що дозволило творцям ролика внести корективи ще до запуску. », — розповідає Олексій.  Акселератори та інвестиції: шлях до зростання  Для Олексія і команди акселераційні програми — це отримання досвіду, пришвидшення розвитку і мінімізація помилок, а також елемент побудови довіри до компанії.  Wantent були учасниками Nest Bootcamp в 2020 році, після чого залучили  $450 000 інвестицій у seed-раунді від фонду QPDigital. Пізніше також брали участь у європейської акселерації STADIEM і у програмі Google for Startups . Цього року стартап став переможцем програми StartUp Academy від Genesis . Олексій визнає, це — одна з найкращих акселерацій, адже саме там вони отримали якісну менторську підтримку з боку стартапів, які на один-два раунди інвестування попереду. Перемога відображає, що наполеглива робота команди була помічена ззовні. Також першість на Pitch Day вплинула на переговорний процес із залучення раунду інвестицій. Окрім цього, дозволила планувати партнерство з Meta із розвитку Emotional Intelligence Engine для побудови емоційних портретів аудиторії, щоб оцінювати ефективність креативів.  Невдовзі Wantent закриє наступний раунд інвестицій. Компанія не розголошує їх обсяг, але гроші спрямують на запуск SaaS-платформи та залучення вже підписаних клієнтів. Також займатимуться розвитком Emotional Intelligence Engine. Нинішня мета компанії — досягти позначки у $90 000 MRR (monthly recurring revenue, регулярний щомісячний дохід) у першому кварталі 2025 року. Майбутній півот Зараз Wantent переходить зі сфери консалтингу в автоматизоване SaaS-рішення за підпискою, вартость якої складатиме від $1500 до $20 000. У компанії вже є клієнти, які готові використовувати сервіс. Такий перехід дасть стартапу можливість швидкого масштабування — його сервіс зможуть використовувати медіакомпанії, агенції, бренди, виробники контенту, а компанія надаватиме підтримку користувачам. Зараз Wantent залучає едвайзера, що допоможе їм ефективніше презентувати результати досліджень перед C-level компаній-клієнтів. SaaS-рішення вже провалідували зі спеціалістами великих агенцій та компаній ТікТок, Meta, Publicist, OMD, DEPT — проводили глибинні інтервʼю і тестування платформи. Синтетична аудиторія — ще одне надбання, над яким команда працюватиме ще понад рік, проте вже почала перші кроки. Синтетичні аудиторії дозволять не залучати реальних людей для фокус-груп, а надавати клієнтам предиктивну аналітику, враховуючи дані по переглядах і перформанс. Впровадження синтетичних аудиторій дозволить оптимізувати кости і пришвидшити всі процеси. Зараз стартап веде перемовини з компанією SKELAR щодо валідації і пропрацювання цієї розробки.

Чому дослідники в українських ЗВО не хочуть публікувати свій код? Як змотивувати айтівців викладати? Що бізнес робить та що ще може робити для підтримки української освіти і науки? Про це говорили на дискусійній панелі в межах науково-популярної та deep tech конференції INSCIENCE  представниця української продуктової IT-компанії Grammarly, екс-програміст Google, а також керівник ШІ-лабораторії в KSE.  High Bar Journal публікує найцікавіші тези з дискусії про виклики для технічної освіти в сучасній Україні. Про взаємодію бізнесу та навчальних закладів  Grammarly співпрацює з різними освітньо-науковими інститутами. Наприклад, компанія надає стипендії для студентів Факультету прикладних наук УКУ (Українського католицького університету — ред.), наші співробітники викладають на факультеті, керують дипломними роботами, беруть участь у рецензуванні магістерських дипломних робіт на щорічному симпозіумі тощо. Крім цього, спільно з УКУ ми організовуємо академічну конференцію з опрацювання української мови UNLP , куди запрошуємо всіх науковців публікувати свої роботи у галузі Natural Language Processing (обробки природної мови). Основна мета цього проєкту — сформувати дослідницьку спільноту у сфері українського NLP та популяризувати створення відкритих інструментів і ресурсів для обробки української мови.  Із КНУ імені Тараса Шевченка ми співпрацювали для покращення освітньої програми. Раніше на Кафедрі української мови та прикладної лінгвістики студенти вчилися програмувати лише з четвертого курсу — це надто пізно. Ми долучилися до покращення програми, а також проводили відкриті лекції для студентів та безплатну літню школу з комп’ютерної лінгвістики. Чимало учасників останньої згодом стали частиною команди Grammarly. Повертаючись до UNLP, варто сказати, що ми бачимо низький рівень подачі статей від науковців з державних ЗВО. На це є дві причини. По-перше, багато дослідників української мови все ще мають занадто низький рівень володіння англійською мовою, щоб якісно написати наукову статтю. По-друге, часто виникає питання відкритих даних. Наука — це про те, як ділитися знаннями, відкриттями. Це відкриті дані, відкритий код, відкриті моделі, — для того, щоби стимулювати розвиток інструментів і розвиток наборів даних. Проте багато дослідників української мови поки не готові відкрито публікувати код чи свої дані у вигляді корпусів. Це — велика проблема, яка гальмує розвиток науки. Освітні проєкти, за якими радить стежити Мар'яна Романишин Школи в УКУ. Університет щороку проводить сезонні школи на різні теми, що стосуються штучного інтелекту, наприклад, про комп'ютерний зір чи про опрацювання природної мови. Остання школа була присвячена генеративному штучному інтелекту. AI House — потужна спільнота. Випускають подкаст про штучний інтелект, постять новини, організовують хакатони та зустрічі наживо у Києві та Львові. Як заохотити «технарів» до викладання?  Мотивувати грішми людину, яка працює в IT, до викладання неможливо. Ми всі розуміємо, що в українській освіті немає такого фінансового стимулу, який є на вільному ринку. В KSE платять більше, ніж в державних ЗВО, але не настільки, щоб фахівець залишив свою роботу в IT і повністю сфокусувався на викладанні.    Тому в такій ситуації ми можемо лише знайти класних фахівців, які мають свою внутрішню мотивацію для викладання, і вона не в грошах. Це здебільшого люди, які розуміють цінність ділитись знаннями  — коли ти ділишся, ти сам отримуєш набагато більше . Що ми як університет можемо зробити зі свого боку? Створити максимально комфортні умови для викладання.  Мінімізувати бюрократичну роботу, яку викладачам треба робити, підтримувати і онбордити людей, які вперше виступають у ролі викладача (в KSE є система менторингу для таких викладачів), дати фахівцю спочатку можливість спробувати себе в якості асистента, а згодом вже викладача, щоб адаптація пройшла комфортно. Або навпаки — дати лектору у підтримку асистентів, які будуть розбиратися з «домашками», на які у лектора може не бути часу. Тому відповідь проста — не заохочувати, а створювати таку систему, в якій викладати буде цікаво і комфортно.  Освітні проєкти, за якими радить стежити Володимир Кулініч  У компанії Data Root Labs є декілька дуже якісних курсів з ШІ та машинного навчання. Вони безоплатні, досить складні, але після них одразу є базові вміння і навички в ШІ.  В KSE Lab є курси з ШІ для нетехнічних фахівців — ШІ для юристів та проєктних менеджерів, скоро запускатимемо «ШІ для підприємців», «ШІ для креаторів» та «ШІ для HR-фахівців».  Як бізнес підтримує українських вчених  Нині солідарність з Україною в міжнародному суспільстві досить висока. Багато приватних, державних, міжнародних фондів шукають можливості допомогти Україні. Наприклад, Simons Foundation один з найбільших приватних американських фондів, що підтримує дослідження в сфері математики та фундаментальних наук, ініціював програму підтримки українських вчених. Вони створили експертну раду, яка обирає вчених, що отримають гранти на свої проєкти. Втім, є умова: над своїми дослідженнями український вчений має працювати разом із іноземним колегою, який забезпечує відповідність результатів і методів, що використовуються, міжнародним стандартам.  Nova Ukraine — це наш благодійний фонд, що з початку повномасштабного вторгнення зібрав для України понад $100 млн. Однією з ніш, які ми для себе обрали, є сприяння україномовному книговиданню. Ми з'ясували, що в Україні бракує науково-популярної літератури українською для школярів, які хочуть читати про науку. Студенти вже в змозі читати англійською, а от для школярів майже нічого немає. Ми купуємо або отримуємо в дарунок права на англомовні книжки з математики, фізики, біології для читачів шкільного віку. Працюємо з партнерами, щоб їх перекласти та видати в Україні.  Кремнієва Долина — приклад для наслідування?  Кремнієва долина, вся динамічна та інноваційна атмосфера і культура того регіону, насправді розпочалася з мілітарних технологій, які стали розвиватися саме при університетах, зокрема в Стенфорді, ще до Другої світової війни.  До того, як стати осередком розвитку мілітарних технологій в США, Стенфордський університет в жодні топи не входив і відставав. Коли там почали проводити дослідження в галузі радіоелектронної боротьби і розвідки, поступово залучаючи все більше і більше коштів на це від держави, все змінилося. З того почалася нинішня Кремнієва долина — з військових технологій.  Другий важливий крок, який зробили в Долині, — надали можливість професорам університетів інтегрувати у свій бізнес і комерціалізувати розробки або дослідження, якими вони займаються в стінах університету. Найчастіше Стенфорд, наприклад, отримує в обмін на ці дослідження частку в компанії, яку професор створив або створить в майбутньому. Саме так виникла компанія Sun Microsystems, яка найбільш відома серед іншого тим, що створила технологію Java. Перші розробки Sun створили аспіранти Стенфорду, а згодом, коли вони принесли прибуток, університет мав від нього частку. Така ж історія повторилася з компанією Google та багатьма іншими. Я сподіваюсь, що Україна може піти тим самим шляхом і досягти того ж успіху. Мілітарні технології вже потрібні, одні вже реалізовані, інші — у процесі розробки.  Наступний крок, який, я сподіваюся, в країні буде зроблено, це дозвіл від університетів на комерціалізацію розробок і технологій.

Amazon планує другий багатомільярдний внесок в Anthropic, обговорюючи нові умови використання серверів Як стало відомо   виданню The Information, нова угода передбачає, що Anthropic частіше використовуватиме сервери Amazon із власними чипами Trainium, а не з чипами Nvidia , яким компанія наразі надає перевагу. Для Amazon ця зміна важлива, оскільки знижує потребу в дорогих Nvidia-чипах та просуває Trainium на ринку штучного інтелекту. Anthropic, у свою чергу, стикається з технічними викликами, адже програмне забезпечення для Trainium менш зріле, ніж Nvidia Cuda, і перехід може обмежити використання інших хмарних провайдерів. Окрім інвестиції, Amazon та Anthropic розглядають угоду про спільний дохід від продажу моделей Anthropic клієнтам AWS, таким як DoorDash і Goldman Sachs. Водночас Anthropic може отримати доступ до потужних серверів Amazon для розвитку своїх моделей, подібних до суперкомп'ютерних кластерів конкурентів, таких як xAI Ілона Маска. Microsoft впроваджує ШІ-чатбота для підтримки Xbox Microsoft запустила  нового ШІ-чатбота під назвою Support Virtual Agent для користувачів Xbox. Чатбот, який доступний для учасників програми Xbox Insiders у США, допомагає гравцям швидко вирішувати проблеми, пов'язані з консолями та іграми Xbox, надаючи відповіді на текстові та голосові запити. Якщо ШІ-агент не може відповісти, користувачі можуть автоматично перенаправитися до живого агента підтримки під час робочих годин.  Це нововведення є частиною загального вектору Microsoft щодо інтеграції штучного інтелекту в продукти та сервіси Xbox. Компанія також досліджує можливості ШІ для створення ігрового контенту та тестування програмного забезпечення, а також для генеративних ШІ-сценаріїв для NPC (неігрових персонажів), повідомляє  видання The Verge. Завдяки підтримці AI Microsoft прагне не лише спростити користувачам доступ до допомоги, але й зменшити навантаження на службу підтримки, оптимізуючи її роботу.  Перемога Трампа: хто з Big Tech у виграші, а хто під тиском Після перемоги Дональда Трампа на виборах фондовий ринок ожив, і акції технологічних гігантів відреагували по-різному. Аналітики Business Insider виділили  серед Big Tech як переможців, так і потенційних «жертв» нової політики Трампа, який у першій каденції вже вносив значні зміни в галузь.  Apple — серед компаній, чиї акції зросли найменше. Інвестори побоюються, що Трамп може запровадити нові китайські тарифи, які вдарять по виробництву iPhone, більшість яких випускається в Китаї.  Найкращий результат показала Tesla, оскільки CEO Ілон Маск активно підтримував Трампа на виборах. Хоча Трамп може скоротити державні дотації для електромобілів, Tesla вже досягла значної фінансової стабільності, що дає їй перевагу над іншими виробниками електрокарів, залежними від державної підтримки. Акції Google несподівано виросли, хоча Трамп і критикував компанію в минулому. Інвестори розраховують, що у другому терміні він може послабити антимонопольний тиск, що позитивно вплине на Google. Крім того, дочірня компанія Alphabet, Waymo, яка займається автономними авто, може отримати підтримку завдяки потенційному пом'якшенню регулювання у сфері безпілотного транспорту. Amazon може постраждати від тарифів на китайські товари, які складають значну частку продажів на платформі, що створить тиск на маржу компанії. Натомість Microsoft виглядає найбільш стійкою серед Big Tech, оскільки найменш залежить від зовнішньої політики, що дозволяє їй продовжувати стабільний розвиток. Україна розпочала пілотний проєкт із тестування 5G у трьох містах 1 листопада Міністр цифрової трансформації Михайло Федоров   оголосив  про запуск пілотного проєкту з тестування 5G-зв’язку в трьох містах України. Проєкт триватиме два роки у два етапи й має на меті перевірити сумісність 5G з військовими мережами. Перше тестування 5G розпочнеться у Львові, після чого проєкт масштабують на Київ та Одесу. Пілотний запуск передбачає лише кілька базових станцій у кожному місті, тож технологія поки що не стане загальнодоступною. Розмови про запуск 5G в Україні тривають із 2018 року, але реальне впровадження ускладнюють воєнні дії та потреба в узгодженні частот із військовими. Виділені частоти 700 МГц і 3400-3800 МГц потребують додаткових технічних рішень для безпечного використання. Операторам доведеться викупити або отримати ці частоти, а також забезпечити перехід користувачів на новий стандарт. Хоча 5G відкриває нові можливості для промислової автоматизації та «розумних» міст, його переваги для звичайних користувачів наразі неочевидні. Більшість базових інтернет-потреб покриває 4G, а максимальна швидкість 5G досягається тільки в лабораторних умовах. За словами Федорова, повноцінний запуск 5G в Україні можливий до 2030 року, і зосередиться він передусім на великих містах із високим попитом. Microsoft проведе Xbox Game Camp в Україні для підтримки місцевих розробників ігор Івент пройде   12 грудня 2024 року як безкоштовна онлайн-подія, орієнтована на українських розробників ігор . В межах Xbox Game Camp учасники зможуть долучитися до практичних воркшопів, лекцій, панельних дискусій та індивідуальних сесій із наставниками від провідних ігрових студій, таких як Mojang (Minecraft), Machine Games, Blizzard та інших. Крім Microsoft, подію підтримують Міністерство цифрової трансформації України та IT-компанія EPAM. Xbox Game Camp має на меті надати розробникам нові знання та інструменти, що допоможуть їм ефективніше працювати над своїми проєктами та виходити на глобальний ринок. Із врахуванням участі відомих українських студій, як 4A Games (творці Metro) та Room 8, захід привертає увагу до високого рівня українських талантів, які вже співпрацюють з глобальними брендами, зокрема Metro, Call of Duty та іншими популярними франшизами. Реєстрація   на Xbox Game Camp Ukraine відкрита до 22 листопада, і організатори закликають усіх зацікавлених скористатися цією можливістю для особистого та професійного розвитку.

Genesis представила онлайн-платформу INTRO — продукт для студентів і випускників українських закладів вищої освіти, які прагнуть отримати перший професійний досвід у продуктових IT-компаніях. INTRO реалізована освітнім департаментом Genesis. Мета платформи — спростити знайомство молоді з технологічним бізнесом та допомогти новачкам зробити перші карʼєрні кроки.  «INTRO by Genesis відкриває студентам і випускникам новий формат співпраці з продуктовими ІТ-компаніями. Ми прагнемо, щоби молодь отримала глибоке розуміння очікувань ринку, необхідні знання та фундамент для майбутніх успіхів, а компанії — молодих спеціалістів, підготовлених до реальних викликів», — коментує Олексій Ніщик, Education Operations Director. Які можливості пропонує INTRO  Створити анкету-резюме. У зручному форматі конструктора та відеовізитівок студенти зможуть описати свої переваги, навіть за відсутності комерційного досвіду. Зокрема, волонтерські проєкти, міжнародні тестування та інші досягнення. Освітньо-карʼєрні матеріали за доменами. На платформі є мапи професійних траєкторій в продуктовому ІТ-бізнесі. Кожна з них містить перелік необхідних базових навичок, які можна опанувати завдяки зібраному на платформі контенту. Зараз вже доступні матеріали в доменах маркетингу, дизайну, аналітики, продакт-менеджменту тощо. Профайли десятків продуктових ІТ-компаній. Користувачам буде легко знайти інформацію про потенційних роботодавців і визначитися, з якими командами вони хочуть працювати. Протягом року набір функцій платформи розшириться. Користувачі зможуть формувати індивідуальні профорієнтаційні траєкторії, проходити онлайн-стажування від компаній екосистеми Genesis та компаній-партнерів, отримувати сповіщення про релевантні позиції, календар лекцій і воркшопів, персоналізовані пропозиції від компаній тощо. «На створення платформи нас наштовхнули інсайти, отримані під час системної роботи з молоддю, компаніями та кар’єрними центрами університетів. INTRO реалізує потреби всіх цих стейкхолдерів та стане зручним каналом комунікації між ними», — коментує Олександра Тиркалова, University Partnerships Lead у Genesis. INTRO by Genesis офіційно представили під час Open Day for Students на початку листопада. Перші 150 користувачів вже долучилися до платформи.  Доступ до INTRO  безоплатний та усі матеріали доступні за умови реєстрації. Дізнатися детальніше й ознайомитися з платформою можна за посиланням .

Історія індустрії IT і технологій налічує не так багато років, проте культових історій, що стали основою для книжок, серіалів та кінофільмів, зібралось достатньо. Ми склали список найцікавіших стрічок, знятих за мотивами реальних подій у світі технологій. Хакери, програмісти, стартапи, інвестори, Стів Джобс і Білл Гейтс — обирайте картину та поринайте у світ IT. «Пірати Кремнієвої долини» (1999)  Рейтинг IMDb: 7.2 Одна з перших стрічок про становлення ери персональних комп’ютерів. Історія гігантів індустрії Apple і Microsoft та протистояння їх засновників — Стіва Джобса та Білла Гейтса. Ми дивимось на них очима їх найближчих друзів та колег: Стіва Возняка та Стіва Балмера. Протягом фільму спостерігаємо за легендарними постатями з часів їх студентства до кінця 80-х років, коли було створено перший Macintosh.  «Злом» (2000)  Рейтинг IMDb: 6.2 Кевін Мітнік — знакова фігура у світі кібербезпеки. Один з найвідоміших хакерів та фахівців з інформаційної безпеки, що в середині 90-х років був заарештований за проведення низки масштабних хакерських атак в США. Серед жертв шахрайства Мітніка — американський фахівець із кібербезпеки Цутому Шимамура, який сприяв арешту Кевіна та згодом випустив книгу про цей кейс.  Книга Шимамури й стала основою для кримінального трилера «Злом», який розповідає історію протистояння двох геніїв кіберпростору.  «Соціальна мережа» (2010)  Рейтинг IMDb: 7.8 Стрічка, яку Квентін Тарантіно назвав  найкращим фільмом 2010-х років. Нині, коли Meta — один з провідних гравців світової tech індустрії, ще цікавіше спостерігати за тим, як все починалось. Історія про те, як два студенти Гарварду створили університетську соціальну мережу і не знали, що вона стане найпопулярнішою у світі. Сценарій картини базується на книзі Бена Мезріча «Мільярдери мимоволі» про Марка Цукерберга та його друга і бізнес-партнера Едуардо Саверіна.  «Стів Джобс» (2015)  Рейтинг IMDb: 7.2 Один з найпопулярніших байопіків про засновника Apple, який вийшов уже після смерті Стіва Джобса. Створення Macintosh, розробка iMac, перипетії робочого та приватного життя Джобса, він сам як особистість — непересічна, мінлива, неоднозначна, видатна. Картина зібрала декілька статуеток «Золотий глобус» та «Оскар» у 2016 році.  «Вибула» (2022) Рейтинг IMDb: 7.5 Історія Елізабет Голмс та її псевдобізнесу Theranos — одна з найгучніших афер епохи стартапів. Дівчина, яка стала наймолодшою мільярдеркою в історії завдяки своєму таланту вводити в оману велику кількість людей, в тому числі й знаних інвесторів. Журналістка Ребека Джарвіс запустила подкаст про історію злету і падіння Theranos, в якому розмовляла з колишніми співробітниками компанії, пацієнтами та інвесторами. Базуючись на випусках подкасту, стримінг Hulu екранізував історію Елізабет Голмс та її стартапу у 10 епізодах.  «Плейліст» (2022)  Рейтинг IMDb: 7.4 Історія створення музичного стримінга Spotify, розказана шістьма її учасниками. Майбутній засновник шведського IT-гіганта Даніель Ек хоче працювати в Google, і отримує відмову. Натомість Даніель вирішує створити свою компанію, не гіршу за Google. Про це — в першому епізоді серіалу. А далі ми бачимо історію Spotify очима головного програміста компанії, юристки, інвестора, топменеджера Sony та виконавиці, що розміщує свої треки на Spotify. Усі сторони IT-бізнесу, підводні камені індустрії, з якими стикаються засновники, конкуренти та користувачі — все це є у «Плейлісті».  «На низькому старті. Битва за Uber» (2022)  Рейтинг IMDb: 7.3 В центрі сюжету стрічки — енергійний та харизматичний засновник Uber Тревіс Каланик, який стикається зі шквалом обвинувачень у шахрайстві та крадіжках ідей, а пізніше — з більш серйозними проблемами на посаді СЕО. Каланик взагалі відомий в індустрії своїм жорстким стилем управління та характером, який влучно зміг передати Джозеф Гордон-Левіт своєю грою у картині.  «Стартап, що зазнав краху» (2022)  Рейтинг IMDb: 7.3 Минуло лише декілька років після скандального викриття шахрайства Елізабет Голмс, як на світовій стартап-арені з’явилися нові антигерої — співзасновники мережі коворкінгів WeWork Адам та Ребека Неймани. Серіал від Apple TV про історію неуспіху перспективної начебто компанії та її химерного засновника, який назбирав боргів на сотні мільйонів доларів та «провалив» IPO. У 2021 році компанія все ж вийшла на біржу, але Адама Неймана відсторонили від управління компанією.    BlackBerry (2023)  Рейтинг IMDb: 7.4 В кінці 90-х років декілька канадських розробників створили перший смартфон — гаджет BlackBerry, який до появи телефонів від Apple був лідером продажів. Як та навіщо розробили BlackBerry? Чому його зірка так швидко «закотилася»? Спойлер – не лише через iPhone. Канадська стрічка-докудрама висвітлює відповіді на ці питання.  «RUIN: гроші, егоїзм та обман у FTX» (2023)  Рейтинг IMDb: 6.4 Технологічний світ багатий на гучні афери. Історія криптобіржі FTX – саме з таких. До того, ж вона розгортається і донині. Каліфорнієць Сем Бенкман-Фрід, випускник MIT, заснував FTX у 2019 році. Стартап швидко злетів, а Сем опинився у списку мільярдерів від Forbes. За три роки компанія була визнана банкрутом, а засновника заарештували за організацію схем з обману інвесторів. Bloomberg зняв документальну стрічку про Бенкмана-Фріда та причини краху біржі FTX.

Як проходить співбесіда з дата-інженерами, та які питання їм ставлять? Цього разу досвідом проведення інтервʼю ділиться Solidgate , партнерська компанія Genesis. Це фінтех-екосистема, яка надає онлайн-бізнесам можливість приймати платежі по всьому світу. Місія компанії — зробити так, щоб онлайн-підприємці могли будувати мільярдні компанії завдяки швидкому виходу на міжнародний ринок. Тетяна Лелюх, Data Engineering Lead в Solidgate, розповіла, як проходять співбесіди дата-інженерів у команду компанії. Вона поділилася головними компетенціями, які шукають у кандидатах, як проводити інтервʼю, щоби у людей не було враження іспиту, як адаптувати запитання під досвід, та чому краще вивчати юзкейси ніж визначення термінів, готуючись до співбесіди. У кінці статті бонус — підбірка актуальних вакансій у технічну команду Solidgate. >  Як проходять співбесіди з дата-інженерами >  Компетенції для Junior та Middle Data Engineer >  Питання для дата-інженера (Junior / Middle) >  Софт-скіли дата-інженера >  Поради кандидатам Як проходять співбесіди з дата-інженерами Процес найму в Solidgate складається із чотирьох етапів. Перший з них — це спілкування із рекрутером, який відбирає кандидатів за релевантністю хард- та софт-скілів, а також відсутністю red flags.  Другий етап — технічна співбесіда, де ми обговорюємо технічні питання, досвід та професійний шлях кандидата. Коли людина ділиться, чому прийняла те чи інше рішення, як обирала попередні компанії тощо, це дає змогу скласти певний портрет, зрозуміти її рівень мотивації та відповідальності. Водночас фокус цього етапу — технічний. Я намагаюся вести розмову у форматі діалогу, щоби це не було схоже на іспит чи опитування, і людина себе почувала комфортно. На початку інтерв'ю попереджаю, що можу перебивати та зупиняти, щоби глибше розкрити досвід кандидата, та пропоную також зупиняти мене і ставити додаткові питання, якщо не вистачає контексту.  Ми маємо підбірку базових питань, які стосуються необхідних компетенцій. Водночас співбесіда зазвичай проходить індивідуально, і скоуп запитань формується під професійний шлях людини.  Третій етап — тестове завдання. Ми намагаємося скоротити його до мінімуму, щоби виконання не займало більше чотирьох-шести годин. Для джуніорів воно більш розширене та загальне, для мідлів — менше за розміром, але технічно складніше. Четвертий етап — співбесіда з C-Level або технічним менеджментом, який перевіряє людину на відповідність Culture Fit — наскільки кандидат відповідає процесам та культурі компанії. Компетенції для Junior та Middle Data Engineer Загалом компетенції й відповідно теми для запитань на технічній співбесіді однакові для всіх ґрейдів. Різниця в тому, що для джуніор-кандидатів вони більш загальні. У мідлів ми перевіряємо глибину знань, тому ставимо питання, які не можна легко нагуглити, або які стосуються їхнього особистого досвіду. Наприклад, якщо ми говоримо про Python, то у джуна я питаю, які йому відомі методи в певній бібліотеці, щоби зрозуміти, чи людина працювала з бібліотекою вдумливо чи просто користувалася шаблонними рішеннями з гугла. У мідла я спитаю власну думку про цю мову: що подобається, які бачить плюси і мінуси тощо? Загалом співбесіда охоплює такі теми.  Бази даних У цьому розділі ми проходимося по загальних питаннях, а також ставлю додаткові точкові питання з досвіду кандидата. Наприклад, якщо в резюме вказано, що людина працювала зі Snowflake, у джуна я можу уточнити, як у цьому інструменті оптимізувати певний запит. Мідла можу попросити пояснити архітектурні особливості Snowflake, спитати, як в цьому DWH реалізований паралелізм, які стратегії скейлінгу можливі. Часом зустрічаються мідли, які не знають бази, тому зазвичай, ми починаємо із декількох «джунівських» запитань, наприклад, «Що таке OLAP і OLTP бази, і в чому їхні відмінності». І якщо людина на це питання не відповідає, то далі в глибину копати зазвичай немає сенсу.  Data-pipelines (ETL, ELT процеси) У цьому розділі ми обговорюємо концепцію та архітектурні підходи data pipelines, а також процеси ETL/ELT. Він містить декілька відкритих питань, тому я пропоную кандидатам подумати, перш ніж дати відповідь.  Загалом усіх інженерів, незалежно від грейду, я прошу ставити уточнюючі питання, якщо кандидат не знає відповіді. Перш за все, мене цікавлять не люди, які мають енциклопедичні знання, а ті, хто можуть логічно мислити, маючи певний набір інформації. Було чимало кейсів, коли кандидат зрештою знаходив, хоч і неточну, але дуже близьку до істини відповідь. З такими людьми класно працювати. Airflow У дата-інженерії існує чимало різних оркестраторів, але ми в Solidgate працюємо з Airflow, і робимо це на досить просунутому рівні. У нас в команді навіть є люди, які контрибʼютять у цей продукт. Відповідно, ми шукаємо людей із сильною експертизою в цьому інструменті. Загалом ми проходимося по загальних концепціях, притаманних Airflow, і переходимо до більш глибоких запитань, наприклад, як моніторити метрики в інструменті. На це питання мало хто відповідає, але воно дає зрозуміти, наскільки фундаментальні знання має людина: це простий користувач, який здатний запустити даги, чи людина, яка задумується про відмовостійкість системи. Тут також працює підхід «давайте подумаємо». Трансформація даних Зазвичай запитую кандидатів, які види трансформацій вони можуть назвати, і як вони реалізують їх з допомогою різних інструментів. Це питання про рефлексію, і показує, наскільки людина може класифікувати якісь загальні знання, знаходити паттерни. І для інженера, як на мене, це важлива характеристика. Валідація даних і моніторинг системи Вважаю, що дані, які не пройшли валідацію, не несуть жодної цінності. В дата-інженерії є великий блок роботи, який називається Data Quality. Оскільки Solidgate — FinTech компанія, то якість даних для нас є пріоритетом. Тому блок про валідацію даних також є важливим для мене. Запитую, з якими інструментами кандидату доводилося працювати, які тести він вважає за потрібне налаштовувати, як можна класифікувати валідацію даних. Від джуніора очікую базових знань інструментів та обізнаності, що дані взагалі треба валідувати. У розмові з мідлом, хотілося б почути певні кейси з попередніх проєктів. Коли людину з досвідом питаєш, як вона проводила валідацію і моніторинг даних, а вона відповідає «ніяк», це завжди сумно.  Python Цей блок питань скоріше для джунів. Вважаю, що Python – це просто інструмент, і якщо кандидат добре розуміється у концептах дата-інженерії, вміє писати юніт-тести, то запитувати в нього щось з Python — це втрата часу. Питання для дата-інженера (Junior / Middle) Нижче перелік базових питань для дата-інженерів ґрейдів джуніор та мідл. Вони розташовані у порядку зростання складності та розділені на блоки, які відображають потрібні компетенції. Деякі питання зі списку можемо поставити і джуну і мідлу, проте очікувана глибина відповіді буде різною. Загальні знання про бази даних 1. Як ви розумієте поняття «транзакція»? 2. Яка відмінність між OLTP i OLAP базою? 3. Які види баз даних ви знаєте? Назвіть принципи поділу. 4. Які архітектурні особливості цих з баз даних?  5. У чому різниця між реляційними та нереляційними базами даних? 6. Які основні відмінності між SQL та NoSQL базами даних? 7. Що таке база даних типу граф? В яких випадках їх доцільно використовувати? 8. Наведіть приклади рівнів ізоляції БД. 9. Як ви розумієте нормалізований вид даних? 10. Розкажіть про архітектуру тієї DWH, з якою ви працювали? 11. Як ви будете пришвидшувати повільний запит (з точки зору написання запиту)? 12. Як пришвидшити читання з таблиці (на прикладі тієї DWH, з якою ви працювали)? 13. Що таке deadlock? Що з ним робити? 14. Переваги та недоліки реляційної і документоорієнтованої БД? 15. Навіщо потрібен індекс? Які проблеми він створює? Data pipelines, ELT/ETL 16. Які переваги та недоліки підходів ELT та ETL? 17. У чому відмінність ETL від data pipeline? 18. Наведіть приклади побудови декількох архітектур data pipelines? 19. Коли та в якому випадку ви б застосували ELT, а коли ETL? 20. Як можна відстежувати зміни у таблиці реляційної бази (щоб опрацювати їх)? 21. За якими принципами ви будете обирати інструменти для побудови data pipelines? 22. Що ви знаєте про стрімінгову передачу даних? 23. Розкажіть про Zero-ETL concept? Трансформація даних 24. Які б ви могли виділити види трансформацій даних? 25. Вам доступні наступні інструменти: Airflow, cloud storage, DWH. Як би ви реалізували трансформації? Які переваги має такий спосіб порівняно з іншими? 26. Як ви зазвичай організовуєте процес екстракції даних з різних джерел? 27. Які методи очищення даних ви використовуєте на етапі трансформації? 28. Як ви виправляєте проблеми якості даних? 29. Що таке нормалізація даних і коли її варто застосовувати? 30. Як здійснюється агрегація даних, в яких випадках вона потрібна? 31. Які є основні стратегії обробки дублюючих записів? 32. Який інструмент для трансформації даних ви вважаєте найкращим і чому? 33. Як можна оптимізувати процес трансформації великих обсягів даних? 34. Що таке індексація і як вона впливає на швидкість трансформацій? 35. Які інструменти ви використовуєте для моніторингу процесів трансформації? 36. Які є основні виклики при роботі з трансформаціями даних у реальному часі і як їх подолати? Airflow 37. Які оператори ви використовували у роботі? 38. Уявіть ситуацію, коли у вас всі задачі зависли в статусі «queued» і не беруться до виконання. Про що це свідчить? Що ви будете робити? 39. Опишіть, для чого можна використовувати XComm, а для яких Variables? 40. Розкажіть про архітектуру Airflow, його концепти? 41. Що таке пули в Apache Airflow? 42. Як відстежувати аномальне виконання дагу? 43. Яка сутність відповідає за найменшу одиницю роботи? Які сценарії застосування бачите? 44. Як можна моніторити навантаження інстанса Airflow, щоб уникнути його падінь? Як можна знімати метрики? 45. Які юзкейси з використання різних типів executors ви можете описати? 46. Які аналоги окрестраторів ви знаєте? Quality & observability 47. Які рішення, інструменти допомагають в задачі data quality? 48. З якими проблемами в data pipelines ви зіштовхувалися і як їх вирішували? 49. Спробуйте класифікувати види валідації даних. 50. Наведіть приклад інтеграційного (функціонального) тесту в DE? 51. Розкажіть про свій досвід модульного тестування? Python 52. Як Python працює з памʼяттю? 53. Що ви знаєте про Pattern Matching? 54. Навіщо потрібен декоратор? Як його застосовувати? 55. Як реалізувати функцію зі змінною кількістю аргументів? 56. Які проблеми/мінуси Pandas ви можете назвати? Які знаєте альтернативи? 57. Розкажіть про multi-threading і multi-processing. 58. Чому ви обрали для себе Python? Які переваги має Python для DE порівняно з іншими мовами? Також перспективним кандидатам рівня Middle можу дати декілька практичних завдань:  59. Задаю умови функціонування системи (кількість репортів, ліміти, частота викладки), в межах яких інженер має запропонувати своє технічне рішення доставки даних для такої системи. Під цю задачу є заготовлені блок-схеми для кращого розуміння умов, а також навіть приклади коду, які пропоную змінити.  60. Надаю вхідні дані по запиту і пропоную оптимізувати його в різних типах баз даних.  61. Надаю вхідні дані по системі і проблему: наприклад, в певний момент часу  ви починаєте отримувати помилку. Якими будуть ваші дії?  Зазвичай подібні питання також підбираються індивідуально і корелюються із досвідом кандидата.  Софт-скіли дата-інженера На технічному інтервʼю немає спеціальних питань, щоби оцінити софт-скіли, — скоріше ми робимо висновки з того, що кандидат розповідає про свій професійний шлях та досвід. Найбільше ми цінуємо такі якості:  Амбітність — така людина бере відповідальність за своє життя, а не пливе за течією. Може пояснити, чому вона прийняла те чи інше рішення. Вміння глибоко копати  — зазвичай протягом інтервʼю питаю про проблеми, що виникали на попередній роботі, та уточнюю, як кандидат їх вирішував, чому вони зʼявилися, як ще можна було їх вирішити тощо. У нас у команді працює підхід: якщо людина не знає причини виникнення проблеми, значить вона в ній не розібралася і не може стверджувати, що проблема вирішена.  Командний гравець  — такий кандидат вміє взаємодіяти з різними командами, готовий менторити інших, відкритий до питань, обговорень і пропозицій. Відповідальність  — робота з даними досить кропітка, і в ній можна легко помилитися. Тому важливо, щоби кандидат був відповідальним та правильно підходив до процесу валідації даних.  Мотивація  — є люди, яких потрібно весь час мотивувати зовні: направляти, підказувати. Але для нас важливий саме внутрішній стимул людини робити систему кращою. Саме такі спеціалісти потім стають видатними інженерами.  Поради кандидатам  1. Бути чесним. Якщо людина не знає відповіді та відкрито про це говорить, — це не погано. Гірше, якщо вона не готова разом зі мною подумати над цим питанням і отримувати нові знання загалом. Нечесність на співбесіді завжди відчувається. 2. Почитати документацію. Якщо у кандидата в резюме зазначений певний інструмент, він має бути готовим відповісти на певну кількість технічних запитань. Тому, якщо цей досвід був давно, варто перечитати документацію та освіжити знання — як це працює, які плюси, мінуси цього інструменту є.  3. Вчити юзкейси замість визначень. Часто у підбірках питань для співбесід є пункти на кшталт «що таке ACID», «що таке база даних». Проте в Solidgate ніколи не ставлять подібних питань. Я скоріше спитаю «як досягається літера А в абревіатурі ACID». Краще занурюватися в глибину, ніж питати поверхневі визначення. Хоча ця порада релевантна саме для нашої компанії, і вимоги бувають різними.

Як проходить співбесіда з продакт-дизайнерами та які питання їм ставлять? Цього разу досвідом проведення інтервʼю ділиться Headway , партнерська компанія Genesis. Це українська EdTech компанія, яка створює продукти з мікронавчання, що допомагають розвиватися мільйонам користувачів у світі.    Андрій Ференс, Product Design Manager у Headway, розповів, як проводять співбесіди продакт-дизайнерів у команду, яких кандидатів шукає компанія, як виглядає тестове завдання, за яким перевіряють хард-скіли, а також чому на технічному інтервʼю фокусуються на софт-скілах. Також Андрій поділився підбіркою поширених питань, які можуть зустрітися продакт-дизайнерам на співбесідах. У кінці статті бонус — підбірка актуальних вакансій у команду Headway. >  Як проходить найм продакт-дизайнера >  Тестове завдання >  Співбесіда з продакт-дизайнером >  Red flags >  Питання на співбесіду з продакт-дизайнером Як проходить найм продакт-дизайнера  Хайринг-процес в Headway починається зі скринінгу, де відбувається перше знайомство, і рекрутер запитує про загальний досвід, мотивацію та очікування кандидата. Наступним етапом є тестове завдання, після якого йде співбесіда.  Загалом співбесіди у різних продуктових компаніях можуть суттєво відрізнятися. У кожної команди свої методи та критерії відбору талантів, тому питання також можуть бути дуже різними. Специфіка найму Headway полягає в тому, що усі хард-скіли ми перевіряємо під час другого етапу, а на інтервʼю фокусуємося скоріше на софт-скілах. Ще одна особливість компанії — відсутність чітких ґрейдів. Зазвичай ми шукаємо в команду не спеціалістів за конкретними рівнями (junior, middle чи senior), а просто людину, чиї навички та досвід найкраще підійдуть під задачі цієї позиції.  Headway працює на американський ринок, тому англійська мова є однією з основних вимог. ЇЇ знання ми перевіряємо вже на співбесіді — просто якийсь час спілкуємось цією мовою.  У нас немає фіксованого переліку питань, адже на нашу думку задавати їх  один за одним по списку усім кандидатам — погана ідея. Важливо, щоби кожне запитання мало мету, допомагало зрозуміти людину, її сильні й слабкі сторони. Та найголовніше — чи вмотивована вона стати частиною саме вашої команди, чи комфортно буде працювати з нею. Тестове завдання Цей етап складається з одного завдання, яке змінюється залежно від вакансії й зазвичай максимально наближений до скоупу обовʼязків, які людина виконуватиме у цій ролі. Ми описуємо проблему користувача, а також надаємо кількісні дані та увесь контекст. Важливо, щоби у кандидата залишався простір для власного дослідження у продуктовому дизайні. Так він зможе пройти весь дизайн-процес від розуміння проблеми, знаходження причин до рішення. Кандидатам варто не боятися ставити уточнюючі питання, — ми завжди до цього відкриті, і це те, що покращить результат тестового завдання.  Приклад тестового завдання: Проблема : на думку користувачів, контент із самарі складно застосовувати в житті. Потрібно знайти спосіб підсилити навчальний процес та сприяти глибшому усвідомленню матеріалу самарі. Завдання : запропонуй декілька гіпотез вирішення проблеми. Сфокусуйcя на одній з них та розроби дизайн-рішення. Воно має включати елементи інтерактивності та гейміфікації.  Продуктові метрики: збільшення кількості активних користувачів протягом місяця. Контекст :  70% користувачів слухають саммарі; 20% користувачів читають саммарі; 10% користувачів слухають та читають водночас. Що ми очікуємо: посилання на файл у Figma; уважність до деталей, зрозумілу подачу та лаконічний опис рішень; смачний та міцний інтерфейс, узгоджений з візуальним стилем продукту. Варто використовувати скриншоти застосунку для наявного функціоналу, щоб уникнути зайвої роботи; готовність макетів до передачі розробникам (є опис доданої логіки, покриті користувацькі сценарії, враховані обмеження мобільної розробки). Виконання тестового завдання дає нам можливість провалідувати важливі для цієї спеціальності хард-скіли. Зокрема ми звертаємо увагу, як кандидат розуміє проблеми користувача, чи використовує дослідницькі методи, де знаходить підтвердження, як організований дизайн-процес. Важливо, щоби кандидат розумів, що ми створюємо якісний інтерфейс не просто так, а щоби закрити потребу користувача.  Якщо людина переходить на наступний етап, це означає, що у нас немає сумнівів у її хард-скілах. Під час інтервʼю ми даємо зворотний звʼязок щодо завдання. Якщо ми розуміємо, що наразі ми не готові зробити офер цій людині, то даємо письмовий фідбек, пояснюючи причини. Підписуйтеся на розсилку  від High Bar Journal, аби щомісяця одержувати найцікавіші тексти та актуальні вакансії. Співбесіда з продакт-дизайнером У першу чергу ми звертаємо увагу на те, чи буде комфортно команді працювати з цією людиною, чи вміє вона давати та отримувати зворотний зв'язок, як вона оцінює свою роботу, наскільки готова брати відповідальність. Якщо кандидат має хард-скіли слабші, ніж очікується, їх завжди можна підтягнути, і ми готові його навчати. Проте нам украй важливо, щоби людина мала схожий майндсет, була готова працювати над собою та швидко вчитися. Також важливо, щоби людина розуміла, що дизайн — це про вирішення користувацької проблеми. І його першочергове завдання — впливати на досвід, який отримує користувач. Зазвичай під час співбесіди ми спілкуємося на такі теми: Загальне розуміння дизайну та дизайн-процесу.  Важливо вирівнятися на базовому формулюванні й розумінні того, що для кожного з вас є дизайн, зрозуміти, чи є в кандидата жага до цієї роботи.  Команда . У цьому блоці запитань ми намагаємось визначитись, чи готовий кандидат працювати в кросфункціональній команді, комунікувати з менеджером та колегами з інших відділів. Ми намагаємося модерувати різні робочі ситуації, щоби зрозуміти, як кандидат буде поводитися у різних обставинах.   Фідбек . Нам важливо зрозуміти, чи вміє людина працювати зі зворотним звʼязком: коректно надавати його чи сприймати. Ми також звертаємо увагу на реакцію кандидата, коли даємо фідбек на тестове завдання.  Рефлексія . Чи вміє людина аналізувати свій попередній досвід, чи усвідомлює свої сильні та слабкі сторони, чи вміє виносити уроки з проблемних ситуацій.  Red flags Найбільшим red flag для мене є байдужість. Вірю, що хороший дизайнер не може бути байдужою людиною — як в житті, так і в роботі. Він завжди має високу планку якості, помічає усі недоліки та говорить про це. Наше завдання — створювати й безперервно покращувати продукт. Прийняття фідбеку як критики, а не точки зростання. Зворотний звʼязок — цінна інформація, яка допомагає людям ставати кращими, тому важливо бути відкритим до неї.  Неприйняття альтернативної думки. Чудово, коли людина відстоює свої ідеї та вболіває за них. Проте варто дотримуватися здорового балансу, адекватно сприймати думку опонентів.  Невміння обгрунтовувати свої думки. Некомандний гравець. Бажаю усім кандидатам не боятися бути собою та говорити про точки зростання. Багато кандидатів прагнуть активно продавати себе на співбесідах, бути ідеальними та уникати всіх незручних питань. Насправді ж якщо людина розуміє свої точки зростання — це про силу, адже вона знає, як їх покращити. Також раджу перед співбесідою порефлексувати про свій попередній досвід та дизайн в цілому, знайти відповідь, чому ви хочете працювати на цій посаді та в цій компанії.  Питання на співбесіду з продакт-дизайнером  Загальні Як ви потрапили в дизайн? Чому обрали саме дизайн? Що таке дизайн на вашу думку?  Як можна схарактеризувати ваш підхід до дизайну? Які ключові принципи керують вашою роботою? Чим би ви займалися, якби не працювали в дизайні? Що б ви робили, якби мали необмежені ресурси для реалізації своїх ідей? Як ви вдосконалюєте свої навички в дизайні? Як слідкуєте за тим, що відбувається в дизайн-світі? Що для вас є хорошим дизайном? Дизайни яких застосунків вам подобаються? Чому? Розкажіть про один із ваших останніх проєктів. Які виклики ви зустріли та як їх подолали? Розкажіть про свій дизайн-процес.  З якого етапу роботи над задачею ви зазвичай починаєте працювати? Користувацькі дослідження Які методи ви використовуєте для дослідження потреб користувачів?  Як ви визначаєте та пріоритезуєте ключові вимоги до дизайну? Як ви вимірюєте успішність дизайну? Гіпотези та експерименти Як ви формулюєте гіпотези перед початком експерименту? Як визначаєте критерії успішності для гіпотези? Які метрики ви використовуєте для вимірювання результатів експерименту? Опишіть процес планування та проведення A/B тестування. Які інструменти для A/B тестування ви зазвичай використовуєте? Чому? Як ви інтерпретуєте результати A/B тестів та приймаєте рішення? Розкажіть про випадок, коли результати тестування не відповідали вашим очікуванням. Як ви діяли далі? Як ви обираєте, які зміни впроваджувати на основі результатів A/B тестування? Як ви використовуєте аналітичні дані для формування нових гіпотез? Зворотний звʼязок Який найскладніший фідбек ви давали/отримували? У чому відмінність зворотнього зв’язку від критики? Які критерії хорошого фідбеку? Як часто ви надаєте фідбек своїм колегам чи підлеглим? Як ви вважаєте, що робить фідбек ефективним і корисним для отримувача? Рефлексія Розкажіть про свої сильні сторони? Які точки зростання ви бачите? Чому, на вашу думку, з вами приємно працювати? Чому з вами може бути важко працювати? Розкажіть про невдачі, з якими ви стикалися. Який досвід ви з них винесли? Як ви оцінюєте свій прогрес та досягнення за останній рік? Робота в команді   Якою ви бачите ідеальну команду? В якій команді вам було б важко працювати та чому? Розкажіть про складних колег, з якими вам доводилося працювати. Що саме було для вас складним і як ви з цим справлялися? Що ви робите, коли команда не погоджується з вашою думкою? Як ви справляєтеся з різними стилями комунікації та роботи в команді?

19-річний вінничанин Ярослав Морозов був одним з перших власників iPhone у своєму рідному місті. Гаджет від Apple визначив його професію на довгі роки вперед — Ярослав спочатку розробляв iOS-застосунки для Genesis, а у 2018 запустив власний стартап в генезійській екосистемі. Нині Universe Group — це група компаній, що об’єднує декілька бізнесів, чиїми продуктами користуються понад 62 млн користувачів у всьому світі. Про те, чому конкурентний ринок — найпривабливіше місце для підприємця та як провести масштабну реорганізацію бізнесу за короткий час, Ярослав розповів для блогу Genesis.  Привабливий червоний океан  Я ніколи не боявся конкуренції, тому що переконаний — на висококонкурентних ринках усі можуть побудувати бізнес. Ще до того, як потрапити в IT, я отримав багато підприємницького досвіду різного роду — продавав айфони з eBay, розмитнював авто, займався логістикою тощо. Так от 19-річним хлопцем я у Вінниці продавав телефони й бачив, що буквально у кожному торговельному центрі є «точки», де продають аксесуари до мобільних телефонів та іншої техніки. Здається, якщо зробиш ще одну таку «точку», вона нікому не буде потрібна, але направду їх з часом стає все більше і більше, і вони лише зростають. Якщо ринок великий, завжди знайдеться місце для ще одного гравця. Водночас на такому ринку можна закріпитись лише з унікальною пропозицією. Якщо твій продукт нічим не кращий за інші, досягти успіху неможливо.  За цим принципом я й обрав нішу, в якій планував запустити свій перший продукт. Ринок утиліт у 2018 році вже був досить великий, стрімко зростав, постійно з’являлися нові гравці. Я був тоді одним із перших iOS-девелоперів в Genesis. В мене була непогана експертиза в розробці застосунків, але жодної, наприклад, у створенні контенту. Утиліти були тою сферою, яка могла підсилити мої сильні сторони.  Ми одразу зробили ставку на простоту. Завантажуючи утиліту, користувач хоче розв'язати конкретну проблему, і йому не потрібен мільйон додаткових фіч. 2018 запустили застосунок-сканер Scan Guru, а в наступні декілька років ще перекладач Translator Guru та утиліту для очищення пам’яті телефону Cleaner Guru.  На перших етапах весь наш фокус був на сканері як на флагманському продукті. Ми проводили там багато експериментів, тестили, і він був успішним. Нам здавалося, що ми можемо просто масштабувати наші підходи на інші продукти, аби вони теж злетіли. Але виявилося, що навіть всередині лінійки утиліт різні продукти потребують різних рішень.  Cleaner Guru роки півтора не показував великих результатів, маючи виторг близько $10 000 - $20 000 на місяць. А конкуренти тим часом швидко зростали. Треба було змінювати ситуацію. Тоді команда повністю переробила продукт, з чистого аркуша. Вони не брали до уваги весь попередній досвід з нашими додатками, а створили новий продукт, як із погляду маркетингу, так і розробки. Цей підхід і фокус цілої команди спрацював — нині Cleaner Guru став в сотні разів більшим, стабільно в топі за завантаженнями у своїй ніші. Нещодавно ми досягли позначки в 10 млн завантажень та повернули лідерство у ніші.  Виклики вебу. Як запустили FORMA  Я регулярно проводжу ресьорч різних ніш, відстежуючи можливості на ринках. В процесі натрапив на SaaS-платформу по роботі з документами для бізнесу. Почав аналізувати цю нішу, побачив, там багато нових гравців, серед найбільших — продукти PDF Smart та PDF Simply. Це знак, що ринок зростає, нові продукти заходять і мають можливість зростати разом із ринком. Зараз, два роки потому, зайти у цю нішу значно складніше — має бути сильна технологія та маркетингова експертиза. Але тоді ми вирішили ризикнути. Сформували невелику команду всередині Guru Apps, але дуже швидко стало зрозуміло, що цей бізнес повністю відрізняється від утиліт, має інші потреби у фахівцях. Тож пішли на експеримент — виділили команду в окремий бізнес, почали шукати людей з відповідною експертизою.  Тут було над чим попрацювати. Існує дві ключові складові, які треба вирішити для того, щоби бізнес круто зростав. По-перше, це маркетинг — як ми можемо ефективно залучати користувачів. По-друге, здатність створити технічно крутий продукт, що задовольнить потребу юзерів.  Нам довелось розбудовувати маркетинг на цьому продукті – PDF Guru, який пізніше став основою бізнесу FORMA, фактично з нуля. На застосунках ми здебільшого працювали з перформанс-маркетингом, а от у вебі експертизи не мали. Треба було опановувати SEO, PPC і ще багато чого. В цей час до нас доєднався Федір Котяй, фахівець з іншого бізнесу екосистеми Genesis, на позицію Head of Marketing. Його компетенції у веб маркетингу стали у пригоді при запуску цього бізнесу. Над продуктовою частиною — теж досить складною — працював юніверсівець Дмитро Канєвський, нині він Head of Product  у FORMA.   Вже за декілька перших місяців роботи команди ми зрозуміли, що Федір бере на себе всю цю відповідальність за продукт: він включався, забирав ініціативу, підтримував усі процеси. Ми поспілкувалися із ним і дійшли згоди, що після досягнення певних KPI він отримає позицію СЕО, а разом з нею і права і відповідальність як СЕО. Нині Федір Котяй — один з СЕО бізнесів Universe Group. Для мене це був перший крок до того, чого я прагнув — дати можливість талановитим фахівцям із менеджерським майндсетом розвивати свої навички, створювати й масштабувати бізнеси всередині групи.  Перші кроки в EdTech В час, коли утиліти Universe почали показувати стабільний ріст,  я згадав про ідею, що з’явилась ще на початку, але не реалізувалась через брак знань про роботу з контентом, — створення освітньої платформи. За допомогою наших партнерів із Meta ми отримали результати дослідження вчених Каліфорнійського університету, в якому йшлося про те, що 70% людей із вищою освітою хочуть самостійно прокачувати свої софт-скіли, які б допомогли їм в роботі. За цю нішу ми ухопилися і створили Wisey — освітню платформу для покращення особистої продуктивності. Основна географія продукту — англомовні ринки країн Tier-1.  Це ще один конкурентний ринок, завоювання якого попереду. Нині Wisey стрімко зростає: близько 30 курсів, десятки тисяч студентів тощо. Ми плануємо розширювати локалізацію на інші ринки — додали іспанську, німецьку і французьку мови. Сьогодні бізнес Wisey очолює також генезієць – Богдан Житник, який доєднався до нас, коли вже платформа була запущена, але він зміг створити новий підхід до роботи з нею – знайти unit-економіку та розвиває сьогодні її у новому напрямку.   Управлінцями не народжуються  У нас в компанії кожен може запустити свій продукт та керувати ним, за умови досягнення певних результатів та надбання необхідних навичок. Що для цього потрібно? По-перше, мати крутий трекшн в одному з бізнесів Universe Group — мінімум рік ефективної роботи й перформансу, що вражає. По-друге, людина має вміти будувати команди та управляти ними. По-третє, вона знає як наймати найкращих і зібрати найкрутіші таланти у себе. Четверте — сильна мотивація побудувати щось грандіозне, вести людей за собою, бути лідером. Я особисто дуже вірю в силу правильної мотивації, тому для мене наявність такої в людині — аргумент на її користь.  П’ять рис ефективного CEO  Жага до результатів. Людина має горіти прагненням досягти мети.  Відсутність страху здатися дурним. Робота СЕО — ставити багато питань, особливо у тих сферах, де він не є експертом.  Допитливість. СЕО має цікавитись усім, що пов’язано з його бізнесом, до найменшої деталі.  Толерантність до змін. Менеджмент — це найперше про генерацію змін. Якщо СЕО не створює зміни, компанія не зростає. Фокус на підсиленні команди. Одна з найголовніших задач управлінця - постійно шукати тих, хто буде робити команду сильнішою. Розділяй і керуй Настав момент, коли в Universe було сформовано повністю три повноцінні  бізнеси  — Guru Apps,  Wisey та FORMA. Стало зрозуміло, що наявна структура не буде ефективною з трьома різними продуктами й командами, що над ними працюють.  По-перше, шеринг ресурсів на декілька продуктів, який ми практикували від самого початку Universe, втрачав свою ефективність разом із ростом кількості команд. Коли є три «замовники» у бекендера, фронтендера і дизайнера, і всім треба на вчора, у всіх «палають» дедлайни, — це проблеми й напружена атмосфера в компанії.  По-друге, лінійка продуктів створювала плутанину під час найму. До прикладу, ми шукали фахівця на Wisey, а приходив кандидат зі словами «Мені дуже подобаються ваші утиліти, хочу працювати із ними». Нам доводилось пояснювати, що шукаємо колегу в інший продукт.  Логічним рішенням цих викликів була зміна структури компанії, точніше перетворення Universe на групу компаній — утворення із «материнською» компанією та «дочками», окремими повноцінними бізнесами із незалежними командами, керівниками, процесами тощо. Genesis побудовано подібним чином, і ми бачимо, що цей підхід ефективно працює там, де продукти масштабуються і весь час з’являються нові.  В результаті роботи над структурою компанії ми прийшли до таких змін:  Три окремі бізнеси — Guru Apps, Wisey та FORMA. Кожен із них має окремого CEO (який раніше був хедом відповідного напряму в Universe) та окрему команду, що працює винятково над своїм продуктом.  Деякі працівники мігрували з одного продукту в інший відповідно до своїх бажань, компетенцій та потреб бізнесу. Весь процес зайняв до пів року.  Нині я займаю дві позиції: СЕО Universe Group і СЕО Guru Apps. В найближчому майбутньому у напряму утиліт з’явиться свій керівник.  Ми запровадили нові методи управління. У кожного бізнесу є свій board, перед яким вони звітують щомісяця і щокварталу — про стан бізнесу, основні пріоритети, виклики тощо.  Уніфікація звітності. До базових документів додали так звані файли хелс-чеку: щомісячні опитувальники, які ми заповнюємо по всім процесам та результатам бізнесів. Так створюється детальна історія кожного продукту, і ми бачимо, що відбувалося, які патерни, які висновки для себе можемо зробити.  Нові процеси планування. Раніше для маленьких бізнесів (Wisey і FORMA) ми робили щомісячне планування, а для Guru Apps — раз на рік, на три й на п’ять років. Нині в Universe Group «маленьких» бізнесів не залишилось, усі створюють повноцінні великі компанії. Тому нині Guru планується раз на чотири місяці, а інші — раз на три місяці. Окрім цього, ми розділили епізоди  — кожна команда зустрічається окремо від інших, аби обговорити результати й плани на наступний період.  Шлях до «єдинорога» Нині Universe Group — це три компані та ми плануємо стати українським «єдинорогом». Я хочу сприяти росту ринку продуктового ІТ в Україні. Планую, що до 2028 року оцінка Universe Group перетне позначку в мільярд доларів. Кожен новий «єдинорог» в Україні буде створювати більше нових можливостей для українців — для тих, хто планує запускати свій продуктовий IT-бізнес, для розробників та нетехнічних IT-фахівців. Я хочу, аби українська tech-екосистема була повноцінною частиною європейської та не поступалась світовим гігантам. Ми на шляху до цього вже зараз.  Моя особиста місія — створювати для моїх співробітників такі ж можливості, які свого часу дала екосистема Genesis. Я прийшов колись як джун і виріс до СЕО окремої групи компаній. Нині вже в моїй компанії є люди, що стали СЕО, і я був радий бути дотичним до їх росту. Це про можливості для талантів, тих, хто наполегливо йде до своєї мрії.