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

Одноденне змагання Marketing Hackathon відбудеться 2 червня у Києві. Участь можуть взяти маркетологи, студенти та спеціалісти інших сфер, які прагнуть дізнатися більше про особливості роботи з ІТ-продуктами та розвиватися в маркетингу. Подію організовує Genesis Academy, екосистема освітніх можливостей для професійного розвитку та навчання у сфері продуктового ІТ. За сім годин хакатону учасники в командах мають розробити маркетингову стратегію для нового ІТ-продукту та виконати наступні завдання: Визначити ринок. Визначити цільову аудиторію продукту. Сформувати ціннісну пропозицію. Презентувати виконані кейси журі. До кожної команди буде прикріплений ментор, який має досвід просування та масштабування продуктів із сотнями мільйонами користувачів по всьому світу. Серед них – топменеджери та фахівці з екосистеми Genesis: компаній Universe Group, Boosters, АМО, Venture Partnership 6037, а також партнерських компаній Quarks, Headway, SKELAR, appflame. Результати хакатону будуть відомі одразу в день його проведення. Найкращі учасники зможуть отримати офер у Genesis, а команди-переможці хакатону – цінні призи. Як потрапити на хакатон Щоби взяти участь у хакатоні, необхідно зареєструватися, пройти онлайн-тестування та заповнити анкету. Заявки на участь приймаються до 19 травня 2024 року включно. Реєструватись можна як індивідуально, так і командами. Учасників, які зареєструвались індивідуально, організатори самостійно розділять на команди. Подати заявку та ознайомитися з відгуками учасників можна за посиланням.

Повномасштабна війна продиктувала нові виклики для підприємців – захистити своїх людей, зберегти бізнес і мати можливість допомагати державі оборонятися. Корпоративна соціальна відповідальність (КСВ) перестала бути бізнес-функцією великих компаній, а стала необхідністю для кожного свідомого бізнесу. Щоби здобути максимальний ефект від кожної інвестованої гривні, бізнесу варто підходити до КСВ стратегічно і системно. Анастасія Кладова, Head of CSR Genesis, поділилася практичними порадами й кейсами з досвіду компанії, які допоможуть бізнесу сформувати пріоритети та визначити власний КСВ-вектор. Робіть проєкти з довгостроковим впливом Поточні потреби війська, як дрони чи автомобілі, — критично важливі й досі потребують залучення волонтерів та бізнесу. Ці запити потрібно закривати, але разом з тим — втілювати проєкти, які будуть давати довгостроковий ефект, тобто допоможуть здобути стратегічну перевагу війську. Наприклад, можна фінансувати програми, які сприяють розвитку використання безпілотних технологій та цифровізації війська, або підтримувати ініціативи, які дають сучасну освіту військовим командирам. У 2023-му Genesis та ще партнерських 5 компаній підтримали «Вишкіл капітанів» – навчальний курс для військових лідерів за стандартами НАТО. Протягом року його завершили 525 офіцерів, а вплив від курсу відчують щонайменше 50 000 військових. Процитую одного з випускників Вишколу: «У наш час навчання і знання зберігають життя навіть більше, ніж броня». Сучасна освіта точно даватиме довгостроковий ефект для війська, тому її варто додати до КСВ-пріоритетів. Оберіть спеціалізацію і втілюйте проєкти комплексно Відмовляти в допомозі — це найважче у соціальній роботі. Втім, запитів значно більше, аніж можливості допомогти. Щоби КСВ була ефективною, варто обрати пріоритет: напрям допомоги (дрони, авто чи такмед) або субʼєкти, з якими ви будете працювати (підрозділ чи цілий рід військ). У 2023-му Genesis з партнерами комплексно допомагали ТрО. «Вишкіл капітанів» — це освіта для офіцерів ТрО, «Здіймемо рокіт» – забезпечення комплектами аеророзвідки чотирьох бригад ТрО, «Броня для життя» – відновлення чотирьох БТЛБ (легкі бронетранспортери) для евакуації поранених воїнів ТрО. Ми намагалися вибудувати систему так, щоби бригади, в яких служать випускники Вишколу, крім знань, отримували й технічні засоби. Це дає впевненість в тому, що інвестовані в КСВ кошти принесуть комплексний результат, який ми вимірюємо збереженими життями. Не відмовляйтеся від довоєнних КСВ-пріоритетів КСВ-пріоритети з періоду до повномасштабного вторгнення варто переглянути, але не викреслювати зовсім. Бо ми маємо і надалі розвивати Україну як сильну та економічно успішну державу, адже економіка також є невіддільною частиною оборони. Якщо серед ваших пріоритетів були, наприклад, освіта для молодих фахівців чи розвиток підприємництва, це залишається актуальним і зараз. Тому додайте до КСВ-пріоритетів освіту для цивільних — починайте готувати кадри як для своєї компанії, так і для індустрії. Genesis ще у 2021-му запустила систему Всеукраїнських курсів для університетів за сферами продуктового ІТ. Після повномасштабного вторгнення проєкт не закрили, а навпаки — масштабували. Ці курси інтегрували в понад 200 університетах і їх уже пройшли понад 10 000 студентів. Скоро вони почнуть працювати в українських ІТ компаніях і допомагати генерувати валютні надходження в Україну. Розширюйте можливості для жінок у бізнесі За оцінками Deloitte, жінки займають 33% посад в технологічних компаніях у світі. «Скляна стеля» для жінок в багатьох сферах все ще існує, і в технологічній індустрії, на жаль, це часто трапляється. STEM-ініціативи для жінок, сприяння жіночого підприємництва не втрачають своєї актуальності. Знайдіть соціальну місію у своїх продуктах Це особливо актуально для компаній, які не можуть виділяти значні суми на КСВ. Наприклад, якщо у вас ШІ-стартап для розшифровки аудіо, — ви можете зробити його безкоштовним для журналістів, які розслідують воєнні злочини росії. Якщо у вас освітні продукти, їх можна зробити безкоштовними для ветеранів чи рідних військових. До прикладу, платформа для вивчення мов Promova з екосистеми Genesis стала одним із перших продуктів у національній програмі популяризації англійської мови Future Perfect. Українцям відкрили безкоштовний преміумдоступ до чотирьох курсів англійської на три роки. Створіть баланс між КСВ в Україні та ESG за кордоном Актуально для глобальних компаній. З країнами, де немає війни, ми живемо в різних реальностях. За кордоном соціально-відповідальна компанія зменшує карбоновий слід, турбується про клімат та робить максимально прозорою свою діяльність. Все це в комплексі називається ESG: поєднання екології (Environmental), соціального розвитку (Social) та прозорого корпоративного управління (Governance). Рівень ESG вказує на те, як бізнес працює із ризиками та впливами своєї діяльності в цих трьох напрямках.  В Україні ми маємо приділяти увагу усьому вищезазначеному, а до того ж — допомагати війську та людям, що страждають від війни. Втім, закордонні стейкхолдери можуть не сприймати мілітарних КСВ-проєктів своїх клієнтів чи партнерів, що несе ризики для бізнесу. Тому українські компанії, які працюють на глобальному ринку, повинні навчитися реалізовувати мілітарні КСВ-ініціативи так, щоб вони приносили бажаний результат, і, водночас не несли загроз для бізнесу. Розвивайте інклюзивність та готуйтеся зустрічати ветеранів Мабуть, у кожного українського бізнесу, який має бодай кілька десятків працівників, частина з них служить у війську. Ми всі з нетерпінням чекаємо демобілізації колег і їх повернення на роботу. Крім того, чим довше триватиме війна, тим більшою буде кількість ветеранів, за таланти яких після демобілізації буде змагатися бізнес. Тому уже сьогодні бізнес разом із державою повинні збільшувати рівень інклюзивності й створювати умови, щоб ветерани й постраждалі внаслідок війни могли реалізувати себе в мирному житті, і продовжувати приносити користь собі, рідним і суспільству. І це не лише облаштування просторів, але й створення спеціальних політик та бенефітів в компаніях, тренінги для максимально ефективного онбордингу та адаптації ветеранів в компанії й багато іншого. А якщо заглянути у мирне майбутнє, то варто уже думати над ініціативами, які допоможуть втримати людей в Україні після відкриття кордонів і будуть мотивувати українців з-за кордону повертатися додому. Важко говорити про світле успішне майбутнє, якщо не буде людей, які його творитимуть.

24 квітня видання Forbes Ukraine та сайт для пошуку роботи Robota.ua нагородили найкращих роботодавців України. В межах форуму «НадЛюди» видання оголосило учасників рейтингу найкращих роботодавців та нагородили компанії, що перемогли в окремих номінаціях. Genesis отримала нагороду «Lovemark for employees», якою відзначають компанії, що мають найбільш лояльних співробітників. Окрім цього, Genesis потрапила в десятку найкращих роботодавців країни. Партнерська компанія Headway стала другою у рейтингу. Це вже четверте дослідження місць роботи, друге за час повномасштабної війни. Для підготовки рейтингу Forbes Ukraine та Robota.ua розіслали анкети найбільшим роботодавцям країни, а також надали змогу подати заявку на участь усім охочим. Видання проаналізувало 41 875 анкет від співробітників понад 200 компаній. Відповіді співробітників становлять 70% ваги у підсумковій оцінці. Ще 20% – оцінка експертів з пошуку кадрів та профільних редакторів Forbes Ukraine, 10% – на основі інформації з відкритих джерел.

