top of page

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

Знайдено 274 позиції за запитом «»

  • Headway вдруге увійшла до 150 найкращих компаній світу з цифрового навчання

    EdTech компанія Headway другий рік поспіль потрапляє до списку найкращих компаній світу, що трансформують цифрове навчання, GSV 150. Цьогоріч Headway стала єдиною компанією у переліку, що представляє регіон Східної Європи. «Те, що Headway включили до цього переліку вдруге, підтверджує значення нашої мети — трансформувати освіту, зробити її доступною та інноваційною. Метод мікронавчання, що пропонують продукти Headway, мінімізує час і зусилля користувачів та показує високу ефективність. Наша робота змінює те, як люди навчаються та розвиваються, і ми пишаємось цим», — коментує СЕО та засновник Headway Антон Павловський. Інвестиційна платформа Global Silicon Valley (GSV) обрала лідерів з-поміж двох тисяч бізнесів за такими критеріями: масштаб та зростання прибутку, кількість користувачів, представленість у різних регіонах. За оцінками GSV, 150 компаній у списку охоплюють близько трьох мільярдів людей, а також сумарно генерують понад $23 млрд доходу щороку. Ці бізнеси роблять навчання доступнішим для дітей та дорослих, допомагають здобувати вищу освіту та опановувати нові навички протягом усього життя. «Світ адаптується до сейсмічних зсувів, спричинених розвитком генеративного ШІ минулого року. Розумні асистенти, репетитори та генератори контенту — ШІ скрізь, і потреба в диференціації є гострішою, ніж будь-коли. Цьогорічний GSV 150 втілює саме цей тренд», — йдеться у дослідженні. Усі компанії списку GSV 150 розділені на категорії за країною походження та напрямом роботи. Найбільш представлені регіони — Північна Америка (61%), Індія (15%) та Європа (12%). Кількість компаній, що походять з цих країн, збільшилася порівняно з 2023 роком. 49% бізнесів сфокусовані виключно на розвитку професійних навичок, 47% — на навчанні дітей, 35% — на вищій освіті. Їхня кількість помітно зросла, порівняно з минулим роком. 16% компаній фокусуються на навчанні людей протягом усього життя.

  • Genesis для України. Освіта для офіцерів та гуманітарні ініціативи

    Понад два роки українці відважно дають відсіч повномасштабній агресії росії. Стільки ж часу бізнеси та команди екосистеми Genesis, а також партнерські компанії допомагають у цій боротьбі. Наша мета – через системні освітні проєкти та цільові ініціативи допомогти зберегти життя воїнів. Розповідаємо, що спільними зусиллями екосистеми Genesis вдалося зробити протягом двох років великої війни. «Вишкіл капітанів» У листопаді 2022 року Сили територіальної оборони ЗСУ запустили навчальний курс підвищення кваліфікації командирів рот, офіцерів штабів батальйонів Сил ТрО ЗСУ «Вишкіл капітанів». Першим до проєкту доєднався фонд «Повернись живим». На початку 2023 року до курсу як основні партнери долучилися Genesis і venture builder SKELAR. Підтримали ініціативу також Universe та AMO з екосистеми Genesis, і компанії appflame і Headway. Курс розробили провідні воєнні фахівці за стандартами НАТО, враховуючи реалії російсько-української війни. Навчання триває вісім місяців: за цей час офіцери вдосконалюють вміння військового планування та управління підрозділами, систематизують набуті знання та напрацьовують алгоритми ухвалення військових рішень. Один із ключових показників успішності курсу – кількість збережених життів, адже внаслідок навчання зростає ефективність підрозділів і зменшуються втрати особового складу. Вишкіл уже завершили понад 500 офіцерів ТрО, Нацгвардії та Десантно-штурмових військ, у кожного з них – близько 100 людей у підпорядкуванні. Тобто курс прямо впливає на злагоджену роботу понад 50 000 військових. «Знання дають змогу включатися в ситуацію максимально швидко. Ухвалювати найбільш адекватні рішення. І берегти життя бійців», — розповідає командир роти із позивним «Корсунь», який вже завершив навчання на курсі. Мета курсу — підготувати офіцерів до ефективного командування ротою та роботи у штабі батальйону, розвинути лідерські якості командира за провідним міжнародним досвідом. «Вже протягом восьми років ми інвестуємо в ІТ-освіту, адже віримо, що від професійності кадрів залежить розвиток цієї сфери. Від ефективності командного складу української армії залежить значно більше: хід війни, майбутнє країни, життя десятків тисяч людей. Вміти аналізувати ситуацію, ухвалювати рішення в умовах невизначеності та ефективно керувати командою — ці менеджерські навички потрібні кожному офіцеру нового покоління. Ми віримо, що проєкт «Вишкіл капітанів» стане важливою складовою майбутньої перемоги», — коментує Володимир Многолєтній, СЕО та співзасновник Genesis. Genesis for Ukraine У квітні 2022 року компанія створила благодійний фонд Genesis for Ukraine,  першочергове завдання якого — забезпечення адресної допомоги співробітникам та їхнім родичам, які боронять Україну у війні з росією. Компанія створила зручний інструмент, за допомогою якого співробітники екосистеми Genesis можуть звернутися по допомогу. Станом на кінець 2023 року фонд закрив внутрішні запити загальною вартістю 10,1 млн грн. За ці кошти придбали понад 1,6 тис. одиниць товарів: засоби зв’язку, компʼютери, тактичний одяг та спорядження, засоби індивідуального захисту та медикаменти. Крім того, компанія зберігає робоче місце та компенсацію мобілізованих працівників, а також через фонд допомагає з лікуванням та відновленням після демобілізації. Здійняли рокіт Проєкт «Здіймемо рокіт» — продовження системної співпраці з фондом «Повернись живим» та Силами ТрО. В межах краудфандингу наприкінці 2023 року бізнеси екосистеми Genesis та партнерські компанії разом зібрали понад 15,5 млн грн та передали фонду компетентної допомоги «Повернись живим». За ці кошти фонд придбав комплекти аеророзвідки для 112, 114, 126 та 241 бригад ТрО. Проєкт побудовано таким чином, аби він підсилював й випускників «Вишколу капітанів»: спершу забезпечити їх знаннями, а згодом їхні підрозділи – технічними засобами. До збору «Здіймемо рокіт» долучилися бізнеси з екосистеми Genesis та компанії-партнери: appflame, Solidgate, Headway, Quarks, Universe, Legit, а також працівники цих компаній Броня для життя, донати для перемоги Окрім системних проєктів, які допомагають здобути стратегічну перевагу, проєкти екосистеми реалізують цільові ініціативи, які дають оперативні результати. Наприклад, на початку повномасштабного вторгнення це були корпоративні донати фондам «Повернись живим», KOLO, та на спеціальний держрахунок для підтримки ЗСУ. Згодом Genesis почала втілювати власні проєкти для збереження життя захисників. Серед таких – проєкт «Броня для життя», який допомагає евакуйовувати поранених  з поля бою. Компанія профінансувала відновлення чотирьох законсервованих МТ-ЛБ – легких бронетранспортерів, які призначені для евакуації поранених. У серпні 2023 року Genesis долучилася до фандрейзингового проєкту Braveproject, в межах якого задонатила 720 000 грн на придбання біонічних протезів від Esper Bionics для поранених українських військових та цивільних. Ініціативи бізнесів екосистеми Genesis та партнерських компаній Від початку повномасштабної війни бізнеси Genesis втілювали власні ініціативи, щоби ще більше допомогти Україні у боротьбі з ворогом. Вони проводять креативні фандрейзингові активності серед працівників, подвоюють їх донати, а ще – реалізовують чимало локальних та міжнародних ініціатив. Ось лише кілька з них. Headway розповідає про феномен свободи України в проєкті «Essence of Ukraine» Компанія Headway створила колекцію самарі українських книг про тисячолітню історію України та її новітні здобутки, стародавню культуру й традиції народу, її вікову боротьбу за свободу через книги українських авторів. Проєкт Essence of Ukraine вмістив 480 хвилин читання або слухання 32 самарі книг українців, які розкривають понад 20 тематик. Колекція  безкоштовна і доступна трьома мовами у понад 140 країнах. Під самарі англійською та іспанською мовами компанія закликає користувачів застосунку з усього світу донатити на офіційну фандрейзингову платформу України UNITED24. Колекцію Essence of Ukraine можна знайти у застосунку Headway в розділі Collections «Незалежна. Сенси Свободи». ОBRIO забезпечує комфорт захисників Щоби працювати ефективно, війську потрібен вишкіл, сучасне матеріальне забезпечення і високий морально-психологічний стан. Останній неможливий без закриття базових потреб, таких як чистий одяг та теплий душ. Компанія OBRIO спільно з фондом Genesis for Ukraine допомогла розв'язати цю проблему для кількох підрозділів ТрО – профінансувала створення мобільних лазне-пральних комплексів. Сім таких загальною вартістю понад 4,6 млн грн дарують воїнам частинку комфорт далеко від дому. Всередині кожного комплексу – пральні та сушильні машини, душовий відділ та баки з водою, місткості яких вистачить для одного використання 25 бійцями. SKELAR навчає тактичної медицини Venture builder SKELAR заснував власний благодійний фонд SKELAR foundation, у фокусі – збереження життя та здоровʼя захисників. Серед проєктів фонду – створення навчально-тренувальних центрів з тактичної медицини «КоЛеСо». З допомогою компанії відкрили 5 центрів у Києві, Запоріжжі, Кривому Розі, Миколаєві та Вінниці, в яких пройшли навчання понад 20 000 людей. Також працівники компанії – активні донори крові. Лише у 2023-му провели три корпоративних донації крові та задонатили близько 40 л крові на потреби цивільних та військових у прифронтових зонах. Universe подвоює донати та надає адресну допомогу У 2022-му компанія Universe сфокусувалася на адресній допомозі співробітникам та їхнім близьким, які долучилися до лав Сил оборони України. А також підтримувала збори перевірених благодійних фондів: «Повернись живим» та «Genesis for Ukraine». У 2023-му компанія подвоювала збори, які ініціювали співробітники – так вдалося закрити 21 збір на автомобілі, амуніцію, тактичний одяг та лікування військових. Jiji допомагає злагоджувати підрозділи Військові Сил ТрО ЗСУ навчаються працювати у підрозділах у пейнтбольних тирах, які допомогла облаштувати компанія Jiji. Це особливо ефективний вид навчання для цивільних, які після початку повномасштабного вторгнення долучилися до лав ТрО. Jiji разом зі співробітниками передали фонду Genesis for Ukraine 500 000 грн, за які придбали 28 комплектів пейнтбольних систем.

  • Як інтегрувати сторонню LLM у середовище розробки. Огляд інструменту Continue

    Розробники все більше надають перевагу великим мовним моделям (LLM) замість Google та Stack Overflow, які так само раніше замінили паперові посібники. Водночас чимало інструментів LLM є «чорними скриньками» — вони непрозорі та незручні у використанні. Доводиться витрачати чимало часу на копіювання з ChatGPT та вгадування, який контекст використовує Copilot. Крім того, для користування цими продуктами треба надати свій код для вдосконалення LLM, проте, як саме модель використовує ці дані — невідомо. Можливість експериментувати, налаштовувати модель під себе та контролювати власні дані є одними з найбільших потреб у комʼюніті. Як наслідок, з'являються рішення для інтеграції локальних та зовнішніх великих мовних моделей в середовища розробки (IDE), а рішення на базі Github Copilot і Jetbrains AI відходять на другий план. Один з таких інструментів — Continue. У цьому матеріалі розбираємося, як він працює, які має переваги, та ділимося інструкціями установки та налаштувань. Бонус — ґайд, як обрати LLM для вашого проєкту. > Що таке Continue > Як встановити Continue > Як налаштувати LLM у Continue > Яку LLM обрати > Популярні LLM та їхні характеристики Що таке Continue Continue — це відкритий автопілот для розробки програмного забезпечення. Цей плагін дозволяє IDE підключатися до будь-якої великої мовної моделі, незалежно від того, розміщена вона локально чи в хмарі. Компанія Continue, яку заснували Нейт Сесті і Тай Данн, у листопаді 2023 залучила $2,1 млн початкового фінансування. Фаундери вважають, що процес розробки з використанням LLM має бути схожим на створення музики. «Розробники відчувають себе успішними, коли їхня робота нагадує гру на гітарі біля вогнища, спів під радіо або експерименти з ритмами в GarageBand, на відміну від застрягання у болоті коду, документації та форумів» — стверджують вони. На базовому рівні плагін Continue усуває потребу в копіюванні з ChatGPT — замість цього потрібно виділити контекст та написати питання у бічній панелі редактору. Також інструмент надає можливість керувати контекстом. Наприклад, можна ввести «@issue», щоби швидко звернутися до проблеми на GitHub під час запиту до LLM, «@README.md», щоб звернутися до файлу, або «@google», щоб включити результати пошуку в Google. Крім того, є безліч додаткових налаштувань. Розробник може написати: власні слеш-команди (наприклад, '/commit' — щоби написати повідомлення для зафіксованих змін, '/docs' — щоб отримати вміст файлу та оновити сторінки документації, '/ticket' — щоби згенерувати завдання із відповідними файлами та інструкціями); джерела контексту (наприклад, проблеми GitHub, Jira, локальні файли, StackOverflow, сторінки документації); шаблонні системні повідомлення; інструменти (наприклад, додавання файлу, виконання модульних тестів, збирання та перегляд помилок) тощо. Continue працює з будь-якими LLM, включно з локальними та відкритими моделями. За замовчуванням розробницькі дані зберігаються у .continue/dev_data на локальному комп'ютері та можуть бути використані для вдосконалення LLM, які використовує команда. Цю опцію Continue і планує монетизувати. Переваги Continue: Вбудований інтелектуальний чат в редакторі коду. Користувач може отримувати поради, рекомендації або навіть допомогу з кодуванням без необхідності переходити до інших програм або вебсайтів. Використання локальних LLM або сторонніх API. Continue надає можливість використовувати локальні або звертатися до зовнішніх сервісів API, які надають доступ до великих мовних моделей. Робота з контекстом проєкту для більш точних та релевантних рекомендацій. Створення власних команд чату, які відповідають потребам та робочим процесам. Приватність і безпека даних. Всі обміни даними здійснюються безпечним чином, а користувацька інформація залишається конфіденційною. Як встановити Continue У VS Code завантажте плагін Continue через Visual Studio Marketplace та встановіть. Коли відповідна іконка зʼявиться у лівій бічній панелі, перетягніть її на праву панель. Якщо у вас виникли проблеми, перегляньте посібник з усунення несправностей. У JetBrains перейдіть до розділу налаштувань або параметрів, використовуючи «cmd/ctrl + shift + ,». Знайдіть розділ плагінів та встановіть Continue. Після інсталяції вам може знадобитися налаштувати плагін, щоби вказати, які моделі ви хочете використовувати (локальні, віддалені чи обидві). Налаштуйте будь-які параметри відповідно до ваших вимог. Обравши моделі, перезапустіть IDE, щоби переконатися, що плагін правильно завантажено та налаштовано. Починаючи працювати з плагіном, варто протестувати його на простих завданнях. Наприклад: Виділіть фрагмент коду та натисніть «cmd+shift+M» (Macos) або «ctrl+shift+M» (Windows), щоби включити його в повідомлення чату Continue. Введіть запитання «скажи мені, як працює цей код» у чаті. Якщо пояснення здається коректним, введіть «як би ти змінив цей код на [ваше завдання]?». Якщо відповідь вас влаштує, введіть /edit [ваше завдання]. Щоби прийняти зміни, використовуйте команду «cmd+shift+enter», щоб прийняти зміни. Щоби відхилити зміни, натисніть «cmd+shift+backspace» та повторіть спробу — плагін знайде іншу рекомендацію. Якщо після чергової спроби Continue надає некоректні пропозиції, спробуйте надати чіткі інструкції або розбити завдання та попросити LLM виконати кожне з них окремо. Як налаштувати LLM у Continue Щойно встановивши Continue, можна випробувати цей інструмент за допомогою проксі-сервера, який безпечно здійснює виклики через API до таких моделей, як GPT-4, Gemini Pro та Phind CodeLlama через OpenAI, Google і Together відповідно. Коли будете готові використовувати свій власний API-ключ або іншу модель/провайдера, натисніть «+», щоби додати нову модель. Їх можна налаштувати через GUI або через config.json — у ньому достатньо вказати, якого провайдера та модель використовувати за замовченням. Приклад підключення провайдера Mistral API: ~/.continue/config.json { "models": [ { "provider": "mistral", "title": "Mistral Small", "model": "mistral-small", "apiKey": "" } ] } Приклад підключення провайдера Ollama: ~/.continue/config.json {  "models": [    {      "title": "Ollama",      "provider": "ollama",      "model": "llama2-7b"    }  ] } Приклад підключення провайдера TogetherLLM: ~/.continue/config.json {  "models": [    {      "title": "Together CodeLlama",      "provider": "together",      "model": "codellama-13b",      "apiKey": "YOUR_API_KEY"    }  ] } Зокрема можна налаштувати шаблон чату. Більшість моделей із відкритим вихідним кодом працюють у певному форматі. Наприклад, llama2 і codellama очікують, що вхідні дані виглядатимуть так: «[INST] Як написати бульбашкове сортування в Rust? [/INST]». Continue автоматично намагатиметься визначити правильний формат підказки. Проте якщо ви отримуєте безглузді відповіді, спробуйте змінити формат у властивостях шаблону. Якщо ви хочете створити повністю новий шаблон чату, це можна зробити в config.ts, визначивши функцію та додавши її до властивостей templateMessages вашого LLM. Приклад templateMessages для формату Alpaca/Vicuna: function templateAlpacaMessages(msgs: ChatMessage[]): string {  let prompt = "";  if (msgs[0].role === "system") {    prompt += `${msgs[0].content}\n`;    msgs.pop(0);  }  prompt += "### Instruction:\n";  for (let msg of msgs) {    prompt += `${msg.content}\n`;  }  prompt += "### Response:\n";  return prompt; } Яку LLM обрати Першим критерієм для вибору є використання відкритих джерел або комерційних моделей. Відкриті моделі зазвичай обирають, коли потрібно тримати код у власному середовищі, є достатньо доступної пам'яті, є вимога знизити витрати та мати доступ до керування та оптимізації. Комерційні моделі обирають, коли надають перевагу простому та надійному налаштуванню та не проти виходу коду за межі середовища. Якщо ви обрали відкриту модель, наступне питання полягає в тому, встановлювати її на локальному комп'ютері чи на хостинг-провайдері. Основні переваги локального розташування — безоплатний доступ та можливість використовувати модель без підключення до Інтернету. Хостинг-провайдери обирають для більш потужних моделей або коли LLM використовуватимуть декілька людей. Нижче — перелік відкритих та комерційних моделей у порядку зростання популярності станом на кінець 2023 року. Відкриті моделі: Code Llama — модель, тренована Meta. Базується на Llama 2, доступна в різних розмірах: 7B, 13B і 34B, що робить її популярною для використання як на локальних машинах, так і через хостинг-провайдери. WizardCoder — побудована на основі Code Llama командою WizardLM. Для уточнення моделі використано метод Evol-Instruct, адаптований для задач програмування. Представлена у розмірах: 7B, 13B і 34B. Phind-CodeLlama — побудована на основі Code Llama компанією Phind. Використовувався власний набір даних, що складається з приблизно 80 тисяч задач і рішень програмування. Загалом модель уточнена на 1,5 млрд додаткових токенів. Доступна у розмірі 34B. Mistral — модель з параметрами 7B, навчена компанією Mistal AI. Вона є найновішою моделлю у цьому списку, проте з перших тижнів випуску викликала певний інтерес. Вже зараз починають з'являтися перші уточнені моделі на її базі. StarCoder — модель з параметрами 15B, навчена компанією BigCode. Вона була навчена на 80 мовах програмування. Не є моделлю для інструкцій, тож команди на кшталт «напиши функцію, яка обчислює квадратний корінь» не працюють добре. Однак через запит Tech Assistant вона може бути корисною. DeepSeek Coder — модель, навчена компанією DeepSeek AI на 2 трлн токенів. З набором даних, який складається з понад 80 мов програмування, це найновіша модель у цьому списку. Вона набрала високі бали у низці тестів з програмування. Llama2 — навчена компанією Meta на 2 трлн токенів. Це найпопулярніша відкрита LLM взагалі, хоча вона не так хороша у редагуванні коду, як інші моделі. Комерційні моделі: GPT-4 від OpenAI вважається найкращою моделлю LLM для використання під час програмування. Корисна для генерування та обговорення коду. Для використання потрібно надіслати свій код до OpenAI через їхній API. GPT-4 Turbo від OpenAI є дешевшою та швидшою версією GPT-4. Має обмеження знань по кінцевій даті у квітні 2023 року та вікно контексту розміром 128 тис. символів. Наразі перебуває на етапі попереднього перегляду, але будь-хто з обліковим записом OpenAI API та доступом до GPT-4 може використовувати її. GPT-3.5 Turbo від OpenAI є дешевшою та швидшою за GPT-4, однак її пропозиції не настільки корисні. Доступна для всіх розробників після реєстрації облікового запису в OpenAI. Claude 2 — модель, навчена Anthropic, має покращені навички в програмуванні порівняно з першою версією Claude. Для використання потрібно надсилати свій код до Anthropic через їхній API. Для отримання доступу до Claude 2 потрібно надіслати заявку. PaLM 2 — модель, навчена Google. Щоб спробувати її, потрібно надіслати свій код до Google через API PaLM після отримання ключа API через MakerSuite, які зараз у загальному доступі. Популярні LLM та їхні характеристики Отже, Continue є корисним інструментом для виконання складного редагування (добре працює в ситуаціях, коли пошук і заміна не працюють), створення файлів та шаблонів з нуля, виправлення помилок у коді тощо. Проте він не підходить для глибокого дебагінгу, редагування великих файлів, довгих рядків, завдань з багатьма кроками чи декількох файлів одночасно.

  • 90+ питань для співбесіди з Android Developer

    Що питають на співбесіді Android Developer? У кожної продуктової ІТ-компанії свій сценарій технічного інтервʼю, який залежить від вимог та культури компанії. Цього разу досвідом проведення співбесід ділиться компанія Lift, бізнес з екосистеми Genesis, що розробляє однойменний застосунок для фото- та відеоредагування. Що з Computer Science має обовʼязково знати Android Developer, та як має готуватися інтервʼюер? Яких кандидатів шукають у компанії, та яких помилок припускаються спеціалісти, відповідаючи на питання? Олесь Никитюк, Senior Android Developer у Lift, поділився питаннями, кейсами та порадами, як підготуватися до співбесіди. > Як проходить співбесіда в Lift > Що питають на співбесіді Android Developer > Red flags > Перелік питань на співбесіду для Android Developer (Junior, Middle, Senior) Як проходить співбесіда в Lift Технічне інтервʼю в компанії Lift складається з трьох частин. Спершу ми розповідаємо про компанію та продукт, цікавимося, чи кандидат зміг подивитися застосунок, чи користувався, що він про нього думає, чи є зауваження. Відповіді на першому етапі можуть багато сказати про його мотивацію працювати у нас. Далі розмовляємо з кандидатом про його досвід. На цьому етапі оцінюємо софт-скіли. Запитуємо, що його мотивує в роботі, чим він хоче займатися у майбутньому, у якому напрямку розвиватися. З якими викликами та проблемами стикався на попередніх проєктах, як їх вирішував. Останнє питання багато говорить про кандидата: він схильний аналізувати та виправляти помилки, або ж розчаровується та уникає цих проблем. За нею йде частина, де ми спілкуємося з кандидатом про його досвід в технічних питаннях, і наскільки це відповідає нашим очікуванням. Сюди входять питання з Computer Science, Android SDK ta Kotlin, архітектури тощо. Додатковий блок — наша специфіка, а саме робота з низькорівневою графікою та медіа. Якщо у кандидата був такий досвід, то ми про це спілкуємося. Це не обов'язково, але буде великою перевагою. Коли компанія відкриває нову позицію, я готую вимоги до кандидата та планую, які завдання він закриватиме в перші місяці роботи. Перед кожною співбесідою вивчаю CV, переглядаю відповіді на питання з прескринінгу, який провів рекрутер. Ця інформація дає можливість зробити певні висновки про потенційні сильні та слабкі сторони кандидата, які я стараюся перевірити на самій співбесіді. Що питають на співбесіді Android Developer Computer Science У першу чергу ми ставимо питання з теорії Computer Science. Ці знання відіграють ключову роль в оптимізації швидкості роботи застосунків, коду, ефективної роботи з даними та використанням ресурсів. Зокрема алгоритми та структури даних — це база для розуміння основних принципів та концепцій розробки. В Android-ком'юніті поширене твердження, що алгоритми вивчають в університетах і одразу забувають, адже ці знання нерелевантні. За моїми спостереженнями, більшість кандидатів розуміє цю тему лише на рівні популярних методів сортування, таких як Bubble Sort. Нам важливо, щоби кандидат усвідомлював, для чого взагалі потрібні алгоритми, як оцінювати їхню складність, як порівняти між собою та обрати той, що підходить для конкретного завдання. Більшість алгоритмів вже реалізовані у стандартній бібліотеці, і загалом їх не потрібно писати з нуля. Проте розуміти — критично важливо. Така ж ситуація зі знаннями про структури даних. Більшість кандидатів використовує 2-3 найбільш популярні типи. Хоч вони й ефективні, але підходять не для всіх завдань. На співбесідах питаю, чи працював кандидат з чимось іншим, за яким принципом обрав, чи розуміє, які переваги. Часто по цій темі кандидати мають суттєві прогалини. Наприклад, є задача спроєктувати свій стек. Це доволі проста структура даних, але багато кандидатів навіть не можуть нормально пояснити, як працює стек. Kotlin, Android SDK Наступна тема стосується Kotlin, Android SDK, зокрема Concurrency та Coroutine.  Це можуть бути загальні питання, як взагалі працює система Android, як вона взаємодіє з застосунком, або щодо оновлень. Зокрема, Android Jetpack Compose – це майбутнє, і треба знати, чи кандидат розуміє, як з ним працювати. Досвід з Compose буде великим плюсом. Також цінується вміння працювати з мультипоточним кодом, розуміння Concurrency тощо. Часом кандидати не дуже обізнані в оновленнях. Наприклад, в Kotlin давно з'явилися value-класи, але досить рідко зустрічаю тих, хто з ними працював, розуміє механіку та переваги. Питання про ООП, принципи SOLID та патерни ми не ставимо. По-перше, вони дуже «заїжджені» на співбесідах, і всі на них очікують. По-друге, якщо у кандидата є прогалини у цих знаннях, це точно буде видно в ході співбесіди. Натомість я стараюся оцінити аналітичні здібності кандидата, побачити, як добре він розуміє тему, чи заглиблювався в неї. Наприклад, якщо ми говоримо про корутини, які всі зазвичай люблять і бачать лише переваги, я питаю, коли їх не варто використовувати. Відповідь покаже, чи добре кандидат розуміє принципи, за якими вони працюють, та аналізує, для чого вони потрібні. Спілкуючись про Concurrency, можна спитати, коли доцільно використовувати декілька потоків, а коли краще обійтись одним. Це теми для розмов зі спеціалістами рівнів мідл та сеньйор. У джуніорів варто перевірити розуміння extension функцій. Їх також усі люблять та використовують, але чи знає кандидат, коли краще використовувати extension функцію, а коли написати звичайну функцію в класі? Архітектура Наступний блок — питання з архітектури. Як краще спланувати архітектуру для UI та обрати один з підходів (MVP, MVVM, MVI)? Який з них краще підходить для Compose? Коли доцільно виносити проєкт на модулі? Як їх правильно структурувати? Також питаємо по Gradle, чи кандидат знає, як збирається проєкт, як його можна оптимізувати у збірку? Для чого там використовується ProGuard і які його плюси? Робота з медіа В застосунку Lift ми працюємо з низькорівневою графікою та медіа: декодуємо, перетворюємо та створюємо відео. Це доволі вузька ніша, яка потребує специфічних знань. Якщо у кандидата є відповідна експертиза, ми спілкуємось на цю тему. Практичні задачі В ході співбесіди я даю також декілька практичних завдань. Зазвичай вони стосуються потенційних робочих проблем або тих завдань, з якими кандидат працюватиме у цій ролі. Усі вони усні, їх можна вирішити доволі швидко. Наприклад, я пропоную спроєктувати кешування зображень. Коли кандидат обміркує, як це зробити та видасть якісь результати, я додаю певні вимоги, що змінилися. Наприклад, тепер нам потрібно видавати зображення за іншим критерієм або попередньо обробляти їх. Це завдання дає зрозуміти, на скільки рішення, що пропонує кандидат, гнучкі. Адже робота в стартап-команді передбачає динамічне середовище, в якому відбуваються постійні зміни. Тестового завдання в Lift немає. Водночас іноді після технічної співбесіди ми можемо дати додаткове завдання, коли є сумніви. Зазвичай це якась задача, з якою кандидат стикнеться в перші тижні роботи. Софт-скіли Найголовніші скіли для джуніора — бажання вчитися, мотивація. Якщо є база з Computer Science, він може швидко опанувати будь-які технології. Для мідла важлива самостійність, щоби він не приходив розбирати кожне питання та дрібне завдання, як джун. Мідл має справлятися з більшістю завдань самостійно. Сеньйор має вміти вирішувати будь-який тип задачі та хотіти працювати в цьому напрямі. Спеціалісти цього грейду часто починають втомлюватися та замислюватися про світчинг до іншого напряму розробки. Важливо, щоби сеньйору щиро подобалося те, чим він займається, а також, щоби він міг бути ментором для інших грейдів. Перелічені теми і питання загалом підходять для всіх грейдів. Різниця тільки в тому, з яких питань я починаю та їхньої глибини. Наприклад, якщо джуніор добре відповідає на прості питання, я переходжу до складніших і намагаюся визначити його рівень. Якщо це сіньор, я не буду починати із простих питань, а братиму складніші і буду заглиблюватися в них. Загалом співбесіда для різних грейдів проходить на схожим сценарієм, відрізняється по софтовій частині. Наприклад, у Джуна ми більше питаємо, як він навчається, звідки бере інформацію, що йому цікаво і так далі. У сеньора ми більше питаємо його плани на розвиток, його досвід, наскільки він мотивований, наскільки йому цікаво буде працювати з тим, чим ми займаємося, з тими технологіями, які у нас. Red flags 1. Мати прогалини в Computer Science Знання алгоритмів та структур даних — це база, без якої розробнику неможливо розвиватися далі. Важливо не просто «погуглити» ці теми перед співбесідою, щоби назвати інтервʼюеру якомога більшу кількість методів та типів, а саме зрозуміти, як вони працюють, які переваги мають, як їх оцінювати, як обрати серед них потрібний. У відкритому доступі є безліч матеріалів з Computer Science, тож раджу кандидатам підтягнути цю тему. 2. Не слідкувати за оновленнями Kotlin — головний інструмент Android Developer. Як мова програмування, так і бібліотеки постійно розвиваються, тому за цим варто слідкувати. Команда Lift використовує сучасний технологічний стек (Android Jetpack, Jetpack Compose, Room, DataStore, Media3, Ktor, Hilt). Якщо кандидат на попередньому місці роботи працював із застарілими бібліотеками та інструментами, то ми очікуємо, щоби він як мінімум цікавився оновленнями та знайомився з ними на пет-проєктах. 3. Не вміти працювати з документацією Вивчаючи технологію, важливо читати документацію. Це звучить очевидно, але чимало кандидатів вивчають Android SDK та Kotlin за прикладами та відео в ютубі. Краще мати терпіння та читати першоджерела. До того ж документація до цих технологій, зокрема Kotlin-бібліотек, корутин, — чудово описана, і читати її — приємно і ненудно. 4. Слабкі софт-скіли Сильні «мʼякі навички» кандидата можуть нівелювати прогалини по технічній частині. Мотивований спеціаліст, який швидко вчиться і має бажання розвиватися, зможе надолужити брак досвіду з певними технологіями, і команда допоможе йому в цьому. І навпаки — якими б потужними не були технічні навички, якщо з людиною некомфортно спілкуватися, він навряд отримає офер. У нас були кейси, коли кандидат був не готовий брати участь у регулярних daily, адже в цей час ходить в зал, або мав власне бачення на архітектуру і непохитну позицію щодо цього. Людина має добре вписатися в команду, щоби разом досягати амбітних цілей, і без софт-скілів досягти цього неможливо. 5. Відсутність мотивації Іноді по кандидату видно, що він вигорів на попередній роботі та не має мотивації розвиватися. Для нас важливо, щоби спеціаліст хотів працювати саме на цій ролі та позиції, любив Android-розробку і щиро цікавився цим напрямом. Наприклад, на співбесіди приходили кандидати, які на питання про подальші плани казали, що хочуть вивчати iOS. Така позиція не надихає найняти саме його. Перелік питань на співбесіду для Android Developer (Junior, Middle, Senior) Computer Science 1.  Що таке алгоритм сортування? Назвіть кілька різних алгоритмів сортування та поясніть, чому вони ефективні. 2.  Як працює BFS та DFS? Як ці алгоритми можуть бути застосовані в розробці? 3.  Що таке рекурсивна функція? Наведіть приклади, коли її доцільно використовувати? 4.  Як ви розумієте поняття складності алгоритмів? Які методи визначення складності ви знаєте? 5.  Які відмінності Heap та Stack памʼяті в Android-застосунках? 6.  Що таке компіляція та інтерпретація? Чим вони відрізняються? 7.  Як працюють механізми обробки винятків в Android-застосунках? 8.  Як визначити та керувати залежностями між компонентами? Які інструменти використати для цього? Структури даних 9. Які структури даних ви використовуєте? Чи є серед них не стандартні (ArrayList, HashMap)? В чому їхня перевага? 10. Чому так часто використовується HashMap? Яка складність операцій? Коли краще використати іншу структуру даних? 11. У чому відмінність між HashMap, ArrayMap та SparseArray? Наведіть приклади, коли краще кожну з них використовувати? 12. Як працює Stack? В чому відмінність від черги (Queue)? 13. Як працює ArrayDeque? Коли він ефективніше ніж ArrayList? Kotlin 14. Чим система типів в Kotlin відрізняється від Java? 15. Що таке autoboxing і як він впливає на продуктивність? 16. Для чого потрібне ключове слово const? 17. Які переваги дає sealed interface/class? 18. Що таке ключове слово object, як відбувається ініціалізація? Який його життєвий цикл? 19. Як можна додати свій оператор до класу? Наприклад, оператор +. 20. Коли використовувати extension function, а коли member function? Яка відмінність? 21. В яких випадках краще використовувати extension function для розширення функціонала свого класу/інтерфейсу? 22. Як працюють inline функції? Які нові можливості вони дають? 23. В чому особливість value class? 24. Як досягається імутабельність колекцій в стандартній бібліотеці Kotlin? 25. В чому перевага Sequence, коли їх краще використовувати? Як це впливає на швидкодію? 26. В чому проблема інтерфейсів List, Map, Set в контексті імутабельності? Чи можна завжди очікувати що ці структури даних будуть незмінними? 27. Практичне завдання: реалізувати клас DataSize (KB MB GB), що описує розмір даних. Concurrency 28. В чому різниця між процесом та потоком? 29. До якої памʼяті має доступ потік? Які проблеми це створює? 30. Для чого потрібна синхронізація потоків? 31. Які ви знаєте способи синхронізації? 32. Яка поведінка у synchronized? 33. Скільки потоків можуть виконуватись в одному synchronized блоці? Який порядок входу в цей блок? 34. В чому різниця між Atomic та Volatile? В які гарантії дає кожен з них? Що таке CAS? 35. Як працює Lock? В чому особливість ReadWriteLock? 36. Практичне завдання: є Executor, на якому паралельно виконуються задачі. Задача може завершитись успішно, або з помилкою. Як можна рахувати кількість успішних і неуспішних задач? Coroutines 37. В чому переваги корутин? 38. Для яких задач недоцільно використовувати Kotlin Coroutines? 39. Як можна створити корутину? 40. Який життєвий цикл корутини? 41. Що відбувається з корутиною, якщо в ній кинути Exception? 42. Від чого залежить ця поведінка? 43. Для чого потрібен CoroutineScope? 44. Як він повʼязаний з CoroutineContext? 45. Що з себе представляє CoroutineContext? 46. Чи можна додати свій тип в CoroutineContext? 47. Як працює CoroutineDispatcher? 48. Як можна створити свій CoroutineDispatcher? 49. Практичне завдання: є CoroutineDispatcher який використовує лише 1 потік. Як можна на ньому виконувати декілька задач, які в циклі while(true) виконують роботу? 50. Які є способи синхронізації корутин? 51. Для яких задач краще підходить Mutex, а яких Channel? 52. Що з себе представляє Flow? Чим він відрізняється від SharedFlow та StateFlow? 53. Яка різниця між операціями flatMapConcat, flatMapMerge, flatMapLatest? 54. Чи є переваги у Flow, SharedFlow та StateFlow над Channel? Android SDK 55. Які є способи взаємодії між застосунками в Android? 56. В чому різниця між Implicit та Explicit Intent? 57. Чому в Android використовується Bundle? В чому його обмеження? З чим це повʼязано? 58. Як працює Main потік? 59. Поясни взаємодію Looper та Handler? 60. Чи можна створити свій потік з Looper? 61. Які є способи збереження даних в Android? 62. Що таке SurfaceView як він працює? Для яких задач його можна використовувати? 63. Чим відрізняється TextureView від SurfaceView? 64. Що таке WorkManager і в яких випадках його доцільно використовувати? Compose 65. Чим Jetpack Compose відрізняється від View системи? Які його переваги? 66. Що таке рекомпозиція? 67. Як Composable function знає, коли робити рекомпозицію? 68. Як можна зберігати стан між рекомпозиціями? 69. Які є вимоги до аргументів функції, щоби вона була skippable? 70. Для чого використовується анотація @Immutable та @Stable? 71. Що таке State Holder? 72. Як можна виконати side effect в Compose? 73. Що буде, якщо виконувати side effect безпосередньо в тілі composable функції? 74. Як задаються та передаються стилі? Media 75. Як відбувається кодування/декодування зображень в Android? Як це можна оптимізувати? 76. Як можна відтворити аудіо не використовуючи MediaPlayer чи ExoPlayer? 77. Як відбувається декодування відео? Як працює MediaCodec? 78. Для чого використовується MediaMuxer? 79. Як можна транскодувати відео інструментами з Android SDK? OpenGL 80. Що таке шейдер? Які типи шейдерів є? Як вони працюють? 81. Що таке GPU і як він працює? В чому переваги GPU над центральним процесором? 82. Як можна щось намалювати за допомогою GPU? 83. Які особливості використання OpenGL в Android? 84. Які основні компоненти архітектури графічного процесора? 85. Які ви знаєте основні типи шейдерів? Як вони використовуються у програмуванні графічних процесорів? Architecture 86. Якому підходу надаєте перевагу для роботи з UI? (MVP, MVVM, MVI, etc) 87. Який підхід буде краще працювати з Compose? 88. Як ви бачите структуру проєкту загалом? 89. Коли проєкт доцільно ділити на модулі? Як ви будете це робити? 90. Як можна зменшити розмір APK? 91. Для чого використовується R8?

  • Epic Games повстала проти Google і виграла. Чи зможе ця справа похитнути позиції техногіганта 

    Чотирирічні судові баталії розробника ігор Epic Games — історія для Netflix. Після видалення Fortnite з App Store та Google Play в 2020 році компанія почала справжнє повстання проти монополії IT-гігантів. Нещодавно кількарічні суди переросли в подію, яку довго обговорювали на технологічному ринку: розробник ігор виграв антимонопольний суд у Google. Окрім того, що це перший програш Google в антимонопольній справі, сам процес містить багато цікавих деталей про антиконкурентні практики Google Play та переплітається з іншим, не менш цікавим кейсом протистояння компанії з кількома десятками штатів. Засідання, на якому суддя має ухвалити фінальні рішення в обох справах, має відбутися 26 лютого. Напередодні нього ми, разом з Compliance Team Lead Русланом Ніфтуллаєвим та Legal Counsel Соломією Петрик, розповідаємо деталі цієї незвичайної справи та пояснюємо, чому вона важлива для індустрії. Епічна перемога «Перемога над Google!» — такими словами розпочинався один з грудневих твітів CEO Epic Games Тіма Свіні. Того дня його компанія виграла антимонопольний суд у Alphabet — материнської компанії Google. Дев’ятеро присяжних швидко та одностайно ухвалили рішення: техногігант перетворив свій магазин для дистрибуції застосунків на монополію та обмежує конкурентну боротьбу. Відносини Epic Games та Google погіршилися влітку 2020 року. Тоді видавець ігор обійшов платіжну систему Google Play Billing та дозволив користувачам свого бестселера, гри Fortnite, робити віртуальні покупки безпосередньо у грі. За цифрові транзакції, виконані у програмах, Google збирає комісію від 15% до 30%, тож такий хід їм не сподобався. Реакція була негайною — і Fortite видалили з Google Play. Однак Epic Games був налаштований на боротьбу — у той же день компанія подала судовий позов. Після кількох років баталій, суд став на бік розробника ігор та підтримав Epic Games в усіх претензіях. Вердикт здивував багатьох, адже у 2021 році компанія фактично програла схожу справу проти Apple, яка одночасно з Google видалила Fortnite з App Store за ідентичний трюк з прямими покупками у грі. Вердикт присяжних не є остаточним документом у справі, тому поки незрозуміло, чого саме домоглися Epic Games. Визначити це має суддя, він розглядатиме справу 26 лютого. Претензії Epic Games Попри те, що Epic Games подала судовий позов одразу після видалення з App Store та Google Play, розробники не висували жодних вимог щодо несправедливості рішення чи грошової компенсації. Натомість творці Fortnite одразу сконцентрувалися на вимозі припинити монополістську практику та антиконкурентну діяльність. Ключові претензії стосуються магазину застосунків Google Play та платіжного сервісу Google Play Billing. Epic Games скаржилася, що контроль над операційною системою Android дає Google змогу вимагати від розробників публікувати застосунки у Google Play та використовувати платіжну систему Google Play Billing для обробки платежів. Через таку зв’язку Google контролює весь процес та забирає за кожну транзакцію комісію розміром від 15 до 30%. Ситуацію, на думку Epic Games, могла б виправити «виконана обіцянка Google про відкриту конкуренцію», відповідно до якої користувачам Android та розробникам застосунків нададуть можливість створювати використовувати інші стори та платіжних провайдерів. Варто зазначити, що з 2018 року Epic Games розвиває свій власний онлайн-магазин. Утім, поки він не приносить компанії прибутку та, за словами топменеджменту, все ще перебуває на стадії зростання. Водночас Epic Games не приховує намірів у майбутньому завоювати половину ринку ігор для ПК. Захист Google Лінія захисту компанії будувалася на кількох аргументах. Адвокати стверджували, що Google Play не можна вважати монополією, адже платформа працює в умовах високої конкуренції. Як доказ вільного ринку захисники наводили App Store та магазин застосунків від Samsung, який виробник встановлює на своїх смартфонах, а також те, що понад 60% телефонів з Android пропонують альтернативні магазини для завантаження застосунків. Також Google апелював до безпеки та конфіденційності користувачів, стверджуючи, що інші «негуглівські» стори поставлять її під загрозу. Високі комісії виправдовували тим, що з 2007 року пошуковий гігант інвестував $40 мільярдів у створення ПЗ для Android, аби допомогти виробникам конкурувати з iPhone. Представники Google одразу заявили, що будуть подавати апеляцію. Їм є що втрачати: вердикт присяжних може загрожувати щорічному прибутку в $200 мільярдів, який компанія одержує від Google Play. Однак ймовірність, що його суттєво змінять — невелика. Одна з причин такого одностайного рішення присяжних — підозріла поведінка менеджменту Google, в тому числі видалена переписка, що стосувалася справи. «Цікаво, як саме Google буде обґрунтовувати недостатність доказів в апеляційній скарзі. Напевне, важко буде стверджувати, що якісь докази не враховані, якщо, як виявилось, частина потенційних доказів видалена самим Google. Там навіть у СЕО був налаштований one-day-mode, й більшість листувань видалялись впродовж доби», — каже Соломія Петрик, Legal Counsel в Genesis. Чому Google визнали монополістом, а Apple — ні Вирок на користь Epic Games здивував технологічний ринок на фоні аналогічної справи Apple. Компанія також видалила Fortnite зі свого магазину застосунків, теж отримала судовий позов від Epic Games, однак на відміну від «колег» справу фактично виграла. Основних розбіжностей дві: те, як судді визначали ринок, і те, хто саме ухвалював фінальне рішення, говорить Соломія Петрик. «Те, як саме розглядають поняття ринку — це ключова історія у будь-якому монопольному спорі. Щоби підтвердити порушення антимонопольного законодавства, потрібно довести, що компанія не лише займала велику частку ринку, а й заважала розвиватися іншим бізнесам. У кейсі з Apple Epic Games наполягала, що потрібно розглядати ринок дистрибуції iOS-застосунків. Тоді виходило б так, що Apple повністю контролює його та обмежує вхід нових гравців. Apple пропонували розширити поняття та говорити про ринок диджитал-ігор загалом — це формулювання уже включає маркетплейси від Apple та Google, а також стори для вебу. У фінальному рішенні суддя визначила ринок як Digital Mobile Gaming Market. Формулювання трохи вужче від того, що пропонував Apple, але воно все одно на їхню користь. У кейсі з Google було інакше. Epic Games говорити про ринок дистрибуції застосунків для Android, а Google пропонували охопити усі мобільні застосунки. Тоді виходить, що Google Play працює поруч з App Store та іншими платформами — і нікому не заважає. Втім у цьому кейсі присяжні визначили ринок дослівно так, як пропонували Epic Games», — пояснює юристка. Більшість антимонопольних процесів взагалі уникають суду присяжних і вирішуються суддею одноосібно. Тут же присяжні швидко й ствердно відповіли на всі 11 ключових питань у справі, визначивши, що Google монополіст, і що Epic Games постраждала від його дій. «У складних кейсах суд присяжних може засідати тижнями. А тут вони уже через кілька годин повернулися з рішенням», — уточнює Соломія. На таке швидке та одностайне рішення присяжних могло повпливати кілька цікавих деталей. Таємні угоди У листопаді 2023 року стало відомо про спеціальну угоду Spotify та Google, яка надає стримінговому сервісу набагато вигідніші умови, ніж багатьом іншим розробникам. Комісія, яку платить Spotify складає від 0 до 4% — якщо йдеться про транзакцію через платіжний шлюз Spotify та Google Play відповідно. Цікаво, що трьома роками раніше Spotify, а також Match Group (розробляє зокрема Tinder, Plenty of Fish та Hinge) підтримали Epic Games в антимонопольній боротьбі. Утрьох вони створили Коаліцію за рівноправність застосунків та прагнули натиснути на власників великих сторів, аби ті знизили комісії й відкрили майданчики для більшої конкуренції. Так, Match Group почала судитися з Google у травні 2022-го, прагнучи використовувати власну платіжну систему замість Google Play Billing. Пізніше цю справу об’єднали з аналогічним позовом від Epic та мали розглядати у листопаді того ж року. Однак за тиждень до засідання стало відомо, що Match Group та Google дійшли згоди у своїх непорозуміннях. Коаліція розпалася, і Epic Games залишилася на полі боротьби сама. Ще однією компанією, якій Google пропонував «спеціальний режим», була Netflix, яка теж користувалася власним платіжним шлюзом. В якийсь момент Google цю можливість забрав, перед тим запропонувавши компанії більш вигідні умови, аби та почала використовувати Google Play Billing. Однак схоже, що Netflix вирішила йти своїм шляхом, адже сьогодні підписатися на сервіс через застосунок на Android не можна. Окрім цих угод, під час процесу випливли внутрішні документи Google, відповідно до яких компанія платила розробникам та виробникам мобільних пристроїв, аби ті не займалися розвитком власних маркетплейсів. Наприклад, Riot запропонували $10 мільйонів, аби вони відмовилися від запуску свого стору, а Samsung міг одержувати $50 мільйонів на рік або ж долю від доходу в обмін на обіцянку не встановлювати на свої гаджети інші магазини застосунків та не розвивати Galaxy Store. Враження справляє і спеціальна угода Project Hug, відповідно до якої Google платив розробникам ігор сотні мільйонів доларів, аби вони залишалися в Google Play. Серед них — Activision, Nintendo, Tencent, Ubisoft та інші відомі видавці. Ще одна справа стосується угод з виробниками смартфонів, які мали «спрямовувати» користувачів на платіжну систему Google Play Billing, яка коштувала техгіганту $90 мільйонів. Перші зміни для Google Play Match Group та Epic Games були не єдиними, кому не подобалося монопольна роль Google. Прокурори 50 американських штатів у колективному позові також звинувачували компанію в придушенні конкуренції в магазині застосунків. Вони представляли інтереси 21 мільйона споживачів, які стверджували, що могли б витрачати на застосунки менше, якби не монополія Google. Судовий розгляд був запланований на листопад 2023 року, однак у вересні суперечку врегулювали, ухваливши мирову угоду. Про її особливості розповідає Руслан Ніфтуллаєв, Compliance Team Lead. «Рішення містить кілька положень, відповідно до яких Google має: сплатити штатам $700 мільйонів. $630 з них розподілять між користувачами, які переплатили за застосунки через політики пошуковика. Кожен юзер, що приєднався до позову, зможе отримати від $2 відшкодування. Тож якщо людина постійно купує щось у Google Play, то зможе отримати вагому компенсацію. Багато це чи мало? Спершу монопольний збиток оцінювали у $10,5 мільярдів, і Google, ймовірно, б виплатила б його, якби прокурори штатів довели справу до судового процесу. дозволити встановлювати застосунки на Android через інші платформи (впродовж семи років). дозволяти розробникам використовувати User Choice Billing (впродовж п’яти років). Конкретно цей пункт не виглядає як перемога для розробників, а сама система — така собі «соломка», яку вирішив підстелити собі Google. User Choice Billing запустили у 2022 році, коли суд з Epic Games уже тривав, а рішення ще не було. У чому суть? Наразі більшість розробників мають за замовчуванням  обирати платіжний шлюз Google, а у майбутньому їм дадуть змогу обирати User Choice Billing. Тоді вони зможуть дати користувачам вибір — заплатити через Google Play Billing або обрати інший варіант, завдяки якому фінальна сума транзакції буде меншою. Раніше за це блокували та могли видаляти зі стору. У випадку користування User Choice Billing комісія платформи буде меншою на 4%. Але фактично це розмір збору, який накладає платіжний провайдер, тобто на комісії це майже ніяк не вплине. дозволити виробникам гаджетів для Android встановлювати на них софт, що не розроблений Google (впродовж чотирьох років). змінити формулювання на екранах, які з’являються перед тим, як користувач завантажить застосунок не з Google Play (впродовж п’яти років). «Раніше у текстах були застереження, на кшталт того, що користувач буде самостійно відповідати за всю шкоду для пристрою, якщо завантажить застосунок зі стороннього стору. Таким чином Google ніби підкреслювала безпеку та надійність своєї платформи. Зараз вони мають змінити текст на більш спокійний, який не буде аж так жахати юзерів. дозволити розробникам зазначати, що на ціну кінцевого продукту впливають збори від Google (впродовж шести років). «Тут фішка у тому, що Google Play тепер не має забороняти розробникам розписувати ціну й показувати юзеру,  який відсоток вартості сформований сервісами Google Play. Глобально це не дуже щось змінює, але показує користувачам, що ціна диджитал-продуктів формується не лише з урахуванням витрат та апетитів розробника, а й з урахуванням частки, яку користувач заплатить стору». За словами Руслана, поки що незрозуміло, як саме зміни вплинуть на ринок, однак тенденція точно позитивна. «Особливо це стосується того, що Google не матиме права на певні дії на Android, а розробники матимуть трохи більше свободи, особливо ті, хто хоче мати власні стори. Зараз конкуренція між ними обмежена становищем великих компаній, які задають правила для всіх інших», — додає Руслан. Відповідно, якщо суддя затвердить документ так, як є, то технологічні гіганти (принаймні, Google) матимуть менше важелів для занадто сильної регуляції своїх платформ. Ключовий пазл Що може спонукати бізнеси вести подібні антимонопольні процеси? Ось кілька пояснень, які наводить Руслан Ніфтуллаєв. «На мою думку, цей випадок має глибший зміст, ніж просто боротьба за частку на ринку мобільних застосунків. У випадку з Epic Games є серйозна особиста зацікавленість СЕО. Він подає процес як боротьбу проти великих корпорацій, що зловживають своїм становищем на ринку. Це питання лежить у площині  більш широкого, західного розуміння бізнесу. Другий момент — конкуренція, адже розробник ігор має свій стор. Третій момент — високі комісії, які мало кого радують». Попри все судові тяганини Epic — це далеко не ключовий елемент, який переформатує систему, розмірковує Соломія Петрик. «Що справді може суттєво вплинути на бізнес-модель сторів? Те, що наразі по всьому світу ухвалюють нормативні акти, спрямовані на приборкання таких великих гравців. Нещодавно в Європі запрацював Digital Market Act, який змусив той же Apple створити окрему платформу для дистрибуції та піти на поступки, як-от можливість для девелоперів продавати свої апки на альтернативних маркетплейсах. Є ймовірність, що зовсім скоро схожі практики повноцінно запровадять багато де у світі — відповідні напрацювання вже є у регуляторів США, Великої Британії, Бразилії, Канади та Австралії. Сподіваємось, що це піде на користь диджитал-ринку та зробить його більш прозорим та конкурентоспроможним».

  • 7 міфів про SaaS-стартапи. Спростовує співзасновниця INPUT SOFT Анастасія Смик

    Кофаундери компанії INPUT SOFT Анастасія Смик, Андрій Смик та Валентин Завадський працювали в авіаційній індустрії. Під час пандемії ковіду зіштовхнулися з кризою у галузі, і 2021 року створили стартап — SaaS-платформу для цивільної авіації. INPUT SOFT збирає та аналізує дані про роботу аеропортів, зокрема, обслуговування літаків і пасажирів. Мета стартапу — оптимізувати  використання ресурсів в авіаційній галузі й трансформувати паперові процеси в цифрові. INPUT SOFT — учасник стартап-екосистеми TRMNL4, яку запустила Genesis. Ми попросили Анастасію Смик спростувати найпоширеніші міфи про SaaS-стартапи. МІФ №1 SaaS-рішення недостатньо безпечні В авіаіндустрії звикли встановлювати ПЗ на серверах компаній із доступом до програм тільки з робочого комп'ютера. Через ковід авіаційна індустрія почала користуватися клауд-системами, хоча у такій консервативній галузі недовіра до хмарних сервісів зберігається досі. Насправді ж великі хмарні провайдери мають більші за звичайний бізнес можливості для зберігання даних, наймають собі найкращих спеціалістів з кібербезпеки й постійно посилюють захист. Ми обрали клауд-провайдера Amazon Web Services, який дотримується всіх вимог до безпеки даних у різних країнах. Також ми працюємо над сертифікацією, постійно проводимо безпекові та penetration-тести. Ми збираємо всю інформацію, що підтверджує захист даних, і надаємо її клієнту, щоби переконати, що хмарні сервіси — це надійно. МІФ №2 Розробку SaaS-платформ краще віддавати на аутсорс Аутсорс – це досить непередбачуваний і дорогий формат, який потрібно постійно контролювати. З інхаус-командою ви зможете швидше втілити всі ідеї. Ще один важливий аспект — це права інтелектуальної власності (IP). Питання про те, кому належать IP, часто ставлять інвестори. Коли ви аутсорсите розробку, маєте прописати в договорах, кому належить IP після розробки. Але якщо продукт створює інхаус-команда, все просто. Продукт написаний в компанії, — значить, і IP належить компанії. Також клієнтам важливо, що імплементацію робить внутрішня команда, а не аутсорс, який намагається щось налаштувати віддалено. МІФ №3 Створити SaaS-бізнес простіше, ніж побудувати інший стартап SaaS-платформу важче розробляти. Якщо ви створюєте  один продукт під конкретного клієнта, то вибудовуєте ТЗ, робите всі завдання, віддаєте його в продакшн, і все. Якщо це SaaS-бізнес, ви маєте передбачити побажання різних клієнтів і роботу вашої програми на різних пристроях і у різних ОС. Платформу треба постійно оптимізувати й додавати нові фічі, щоби залучати та утримувати клієнтів. Як це працює в INPUT SOFT У нас велика індустрія, дуже складні розрахунки на бекенді, свій prediction-алгоритм затримок рейсів, ми підʼєднуємось до супутникових даних, щоб отримувати розклад польотів і постійно оновлювати інформацію. Тому якщо B2C-застосунки можуть випустити перші продукти вже через три місяці роботи, то у нас релізи можуть займати роки. Крім вебінтерфейсу ми маємо додатки для iOS та Android. При розробці нам треба продумувати всі варіанти, щоби всі можливі клієнти були задоволені. В нас є мінімальна кастомізація, але вона вже готова — клієнт може просто сказати, які частини нашого рішення йому потрібні. В розробці й підтримці це важче — кожен з клієнтів може мати додаткові вимоги. Але якщо ви напишете програму винятково під клієнта, вам доведеться додавати індивідуальну підтримку на різні фічі програми, а це можливо тільки в великих компаніях. МІФ №4 SaaS-рішення вимагають меншої підтримки після запуску Насправді на підтримку інфраструктури після запуску йде багато ресурсів. В SaaS ставку роблять на стабільний ріст кількості клієнтів, і вам потрібно одночасно підтримувати старих користувачів і створювати інфраструктуру для нових. Як це працює в INPUT SOFT Побудова інфраструктури була однією з наших проблем на старті. Ми зіштовхнулися з величезним навантаженням на сервер і перебудовували інфраструктуру за порадами наших менторів з Techstars. Для нас це було складно, тому що ми вже провели велику роботу, й довелося майже усе зносити та будувати наново. Тому я раджу одразу йти до менторів, шукати підтримку, запитувати людей, які вже з цим працювали. Буде набагато важче переробляти інфраструктуру, коли ви вже випустите альфа-реліз. МІФ №5 SaaS-рішення важче кастомізувати У нас є різні програмні модулі, їх можна купувати пакетом, а можна брати окремо. В самому модулі ми надаємо кастомізацію аналітики — дашборди, кастомізацію внесення даних. З кожним клієнтом окремо ми підключаємося до всіх можливих баз даних і програм, які в них вже є, щоб максимально автоматизувати потік даних, щоб не потрібно було вручну вносити інформацію, наприклад, розклад польотів. Ми автоматично можемо віддавати ці дані для інвойсінгу та зарплатних проєктів. Кастомізація і підключення в нас входять в імплементацію. Тому ми не вважаємо, що SaaS рішення важче кастомізувати. Якщо співпраця з клієнтом побудована правильно, в мінімальній кастомізації немає проблем. МІФ №6 Підписка на SaaS-платформи коштує небагато, а ціни мають бути доступні на сайті Все залежить від ринку. Враховуйте, B2B- чи B2C-продукт ви створюєте, чи легко користувачам наважитись на покупку, скільки коштують послуги ваших прямих конкурентів у галузі. Як це було в INPUT SOFT На старті ми дивились на інші SaaS-платформи, щоб утворити свою ціну. Насправді ми мали вивести свої показники, а не порівнювати себе з SaaS-продуктами з інших сфер. Спочатку ми хотіли, щоб аеропорт міг зайти на наш сайт, і одразу, як у Notion, подивитись прайсинг і оформити підписку. Потім ми зрозуміли, що жодний менеджер в аеропорту не буде підвʼязувати особисту картку і купляти рішення без узгодження з керівництвом. Перший місяць ціни на підписку висіли на нашому сайті, потім ми зрозуміли, що маємо відкинути цю ідею. МІФ №7 Churn Rate — головна метрика SaaS-бізнесу Коефіцієнт відтоку — дійсно дуже важливий показник для бізнесу за підпискою. Він допомагає відстежувати та контролювати кількість клієнтів, що відмовляється від сервісу. Проте для нас не менш важливі й інші метрики: СAC, Customer Acquisition Cost (вартість залучення користувача), тому що у нас досить довгий Sales Cycle (6-9 місяців), і нам треба розуміти, скільки зусиль, часу, людиногодин ми витрачаємо, щоби залучити клієнта. Чи буде сума контракту адекватною тому, скільки ресурсів ми витратили? Ми намагаємось постійно зменшувати цей Sales Cycle і покращувати Customer Acquisition Cost. LTV, Lifetime Value — цінність клієнта, прибуток, який він приносить за весь час роботи з ним. В авіаіндустрії контракти на софт підписують на пʼять років — так склалося історично. У нас же в INPUT SOFT немає обмежень на такий термін. Ми хочемо перевірити, чи правильним було це рішення, або ми маємо теж встановити мінімальний термін у пʼять років.

  • Технологічні та продуктові тренди мобільної розробки 2024

    Здається, що технології розвиваються надзвичайно швидко. Водночас остання визначна подія в архітектурі програмного забезпечення відбулася 2015 року. Нею стала поява мікросервісів. Хмарні обчислення почали розвиватися 2010 року, Agile повертає нас до 2000. Вебу — понад 30 років, браузер Netscape з’явився в 1994, і був не першим. Ми думаємо, що ІТ-галузь переживає постійні потрясіння, але насправді їх було відносно небагато. Вони трапляються умовно раз на 5 років, стверджує звіт O’Really. Видавнича компанія, яка випускає книги з компʼютерних технологій, щороку аналізує уподобання своєї аудиторії. На їхню думку, 2023 рік був одним із тих рідкісних руйнівних років. ШІ принесе зміни майже до кожного аспекту ІТ-індустрії. Якими будуть ці зміни, і чи готові до них користувачі? Ми зібрали ключові тренди розробки, продуктового дизайну та користувацьких настроїв 2024 року від провідних аналітичних та консалтингових агенцій: Gartner, Accenture, Emergen Research, а також техлідів, опитаних Forbes. > Технологічні тренди > Тренди продуктового дизайну > Тренди користувацьких настроїв Керування ШІ, кібербезпека та гіперперсоналізація. Що зміниться в розробці Складність та масштаб ІТ-продуктів щороку зростає. Головне питання наступного року: чи зможе генеративний штучний інтелект допомогти розробникам або лише додасть нових викликів? Наразі ШІ здатний створювати лише низькорівневий код, коли ж він зможе виконувати високорівневий дизайн? І справжнє питання, яке змінить нашу галузь, звучить так: «Як розробити системи, в яких генеративний ШІ та люди ефективно співпрацюватимуть?». ШІ як партнер ШІ-моделі стали невіддільною частиною технологічних проєктів. Gartner прогнозує, що до 2027 року ШІ-інструменти використовуватимуть 70% розробників. Водночас попри стрімкий розвиток генеративні моделі залишаються ненадійними та потребують системного контролю. Технологічні команди вже зараз шукають рішення, як правильно імплементувати, тестувати та налаштувати їх. TRiSM (Trust, Risk and Security Management) — підхід, який передбачає застосування інструментів для моніторингу, захисту конфіденційних даних, безпеки та точності результатів ШІ тощо. Gartner прогнозує, що з допомогою такого підходу генеративні моделі будуть більш точними та послідовними, а компанії зможуть уникнути до 80% неправдивої інформації. Інвестиції в кібербезпеку Хакерство та кібератаки невпинно зростають. За даними Всесвітнього економічного форуму (ВЕФ), кіберзлочинність стала третьою за величиною економікою світу після США та Китаю. Cybersecurity Ventures прогнозує, що 2024 року це коштуватиме світові $9,5 трлн. Розвиток ШІ сприяє цій тенденції. Наприклад, злочинці вже використовують генеративні моделі для верифікації акаунтів за допомогою фотографій. Наслідок —  користувачі втрачають довіру до онлайн-сервісів та мобільних застосунків. Отже, інвестиції у кібербезпеку та захист конфіденційних даних стануть трендом розробки мобільних застосунків. Gartner пропонує системний підхід CTEM (Continuous Threat Exposure Management), який допоможе скоротити кількість несанкціонованого втручання в системи на 60%. Цей фреймворк допоможе правильно оцінювати ризики, пріоритезувати вектори критичних загроз, аналізувати їх з точки зору зловмисника та тестувати ефективність заходів безпеки. Прогресивні вебзастосунки PWA (Progressive Web Applications) поєднують переваги вебтехнологій та мобільних застосунків у одному продукті. Вони базуються на HTML, CSS, JS та використовують логіку нативних додатків. PWA пропонують швидке завантаження, адаптивний дизайн, автономну функціональність і кросплатформенну сумісність. Їх можна встановити без використання магазинів застосунків, а також вони можуть працювати офлайн. Очікується, що 2024 року PWA отримають новий поштовх до розвитку. Згідно з аналізом Emergen Research, глобальний ринок PWA складатиме $10,44 млрд до 2027 року. Нативні хмари У минулому компанії створювали програмне забезпечення для локальної роботи, а потім за потреби переносили його в хмару. Величезний сплеск хмарної розробки свідчить про те, що компанії почали використовувати хмари як основну платформу розгортання. Нативні хмари — найпоширеніша тема 2023 року, яка виросла порівняно з 2022 на 175% — O'Really. Нативні хмари підвищують продуктивність мобільних застосунків для користувача. Програми можуть зберігати дані та виконувати складні обчислення в хмарі, на відміну від зберігання інформації безпосередньо на пристрої. 2024 року їхня популярність продовжить зростати, забезпечуючи масштабованість, доступність і безперебійну синхронізацію даних між пристроями. Гіперперсоналізація Персоналізація за допомогою штучного інтелекту має стати ключовим трендом розробки мобільних застосунків. Налаштування безперервної взаємодії та адаптація до індивідуальних уподобань користувачів стануть головним завданням команд розробки. Зокрема очікується, що великі мовні моделі інтегруються до UX-дизайну мобільних застосунків та надаватимуть гіперперсоналізований контент. Наприклад, особистий план з фітнесу чи харчування на основі даних біомаркерів, отриманих з переносних пристроїв. AR, голосовий інтерфейс та неоморфізм: яким буде продуктовий дизайн Все більше людей покладаються переважно на мобільні пристрої для покупок, ігор, виконання повсякденних завдань і перегляду вебсторінок. Отже, їхні очікування щодо дизайну та функціональності мобільних застосунків продовжують зростати. Forbes опитав техлідів індустрії та зібрав тенденції, які домінуватимуть 2024 року. Навігація з доповненою реальністю Застосунки з AR, які накладають цифрову інформацію на фізичний світ в реальному часі, стають все складнішими в розробці та водночас зручнішими для користувача. Ці програми можуть покращити навігацію в містах, торгових центрах, аеропортах та інших громадських просторах. Очікується, що 2024 року інтеграція доповненої реальності пошириться на різні ніші: від електронної комерції до освіти. Пропонуючи захопливий досвід, AR створює нові стандарти інтерактивності застосунків і залучення користувачів. Голосові інтерфейси Поява голосових інтерфейсів (Voice User Interface, VUI) уособлює глибокі зміни звʼязку користувача з пристроями. Тоді як Siri, Google Assistant і Alexa дали відчути можливості голосових команд, VUI готові розпочати еру взаємодії на основі розмови. Переваги голосових інтерфейсів виходять за межі керування пристроєм в режимі «вільні руки». Користувачам більше не потрібно натискати, друкувати або проводити пальцем, вони спілкуватимуться з технологіями так само природно, як і з друзями. Впроваджуючи VUI, команди зможуть розробляти інтуїтивно зрозумілі мобільні застосунки, що пропонують голосове усунення несправностей і обслуговування клієнтів. Наприклад, вдосконалення послуг підтримки клієнтів через персоналізацію та уникнення навігації складним меню або очікування на гарячій лінії. Allied Market Research очікує, що глобальний ринок VUI досягне $95,41 млрд до 2030 року. Мінімалізм і неоморфізм 2024 року принципи мінімалізму та неоморфізму вийдуть за межі дизайну інтерʼєру й одягу та значно вплинуть на естетику мобільних застосунків. Очікується, що користувацькі інтерфейси ставатимуть простішими та швидшими. Емоційний інтелект 2024 року все більше мобільних застосунків матимуть функції емоційного інтелекту. Йдеться про алгоритми, що можуть розпізнавати, розуміти та взаємодіяти з людськими емоціями. Використовуючи ШІ та машинне навчання, вони аналізують вираз обличчя, тон голосу, текстовий контент та інші сигнали, що вказують на емоційний стан користувача. Далі програми адаптують свої відповіді та рекомендації під нього. Урок для розробників полягає в тому, щоби створювати більш персоналізований і емоційно резонансний досвід для користувача. Мікровзаємодії в інтерфейсах Цей тренд — про невеликі гіперфокусовані функції у застосунках. Вони замінять незграбні меню інтуїтивно зрозумілими жестами та голосовими командами. Нюансна анімація чи тактильний відгук (м’яка вібрація телефону, коли користувач торкається кнопки), тонкі зміни значків, коли надходить нове повідомлення чи індивідуальні сповіщення — ці деталі формують динаміку залучення користувачів. 2024 року мікровзаємодії стануть незамінними для створення персоналізованого досвіду. Командам варто подумати про динамічні головні екрани, підказки та рекомендації, що враховують контекст взаємодії користувача з інтерфейсом, та плавну багатозадачність. Мультимодальне навчання Мультимодальні навчальні програми на базі штучного інтелекту домінуватимуть у розробці мобільних програм 2024 року. Такі застосунки пропонуватимуть персоналізований досвід навчання та поєднуватимуть інтерактивні уроки, доповнену реальність і репетиторів зі штучним інтелектом. У сучасному світі, де постійне навчання важливе, є високий попит на індивідуальні освітні рішення та ефективне опанування навичок. Розчарування, креативна стагнація та невизначеність: що турбує користувачів Стрімкі технологічні зміни та розвиток ШІ впливають і на користувацькі настрої. Accenture провів ґрунтовне дослідження їхніх очікувань, побоювань і потреб. Ерозія користувацького досвіду Протягом десяти попередніх років кореляція між клієнтським досвідом і зростанням доходу спонукало компанії тримати користувачів у центрі уваги попри все. Здавалося, що бренди одержимі своїми стосунками з клієнтами. Тепер економічні умови змушують їх іти на непопулярні кроки: підвищувати ціни без надання додаткових фічей, знижувати якість, маніпулювати підписками та економити на обслуговуванні клієнтів. Люди, що також опинилися в центрі економічного шторму, помічають це і розчаровуються. У результаті вони неминуче скасовують підписки та відмовляються від послуг. 2024 року компанії мусять знайти спосіб збалансувати витрати, намагаючись не збільшувати цін для користувачів. Навіть якщо такі рішення не окупляться миттєво, емоційна цінність бренду може бути ефективним інструментом у часи економічних труднощів. У дослідженні наводиться кейс американського ритейлера Costco. Його рішення підтримувати ціни на стабільному рівні в умовах рецесії на відміну від конкурентів спричинило стрибок продажів на 15%. Брендам знадобляться нові стратегії донесення їхньої цінності користувачам та розвитку їхніх стосунків. Зокрема, варто подбати про інструменти відстеження змін настроїв клієнтів. Втома та креативна стагнація Сьогодні людям доступно стільки застосунків, можливостей, контенту та продуктів, ніж будь-коли, але є відчуття розчарування від того, що все однакове. Диференціація давно є ключовим викликом для бізнесу, але сьогодні це відчувається гостріше, ніж будь-коли. 35% людей вважають, що функціонал і дизайн мобільних застосунків дуже важко розрізнити — Accenture. З розвитком ШІ виділитися стає складніше, адже через високий обсяг пропозицій змагання за увагу стає все більш жорстким. Іншими словами, копиця сіна продовжуватиме зростати, і голку унікальності знайти в ній все важче. Люди прагнуть новизни. У морі зайвого контенту, який перевантажує користувача, компаніям варто шукати способи відрізнятися. Accenture закликає бути уважним до використання ШІ, щоби нові інструменти розширювали підходи, а не стали шляхом до кліше. Користувачів лякають технології Відносини цифрових технологій і людства мають бути неймовірно позитивними, оскільки вони постійно генерують численні переваги: доступ до інформації, здатність миттєвого спілкування, розваги та мистецтво тощо. Але, як і в багатьох стосунках, все не так просто. Accenture виявив, що чим більше технологій люди регулярно використовують, тим більш імовірно, що технологія настільки ж ускладнює їхнє життя, наскільки й спрощує. Замість розв'язання своїх проблем люди отримали величезну кількість інструментів, мультикомунікацію та нагромадження сповіщень. Здається, що стрімкий розвиток технологій радше відбувається з людьми ніж для них. Головна проблема полягає в тому, що революція ШІ відчувається як величезна незрозуміла сила, що зосереджена в руках невеликої кількості технічних лідерів. Ipsos Global Trends виявили, що у Великобританії люди все більше погоджуються з твердженням «Я боюся, що технічний прогрес руйнує наші життя». 61% громадян США вважають, що «ШІ загрожує майбутньому людства». 47% людей у світі вважають швидкість розвитку технологій занадто високою. Що далі? Очікується, що люди намагатимуться контролювати свою залежність від технологій, обмежувати користування гаджетами та навіть частково повертатися до аналогових технологій або надавати перевагу простим рішенням. Ті бізнеси, хто запропонує людям рішення, як опанувати контроль над технологіями, швидше за все, стануть надійними партнерами. Про що варто подумати компаніям: Нова технологія полегшує завдання чи просто додає інші рівень розумового навантаження для користувачів? Як пристосуватися до нового поділу між користувачами, які приймають темпи технологічних змін, і тими, хто не встигає? Як надати користувачам більше вибору та контролю? Чи можемо ми спростити технологію і зробити її зрозумілішою? Отже, 2024 рік може стати переосмисленням розробки мобільних застосунків. Поєднання AI, AR і VR, VUI та інших технологій мають високий потенціал трансформувати звичний спосіб життя. Ці тенденції не є поодинокими явищами, вони перетинаються та накладаються, створюючи мережу можливостей, яка розповсюджується на різні ніші. Саме взаємозв’язок цих тенденцій робить їх такими потужними. Сила трансформувати галузі, покращувати життя та змінювати світ у нас під рукою. Якщо ви не берете активної участі в революції мобільних додатків, ви ризикуєте відстати у все більш конкурентному цифровому середовищі.

  • Найбільші технологічні компанії України презентували Спілку Diia.City United

    Genesis доєдналася як компанія-співзасновник до Diia.City United – Спілки, що об’єднує потужні технологічні бізнеси, які працюють в Україні зараз, підтримуючи ЗСУ. Мета Спілки – формувати зрозумілі бізнес-правила, впроваджувати фундаментальні зміни, розвивати середовище Дія.City так, щоби технологічний бізнес з України зростав глобально. Серед інших компаній-співзасновників: Ajax Systems, MacPaw, Monobank, Netpeak Group та Roosh та інші. Об’єднання очолила Наталія Микольська, експертка зі стратегічних трансформацій і глобалізації українського бізнесу, колишня торговий представник - заступниця міністра економічного розвитку і торгівлі України. «Ми будемо голосом технологічного бізнесу, аби влада не лише почула нас, але й зрозуміла, що потрібно бізнесу і що й бізнес може дати і допомогти державі. Ми сфокусовані на розв'язання актуальних питань режиму Дія.City та його розвитку, промоції України та українського технологічного бізнесу в світі». – підкреслює Наталія Микольська. Стратегічні пріоритети Diia.City United: захистити та доопрацювати режим Дія.City; сформувати чесні правила взаємодії між владою та технологічним сектором; розв'язати нагальні проблеми IT індустрії; розвивати освіту; прискорити інтеграцію української технологічної галузі у ринок ЄС і глобально; побудувати простір чесних правил різноманіття, рівності та інклюзії. «Бізнес — це те, що відокремлює успішні країни від неуспішних. Ми підтримали режим Дія.City на самому початку його заснування, бо прагнемо жити в країні, де ІТ-кластер функціонує за прикладом Абу-Дабі, а не Афганістану. Мета об’єднання така ж — не допустити того, щоб Україна стала недоінвестованою. Готові працювати, аби в країну стояла черга з інвесторів, а у вітчизняних бізнесів були нормальні, комфортні умови для роботи», — зауважив Володимир Многолєтній, засновник та СЕО Genesis. За словами Михайла Федорова, Віцепрем’єр-міністра України з інновацій, розвитку освіти, науки та технологій – Міністра цифрової трансформації України, нині серед резидентів Дія.City вже понад 800 компаній. Серед них близько 100 defense tech компаній.

  • Genesis потрапила у трійку найкращих IT-роботодавців країни

    Genesis посіла третє місце у щорічному рейтингу найкращих IT-роботодавців України за версією порталу DOU. Компанія увійшла у трійку найкращих в категорії «Понад 1500 спеціалістів». Фахівці оцінювали компанії за такими критеріями: компенсація, умови праці, проєкт, кар’єра та лояльність. Анкети заповнювали лише чинні працівники компаній. В інших категоріях рейтингу призові місця також посіли партнерські компанії Genesis. В категорії «800-1500 спеціалістів» на другому місці — SKELAR, в категорії «200-800 спеціалістів» четверте місце посіла Headway, в категорії «81-200 спеціалістів» в п'ятірку найкращих увійшла Solidgate.

  • «Почну з понеділка»: вакансії до Head Office Genesis

    Genesis — це екосистемна компанія, яка допомагає зростати іншим бізнесам. Спочатку ми надаємо перспективним стартапам необхідні ресурси та експертизу для розвитку, а потім супроводжуємо проєкт, доки він не стане самостійним бізнесом. З цим допомагають кілька команд у головному офісі — PR, біздев, юристи, фахівці з кібербезпеки тощо. У цій підбірці вакансій ми допомагаємо знайти своїх людей саме цим командам. Operations Manager Якщо ви прагнете вийти на новий кар’єрний рівень в операційному менеджменті, не оминайте увагою цю позицію. Робота передбачає побудову ділових відносин з компаніями екосистеми, оптимізацію витрат бізнесу та співпрацю з багатьма стейкхолдерами. Найкраще з роботою впорається фахівець, що мінімум чотири роки працював у FMCG, консалтингу чи фінансах із вмінням робити ефективні презентації. Знання Data Studio, Looker, Tableau та інших BI-інструментів буде перевагою. PR Manager До PR-команди Genesis шукають фахівця, який розвиватиме відносини з профільними українськими ЗМІ, оновлюватиме базу медіа й журналістів та оптимізує роботу з медіазапитами. Окрім того, він буде працювати з івентами, а саме — профільними технічними заходами, організовувати спільні події з українськими ЗМІ. Очікування команди: не менше як два роки релевантного досвіду, навички пітчингу, пошуку й відпрацювання інфоприводів, «теплі» контакти з ключовими медіа. На співбесіді потрібно буде показати портфоліо реалізованих проєктів. Community Specialist Спеціаліст буде розвивати T4.Community — спільноту, яка об’єднує понад 100 засновників стартапів з Центральної та Східної Європи. На позиції потрібно буде організовувати освітні та нетворкінгові заходи, модерувати різні канали комунікації та допомагати стартапам будувати міцні зв’язки між венчурними фондами, технологічними корпораціями тощо. З цим чудово впорається людина з парою років релевантного досвіду, сильною англійською мовою та лідерськими якостями. Перевагу нададуть кандидатам, що уже працювали в IT, EdTech, інвестиційному секторі, проєктах для МСБ або громадських організацій. Business Development Specialist Головний обов’язок біздева — розбудовувати системну співпрацю з ключовими партнерами компанії, зокрема, Apple, Amazon, Google, Meta, Pinterest, Snapchat, TikTok тощо. Ця задача передбачає регулярне спілкування як з представниками цих бізнесів (задля обміну досвідом та фідбеком), так і з C-level Genesis та партнерських компаній (для визначення пріоритетів та труднощів у розвитку). Також треба досліджувати ринок, вести перемовини, укладати й переглядати угоди. Знадобляться два-три роки досвіду у «великій четвірці», FMCG, юрфірмах, біздеві чи партнерствах, вільна англійська, а також досвід успішного управління проєктами чи укладання угод. Creative Compliance Manager Людина, що приєднається до команди, буде перевіряти контент мобільних застосунків, маркетингові та медіаматеріали, аби вони відповідали політикам платформ, на яких їх розміщують. Фахівець регулярно спілкуватиметься з командами бізнесів щодо питань дотримання політик партнерів, затверджуватиме маркетингові матеріали,  стежитиме за ринком та змінами в політиках найбільших платформ. Очікування команди — досвід у сфері права чи комплаєнсу, вільна англійська мова та хороші навички  презентацій. Partnership and Operations Manager Шукають фахівця, який зможе організувати безперебійну роботу з партнерствами для бізнесу. Що саме потрібно робити? Будувати відносини з локальними й міжнародними партнерами та підрядниками, допомагати командам відкривати рекламні акаунти чи кредитні лінії у Facebook, Google, Snapchat тощо, удосконалювати процеси. Серед вимог — вільна англійська мова, успішний досвід управління проєктами та укладання угод, знання інструментів Microsoft Office та графічних редакторів на кшталт Canva чи Vista Create (ex-Crello). Перевагу нададуть кандидату, що має досвід роботи у сфері Partnership & Operations, «великій четвірці» та юридичних фірмах. Legal Counsel Кандидат посилить команду юристів Головного офісу та буде займатися підготовкою, аналізом та переглядом різноманітних документів, виявляти потенційні юридичні ризики та допомагатиме продуктовим командам зменшувати юридичні ризики у їхній щоденній роботі. Найкраще на посаду підійде фахівець, який має рік-два релевантного досвіду, вільно володіє англійською мовою (перевагу нададуть тим, хто може підтвердити знання сертифікатами IELTS чи TOEFL) та вчився у профільному юридичному ЗВО. Security Engineer Знаєте основні концепції розробки, безпеки інфраструктури чи хмари? Працювали з системами відстеження помилок та управління змінами? Маєте навички усунення та дебагінгу складних проблем? На вас чекають у команді кібербезпеки Genesis. Ідеальний кандидат має мінімум два роки досвіду та профільну освіту, а також принаймні два сертифікати тестування безпеки з наступного списку: OSCP, OSCE, OSWE, OSEP, PNPT, CPENT, eCPPT, eMAPT, eJPTv2, eWPT/eWPTXv2. Посада передбачає дуже різноманітні завдання: проводити пентести, розробляти сценарії автоматизації, впроваджувати практики та фреймворки тестування безпеки. Administrative Assistant На цю роль шукають людину, яка не боїться багатозадачності, цінує розвиток та креативно підходить до роботи. Якщо ви вже працювали на подібній посаді хоча б рік, орієнтуєтеся у різних видах оплати, вмієте знаходити спільну мову з людьми, ви точно впораєтеся з усіма обов’язками. Серед них — забезпечення комфортного офісного життя, пошук нових підрядників та постачальників, робота з кур’єрськими службами та різні креативні завдання, на кшталт продумування подарунків чи брендованої продукції.

  • Genesis Crew: Дмитро Канєвський — від Junior Product Manager до Head of Product

    У рубриці Genesis Crew — новий матеріал. Цього разу публікуємо історію Дмитра Канєвського з компанії Universe з екосистеми Genesis. Він пройшов шлях від Junior Product Manager до Head of Product всього за два роки, і зараз відповідає за розвиток нового вебпродукту. В інтерв'ю Дмитро розповів, чим корисно починати карʼєру з волонтерських проєктів, що спільного в Індіани Джонса та продакт-менеджера, а також з якими викликами він стикався у різних продуктах. > Продакт-менеджер в ІТ > Індіана Джонс, навчання в КПІ та брат-близнюк > Волонтерство та перша робота > Масштабування глобальних продуктів без досвіду > Запуск нового продукту в режимі пригодницького екшену Продакт-менеджер в ІТ Позиція Junior Product Manager була моєю першою роботою в продуктовому ІТ. Я прийшов в ІТ-компанію Universe на четвертому курсі університету, маючи за плечима невеликий досвід у комерційних та волонтерських проєктах, а також закінчивши Genesis IT School. Продакт-менеджер відповідає за те, щоби продукт був прибутковим та закривав потреби користувачів. Цей спеціаліст працює на межі  бізнесу, маркетингу і технологій та синхронізує роботу всіх департаментів. Першим моїм завданням був перезапуск двох застосунків на глобальних ринках. Через фокус на флагмані Scan Guru, ці продукти тимчасово не розвивалися. Збільшення ресурсу команди дозволило знову взятися за них. Доручення такої амбітної мети «зеленому» спеціалісту може здатися безвідповідальним. Проте в Universe замість того, щоби тижнями знайомити людину з процесами, одразу інтегрують у всі події. Спочатку це змушує понервувати, водночас довіра команди надзвичайно надихає та мотивує. Крім того, поряд був ментор та менеджер, який направляв мене. За два з половиною роки в Universe я виріс до Head of Product нового вебпродукту та встиг отримати досвід: перезапуску продуктів на глобальних ринках, які не займали лідерських позицій у нішах; роботи з флагманом портфеля, одним з лідерів ринку; запуску продукту з нуля та розробки MVP; розвитку та масштабування вебпродукту. Індіана Джонс, навчання в КПІ та брат-близнюк У дитинстві я мріяв стати археологом. Подивившись фільмів про Індіану Джонса, я уявляв, що ця професія насичена пригодами та драйвом. Коли краще розібрався у деталях, зрозумів, що це не моє. Ідея тривалого пошуку чогось потенційно цінного серед тонни піску та землі не дуже надихала. Іншою мрією була політична карʼєра: я виріс у Боярці, невеликому місті під Києвом, і мені завжди хотілося змінити життя людей навколо, покращити його. У цих дитячих мріях було дещо спільне: жага до пригод, бажання заглиблюватися в деталі та прагнення впливати на навколишній світ. Думаю, це згодом і привело мене до продуктового ІТ. Я з багатодітної сімʼї, у мене є 4 брати, серед яких один — близнюк. Після закінчення технічного ліцею КПІ ми разом вступили до Інституту прикладного системного аналізу (ІПСА) КПІ імені Сікорського. Ще у школі ми розуміли, що ІТ є перспективним напрямом, в якому можна реалізуватися. Щоби отримати підвищення, тут не треба роками працювати на одній посаді. В ІПСА дають потужну математичну базу, розуміння як технічно будуються продукти, прокачується аналітичний майндсет, тому випускники цього факультету переважно стають розробниками та аналітиками. Ще на першому курсі мій брат захопився програмуванням, мені ж більше подобалися дані. Ми допомагали один одному і це сильно підтримувало нас протягом навчання. Волонтерство та перша робота На першому курсі я зосередився на розвитку навичок. Університетська програма закривала хард-скіли, проте не враховувала софт-скіли, хоча вони не менш важливі для дорослого життя та побудови карʼєри. Розвивати їх я почав у волонтерських проєктах. Усе почалося зі студради КПІ, згодом стажувався у Klitschko Foundation, приєднався до міжнародної волонтерської організації AIESEC. Наступним кроком була робота проджект-менеджером у SocialBoost — CivicTech організація, яка реалізовувала соціально значущі проєкти. Волонтерство було чи не єдиною можливістю отримати базовий менеджерський досвід на першому і другому курсах. Йти працювати фултайм було зарано, а також для цього не вистачало досягнень, які я планував отримати у волонтерстві. Водночас це шанс долучитися до важливих ініціатив, які роблять світ кращим, а також прокачати комунікативні навички. На третьому курсі я вирішив спробувати себе в комерційних проєктах і перейшов на позицію Sales Manager в Jooble. Це була перша фултайм робота, проте згодом зрозумів, що не хочу довгостроково розвиватися в цій сфері через відсутність впливу на продукт. Чи подобається він тобі, чи ні, але ти мусиш «продавати» і робити це переконливо. Коли немає можливості виправити навіть дрібні недоліки, запропонувати інші варіанти реалізації, це демотивує. Навесні 2021 року стартувала Genesis IT School, до якої мені пощастило потрапити. Два місяці навчання значно доповнили моє розуміння, що таке продуктове ІТ, які можливості воно дає. За короткий час я багато дізнався та укріпився у цілі працювати саме у продуктовій команді. Тому я звільнився з Jooble та почав активно ходити на співбесіди. В результаті отримав декілька оферів, одним з яких був від ІТ-компанії Universe. Мене зацікавили задачі та сама позиція — Product Manager, адже вона ідеально поєднувала ті харди, які я отримав в університеті та софт-скіли у волонтерстві. Бути продакт-менеджером — це можливість знаходитися в IT-середовищі, створювати продукти для всього світу, але водночас не писати код, а більше взаємодіяти з людьми. Масштабування глобальних продуктів без досвіду Universe — це продуктова ІТ-компанія, що працює у двох напрямах: створення застосунків-утиліт та розвиток R&D-центру. На початок 2024 року її продуктами користуються понад 55 мільйонів людей у всьому світі. Коли я приєднався до команди, флагманським продуктом у напрямі утиліт був Scan Guru — сканер документів для iOS. Також в портфелі було два продукти, розвиток яких довірили мені: Translator Guru — перекладач для iOS в реальному часі. Cleaner Guru — інструмент для очищення памʼяті iPhone. Це були готові продукти з широким набором функцій та мільйонами користувачів. Водночас їх не розвивали активно, тому вони не займали лідерських позицій в ніші, але мали такий потенціал. Я проводив дослідження ринку, конкурентів, вивчав потреби користувачів, шукав ідеї, як покращити воронку, займався оптимізацією екрана онбордингу. Усі гіпотези ми безперервно тестували. Спочатку я думав, що маленькі локальні зміни можуть принести значні результати. Пізніше зрозумів, що це можливо тільки завдяки спільним зусиллям всієї команди та численним безперервним ітераціям. Також я відчайдушно відстоював ідеї, які подобалися особисто мені. Насправді ж продакт-менеджер має обʼєктивно підходити до усіх гіпотез та не піддаватися когнітивним викривленням. Translator Guru мав сильний базовий функціонал: голосовий і текстовий переклад, вбудовані словники та розмовник, персоналізацію, переклад за допомогою камери. Моя улюблена фіча — можливість виділити текст у будь-яких застосунках і одразу побачити переклад у нашій клавіатурі без потреби «стрибати» між застосунками. Ми продовжували експериментувати, генерували складніші гіпотези, пов'язані з ретеншеном, і зрештою це спрацювало. Нам вдалося перезапустити Translator Guru, який почав активно зростати. Конверсія в покупку виросла на 58%. Це були чудові результати, які дозволили маркетингу масштабуватися. Водночас перезапустити Cleaner Guru не вийшло. Цей продукт потребував значних змін та окремої команди. З одного боку це був мій факап, адже я вірив, що до нього можна застосувати сценарій Translator Guru, і успіх гарантовано. Проте з іншого боку цей фейл дав нам корисний досвід та розуміння, що потрібно для перезапуску. За шість місяців для Cleaner Guru зібрали окрему команду, якій вдалося масштабувати застосунок у десять разів. Що має робити продакт-менеджер, щоби швидко зростати: постійно розширювати зони відповідальності; приймати рішення та бути проактивним; заглиблюватися в деталі та знаходити причинно-наслідкові звʼязки; вміти продавати ідеї; дізнаватися, чому ухвалюється те чи інше рішення; заглиблюватися у деталі та шукати рішення; розвивати лідерські якості. Запуск нового продукту в режимі пригодницького екшену Крім розвитку продуктів портфеля, команда постійно знаходиться в пошуку нових ідей. Так 2022 року ми знайшли нішу, у якій можна було отримати кратне зростання, і почали працювати над MVP (Minimal Viable Product) нового вебпродукту — сервісу з роботи з документами. Ми вже мали певну експертизу в подібній ніші бізнес-утиліт. Я працював над розвитком Scan Guru. Памʼятаю, як отримав завдання збільшити конверсію, продивився беклог і зрозумів, що команда протестила вже таку кількість гіпотез з покращення екранів, функціоналу, воронок та креативів, що з новини ідеями буде непросто. Коли ти запускаєш продукт з нуля, в тебе немає нічого: продукту, користувачів, процесів, бізнес-логіки тощо. Є тільки ідея, базова команда та мотивація. Ти пишеш документацію, будуєш графіки, створюєш чати, оформлюєш борди. Це процес, який вимагає постійних змін та нових компетенцій на кожному етапі. Наприклад, коли ми створили MVP продукту і почали залучати туди перших користувачів, зʼявилася потреба налаштувати сапорт-команду — добре, коли продакт-менеджер може організувати їхню роботу, комунікувати, як правильно відповідати, що треба робити, а чого не варто. Наступна проблема: користувач хоче заплатити, а в нього не виходить. Треба розбиратися чому, вивчати тонкощі. Налаштування платіжної інфраструктури — «чорна діра» за кількістю знань і експертизи, куди мені довелося зануритися, чому я дуже радий. Так зона моєї відповідальності кратно зростала з кожним новим викликом. Коли проєкт вже мав позитивну динаміку, зʼявилася потреба у людині, яка очолить багато процесів, і я отримав позицію Head of Product нового вебпродукту, про який ми незабаром розповімо. Виклик, над яким ми працюємо прямо зараз — надшвидке зростання. Здавалося б, це не може стати проблемою, проте на цьому етапі можна наробити чимало помилок. Коли одночасно масштабується технічна та продуктова команди, важливо правильно налаштувати процеси, щоби уникнути хаосу. Тих, чия карʼєра стрімко розвивається, часто переслідує синдром самозванця або ж навпаки надлишкова самовпевненість. Думаю, важливо бути відкритим та вміти чути фідбек. Не можна завжди бути готовим на 100% до викликів та знати усі відповіді. Варто іноді вмикати режим «Індіана Джонс», який вміє стрибати у невідомість та пробувати знайти рішення. «Треба тестити» — неофіційний слоган команди Universe і відповідь на більшість питань.

  • Impulse став світовим лідером серед iOS-застосунків у ніші Health&Fitness 

    Застосунок для тренування мозку Impulse, який є частиною EdTech-компанії Headway, посів перше місце за кількістю завантажень у категорії Health&Fitness й уже два роки залишається лідером серед iOS-застосунків у цій ніші. Наразі продукт завантажили понад 55 мільйонів користувачів. Середня оцінка застосунку в App Store — 4,7, яка сформована на основі понад мільйону оцінок. У 2023 році Impulse потрапив до десятки лідерів App Store за світовим доходом у категорії Health&Fitness. Impulse — це застосунок для тренування мозку, що покращує пам’ять, увагу та логічне мислення за допомогою bite-sized-ігор. Застосунок є світовим лідером у ніші Brain Training за виторгом та завантаженнями, аніж усі конкуренти разом взяті (2021-2023 роки).

bottom of page