Як проходить співбесіда з маркетологами різних грейдів у продуктових ІТ-компаніях та які питання їм ставлять? Цього разу досвідом проведення інтервʼю ділиться Promova — стартап, що народився в компанії Boosters з екосистеми Genesis. Це платформа для вивчення іноземних мов, яка складається із мобільного застосунку, вебсайту, групових курсів та індивідуальних уроків з репетиторами. Катерина Боровська, CMO Promova, розповіла, що питають маркетологів різних спеціалізацій на співбесіді у команду компанії. Вона поділилася найголовнішими якостями, які шукають у кандидатах, чому інтервʼюер перевіряє вміння заперечувати менеджеру, яка одна з найголовніших вимог до сеньйора, а також чим відрізняються інтервʼю для різних напрямів маркетингової команди. Публікуємо підбірку загальних питань для Junior, Middle та Senior спеціалістів, а також перелік для User Acquisition Manager, Creative Marketing Specialist та SEO Specialist. Звісно, на інтервʼю кандидатам задають лише декілька запитань з цього списку, проте він може бути орієнтиром для підготовки. У кінці статті бонус — підбірка актуальних вакансій у Promova та в інші проєкти Boosters. > Як проходять співбесіди в Promova > Що питають маркетологів на співбесідах > Співбесіда з Junior маркетологом > Співбесіда з Middle маркетологом > Співбесіда з Senior маркетологом > Питання для User Acquisition Manager > Питання для Creative Marketing Specialist > Питання для SEO Specialist > Актуальні вакансії для маркетологів Як проходять співбесіди в Promova Співбесіда з маркетологом в Promova складається з чотирьох етапів: попереднє інтервʼю з рекрутером, тестове завдання, технічна співбесіда з менеджером та баррейзинг. Ми відбираємо до себе в команду сильних гравців, тому ставимося до відбору доволі прискіпливо. Проте витрачений час завжди компенсується, коли до команди приходять «свої» люди. Запускаючи в роботу нову вакансію, ми створюємо так звану «картку найму» з максимальною деталізацією. Це важливий підготовчий етап, щоби рекрутер отримав максимум інформації. Ми фіксуємо обов'язки та зони відповідальності людини на проєкті, мінімальний досвід, обов'язкові хард-скіли, компетенції тощо. Попереднє інтервʼю триває близько 30 хвилин. Рекрутер оцінює враження, як людина відповідає, чи не губиться, який в неї бекграунд, що їй подобалось у роботі раніше, а що не подобалось, яких можливостей вона шукає, як розвивається. Його завдання: зафіксувати потенційні переваги кандидата та написати фідбек. Далі менеджер, який відповідає за цю вакансію, вивчає зворотний звʼязок рекрутера і визначається, чи давати кандидату тестове завдання. Ми намагаємося не робити його складним, щоби виконання займало не більше двох годин, або ж пропонуємо компенсувати витрачений час. Самі завдання можуть відрізнятися, залежно від маркетингової спеціалізації. Так, питання кандидату на посаду User Acquisition Manager можуть бути повʼязані із запуском нового каналу на основі певної інформації (Acquisition Cost, CPC тощо). Marketing Campaign менеджеру запропонують продумати, як запустити, наприклад, кампанію з реактивації користувачів CRM-інструментами та ремаркетингом. Маючи початковий фідбек і результати тестового, ми складаємо перелік запитань для технічного інтервʼю. Він змінюється залежно від розвитку ситуації. Останній етап — баррейзинг, де ми ближче знайомимося з кандидатом та можемо поділитися усіма перевагами роботи в нашій компанії. Після нього ми приймаємо остаточне рішення. Приклади питань для співбесіди маркетолога з рекрутером: 1.  Чому ви вирішили змінити роботу та покинути попередню компанію? 2.  Що вам подобається у вашій роботі, а що — навпаки, не дуже? 3.  Що ви знаєте про Promova? 4.  Чи маєте досвід роботи на аналогічній посаді? 5.  Які свої навички або досвід ви вважаєте найбільш корисними для розвитку кар'єри? 6.  Назвіть свої найбільші професійні досягнення на попередніх проєктах? 7.  Які б нові навички ви б хотіли опанувати протягом наступного року? Що питають маркетологів на співбесідах Під час технічного інтервʼю ми спираємось на важливе твердження: немає спеціалістів, які знають абсолютно все. Тому шукаємо людей з певним набором якостей: хард- та софт-скілів. Більшість питань співбесіди стосується конкретних щоденних завдань, а не абстрактної теорії. Сьогодні знання — це відкрита інформація, яку можна отримати безкоштовно. Найбільша цінність спеціаліста — вміння ними користуватися у потрібний момент: придумати новий креативний концепт, побудувати валідну гіпотезу на даних, провести тестування, зробити лаконічні та чіткі висновки, ризикнути та спробувати те, чого ніхто не робив. Тому на технічному інтервʼю ми фокусуємося не на термінології, а на тому, як вирішити ті чи інші завдання. Наприклад, на одній співбесіді кандидат сильно перехвилювався і почав плутатися в термінології, назвах метрик. Водночас ми бачили, що це талановита людина, яка точно розуміла, що, як та навіщо вимірювати. У результаті цей спеціаліст отримав офер, і ми жодного разу не пошкодували про це. Кожен напрям маркетингової команди працює з певним набором інструментів — базами даних, системами аналітики, BI-репортами, платформами для автоматизації тощо. Під час співбесіди ми питаємо загалом про досвід користування цими тулзами, проте якщо людина користувалася аналогами, це не проблема. Усі вони працюють за одним принципом, тому можна швидко опанувати ці інструменти. Головне, щоби кандидат розумів коли, де та як отримати дані, чи можна їм довіряти, як їх валідувати та потім використати. Розмовляючи про досвід, ми просимо кандидатів згадати про досягнення, нові підходи, реалізацію незвичних проєктів. Часом також перевіряємо рівень відповідальності кандидата. Наприклад, питаємо «якщо ви вірите у нетипове рішення, але ваш менеджер просить діяти як завжди, що ви будете робити?». Для нас важливо, щоби людина не боялася заперечувати своєму керівнику, могла аргументувати та брати відповідальність за результат. Ми дуже цінуємо таких людей та формуємо відповідну культуру всередині компанії. Коли спеціалісту, який найкраще знає, як виконувати свою роботу, не дають свободу дій — це найгірше, що може трапитись у стартапі. Це свідчить про брак довіри до команди з боку менеджера та блокує розвиток гравців у команді. «Ким ти бачиш себе через 5 років» — питання, яке часто сприймається негативно, в кращому випадку з іронічною усмішкою. Проте воно допомагає зрозуміти, в якому напрямі кандидат прагне розвиватися: горизонтально, вертикально чи навіть світчнутися в іншу спеціальність. Задача менеджера — створити для кандидата сприятливу та дружню атмосферу, щоби він міг відверто говорити про свої плани на майбутнє.Якось на співбесіду прийшов кандидат на позицію SEO-копірайтера. Протягом баррейзингу ми побачили, що людина дуже амбітна, талановита, має сильний бекграунд у сфері продажів. Через пів року спеціаліст проявив цікавість до спеціальності PMM (Product Marketing Manager), тож після стажування та виконання тестового завдання перейшов до Growth-команди. Ми намагаємося створювати різні можливості для розвитку карʼєри, і це питання допомагає визначитись, куди людині цікаво рухатись. Співбесіда з Junior маркетологом Інтервʼю з кандидатами рівня Junior можна назвати умовно технічним, адже ми більше звертаємо увагу на софт-скіли: чим людина цікавиться, чим займалася раніше. Це можуть бути світчери, які переходять з іншої індустрії, або випускники закладів вищої освіти. Зазвичай такі кандидати не мають сильного бекграунду чи досвіду у маркетингу. Ми звертаємо увагу на те, чи розуміє людина, чим вона буде займатися, а також чим її зацікавила ця спеціальність. Спеціаліст у маркетингу доволі швидко здобуває хард-скіли та відточує їх. Для нас важливо, щоби він не працював за чіткою інструкцією, ніби «за підручником», а шукав інші підходи, експериментував. Також звертаємо увагу на комунікативні навички кандидата: чи може він вчасно просити про допомогу, поставити питання. Важливо дати зрозуміти кандидату, що на деякі запитання ми не очікуємо «правильної відповіді», нам важливо зрозуміти, як людина мислить. Приклади питань для Junior маркетолога: 8.  Опишіть свій бекграунд. Чим ви займалися раніше? 9.  Як ви дізналися про цю спеціальність? Чим вона вас зацікавила? 10. Як змінилися ваші навички за останній рік? 11.  Які нові знання, інструменти ви опанували за останній час? 12. Опишіть ситуацію, коли ви стикалися з викликом або проблемою, з якою раніше не стикалися. Як ви її вирішили? 13. Які методи або ресурси ви використовуєте для навчання та покращення своїх професійних навичок? 14. Що таке цільова аудиторія та як її визначити? 15. Які основні канали маркетингу ви знаєте? 16. Що таке SEO та чому воно важливе для маркетингу? 17. Які метрики ви вважаєте ключовими для вимірювання ефективності маркетингових кампаній? 18. Що таке CRM та як воно використовується в маркетингу? 19. Що таке конверсія в маркетингу? 20. Які бувають типи конверсій? 21. Що таке воронка продажів? Які її основні етапи? 22. Що таке контент-маркетинг та які його типи ви знаєте? 23. Що таке платний рекламний трафік? Як його можна оптимізувати? 24. Які інструменти аналітики використовують для відстеження результатів маркетингових кампаній? 25. Що таке маркетингова стратегія та як вона відрізняється від тактики? 26. Що таке A/B тестування і чому воно важливе для маркетингу? 27. Як визначити ROI маркетингової кампанії? 28. Які є способи відстеження поведінки користувачів у застосунку? 29. Що таке CTR? Як ця метрика використовується для аналізу рекламної кампанії? 30. Що таке bounce rate? Як ця метрика визначає оцінку якості трафіку? Співбесіда з Middle маркетологом Спеціаліст цього рівня має певний базовий бекграунд, зокрема досвід роботи з різними рекламними платформами. Важливо, щоби кандидат розумів відмінності та нюанси роботи з ними. Зазвичай ми говоримо про базову аналітику, конверсії, атрибуцію, приклади сетапів кампаній, автоматизацію, специфіку контенту тощо. Також ми моделюємо ситуації, щоби зрозуміти, як людина діє в кризових ситуаціях: якщо виникають проблеми з кампаніями, бюджетом, не вдається досягти KPI тощо. Приклади питань для Middle маркетолога: 31. З якими найбільшими викликами ви стикалися протягом розвитку карʼєри? Як їх долали? 32. Опишіть найбільш нестандартне завдання на минулих проєктах. Як ви його вирішували? 33. Уявіть, що ви знайшли нетипове рішення і дуже в нього вірите, але ваш менеджер просить робити, як завжди. Ваші дії? 34. За якими KPI ви працювали на минулому проєкті? 35. Якщо вам не вдається досягти KPI, які ваші дії? 36. Компанія провела маркетингову кампанію та зібрала дані про її результати. Потрібно проаналізувати їх та зробити висновки. З чого почнете? 37. Якими маркетинговими дослідженнями ви користуєтесь? Як застосовуєте на практиці? Наведіть приклад. 38. На основі яких даних ви робитимете висновки про ефективність кампанії? 39. Компанія має дані про відвідуваність та поведінку користувачів. Які метрики вивчатимете в першу чергу? Чому? 40. Опишіть сетап нової рекламної кампанії. 41. Як ви визначатимете цільову аудиторію? Які критерії ви використовуєте для сегментації аудиторії? 42. За якими принципами ви обираєте канали просування для рекламної кампанії? Як ви розподіляєте бюджет між різними каналами? 43. Які KPI ви встановлюєте для оцінки успіху кампанії? 44. Які особливості рекламних каналів варто врахувати, плануючи нову кампанію? 45. Поділіться досвідом інтеграції даних з різних рекламних платформ для аналізу та звітності. 46. Як забезпечити синхронізацію даних між різними системами через API? 47. Чи був досвід моніторингу за рекламними кампаніями в реальному часі через API? 48. Чи можете навести приклади використання API для автоматизації процесів управління рекламними кампаніями? 49. Під час взаємодії з API рекламної платформи виникли помилки. Які кроки ви здійснюєте для їх виправлення? 50. Які мікроконверсії ви вважаєте найважливішими для рекламної кампанії та чому? 51. Як ви використовуєте мікроконверсії для ретаргетингу або персоналізації рекламних кампаній? 52. Наведіть приклади успішних кейсів роботи з мікроконверсіями. 53. Які методи ви використовували для контролю та оптимізації рекламного бюджету, щоби досягти конкретних рівнів витрат. Які були результати? 54. Наведіть приклад рекламної воронки та наведіть середні значення для вашої ніші? 55. Promova хоче запустити продукт на новому ринку. Які стратегії ви запропонуєте? 56. Ваша рекламна кампанія не починається за плановим часом. Ваші дії? 57. Бюджет рекламної кампанії вичерпано раніше, ніж планувалося. Як можна оптимізувати використання бюджету? 58. Рекламні матеріали мають низьку конверсію. Ваші дії, щоби проаналізувати та вдосконалити контент? 59. Рекламна кампанія не досягає цільової аудиторії. Ваші дії? 60. Ви помітили високий CPC без відповідного збільшення конверсії. Як відреагуєте? 61. Рекламна кампанія має високий Bounce Rate. Які заходи приймаєте для його зниження? 62. Як ви вирішуєте конфлікт інтересів між рекламними каналами для оптимізації використання бюджету? 63. Рекламна кампанія зіштовхується з негативними відгуками або критикою в соціальних мережах. Ваша реакція? 64. Рекламна кампанія привертає увагу великої кількості нецільової аудиторії. Як скоригувати налаштування? Співбесіда з Senior маркетологом Зазвичай рівень сеньйор у маркетингу передбачає щонайменше два роки досвіду з різними платформами. Це скілова людина, яка мислить стратегічно. Вона не просто виконує певне завдання, а може менеджерити його «під ключ» — організувати запуск каналу з нуля, знає, які креативи потрібні, як налаштувати аналітику, таргети та все необхідне. Її можна поставити на будь-яку ділянку, і вона там «зробить вітер». Та найголовніше — зможе вирішувати завдання стратегічно у зв'язці з іншими каналами або напрямами. Проблема з сеньйорами полягає в тому, що окрім маркетингових завдань, ця роль часто передбачає навчання інших (зокрема джунів), або вертикальне зростання до тимліда або менеджера. Проте плани особистого розвитку у всіх різні — не всі люблять менторити та готові приділяти цьому час. На інтервʼю з сеньйорами звучать технічні питання, але фокус — більше на софт-скіли: наскільки цей кандидат зможе зростати вертикально до менеджера, чи є у нього зацікавленість до продукту, який ми розвиваємо, компанії, чи резонує йому наша місія. Ці питання є основним фактором довготривалих робочих стосунків. Приклади питань для Senior маркетолога: 65. Якими максимальними бюджетами рекламної кампанії ви керували? 66. Як ви підходили до сегментації цільової аудиторії? 67. Опишіть, як ви здійснюєте аналіз конкурентів? Для чого, які інструменти використовуєте? 68. Коли ви приходите до нової команди, які аналітичні звіти ви б переглянули в першу чергу? 69. Назвіть останні маркетингові тренди? Чи застосовували ви їх в роботі? 70. Що важливіше: продукт, креатив чи налаштовані інструменти? 71. Маркетингова стратегія якої компанії вам імпонує? Наведіть приклади. 72. Різкі зміни в поведінці споживачів призвели до зниження ефективності рекламної кампанії на основних каналах. Як ви будете адаптувати рекламну стратегію в нових умовах? 73. Деякі канали не досягають очікуваних результатів, але працюють на одну цільову аудиторію. Ваші дії? 74. Новий продукт потребує швидкого впровадження на ринок. Як розробити та впровадити маркетингову стратегію в умовах обмеженого часу? 75. Партнерські програми не приносять очікуваних результатів. Як їх оптимізувати? 76. Різні команди маркетингу працюють незалежно одна від одної, не координуючи свої дії. Як би ви вирішили цю проблему? 77. Сезонні чи глобальні події впливають на споживчі настрої та поведінку. Як ви використовуєте ці тренди для адаптації маркетингових стратегій? 78. Чи був досвід менторингу молодших спеціалістів? Які ваші враження? 79. Уявіть, що вам потрібно делегувати одну зі своїх функцій джуніор-спеціалісту. Ваші дії? 80. Запропонуйте ключові показники ефективності (KPI) для моніторингу успіху стратегії. 81. Компанія хоче оптимізувати свій маркетинговий бюджет та зосередити увагу на найбільш ефективних каналах просування. Як би ви провели аналіз маркетингових каналів, щоби визначити їхню ефективність? 82. Запропонуйте стратегію для моніторингу та аналізу витрат. 83. Запропонуйте рекомендації щодо розподілу бюджету між різними каналами. Спеціалізації маркетологів Загалом над маркетингом Promova зараз працює 30 людей. Команда складається з таких напрямів: Paid Acquisition Team, куди входять User Acquisition та Creative Marketing спеціалісти. Organic Acquisition Team. Займається SEO (Search Engine Optimization) і ASO (App Store Optimization) та має власних райтерів, лінкбілдерів та інших спеціалістів. Ця команда повністю закриває органічне залучення користувачів, а також SERM-функції. Partnership Team. Ця команда працює з реферальним трафіком. Тобто це афіліат- та інфлюенс-маркетологи. Growth Team. Складається з декількох людей, їхнє основне завдання — конвертувати весь трафік, який ми проводимо, на різні плейсменти. MarkOps (Marketing Operations). Відповідає за всі активи компанії (підписки, контентні продукти та інші), а також стратегію апсейлів, реалізацію стратегічних партнерських проєктів, Go-to-market стратегії тощо. Також у Promova є окрема функція монетизації, яка наразі активно розвивається. Спеціаліст тестує різні підписки, ціни та займається підтримкою платіжної інфраструктури компанії. Важливо, щоби незалежно від спеціалізації кожен розумів суть продукту та етап його розвитку. Тісна взаємодія між продуктом і маркетингом — це основа для швидкого зростання компанії. Співбесіди з різними видами маркетологів містять як загальні питання, перелічені вище, так і вузькоспеціалізовані. Наводимо приклади для User Acquisition Manager, Creative Marketing Specialist та SEO Specialist. Питання для User Acquisition Manager: 84. Як ви визначаєте цільову аудиторію для рекламних кампаній? 85. З якими каналами залучення користувачів ви працювали? 86. Як обрати найефективнішу рекламну платформу для цільової аудиторії? 87. Як виміряти ефективність рекламних кампаній? Які основні метрики ви використовуєте? 88. Назвіть декілька способів оптимізації рекламного бюджету для досягнення найкращого ROMI? 89. Як ви працюєте з тією частиною воронки, де користувачі відходять або не завершують конверсію? 90. Опишіть ваш досвід взаємодії з іншими командами для досягнення спільних цілей залучення користувачів? 91. Розкажіть про досвід роботи з рекламними креативами. Чи придумували ви їх самостійно? 92. Чи є у вас досвід автоматизації роботи? Як це перегукувалося з ручною роботою? 93. Вам ставлять завдання запустити новий канал залучення користувачів. Які дані вам потрібні для побудови стратегії? 94. Які інструменти використовуєте для збору, аналізу та інтерпретації даних? 95. Які інструменти використовуєте для візуалізації даних? 96. Як вирахувати конверсію в різних каналах? Які метрики ви використовуєте для цього? 97. Опишіть процес, як ви аналізуєте конверсії? 98. Які стратегії ви використовуєте для оптимізації конверсії? Можете навести приклади успішних кейсів? 99. Як ви генеруєте гіпотези для оптимізації конверсії? Які інструменти або методи ви використовуєте для перевірки цих гіпотез? 100. Як ви аналізуєте результати A/B тестувань? Які критерії ви використовуєте для визначення статистичної значущості та успішності тесту? Питання для Creative Marketing Specialist: 101. Які соціальні мережі ви використовували для створення рекламних креативів 102. Як ви адаптуєте контент під кожну платформу? 103. Як ви вимірюєте ефективність креативів на різних платформах? 104. Як ви проводите аналіз ринку, щоб ідентифікувати тренди, конкурентів та інсайти споживачів? 105. Які інструменти ви використовуєте для систематизації та узагальнення креативних матеріалів? 106. Як ви адаптуєте рекламні креативи до різних цільових аудиторій? 107. Як ви інтегруєте AI-інструменти в процес створення рекламних креативів? 108. Які фото- та відеоредактори ви використовуєте для створення рекламних матеріалів? 109. Як ви оптимізуєте креативи для підвищення конверсії та залучення цільової аудиторії? 110. Опишіть досвід дослідження конкурентів для пошуку креативних концепцій? 111. Як ви адаптуєте креативи для різних етапів воронки продажів? 112. Як ви забезпечуєте відповідність рекламних креативів правилам та стандартам платформи? Питання для SEO Specialist: 113. Сайт підпадає під зміну алгоритмів пошукової системи. Ваші дії? 114. Опишіть свій підхід до побудови лінкбілдинг стратегії для сайту. 115. Які основні фактори ви вважаєте найважливішими для оптимізації вебсайту під пошукові системи? 116. Опишіть, як ви проводите SEO-аудит вебсайту? Які інструменти використовуєте? 117. Опишіть свій досвід оптимізації технічної частини SEO? 118. Які теми можуть залучати аудиторію в застосунок для вивчення мов? На який трафік можна розраховувати? 119. Які вимоги до статті ви б поставили? 120. Як ви використовуєте ШІ у своїй роботі, як він допомагає? Червоні та зелені прапорці Бажання просто виконувати свою роботу. В цьому прагненні немає нічого поганого, якби це не був відділ маркетингу у стартапі. Це надзвичайно динамічне середовище, у якому немає двох однакових задач кожного кварталу. А якщо вони схожі, то скоріше за все ми будемо використовувати різні методи. Тому якщо людина не хоче сперечатись, брати на себе відповідальність, бути ініціативною та пропонувати ідеї, на жаль на даному етапі розвитку вона нам не підходить. Усі попередні роботодавці — проблемні. Коли людина на співбесіді жаліється, що «усі неправі, а вона — квіточка», скоріше за все це не так. Трапляється, що спеціаліст працює не на своєму місці, у проєкті є мікроменеджмент, не складаються стосунки з командою. Але малоймовірно, щоби це відбувалось протягом усіх 10 років його професійного розвитку. Скоріше за все, це свідчить про конфліктність та токсичність кандидата. Спроба ухилятися від відповіді та брехати. Зазвичай це досить легко розпізнається, якщо інтервʼюер має досвід спілкування з людьми та певну емпатію. Кандидат нічого не знає про проєкт. Це свідчить про те, що людину мотивує лише фінансова винагорода, а сама компанія не цікава: вона прийшла по-чесному обміняти час на гроші. Такі кандидати не схильні докладати зусиль та часто не затримуються надовго у компанії. Дізнатися базову інформацію про компанію, прочитати декілька статей — це пункт №1 у підготовці до співбесіди.  Якщо ви додатково зробите декілька нотаток та підготуєте запитання — менеджер це точно оцінить. Загалом питання з боку кандидата — один з найголовніших «зелених прапорців» для інтерв'юера. Це говорить про те, що людина рефлексує та справді зацікавлена у цій роботі. Лишається тільки випити чаю, заспокоїтись та не нервувати: якщо ви підходите під цю вакансію, вас обов'язково візьмуть, а якщо ні — то візьмуть в інший проєкт. Актуальні вакансії для маркетологів: Creative Marketing Specialist (Promova) User Acquisition Manager (Promova) Junior Creative Marketing Specialist (Promova) CRM Marketing Manager (Promova) Middle Creative Marketing Specialist (Manifest) Junior User Acquisition Manager (Manifest)

Алгоритми та структури даних створюють основу для розв'язання ґрунтовних завдань у програмуванні. Попри те, що в багатьох галузях IT можна працювати й без них, знання у ніші роблять кожного програміста у кілька разів компетентнішим, допоможуть пришвидшити та удосконалити його роботу. Tech Lead в Futurra Group Антон Чередниченко у своїй колонці розглядає кілька причин, які можуть підштовхнути розробників до вивчення алгоритмів та ділиться ресурсами, які можуть у цьому допомогти. Для початку визначимося з самим поняттям. Алгоритмами у розробці називають певну послідовність дій, які виконуються для розв’язання конкретної задачі. По суті, це «рецепт», який описує, як саме комп’ютер має обробляти вхідні дані, щоб одержати конкретний результат. Серед алгоритмів є прості, як-от обчислити суму, знайти максимальний елемент у масиві або прості числа у заданому діапазоні. А є складніші — наприклад, K-Mean для кластеризації даних або AES для захисту їхньої конфіденційності. Розберемося докладніше, для чого їх вивчати. Здатність швидко опанувати будь-який технологічний стек Я не можу сказати, що алгоритми, структури даних, теорія ймовірностей чи алгебра — це те, без чого неможливо бути розробником. Існує купа напрямів та завдань, де і без них можна стати хорошим фахівцем. Це, наприклад, створення вебсервісів або простих мобільних застосунків. Однак знаючи, як влаштовані алгоритми та структури даних, ви зможете опанувати будь-який технологічний стек. Вони не зв'язані на конкретних мовах програмування чи фреймворках. Тому, якщо у розробника є відповідна експертиза, і до нього потрапляє незнайома задача, він розуміє, який шлях найкраще підійде для її реалізації. Алгоритми можуть не бути прямо пов'язані з поточною роботою, але вони розширюють кругозір та допомагають краще орієнтуватися у технологічному середовищі. Вивчаючи їх, можна краще розуміти архітектуру Інтернету загалом та механізми, які використовуються в масштабних продуктах. Це відкриває нові перспективи та дає змогу ефективніше вирішувати завдання в майбутньому. Можливість одержати роботу у MAANG-компаніях Компанії на кшталт Google, Amazon чи Netflix, зазвичай беруть на роботу не вузького фахівця зі знанням певної мови програмування, а наймають розробника-інженера. Тоді вони впевнені: маючи людину з фундаментальними знаннями, зокрема алгоритмів та архітектури систем, її можна поставити на проєкт в будь-якій ніші — і вона зможе рости та розвиватися. Ба більше: під час прийому на роботу компанії звертають увагу на  рейтинги програмістів на платформі LeetCode. Підхід загалом широко застосовується у Європі та Америці. Багато бізнесів, які розуміють цінність подібних знань, вкладаються у навчання й самостійно вирощують технічних інженерів. Знаю такий кейс — мій друг колись поїхав до Лондона на безкоштовне навчання. Компанія відібрала 500 людей та мінімально покрила всі базові витрати. Навчання тривало шість місяців, вони вивчали мови програмування, алгоритми, системний дизайн. Мій друг розповідав, що це навчання було найскладнішим в його житті, а робота, яку він отримав після успішного складання іспиту, була вже набагато простішою. Створення інновацій Чому вимоги до роботи у MAANG-компаніях завжди були високими, а увага роботодавців до кваліфікації працівників тільки зростає? Ці бізнеси створюють інновації. Так, до YouTube важко було уявити цілі міста, створені під дата-центри, які будуть забезпечувати стрімінгові послуги по всьому світу. А ринок хмарних рішень нині неможливий без AWS, який зародився через необхідність компанії знизити витрати на сторонні сервери. Через це технологічні компанії пильно стежать за американськими технологічними університетами, які щороку випускають технічних фахівців високого ґатунку. Багато світових лідерів зароджувалися саме там — достатньо згадати Facebook, Dropbox чи WordPress. Інший приклад — Китай. Попри ізольованість від інших ринків, там вміють робити рішення на мільярди користувачів. Технологічний прогрес цієї країни помітний у багатьох галузях — починаючи від розробки власної архітектури набору інструкцій для процесорів до створення мікросхем ШІ, швидкість яких перевищує показники Nvidia в 3000 разів. А за всіма здобутками стоять вчорашні студенти з топовими позиціями у рейтингах LeetCode. Допомога Україні у боротьбі з ворогом Нині до Defence та Military Tech активно долучаються багато програмістів. Вони створюють програмне забезпечення для техніки, проєктують дрони та вирішують інші завдання. Стартапи у цій галузі залучають гранти від держави та приватних інвесторів, іноземні компанії відкривають офіси в Україні, а Міністр цифрової трансформації прогнозував, що країна може стати світовим лідером за розвитком military tech. Водночас завдання в цій галузі набагато складніші, ніж будь-де. Через це багато напрямів, як-от кібербезпека, проєктування дронів, радіоелектронів, шукають саме інженерів, які можуть вирішувати якраз-таки широкий спектр завдань та швидко опановувати потрібні технології. Однак є проблема: багато розробників здатні писати код, але не мають поглиблених знань математики, фізики та інших дисциплін. Якщо є бажання працювати у цій сфері, але не вистачає знань, то вивчення алгоритмів може стати хорошим початком, щоб їх надолужити. Як і коли вивчати алгоритми Ідеально починати ще в школі чи університеті. Тоді можна закласти базу, яка допоможе у розумінні архітектури. Це особливо актуально для бекенд-розробників, DevOps-інженерів та архітекторів ПЗ. Якщо такої можливості не було, допоможуть платформи LeetCode та NeetCode, а також навчальні програми на кшталт GRIND. Вирішення достатньої кількості задач на платформі допоможе суттєво вдосконалити свої вміння. Однак, якщо натхнення розв’язувати задачі по вечорах після роботи не вистачає, надолужити знання допоможе спільнота. Наприклад, в Україні є проєкт, де люди обговорюють, що вчити для роботи в MAANG-компаніях, та як проходити співбесіди до них. Його організатор нині виступає як коуч, він зібрав навколо себе дуже багато людей. Свого часу я цікавився алгоритмами та системним дизайном — і навчався саме через таку спільноту. Охочих було багато, тож нас розподілили на групи по 15 людей. Ми брали одну тему з LeetCode і присвячували їй тиждень: збиралися на обговорення, вирішували завдання і так поступово рухалися за заздалегідь сформованою програмою. Коли я пройшов це навчання, то більше дізнався про свою мову програмування PHP, почав розуміти, як все працює «під капотом», як влаштовані бінарні операції тощо. Тому я думаю, що подібні ком’юніті — це класна можливість для розвитку, адже поруч є багато замотивованих IT-спеціалістів. Їм можна поставити будь-яке питання й одержати дуже різноманітні фахові відповіді.

У травні видавництво «Лабораторія» у партнерстві з Genesis випускає книгу «Хто. Як наймати найкращих». Її написали Джефф Смарт та Ренді Стріт. Перший — голова та засновник глобальної консалтингової компанії з питань лідерства ghSMART, другий — керівний партнер цієї організації, який понад 25 років консультує топменеджемент з питань найму. У своїй книзі вони акцентують: ефективні співробітники, які ухвалюють рішення та керують напрямами, набагато важливіші  за «правильні» стратегії та процеси. Genesis долучився до видання, адже компанія також робить ставку на найм найкращих, має багато етапний процес відбору та цілу культуру навчання для менеджерів. Публікуємо уривок з нової книги — про те, з чого починається успішний найм. Картка найму: проєкт успіху Картки найму — ваш проєкт успіху. Спираючись на теоретичне визначення Гравця А, вони конкретно описують роботу, для якої вам потрібно знайти виконавця. Картки найму вміщують місію посади, очікувані результати й компетенції, які відповідають і культурі організації, і функціональним обов’язкам. Ви не хотіли б, щоби вам будували житло без проєкту архітектора. Тож і не думайте проводити найм у команду, якщо не маєте відповідного проєкту. На багатьох наших перших зустрічах із клієнтами стає очевидно, що вони не завдають собі клопоту сформулювати власні побажання до того, як когось наймати. Нещодавно ми працювали із глобальною фінансовою установою, яка хотіла найняти віцепрезидента зі стратегічного планування. «У чому полягає ця робота?» — спитали ми відповідального за найм службовця. Він відповів: «Ну, ми шукаємо когось, хто може співпрацювати з різними бізнес‐підрозділами й об’єднати їхні плани в головний бюджет. Нам дуже потрібен інтегрований план. Віцепрезидент зі стратегічного планування допоможе зібрати всі ідеї в єдину програму». Керівник цього службовця теж сидів у кімнаті. У цю мить він поспішно втрутився в розмову: «Це взагалі не те, що нам треба! Нам потрібен не тактичний планувальник, а лідер‐візіонер. Той, хто вміє досліджувати ринок і допоможе нам розробити нові стратегії та продукти. Нам потрібна людина, з якою ми випереджатимемо конкурентів». Кімната зашуміла: вони 20 хвилин обговорювали свої суперечливі думки про роль стратегічного планування. Зрештою менеджер‐наймач сказав: «Я вже збирався запропонувати цю роботу своєму найкращому кандидатові. Здається, краще із цим почекати, поки ми визначаємо, чого дійсно хочемо». Бінго! Перша помилка найму — брак чіткого розуміння, яких результатів ви очікуєте від працівника. Можливо, у вас є якась невиразна думка, чого ви хочете. Інші у вашій команді, ймовірно, теж мають власні невиразні думки про ваші бажання і потреби. Але дуже можливо, ваші невиразні думки не збігаються. Ознайомтеся з карткою найму, яку ми розробили для встановлення ваших критеріїв до конкретної посади. Невілл Айсделл, голова й колишній гендиректор CocaCola Company, поділився прикладом цієї концепції із власного досвіду. «У наймі все залежить від ситуації, — пояснив він нам, — і кожна ситуація унікальна. На різних етапах розвитку організації вам будуть потрібні різні типи лідерів. Коли я прийшов гендиректором у Coca‐Cola, мені знадобився новий керівник HR‐відділу. У нас були серйозні проблеми з моральним станом і HR‐відділ поважали, мабуть, найменше. Я шукав того, хто міг би змінити ситуацію, налагоджуючи співпрацю, і зробити це енергійно, завзято і швидко. Це означало, що мені був потрібен працівник із високим рівнем емоційного інтелекту, дуже глибоким знанням бізнесу, чудовими навичками спілкування і вмінням налагоджувати стосунки. То був конкретний тип ситуації, який вимагав конкретного типу людини». Завдяки цьому чіткому розумінню ситуаційної потреби Невілл Айсделл призначив Синтію Маккейґ, яка отримала цю посаду саме за риси, що шукав Айсделл. Картка найму складається із трьох частин: місія, результати й компетенції. Разом ці три частини описують А‐результативність — чого має досягти людина та як. Вони встановлюють чіткий зв’язок між працівниками, яких ви наймаєте, і вашою стратегією. Місія: суть роботи Місія стисло викладає головне, для чого призначена робота. Вона конкретизує її суть, тому кожен розуміє, чому вам потрібно найняти когось на вільне місце. Подивіться на приклад картки найму на наступних сторінках. Місія віцепрезидента із продажів чітко пояснює, для чого існує ця посада: збільшувати дохід через прямі контакти із промисловими клієнтами. Ось у чому її суть. Не в тому, щоби створювати канали продажу. Не шукати нові промислові вертикалі. Не працювати адміністратором. Щоби місія мала сенс, її треба написати простою мовою, а не канцелярщиною, яка сьогодні дуже поширена в бізнесі. Ось ідеальний приклад того, як не треба робити: «Місія цієї посади — максимізувати вартість акціонерного капіталу через використання основних активів NPC‐підрозділу, мінімізуючи недоліки та плутанину в комунікації». Це перебільшення, але не надмірне. Закладаємося, ви знайдете у своїй компанії схожі позбавлені сенсу формулювання. І закладаємося, той, хто їх написав, і гадки не мав, якою є та якою має бути ця робота. Якщо усунути зайве, ваші місії будуть стислими, милозвучними та, найголовніше, зрозумілими. Ви знатимете, що місія гарна, коли кандидати, рекрутери та навіть інші члени вашої команди розуміють, кого ви шукаєте, без потреби в уточнювальних запитаннях. У випадку тієї компанії з надання фінансових послуг незгода про роль стратегічного планування ніколи б не виникла, якби було чітке формулювання місії. Це могло б бути щось таке: «Діяти як лідер‐візіонер, який допомагає банку забрати в конкурентів частку ринку, аналізуючи його й розробляючи успішні нові стратегії та продуктові пропозиції». Це місія, яку зрозуміє будь‐хто в бізнесі. Місії допомагають вам уникнути однієї із найпоширеніших пасток: найму спортсмена‐багатоборця. Спортсмени‐багатоборці — це кандидати, які приходять до нас і демонструють разючу особисту історію, яскравий імідж, список гідних захоплення досягнень на різноманітних місцях роботи. За три роки подвоїти наш дохід, підписавши великі вигідні контракти із промисловими клієнтами. Ство­рити одну пошукову команду для виявлення нових за­мовників й одну операційну команду для роботи з по­точними. Таке враження, що вони вміють усе. Вони гарно говорять, швидко навчаються, мають широкі погляди на стратегію компанії і запевняють нас, що здатні пристосуватися до практично будь‐якої проблеми чи завдання, які компанія може покласти їм на плечі. У теорії, хто б не погодився взяти когось такого в команду? Проте дуже часто наші інтерв’ю із гендиректорами й вищими керівниками виявляють, що найм спортсменів‐багатоборців рідко допомагає. Вони універсали за визначенням. У цьому їхня привабливість. Вони багато що вміють добре робити і здатні діяти в багатьох різних амплуа. Але посадові вимоги зрідка універсальні. Якщо ви від початку правильно визначили суть роботи, вам необхідно шукати вузьку, але глибоку компетенцію. Подумайте про це з медичної точки зору. Сімейний лікар чудово виконує свою роботу, поки ви приходите до нього зі звичайним кашлем, застудами й тестами на холестерин. Але якщо діагноз поставити складно чи проблема загрожує життю, ви якомога швидше йдете до спеціаліста. Ви ж не дозволите своєму сімейному лікарю робити вам операцію на відкритому серці, і так само вам не варто шукати цілу команду універсалів, щоб усунути свої бізнес‐проблеми. Місія має допомогти вам знайти не універсала, який укаже вам на проблему, а найкращого спеціаліста, який допоможе її позбутися. Детальніше про місію та інші частини карти найму читайте у книжці «Хто. Як наймати найкращих». Її можна замовити за посиланням.

Перші дні повномасштабного вторгнення запамʼяталися усім масованими обстрілами, заторами та чергами на кордонах. Водночас у той час відбувалася потужна атака на Україну в інформаційному просторі. В медіа та соціальних мережах ширилися тисячі фейків, які викликали паніку в українців. Зі спроби протистояти цій проблемі виріс стартап Mantis Analytics. Антон Тарасюк, Expertise Lead та співзасновник компанії розповів про шлях від волонтерської ініціативи до глобального B2B продукту. Він поділився тим, як команді вдалося залучити найкращих ML-інженерів, трансформувати досвід пошуку російської дезінформації у систему ризик-менеджменту для корпоративного сегмента та як виходити на американський ринок під час війни. До вторгнення Антон Тарасюк займався стратегічними комунікаціями у B2B та B2G сегменті. Під час перших повітряних тривог, як і багато українців, він рефлексував, чим його експертиза може бути корисною державі. «Якщо моє життя зараз скінчиться, чи хочу я, щоб головним моїм здобутком були консалтингові PDF-презентації, — думав я.  Якими б якісними та корисними вони не були, чи готовий я, щоб вони стали моїм «плювком у вічність»?», — згадує Антон. З цього почався невеликий проєкт, що моніторив іноземні новини. Познайомившись з волонтерами AI/ML-комʼюніті, він знайшов майбутніх партнерів для стартапу. Команда створила платформу, яка виявляла фейки та маніпуляції російської пропаганди. Протягом першого року проєкт існував власним коштом. З 2023 переріс у стартап, зосереджений на управлінні ризиками та захисті корпоративних активів за допомогою ШІ. Того ж року компанія стала учасником програми StartUp Academy 3.0 від Genesis та Meta. > Фактчекер для РНБО, що опрацьовує терабайти інформації > Магія LLM: як це працює > Переосмислення та трансформація проєкту > Не за планом: де фаундерам шукати знання > Вихід на американський ринок та пошук інвесторів Фактчекер для РНБО, що опрацьовує терабайти інформації Перший трекшн проєкту був швидким та досить нестандартним, адже зазвичай стартапи не починають працювати з інституціями на кшталт Ради національної безпеки та оборони. «У світі глобальних стартапів це може виглядати як шизофренія, адже така співпраця не несе швидких комерційних вигод, важко масштабується та до того ж часто є секретною, — згадує Антон. — Але ми жили в зовсім інших реаліях. Під час хаосу лютого-березня 2022 року можна було знайти будь-який контакт та прийти з пропозиціями навіть в заклади такого рівня». У когось з команди знайшлися потрібні контакти, виявилося, що у спеціалістів з РНБО була потреба в автоматизованих рішеннях моніторингу інформаційного простору. Так розпочалася співпраця РНБО та Mantis Analytics. Розробка команди допомагає виявити дезінформацію та швидко прийняти рішення, як їй протидіяти. Провести брифінг, спростовувати чи запускати контрнаратив — на відповідь є не більше 24 годин після вкиду. Якщо працювати вручну, відреагувати у такий короткий проміжок складно — перед цим інформацію треба зібрати, обробити, проаналізувати та верифікувати результати. В умовах, коли лише в одному Telegram генеруються терабайти інформації, без AI/ML-технологій не обійтися. «Ми натренували модель на пошук потенційної дезінформації та пропагандистських риторичних прийомів у великих масивах даних. Ми збираємо та опрацьовуємо  десятки тисяч одиниць контенту 24/7» — пояснює Антон. Магія LLM: як це працює Платформа Mantis Analytics — повністю автоматизоване рішення. До системи завантажується масив даних (наприклад, повідомлення та коментарі з понад сотень тисяч каналів в Telegram). Штучний інтелект обробляє їх та проводить очищення від нерелевантної інформації та розподіляє на два потоки: фізичні події та ментальні сигнали. Після цього починається «магія»: NLP та LLM моделі застосовують свої аналітичні здібності, щоби виявити потенційну дезінформацію, пропагандистські техніки, просканувати настрої в інформаційному полі та геокодувати джерела або події. Щоби навчити алгоритм все це роботи, команда спостерігала за робочими процесами фактчекерів. Система ставить оцінку потенційно небезпечним повідомленням та сповіщає про них. Додатково результат можуть верифікувати «вручну». Наприклад, у такий спосіб команді Mantis Analytics вдалося виявити вкид російських пропагандистів, у якому звільнений з полону Сергій Волинський (​​командир 36-ї окремої бригади морської піхоти, учасник оборони Маріуполя) буцімто в інтервʼю турецьким ЗМІ повідомив, що на «Азовсталі» з ними перебували високопосадовці НАТО. Алгоритм промаркував це повідомлення як дезінформацію з імовірністю у 96%. Виявилося, що це підроблена цитата, Сергій не давав такого інтервʼю, та автор тексту ніколи не працював на це ЗМІ. «Це був кристальний кейс, наче з підручника з дезінформації. Текст був не тільки хибним, але й шкідливим та ніс репутаційну шкоду людині, війську та державі загалом, — згадує Антон. — Зазвичай такі речі виникають в інформаційному просторі непомітно, і головне швидко це виявити та зреагувати. Нам це вдалося: майже одразу цей вкид було спростовано». Переосмислення та трансформація проєкту Волонтерська ініціатива приваблювала багато вмотивованих талантів. Фахівці з великим досвідом та унікальною експертизою прагнули долучитися до спротиву російській пропаганді. Серед них — два Kaggle Grandmaster (один з найвищих рівнів у системі оцінювання спеціалістів з машинного навчання): Володимир Сидорський та Олег Ярошевський. Загалом фахівців з цією відзнакою не більше 350 у світі. На думку Антона, якби не важлива місія, стартапу було б складно залучити такі кадри. Команда складається з AI/ML інженерів, фронтенд- та бекенд-розробників, QA, UI/UX дизайнерів. Координацією технічної роботи керує СТО, Остап Вихопень, який раніше працював Senior Delivery Manager в EPAM Systems. За загальний менеджмент та продукт відповідає СЕО, Максим Терещенко. Він мав досвід побудови дата-продуктів та роботи в стартапах. Антон Тарасюк називає себе єдиним нетехнічним спеціалістом у команді. Він відповідає за внутрішню експертизу команди у сфері стратегічних комунікацій. «Дезінформація і ризик-менеджмент — речі, які мають певні юридичні виміри, термінологію, регуляцію, протоколи та багато інших нюансів», — пояснює він. Протягом першого року у проєкті були залучені близько 20 спеціалістів: частина з них була кістяком команди, інші — працювали тимчасово. За словами Антона, це була скоріше волонтерська ініціатива, можливо навіть «клуб за інтересами», а не команда, що системно розвиває бізнес. Наразі їхня кількість зменшилася до 12 людей. «Деякі приходили та одразу зникали, інші — з часом вигоряли. Будь-яке волонтерство — складне і виснажливе, тому не можна вимагати від людей стабільної роботи та мотивації, — згадує Антон. — Ми розуміли, що усі волонтерські ініціативи мають досить обмежений життєвий цикл, і проєкт не зможе розвиватися без фінансування. Тому паралельно зі співпрацею з РНБО ми почали вивчати попит на такі продукти на європейському та американському ринках». 2023 року у проєкті почалися трансформації. Поспілкувавшись з потенційними клієнтами, засновники Mantis Analytics переосмислили фокус стартапу. Платформа могла допомагати не лише з детекцією інформаційних загроз, але й фізичних для захисту активів компаній. Наприклад, бізнес має велику мережу складів у різних точках світу. Алгоритм може допомогти компанії відстежувати ситуацію в цих регіонах, починаючи з кримінальної активності та можливих стихійних лих і закінчуючи ланцюгами постачання та активізмом. «Якось ми спілкувалися з компанією, біля складу якої активісти влаштували страйк і спалили його. Ця акція готувалася заздалегідь і могли бути відстежена», — ділиться Антон. За його словами, платформа може надавати своїм клієнтам загальну картину ризиків. Інший приклад — менеджмент ризиків у мегаполісі. Наразі Mantis Analytics веде переговори з впровадження комплексного відстеження ситуації в одному з українських міст. Алгоритм швидко збиратиме інформацію про те, де зламався тролейбус, прорвало трубу, сталося ДТП або відбулася сутичка. Таку інформацію можна використовувати, щоби покращувати роботу безпекових, комунальних та інших служб. Команда веде переговори з компаніями у різних сегментах. Здебільшого це аналітичні центри, департаменти ризик-менеджменту великих корпорацій та приватні аналітичні безпекові компанії. Продовжується також співпраця з РНБО, як частина соціальної місії проєкту. Не за планом: де фаундерам шукати знання Антон порівнює запуск стартапу з народженням дитини — це те, до чого неможливо підготуватися на 100%. «Скоріше за все, усе, що ви планували, піде не за планом, — стверджує він. — Тому найбільш цінним в цей період є спілкування з людьми, які цей шлях вже пройшли». Почавши будувати глобальний B2B бізнес, команда моніторила українські освітні ініціативи та акселератори для стартапів. «Порівнявши пропозиції, ми обрали Genesis Startup Academy, який пропонував equity-free формат, — розповідає Антон. — Нам також сподобалася команда менторів, до того ж підігрівав інтерес досить складний тест для зарахування. Очевидно, що туди брали не всіх охочих, а справді перспективні проєкти». StartUp Academy — це освітня програма з розвитку та масштабування технологічних бізнесів, яку Genesis разом із Meta запускає від 2021 року. За цей час в Академії взяли участь 135 стартапів з-понад 20 країн Центральної та Східної Європи. Найбільш цінним в таких програмах, на думку співзасновника, є практичний досвід менторів, спілкування з досвідченими підприємцями, фідбек та комʼюніті. «Загальні знання, фреймворки — корисні, але таку інформацію можна знайти в мережі. Коли ж Володимир Многолєтній, який пройшов шлях побудови десятків компаній з нуля, розповідає, як приймати рішення, та чому стартап на ранній стадії має бути диктатурою — це неоціненні інсайти». Крім того, участь в таких проєктах допомагає будувати стосунки з іншими партнерами та швидше зростати — деякі з випускників після програми залучили інвестиції сумою понад $7,5 млн. Вихід на американський ринок та пошук інвесторів Стартап Mantis Analytics вже залучив $25 000 від українського кластера оборонних технологій Brave1, а також $50 000 від українського фонду ZAS Ventures. За словами співзасновника, загалом є домовленість про близько $200 000.  Наразі проєкт знаходиться на стадії підйому посівного раунду. Його завдання — здобути більше корпоративних контрактів та закрити раунд. Зараз стартап фокусується на американському ринку. В поточних умовах українським компаніям складно самостійно вийти на ринок США. У світі безліч стартапів, їхній життєвий цикл досить швидкоплинний, тому ставлення до них часто скептичне. До того ж Україна вважається високоризикованою країною. Один зі способів це зробити — залучитися підтримкою профільних інкубаторів. Для цього команда долучилася до Alchemist, одного з найбільших акселераторів для B2B-компаній ранньої стадії. Mantis Analytics став, за словами Антона, одним з небагатьох українських стартапів, який потрапив до Alchemist за всю історію його заснування з 2012 року. Це їм вдалося з третього разу. За словами Антона, інтерес інвесторів до українських проєктів є, але чимало такої уваги є фіктивною. «Ми називаємо таку категорію інвесторів «with Ukraine till the end». Вони висловлюють багато підтримки, обертаються в колах навколо українських проєктів, проте коли доходить до фінансових питань, високі ризики та розташування команди в Києві стають непереборною причиною не інвестувати. На жаль, можна витратити багато часу на такі пусті переговори», — ділиться співзасновник стартапу. З іншого боку, в пайплайні проєкту є багато інвесторів, які висувають конкретні критерії для отримання коштів: один контракт, три листи про співпрацю тощо. «Це схоже на компʼютерну гру, де ти маєш пройти квест, щоби розблокувати наступний рівень. Проте нам такий формат підходить, адже у ньому більше конкретики та чіткий таймінг», — каже співзасновник.

У Genesis є п’ять цінностей, одна з яких — High Bar for Talent. Це означає, що ми ретельно відбираємо кандидатів, щоб підтримувати високий стандарт найму в компанії. Важливий етап відбору — баррейзинг. Це фінальна співбесіда, на якій і компанія, і кандидат остаточно розуміють, наскільки підходять одне одному. У цьому матеріалі ми розповідаємо, чому з’явився баррейзинг, як він проходить, яким спеціалістам Genesis каже «так!» і як підготуватися до співбесіди. Щоб написати матеріал, ми поговорили з чинними баррейзерами компанії — Head of Product & UX в партнерській компанії Headway Анатолієм Денисюком та CEO Universe Group Ярославом Морозовим, а також із Internal Education Lead Вікторією Прищепою, яка відповідає за навчання баррейзерів у Genesis. > Що таке баррейзинг і хто його проводить > Чому в Genesis запровадили баррейзинг > Хто такі баррейзери в Genesis і як ними стають > Навіщо бізнесу баррейзинг — зрозуміло. А що отримує кандидат > Як проходить баррейзинг > Яких спеціалістів шукають у Genesis > За що кандидат може отримати відмову > Чим відрізняється баррейзинг на джуніор та сеньйор-позиції > Як підготуватися до баррейзингу Що таке баррейзинг і хто його проводить Баррейзинг — це фінальний етап відбору після інтерв’ю, тестового завдання та збору рекомендацій. Він проходить у формі співбесіди з фахівцем топрівня, який не працює в проєкті, куди подається кандидат. Тож баррейзер не зацікавлений у закритті конкретної позиції, а тому може дати об’єктивний і неупереджений фідбек. В першу чергу під час баррейзингу перевіряють відповідність культурі компанії, а не хард-скіли чи софт-скіли кандидата. Звідки походить ця процедура і чому так називається Баррейзинг з’явився в Amazon у 1999 році. Тоді компанія розробила власний план рекрутингу технічних спеціалістів, аби зменшити ймовірність похибки у наймі. План назвали barkeeper program (можна перекласти як програма збереження заданої планки — ред). «Bar» у цій назві — це умовний рівень навичок спеціалістів, що займають такі ж посади, як і кандидат. І хоча назва говорила лише про «підтримання планки», програма мала на меті підвищити загальний рівень спеціалістів у компанії. Тому баррейзери в Amazon мають гарантувати, що обрані кандидати справді посилять свої команди. Чому в Genesis запровадили баррейзинг Робота в продуктових компаніях значно відрізняється від аутсорсу, де зона відповідальності спеціаліста чітко окреслена. У Genesis зазвичай наймають не лише під конкретні завдання, а й на перспективу, тобто ще на етапі відбору визначають, які завдання та на якій позиції працівник зможе виконувати за рік-два. Отже, це більш довготривалі стосунки, що передбачають спільні цінності між компанією та співробітником. Важливо також, щоб цілі фахівця і команди збігалися. Через це баррейзинг застосовують здебільшого у продуктових компаніях. Процес найму в Genesis ґрунтовно перелашували у 2014 році, а вже у 2015 році спеціалістів набирали за новою системою. За експертизою звернулися до провідних компаній світу — Facebook, Amazon, Google. У 2014 році Genesis уже був партнером цих компаній та міг переймати їхній досвід. Хто такі баррейзери в Genesis і як ними стають Це спеціалісти топрівня — C-level, Head, Lead, які працюють в екосистемі Genesis понад рік, провели 200+ співбесід та відмінно розуміють цінності й корпоративну культуру компанії. Домен баррейзера не є важливим. Адже цей етап найму — про перевірку цінностей, мотивації, амбіцій, глибини розуміння кандидатом себе. І основне — загального розвитку людини. Однак, за потреби хайринг-менеджер може попросити баррейзера перевірити ті чи інші хард-скіли кандидата або його обізнаність в домені. Для таких випадків баррейзеру рекомендовано мати експертизу в галузі знань кандидата. Щоби постійно мати необхідну кількість баррейзерів, у Genesis проводять спеціальну освітню школу. Вона складається із двох частин: теоретичної й практичної. Учасники слухають лекції більш досвідчених колег та разом практикуються на відповідних воркшопах. Для бізнесів баррейзинг — важлива складова їх росту, а баррейзери — ключові люди в компанії, які забезпечують стабільно високу якість талантів, що доєднуються до команди, - підкреслює Вікторія Прищепа, Internal Education Lead в Genesis. Навіщо бізнесу баррейзинг — зрозуміло. А що отримує кандидат Баррейзинг — двосторонній процес. Не лише компанія обирає кандидата, а й кандидат — майбутнє місце роботи. На цьому етапі відбору спеціаліст може якнайбільше дізнатися про компанію, яка її місія і цінності, та зрозуміти, чи поділяє він їх. Під час розмови кандидат також може прояснити, які кар’єрні можливості він матиме в компанії та з якими людьми працюватиме пліч-о-пліч. Баррейзинг — спосіб оцінити власний досвід і знання зі сторони. Це найефективніша година для кандидата на всіх етапах найму, навіть якщо фінальне рішення буде не на користь фахівця. Як проходить баррейзинг? Зазвичай баррейзинг проходить за стандартною структурою, але деталі та акценти можуть змінюватися залежно від кандидата та особи інтерв’юера. З одними більше обговорюють досвід, з другими — фокусуються на фундаментальних знаннях, з третіми — акцентують на мотивації. Здебільшого співбесіда складається із декількох блоків: Досягнення. Тут усе просто — кандидат розповідає, за що відповідав на минулому місці роботи і яких результатів йому вдалося досягти. Мотивація. Важливо, чи «горить» людина своєю роботою, адже від цього залежить, наскільки швидко вона просуватиметься кар’єрними сходами. Інтелект та реакція. Інтерв’юер може попросити кандидата розв’язати якусь логічну задачу або поставити неочікуване питання на кшталт «Скільки вагонів у київському метро». Тут важлива не так правильна відповідь, як підхід до розв’язку задачі й реакція людини. Питання від кандидата. Якщо кандидат приходить на співбесіду зі списком запитань, це говорить про його зацікавленість у позиції та компанії. За характером таких питань можна чіткіше зрозуміти мотивацію фахівця. Яких спеціалістів шукають у Genesis Я звертаю увагу на декілька моментів: Позитивне сприйняття світу. Проактивність. Проактивна людина може показати плоди своєї праці. Це можуть бути й кількісні показники з минулої роботи, й опис проєкту або стартапу, над яким працював кандидат. Усвідомлення своїх дій і процесів. Професіонал може пояснити, як і завдяки чому він одержав той чи інший результат. Якщо не може і вважає його випадковістю — це привід задуматися. Я дивлюсь на сукупність чинників: як людина розмовляє, що саме вона говорить, наскільки вона вихована, емпатична, чи вміє слухати. Питаю про те, які складнощі та успіхи були на минулій роботі. Кандидат, якого я порекомендую найняти до Genesis, має: бажання працювати в команді. Без цього тут важко буде досягти значних результатів. Людина має бути комунікабельною, працювати на спільний результат і надихатися командною роботою. прагнення розвиватися. Людину не можна змусити працювати над собою, якщо вона сама цього не хоче. Один із критеріїв — читання книжок. Ми в Headway особливо ставимося до читання, бо з ним пов’язаний наш продукт. Тож, якщо спеціаліст не читає зовсім, є питання, наскільки він прагне розвиватися. Звісно, крім книжок є ще й інші ресурси для освіти, але без них набагато складніше. готовність працювати в атмосфері стартапу. Genesis складається з півтора десятка проєктів, які так чи інакше працюють у ритмі стартапу — швидко. Це не означає, що тут змушують працювати ночами. Але якщо людина вміє організувати свій час так, щоб тримати темп компанії, що зростає, то це наш кандидат. адаптивність, гнучкість та вміння швидко приймати рішення. За що кандидат може отримати відмову Баррейзери вказали на декілька «червоних прапорців». Найбільше вони згадували про токсичність і нещирість. Якщо в кандидата «непрозорий» попередній досвід, і він щось не договорює, то хайринг-менеджерам радять відмовитися від співпраці з ним. З токсичною людиною — тією, яка розповсюджує негатив, жаліється, але не діє та не робить висновків — також не матимуть справи. Це саме стосується й тих ситуацій, коли кандидат не вміє приймати фідбек та реагувати на критику. Ще один «червоний прапорець» — коли кандидат присвоює заслуги інших людей або ж декларує себе експертом в темах, на яких насправді не розуміється. Чим відрізняється баррейзинг на джуніор та сеньйор-позиції Анатолій Денисюк: під час інтерв’ю з кандидатами-джуніорами я звертаю більше уваги на мотивацію, з сеньйорами — на досвід та рефлексію. Під час пошуку джуніора основний акцент робимо на його мотивації й потенціалі, бажанні рости й розвиватися, обмірковуємо, на яку позицію людина може претендувати в майбутньому. Як підготуватися до баррейзингу Ярослав Морозов: важливо проявити зацікавленість у позиції. Дізнайтеся більше про проєкт і команду, про свої обов’язки та зону відповідальності, про те, як ваша робота вплине на командні цілі. Сильні кадри зазвичай приходять зі списком запитань — і це підіймає кандидата в очах інтерв’юерів та показує, що людина зацікавлена працювати в компанії й зможе глибоко зануритись у процеси. Визначте свої сильні й слабкі сторони. «Пройдіться» своїм досвідом й випишіть те, чим пишаєтесь. Якщо досвіду зовсім мало — вивчіть інформацію про проєкт, і подумайте, яку користь ви можете йому принести. Анатолій Денисюк: найчастіше до компанії потрапляють кандидати, які зрозуміли слабкі місця попередньої співбесіди й зробили «роботу над помилками». Запам’ятайте зауваження, проаналізуйте фідбек, і тоді ви прийдете на нову зустріч уже більш підготовленим фахівцем. Якщо ж на баррейзингу кандидат наступає на ті самі граблі — це означає, що він не рефлексує. Це стосується не лише попередніх етапів відбору. Наприклад, усі ми розуміємо, що жалітися на колишніх роботодавців — не найкраща ідея, тому зазвичай кандидати обирають взагалі не розповідати про минулий негативний досвід. Але є ще один варіант: людина проаналізувала ситуацію, проявила емпатію й усвідомлено розповідає про свій досвід. Наприклад: «У мене були непорозуміння із керівництвом. Я не погоджувався з оцим, адже це негативно впливало на процеси. Однак я розумію, чому це відбулося ось так, і чому від мене вимагали ось це». Це найвищий рівень.

Genesis у партнерстві з факультетом інформатики Національного університету «Києво-Могилянська академія» (НаУКМА) відкрили четвертий набір на щорічну двомісячну програму Genesis & KMA Software Engineering School 4.0 для розробників рівнів junior та middle. Навчання складається з лекцій, практичних завдань, live refactoring сесій, воркшопів, code review сесій. Учасники працюватимуть над власним проєктом, отримають корисний нетворкінг із лекторами та іншими учасниками програми. «Від 2021 року ми з партнерами щороку запускаємо програму Software Engineering School про архітектурні підходи в розробці. Це можливість для учасників перейняти експертизу розробників, архітекторів і СТО, систематизувати наявні знання та дізнатися, з якими типовими викликами зіштовхуються технічні команди глобальних ІТ-продуктів», — коментує Олександра Тиркалова, University Partnerships Lead у Genesis. Серед лекторів та експертів програми — спеціалісти продуктових ІТ-компаній Genesis, SKELAR, Solidgate, AMO, а також викладачі факультету інформатики НаУКМА. Програма фокусується на викликах і підходах у розробці ІТ-продуктів та охоплює такі теми: чистий код, який легко підтримувати; архітектурні патерни, принципи та підходи до проєктування; робота з хмарними сервісами; використання ефективних засобів безпеки; життєвий цикл розробки продуктів; специфіка роботи технічних команд у продуктових компаніях. «НаУКМА регулярно співпрацює з ІТ-компаніями, щоб надати українській молоді актуальні знання. Цьогоріч ми знову обʼєднуємо зусилля з Genesis та запускаємо Software Engineering School 4.0 задля формування талановитих кадрів та зміцнення ринку продуктового ІТ в Україні», — зазначає Андрій Глибовець, декан факультету інформатики Києво-Могилянської академії. Щоби взяти участь у програмі, необхідно пройти конкурсний відбір, який складається з тесту, практичного завдання та співбесіди. Заявки на участь приймаються до 8 травня 2024 року включно. Навчання розпочнеться 4 червня і триватиме близько двох місяців. Подати заявку та ознайомитися з деталями програми, форматом навчання та відгуками випускників можна за посиланням.

SRE (Site Reliability Engineering) — це підхід до управління ІТ-інфраструктурою, який популяризував Google. 2003 року компанія виявила, що традиційні методи не відповідають потребам їхньої вебінфраструктури, і винайшла свій. Основні принципи SRE передбачають автоматизацію процесів, вимірювання та аналіз рівня надійності, стратегії моніторингу, план реагування на інциденти тощо. Практики SRE швидко стали популярними: їх почали інтегрувати різні команди, змінюючи та налаштовуючи під себе. Netflix, Dropbox, Facebook, Uber, LinkedIn та багато інших — SRE-практики допомагають цим сервісам забезпечити безперебійну роботу за високих навантажень та швидко відновлюватися у разі збоїв. Google та інші бізнеси детально описують ці принципи. Проте без прийняття культури й мислення, що лежать в основі SRE, у бізнесів просто з'являтимуться нові співробітники та процеси без вагомих результатів. У цьому матеріалі ділимося ключовими підходами SRE. Для ілюстрації застосування цих практик ділимося кейсом компанії Preply, про який розповів Олексій Остапець, Senior Site Reliability Engineer в Preply на конференції DevOps fwdays'24, що відбулася у лютому в просторі Genesis Space. Він прокоментував, як розвивати інженерну культуру команди та сприймати інциденти не як технічні збої, а справжні бізнес-події, які потребують розумного вирішення. > Вимірювання доступності > Від 99,9 до 99,99: кейс Preply > Ключові метрики SRE > Як зменшити MTTR. Алгоритм відповіді на інциденти > Побудова культури > Попередження інцидентів Вимірювання доступності Чи може сервіс бути доступним на 100%? Методика SRE передбачає, що уникнути збоїв — неможливо. Стабільність систем зазвичай оцінюють у кількості «девʼяток»: 99%, 99,9%, 99,99% тощо. Так, 99% передбачає 128 хвилин години недоступності (даунтайму) на тиждень, а 99,999% — всього 6 секунд. Також доступність може вимірюватися не у часі, а, наприклад, за кількістю запитів. У будь-якому випадку структура формули однакова: успішні одиниці / загальна кількість. Незалежно від способу вимірювання, результат буде у відсотках, які округляють до девʼяток. Показник доступності може також враховувати додаткові критерії. Наприклад, компанія визначила правило, за яким система має відповідати користувачу швидше ніж за 600 мс. Якщо затримка перевищує це значення, можна вважати, що система не працює. Рівень доступності, який встановлює компанія, залежить від її цілей та пріоритетів. Здавалося б, варто прагнути якомога більшої кількості девʼяток. Проте виявляється, що висока надійність має свою ціну: максимальна стабільність обмежує швидкість розробки нових фічей і доставки користувачам, а також різко підвищує їхню вартість. Водночас користувачі можуть навіть не помітити різниці, адже у взаємодії присутні менш надійні компоненти, такі як стільникова мережа або пристрій, з яким вони працюють. «Користувач смартфона, надійного на 99%, не може відрізнити надійність обслуговування на 99,9% і 99,999%», —  йдеться в інструкції Google. Хоча абсолютна доступність неможлива, галузь зазвичай визначає досить високі значення. У найпопулярніших глобальних продуктів цей показник варіюється в межах 99.99%. Компанії, які пропонують складніші технологічні сервіси, такі як хмарні сховища, визначають доступність на рівні пʼяти девʼяток (99,999%) і вище, наприклад, певні сервіси Google Cloud Platform, Amazon Web Services, Azure Cosmos DB. Серед них є Amazon S3 з режимом «11 дев'яток» доступності. Від 99,9 до 99,99: кейс Preply Preply — це платформа для репетиторів та студентів усього світу, на якій проводиться мільйони уроків щомісяця. Команда вносить чимало змін до продукту: на 120 інженерів припадає близько 100 релізів на день, тому періодичні баги та збої є природними. «За останній календарний рік у нашій системі трапилося 138 інцидентів, які наші клієнти відчули на собі, — ділиться Олексій Остапець, Senior Site Reliability Engineer в Preply. — Чи можна цю ситуацію покращити? Як варіант — перестати релізити код, однак ми живемо в інших реаліях. Користувачі очікують постійних оновлень та нових фіч, отже ми мусимо експериментувати. Отже, навчилися швидко відновлюватися і робити висновки». $63 000 — стільки склали фінансові втрати компанії за останній рік лише через інциденти. Іншими словами, стільки обходиться та швидкість розробки, яку вона підтримує. Пʼять років тому команда не оцінювала фінансовий вплив, проте розуміє, що раніше ця цифра була в десятки разів більша. 2019 року, під час Covid-19, у світі вибухає тренд на онлайн-навчання, і Preply починає швидко зростати. На той час у системі було 20 моніторів, платформна команда складалася з двох людей, які кожну другу ніч отримували OnCall-дзвінки через інциденти. Доступність сервісу складала 99,9%, що еквівалентно 45 хвилинам недоступності на місяць. Тоді компанія почала розвивати SRE-практики: аналізувати кожен інцидент, ділитися висновками (так званими постмортумами), рахувати фінансові втрати та вплив на користувачів, оновлювати процеси та безперервно покращувати їх, а також інвестувати у розвиток інженерної культури команди. Нині у системі працюють вже тисячі моніторів, у команді є налагоджені процеси. Більшість інцидентів закриваються продуктовими командами у значно коротший термін. Попри кількість щоденних релізів та кратне зростання команди, доступність сервісу складає 99,99%, що еквівалентно 4,5 хвилинам недоступності на місяць. «Найголовніше, що ми зрозуміли за кілька років розвитку SRE-практик, — інциденти все одно трапляються. Варто сприймати кожен з них, як подію, коли ми можемо зробити висновки, навчитися та оновити процеси. Якщо у вас давно не було інцидентів, — це підозріло. Напевно ви регулярно робите зміни до продукту, на вас здійснюють DDOS-атаки та полюють баунті-хакери. Скоріше за все, у вас просто недостатньо розвинуте бачення системи (так зване observability)», — пояснює Олексій. Ключові метрики SRE Завдання SRE — не просто максимізувати час безвідмовної роботи, а збалансувати ризик недоступності з цілями швидкого впровадження інновацій. Якщо ви дбатимете лише про стабільність, тоді випуск нових фічей та інновацій припиняться. Тож як визначити, коли найкращий час для нових релізів, а коли варто зосередитись на технічному боргу та покращенні стабільності системи? Команда Google, розробляючи методику, хотіла визначити точний показник вимірювання доступності. Так зʼявилося поняття SLO (Service Level Objective), на якій ґрунтується уся робота над стабільністю системи. Це конкретна мета, яку організація встановлює для якості своїх послуг. Наприклад, 99.9% аптайму за місяць або відгук сервера не довше ніж 5 мс. Ця метрика не має бути захмарною, так само як не варто гнатися за «девʼятками». «Надмірна доступність стала очікуванням, що може призвести до проблем. Не робіть свою систему надто надійною, якщо досвід користувача не вимагає цього, — пояснює команда Google. — Визначте найнижчий рівень надійності, прийнятний для користувачів кожної служби, а потім вкажіть це як свій SLO». «Внутрішні SLO дають командам розуміння відповідальності за свій домен, за користувачів, для яких вони релізять фічі, — це ключовий фактор попередження інцидентів. Це змушує команди робити певні висновки та відповідально підходити до змін», — ділиться Олексій. SLI (Service Level Indicator) — це метрика, яку використовують для вимірювання рівня якості послуг. Це фактичні дані, які вказують, наскільки добре або погано функціонує система. SLA (Service Level Agreement) — це угода з клієнтом, в якій ви гарантуєте стабільне дотримання певної метрики. В ній також встановлюються штрафи за невиконання цього показника. Часто SLA може бути нижчим за SLO — наприклад, компанія визначила як мету швидкість відповіді у 5 мс, але перед користувачами гарантує швидкість не менше 10 мс, щоби мінімізувати фінансові втрати. Ці метрики лягають в основу поняття Error budget. Бюджет помилок — це час, протягом якого ви готові дозволити своїм системам не працювати на користь релізів нових фічей та інновацій. Наприклад, Preply встановила SLO на рівні 99,99% доступності системи, що означає, що недоступність не має складати більше ніж 4,32 хвилини на місяць. Доки ліміт не перевищено, команда може релізити нові фічі, ризикувати та фокусуватися на швидкості розробки. «Якщо ми виходимо за Error Budget, команда домовляється з менеджментом, що працюватиме над покращенням стабільності системи протягом наступного спринту», — пояснює Олексій. З цими метриками має працювати кожна команда та стейкхолдери, інакше вони не зможуть прийняти важливі рішення, чи потрібно зробити продукт більш стабільним, чи дозволити більшу швидкість розробки. У такий спосіб команда розробки продукту стає самоконтрольованою. Вони знають бюджет і можуть керувати ризиками. Щоби зрозуміти та спланувати бюджет помилок, практики SRE передбачають дві додаткові концепції: MTBF — загальний час безвідмовної роботи / кількість відмов. Це середній час між збоями. MTTR — загальний час простою / кількість відмов. Це середній час відновлення після збою. Ці показники можна обчислити історично (наприклад, за останні 3 місяці або рік). Наприклад, у компаній встановлений SLO 99,9%, який дозволяє 43,2 хв недоступності на місяць. Її історичний MTBF складає 10 днів, а історичний MTTR — 30 хв. Тоді команда може розрахувати очікувану недоступність у 90 хвилин на місяць ((30 днів / 10 днів) * 30 хвилин). Це виходить за межі цільового показника, значить команда має зменшити MTBF або MTTR — тобто подбати, щоби збої траплялися рідше (випускати менше релізів) або швидше відновлюватися. Для цього потрібен алгоритм відповіді на інцидент, який ми розглянемо далі. Як зменшити MTTR. Алгоритм відповіді на інциденти Команда Google пропонує алгоритм дій для реагування на інциденти, який передбачає такі кроки: Виявлення інциденту — проблеми або порушення в роботі системи. Оцінка впливу інциденту на користувачів та бізнес-процеси. Аналіз та діагностика проблеми. Відновлення сервісу. Пошук кореневої причини інциденту та її виправлення. Рефлексія (аналіз ефективності заходів, їхнього впливу на систему, випуск постмортума). Висновки та вдосконалення — впровадження поліпшень для покращення майбутнього реагування на подібні інциденти. Важливо здійснити перші чотири кроки якнайшвидше, адже саме цей проміжок часу визначає MTTR. Цей механізм має бути відпрацьованим командою до автоматизму. Після того, як буде відновлено систему, команда може спокійно працювати над виправленням помилок, адже витрати error budget вже зупинено. «Альтернативою ролбеку може бути перемикання функціонала — так звані feature-switchers. У нашій команді розвинена культура експериментів, тому всі зміни реалізовані під так званими прапорами, які можна масштабувати на певну кількість користувачів і відключити частину функціонала сайту або застосунку», — каже Олексій. На його думку, важливо фіксувати усі (навіть незначні) інциденти. Навіть якщо ці edge-кейси побачили всього тисяча користувачів, все одно варто проаналізувати вплив. Якщо знаходять корисні інсайти, ними діляться з командою та закривають відповідні прогалини в моніторингу або end-to-end тестах. Як правило, на кожному постмортумі SRE-команда Preply генерує одну або дві першочергові задачі, щоби запобігти подібним проблемам у майбутньому, та декілька другорядних. Побудова культури На думку Олексія, працюючи над практиками реагування на інциденти, бізнес має сфокусуватися на трьох аспектах: розвитку навичок, налагодженні інструментів та найголовніше — побудові відповідної інженерної культури. Комунікація є важливою частиною в ефективному менеджменті інцидентів. «Як правило, коли трапляється інцидент, розробники не хочуть ділитися цим публічно та брати на себе відповідальність. Натомість вони займають позицію очікування. Ми мусимо зламати цю «стіну» і показати, як добре робити висновки та оновлювати процеси, аби проблеми не повторювалися» — стверджує він. Ще більший страх у розробників викликає механізм відкату. Філософія Google полягає в тому, щоб сприймати це, не як факап, а як нормальну процедуру, необхідну для повернення стабільності системи. «Ми зрозуміли, що немає успішного розгортання, якщо у вас не підготовлений відповідний відкат», — йдеться в інструкції Google. Так, щоби закріпити вищенаведений алгоритм та розвивати відповідну культуру, в Preply практикують низку тренінгів, зокрема симуляції інцидентів. У ньому бере участь невелика група інженерів, які мають реагувати на реальний інцидент у продакшені. «Ми створюємо окремий ротейшн на учасників тренінгу і генеруємо помилки від імені певної кількості користувачів у системі (ендпойнти або бекграунд-задачі). Далі тригериться інцидент, і ми  переходимо до відпрацювання алгоритму: організовуємо дзвінок, розподіляємо ролі, проводимо дослідження і звичайно здійснюємо ролбек», — ділиться Олексій. За його словами, головний ефект таких тренінгів — прокачка базових навичок, потрібних під час реальних інцидентів та подолання страху здійснити відкат. «Цю практику ми проводимо вже понад два роки, і зараз більшість інцидентів швидко закриваються командами з мінімальним впливом на користувачів, — розповідає він. — Якщо раніше інженери боялися брати відповідальність та довго дискутували: в чому проблема, як її виправити, підготуймо фікс, то тепер вони мислять в інший спосіб. Зʼявилася проблема, — усі знають, що її треба усунути якомога швидше, і знають, як це зробити». Попередження інцидентів Чи можна попередити інциденти у системі? Погана новина — ні. Хороша новина полягає в тому, що їх і не треба попереджувати. Цікаву практику описує команда Google Cloud: вони власноруч впроваджують періодичні даунтайми в деяких службах, щоб уникнути надмірної доступності. «Ми виявили, що ця практика допомагає виявити служби, які використовують ці сервери неналежним чином. Маючи цю інформацію, можна перемістити робочі навантаження в більш слушне місце та підтримувати належний рівень доступності серверів», — стверджують вони. Для пошуку слабких місць та вразливостей команда Netflix використовує практику Chaos Engineering — метод систематичного впровадження стресу в системі. З допомогою спеціальних інструментів вони імітують сценарії раптових збоїв, стрибки трафіку, мережеві збої, відмову серверів та перевіряють, як система реагує на такі події. Це дозволяє виявити проблеми в архітектурі, конфігурації або коді та вирішити їх. Щоби мінімізувати вплив інцидентів на систему, зокрема, використовують Canary-релізи — метод поетапного впровадження нового релізу (спочатку на обмежену групу користувачів, а за відсутності помилок — на всіх). Цей термін взятий з практики американських шахтарів, які брали до вугільних шахт канарок у клітинах, щоб виявляти небезпечний рівень чадного газу. Наразі розробники використовують для цього автоматизовані інструменти. «Якщо система бачить, що збільшується Error Rate або падають важливі метрики, вона автоматично повертає сервіс до минулого релізу. В Preply використовуємо для цього інструмент Argo Rollouts. Водночас з Canary-релізами варто бути обережним. Якщо протягом деплойменту відстежувати забагато метрик, система може видати хибнопозитивний результат», — ділиться Олексій. Крім того, командам варто налаштувати якісний моніторинг з прогнозуванням, який допомагає визначити заздалегідь проблеми з інфраструктурою, як закінчення пропускної здатності або наближення до максимальних навантажень та виявляти аномалії. Отже, SRE-практики допомагають знайти баланс між швидкістю розробки та стабільністю і пропонують метрики для вимірювання та відстеження впливу. Згідно з SRE Report 2024 від Catchpoint, 47% компаній вважають інциденти джерелом корисних бізнес-інсайтів. Кожен збій може стати джерелом інформації для покращення користувацького досвіду. Варто розвивати інженерну культуру, будувати якісні процеси та навчитися швидко відновлюватися.

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

Мова програмування Python починалася з пет-проєкту й більш ніж за 30 років стала однією з найпопулярніших серед розробників. Невеликий поріг входу, простота та зручний синтаксис відносно швидко зібрали навколо себе велику й зацікавлену спільноту. Однак в історії цього інструменту були й дуже неочікувані повороти, як-от реліз третьої версії, який додав головного болю всім розробникам. У цьому матеріалі ділимося історією розвитку Python, та разом з директором та співзасновником Design and Test Lab Володимиром Обрізаном пояснюємо особливості популярної мови. Різдвяні канікули Взимку 1989 року 35-річний нідерландський розробник Гвідо ван Россум зовсім не мав планів на різдвяні канікули. Близьке коло його спілкування зводилося до нуля, тож програміст вирішив присвятити вихідні роботі. На той момент Гвідо уже три роки працював у Науково-дослідному інституті математики та інформатики в Амстердамі (CWI). Спочатку він займався проєктуванням ABC — простої мови програмування зі зручним синтаксисом, яку могли швидко опанувати люди без досвіду в розробці. Утім, проєкт закрили — і Гвідо перейшов до команди, яка працювала над Amoeba, розподіленою операційною системою для великих компаній. Робота потроху просувалася, однак розробникам бракувало розширеної скриптової мови. Саме за такий проєкт і взявся Ван Россум. За основу він обрав напрацювання ABC з елементами C та Pascal. Через кілька місяців пет-проєкт був готовий. Найперша версія містила базовий синтаксис, оператори, словники, списки, рядки та інші типи даних. Крім того, Гвідо створив просту віртуальну машину, парсер та середовище виконання. Колеги Гвідо, яким він показав свої напрацювання, оцінили новий інструмент. Особливості мови давали розробникам інноваційну для свого часу можливість — вони могли самостійно додавати до системи потрібні типи об’єктів. Тому багато з них пропонували покращення та пробували використовувати мову для своїх проєктів. Monty Python і священна мова програмування Новий проєкт потребував назви, і Гвідо обрав перше, що спало на думку. Попри очевидні асоціації, неймінг не мав нічого спільного з плазунами.  Програміст був палким шанувальником комедійного шоу «Летючий цирк Monty Python», тож назвав нову мову на честь нього. Подібний хід також відповідав моді того часу називати мови програмування іменами відомих людей (так, наприклад, з’явилися Pascal, Ada чи Eiffel). Ще одна річ, яка потрібна була новонародженій технології, — логотип. Гвідо не став перейматися і тут: він обрав рандомний шрифт та написав ним слово Python. Однак юзери вперто не хотіли використовувати текстове зображення — їм подобалося асоціювати мову зі зміями. Останню крапку поставило видавництво O’Reilly, відоме своїми книжками з програмування та традицією зображати тварин на обкладинках. Python, без сумніву, мала представляти змія — і Гвідо здався. Перші кроки молодої технології У лютому 1991 року Ван Россум опублікував вихідний код Python на ресурсі alt.sources. Так виникла версія 0.9.0, яка обслуговувала винятки, функції, базові типи даних, володіла механізмом обміну функціональності між класами. Пропонувати покращення та зміни могли всі охочі, тож за пару років з’явився comp.lang.python — користувацький форум, який став початковою віхою в розвитку потужної Python-спільноти. Першу версію мови остаточно фіналізували у січні 1994 року. На той момент вона мала нові функції простої обробки списку даних, як-от зіставлення, фільтрація і скорочення. Багато відгуків від програмістів ще кілька років давали змогу Гвідо та іншим Python-ентузіастам оновлювати та вдосконалювати інструмент. Але один допис вплинув на цей процес значно суттєвіше за всі інші. Позбутися bus-фактора У червні 1994 року один з учасників форуму опублікував розлогий допис з провокативною назвою «Що, якби Гвідо збив автобус?». Автор статті, Майкл МакЛей, писав, що попри певну «фанатську базу» та кількох волонтерів, Ван Россум залишався єдиним ключовим творцем Python. З цим, на думку МакЛея, була пов’язана інша проблема: попри зручність та простоту мови, великі бізнеси та академічні спільноти не хочуть нею користуватися, побоюючись ризиків. Якщо Гвідо «зникне», то незрозуміло, що далі буде з мовою, а отже — з їхньою роботою. Спілкування програмістів вилилося в пропозицію для Гвідо стати запрошеним дослідником у Національному інституті стандартів та технологій США (NIST). Пізніше, у 1995-му Ван Россум переїхав до США, аби продовжувати роботу над Python у Корпорації національних дослідницьких ініціатив (CNRI). Навколо Ван Россума та МакЛея поступово почали збиратися програмісти, що призвело до створення Python Software Foundation —  некомерційної організації, яка відповідає за розвиток та «процвітання» Python. Її основу складає core-команда розробників, яка відповідає за підтримку інтерпретатора CPython, розробку мови та стандартних бібліотек, а також випускає нові версії. Таким чином технологію убезпечили від прив’язки до однієї людини. Сам Гвідо отримав жартівливу посаду «великодушного довічного диктатора» (англ. Benevolent Dictator For Life). Вона передбачала, що всі ключові рішення щодо розробки мови лишаються за ним. Нині Python Software Foundation продовжує опікуватися розвитком мови. Її команда розробляє основний дистрибутив Python, займається правами інтелектуальної власності, організовує конференції для розробників та забезпечує стипендіями розробників-початківців. PSF має кілька ступенів членства (детальніше про це можна почитати ось тут). Діяльність організації фінансується завдяки донатам від спільноти та компаніям-спонсорам. Легендарні версії У травні 2000 року Гвідо та основна команда розробників Python перейшли працювати до BeOpen.com. На базі цієї компанії сформувалася BeOpen PythonLabs, команда якої реалізувала Python 2.0. Версія суттєво спростила процес створення коду: вона містила значні покращення PEP, повну підтримку Unicode, концепції генераторів, list comprehensions, нові модулі та удосконалення стандартної бібліотеки та інше. Приблизно у цей період з’явилася «філософія Python» — набір принципів, відповідно до якого працює мова. Її називають  «The Zen of Python». Ключові принципи цієї філософії зводяться до кількох речей: прагнення до простоти та інтуїтивності у сприйнятті коду; прості, але суворі правила з мінімумом винятків та багатозначних трактувань; орієнтація на практичні завдання та пошук очевидних рішень. Повний текст можна побачити в інтерпретаторі Python, для цього потрібно скористатися командою import this. BeOpen PythonLabs згодом об’єдналася з компанією Digital Creations, під «дахом» якої з’явилася Python 2.1. Поступово виходили інші версії, спільнота зростала, а вживаність мови набирала обертів. Здавалося б, усе йшло чудово, однак у грудні 2008 року стався колапс. Розробники зарелізили Python 3.0. Вона містила функцію print, додаткову підтримку розподілу чисел та обробки помилок, але в цілому мета створення нової версії полягала у виправленні критичних несправностей попередніх. Працюючи над нею, програмісти суттєво змінили всю архітектуру мови. Характер змін був такий, що нова версія виявилася повністю несумісною з попередньою, що спричинило низку проблем для розробників. Щоби полегшити розробникам перехід на нові версії, Python-спільнота 12 років випускала оновлення для старої версії. З кінця 2020 року офіційно підтримується лише третя версія, а Python 4, за словами Ван Россума, скоріше за все, ніколи не вийде. «Я почав працювати з Python у 2012 році. Тоді у нас були невеликі проєкти на Python 2.7. Вони закінчувалися, а нові ми вже починали на мові з третьою версією. Тому, на щастя, я не встиг напрацювати велику кількість кодової бази, щоби відчути всі труднощі переходу. Але це не означає відсутність труднощів переходу з мінорних версій, наприклад, останній перехід з 3.11 на 3.12. Змінити інтерпретатор загалом доволі легко — треба завантажити файл з сайту та встановити. Це завдання на дві хвилини. Та й сумісність самої мови між мінорними версіями дуже гарна. Я не памʼятаю, щоб треба було щось взагалі змінювати в коді, коли міняєш версію з 3.10 на 3.11, наприклад. Однак є одне велике «але». Близько 85% коду в бекенд-додатках, які ми розробляємо — це сторонні бібліотеки, їх десь 100. Тому коли ми змінюємо версію мови, є дуже велика ймовірність, що десь там в однієї з них є поганий код, який зламається від зміни мови. Тому ми переходимо на нові версії мови, але робимо це повільно: тобто не одразу як виходить нова версія, а за півроку-рік, коли більшість бібліотек теж адаптується до змін», — каже Володимир Обрізан, директор та співзасновник Design and Test Lab. Палиця з двома кінцями «Я почав вивчати цю мову досить випадково, — розповідає Володимир. — До цього встиг попрограмувати на Basic, Pascal, C/C++, C# та Objective-C. У 2012 ми почали розробляти прості вебсервіси та адмінпанелі для наших замовників, та мені треба було обрати якийсь фреймворк. Я вирішив обрати Google App Engine для розробки вебсайтів та вебсервісів. Тоді вони мали SDK для мов Java та Python». Спочатку Володимир обрав Java. Відкрив т’юторіал, почав робити усе за інструкцією, завантажив IDE Eclipse, завантажив Java, але після 3-4 годин без успіху не зміг запустити навіть Hello, world. Тоді він вирішив дізнатися, як це робиться на Python — і зміг запустити Hello, world-застосунок за 15 хвилин. «Тоді я зрозумів, що на Python багато чого робиться швидко та без великої кількості зайвого коду», — каже програміст. Python дійсно має низку переваг перед іншими мовами, головна з яких — зручність та простота. Серед інших сильних сторін Володимир Обрізан виокремив такі: стандартна бібліотека та велика кількість пакетів із відкритим вихідним кодом, завдяки чому можна підібрати готове рішення під практично будь-яке завдання; популярність мови, яка виражається в інтересі людей до професії Python-програміста, різноманітті технічної документації та рішень на Stack Overflow; мова часто використовується як механізм скриптингу для розширення можливостей програм, що вже існують. Наприклад, геоінформаційна система QGis використовує Python для розробки розширень та автоматизації завдань; підтримка Python SDK від різних вебсервісів, як-от бібліотека boto3 для роботи з будь-яким сервісом Amazon Web Services. Водночас Python має і слабкі сторони. Окрім складної системи  публікування власних пакетів Open Source та специфічної контейнеризації, серед недоліків можна позначити: брак інформації про те, як розробляти на Python великі програми з інтеграцією безлічі доменів та сервісів — у ніші розробки вебсайтів і вебсервісів Python більше асоціюється з невеликими програмами та MVP; слабка сторона анотацій типів (type hints). Те, що код, якщо проанотований, не дає гарантії, що там немає помилок типізації, адже типізація перевіряється тільки на етапі введення інструкцій і під час лінтингу, а в момент виконання можна підставити об'єкт будь-якого типу. «Мова добре підходить для розвʼязання алгоритмічних завдань, роботи з операційною системою, розробки вебсервісів, автоматизації тестування. Однак якщо потрібно максимально ефективно використовувати ресурси комп’ютера (памʼять та процесор) — тут Python, на жаль, програє. Попри зусилля, навіть в теорії Python не зможе наздогнати такі мови як C, C++, та Rust», — пояснює Володимир Обрізан. Python сьогодні У 2021 році Python виповнилося 30 років. Нині він посідає перше місце у рейтингах мов програмування ТІОBE та IEEE Spectrum. Простота у вивченні, велика кількість бібліотек та активна спільнота зробили технологію популярною у багатьох галузях — від вебу до машинного навчання. «Мова стала такою популярною завдяки низькому порогу входу. Для неї не треба роками вивчати компʼютерні науки та розумітись на тому, як працює віртуальна памʼять комп'ютера та вказівники. Тому Python почали використовувати багато фахівців, які не є професійними програмістами. Їм не треба було вивчати програмування, а треба було вирішувати робочі завдання. Також спрацювала філософія відкритості — навіть я з 10-річним досвідом роботи з Python не можу пригадати жодної комерційної бібліотеки. Усі завдання вже розвʼязали за допомогою Python та виклали у вільний доступ. Шукай потрібне, встановлюй та використовуй», — каже Володимир Обрізан. Головним автором мови все ще залишається Гвідо ван Россум, хоча внесок у її розвиток зробили багато інших людей. 2018 року Ван Росум відмовився від свого «титулу» і нині допомагає розвивати спільноту та мову як простий розробник. 2019 року він попросив не включати себе до ради директорів та підтримав інших кандидатів, остаточно зробивши Python незалежною технологією, яка більше не потребує засновника. Сила спільноти Спільнота розробників Python складається з великої кількості розробників та ентузіастів з усього світу, які активно співпрацюють між собою. Навіть у Python Software Foundation всі стратегічні рішення наразі приймаються колективно, а контроль за дотриманням порядку здійснює рада керівників — тимчасовий орган, який регулярно переобирається та складається з п'яти осіб. Якщо з одним керівником щось трапиться, його місце займе інший. На розвиток Python-спільноти це не вплине. У Python є PEP-індекс — задокументований регламент щодо внесення змін до структури та синтаксису мови. Будь-який розробник може запропонувати покращення, аргументувати їх цінність та надіслати текст на перевірку редакторам Python-спільноти. Якщо пропозиція пройде попередню перевірку, вона з'явиться на офіційному сайті спільноти. Тоді всі учасники зможуть вивчити її, обговорити майбутню цінність та проголосувати за заміни. «На жаль, особисто я ніколи не працював та й не спілкувався з core-розробниками. Але хочу зазначити, що українці працюють над інтерпретатором Python навіть в умовах обстрілів та війни. Наприклад, у релізі Python 3.11 (жовтень 2022) український core-розробник Сергій Сторчака зробив понад 20 змін в інтерпретаторі мови, працюючи з Конотопу на Сумщині. В релізі Python 3.12 (жовтень 2023) він зробив понад 10 змін, в релізі 3.13 (очікується восени 2024) — біля 30 змін», — розповідає Володимир. Майбутнє Python «Те, що я бачу останні роки —  Python стає «дорослою» мовою. Тут я маю на увазі, що розробляють механізми, щоб за допомогою Python можна було створювати великі проєкти. Наприклад, коли додали анотації типів, та можливість їх перевіряти, — це стало обовʼязковим в нашій компанії для розробників: за дві хвилини можна перевірити 100 000 рядків коду, що там ніде не наплутано з типами даних та вони сумісні між собою. Тому код стає більш надійним. Ще я бачу, що багато робиться для оптимізації продуктивності інтерпретатора. Багато бібліотек переведено на асинхронну роботу з вводом-виводом інформації, тобто значно підвищилась продуктивність додатків, які обробляють велику кількість мережевих запитів. Те, що Python — найпопулярніша мова (за TIOBE), не означає, що вона найкраща. Але, якщо нас всіх не замінить штучний інтелект, вона буде залишатися найбільш затребуваною ще багато років», — розмірковує Володимир Обрізан.