Декілька років тому, у 2021-му, глобальна PR-індустрія зросла на 10,2% — цьому посприяв активний ріст цифрових ЗМІ через COVID-19. Прогнозують , що до 2026 року обсяг індустрії збільшиться до $129 мільярдів проти сьогоднішніх 88. І це не дивно: вдала стратегія зв’язків з громадськістю не лише привертає увагу до продукту, а й допомагає отримати більше потенційних клієнтів, збільшити продажі та створити сильний бренд. Аби сформулювати останні галузеві тренди, ми звернулися до Ганни Устинової, Global PR Lead в продукті Headway та однойменній партнерській компанії Genesis та Рити Фломбойм, PR & Comms Manager в продукті AlphaNovel . Вони організовують PR цифрових продуктів на західних ринках, але їх досвід можна адаптувати й до локальних проєктів. Ганна працює в комунікаціях 10 років, а півтора року тому запустила напрям міжнародного PR в Headway. Рита в комунікаціях понад чотири роки, вона розвивала бренди продуктових і сервісних IT-компаній, а зараз керує PR-напрямом в AlphaNovel. Редакція корпоративного блогу разом із фахівцями Genesis підготувала великий ґайд трендів продуктового ІТ на 2023 рік. Підпишіться на розсилку Gen.Read та дізнайтеся ключові тенденції за іншими напрямами. > Data-driven підхід до PR > Важливість власних медіа > Партнерства з інфлуенсерами > Персоналізація > Відповідальність is a new black > Створення контенту, а не лише пітчинг > Створення ком’юніті навколо бренду Data-driven підхід до PR Кількісне вимірювання комунікаційної цінності is a must. Мета маркетингових активностей продуктових компаній — залучити користувачів, тож PR та репутаційний менеджмент мають підсилювати бренд на ринку, і, як результат, збільшувати потік юзерів. Важливо зрозуміти ваші бізнес-цілі, від них сформувати комунікаційні, а потім визначити метрики, за допомогою яких ви матимете змогу відстежувати прогрес у досягненні мети. Наприклад, ваша мета — збільшити кількість завантажень застосунку, і ви обрали інструмент — колаборації з інфлуенсерами в TikTok. Оцінити результат, наприклад, кількість завантажень, можна за: CTR (Click Through Rate). Метрика показуватиме, наскільки часто користувачі, які бачать ваші колаборації в TikTok, переходять за посиланням або клікають на сторінку бренду. CTR допомагає зрозуміти, які концепції відео працюють краще, а які — гірше; CPM (Cost Per Mile). Вартість за тисячу переглядів дасть змогу порівняти різні колаборації. Так, співпраця з одним креатором може коштувати дорожче, але ціна за тисячу буде нижчою завдяки великому охопленню; обсягом пошукового трафіку за ключовими словами. Специфіка TikTok така, що вірусні відео потрапляють до рекомендацій, але користувачі не завжди переходять у профіль креатора та клікають на посилання. Натомість вони просто загуглять його ім’я. Тому оцінити ефект від колаборації допоможе аналіз джерел росту пошукового трафіку. Якщо говорити про класичний PR, мета якого — збільшити впізнаваність бренду, ефективність ваших публікацій можна вимірювати такими метриками: рівень обізнаності про бренд — це якісний показник, який важливо регулярно відстежувати за допомогою досліджень і опитувань; обсяг пошукового трафіку за ключовими словами. Після масових публікацій пресрелізів або новин, треба зрозуміти, наскільки збільшилася аудиторія зацікавлених вашим продуктом користувачів; CTR (якщо в матеріалах розміщені гіперпосилання) дає змогу проаналізувати, наскільки аудиторія, що читає статті, зацікавлена у продукті, та які майданчики будуть найбільш вдалими; кількість згадок дозволить проаналізувати, наскільки проактивні публікації (ті, що ви генеруєте самостійно) збільшують інтерес аудиторії до вашого продукту та спонукають писати про вас більше. Важливо зазначити, що для кожного проєкту й кожної задачі метрики можуть суттєво відрізнятися. На це впливає бізнес-мета, ресурси, взаємодія PR й маркетингових інструментів та інші чинники. Чим ретельніше ви дослідили аудиторію, тим швидше можна до неї достукатися. Для цього слід вивчати інтереси своїх споживачів, їхні болі та бажання. Як це зробити у PR? Проводити глибинні дослідження, дізнаватися, чому люди купують саме ваш продукт. Також data-driven — це win-win-підхід у пітчингу, оскільки журналісти завжди шукають цікаві статистичні дані для матеріалів. Ви можете запропонувати їм інсайти із власних досліджень. Наприклад, ми в Headway провели опитування й дізналися, що понад 60% людей із США, Британії та Австралії хочуть бути більш продуктивними. Ці дані залюбки підхопили для своїх публікацій західні медіа та ньюзлетери. Важливість власних медіа Рита: Для інтегрованих комунікацій важливо використовувати всі наявні канали. Звісно, з поправкою на користь вашому бренду. Один зі шляхів визначення каналів — модель PESO . Вона включає: платні канали (Paid) — такі, що потребують оплати за розміщення; отримані (Earned) — безкоштовні публікації; соціальні медіа (Social) — репости, реакції, згадки в інфлуенсерів тощо; власні медіа (Owned) — блог, сторінки в соціальних мережах, сайт. Власні медіа — це спосіб комунікувати з цільовою аудиторією, утримувати наявних і залучати нових користувачів. Так, наприклад, власні медіа можуть стати майданчиком для навчання, інформування про оновлення тощо. Ми в AlphaNovel створюємо продукт для читання романтичних новел і коміксів. Щоби покращувати нашу взаємодію з письменниками, ми системно розвиваємо власний блог , ком’юніті та email-розсилки для авторів. Це дає змогу залучати письменників до взаємодії з читачами. Наприклад, відповідати на коментарі або навіть змінювати сюжет за запитом фанатів. Як наслідок, читачі отримують унікальний досвід читання й спілкування з улюбленими письменниками, а автори — швидкий фідбек від аудиторії. Створення контенту, а не лише пітчинг Рита: Кількість штатних журналістів у американських медіа падає — з 2008 року їхня вона знизилась на 26%. Продуктовий бізнес, що працює на ринках Tier-1, має не лише будувати стійкі стосунки з ключовими журналістами, а й самостійно генерувати контент (або котриб'ютити) для пріоритетних медіа. Фокусуватися варто не на виданнях general interest, а на нішевих медіа, що стосуються вашого ринку або бізнесу. Наприклад, якщо продукт для дитячої аудиторії, є сенс публікуватися в медіа для батьків — MomJunction , FamilyEducation тощо. Розповісти можна про найкращі сучасні ігри для розвитку уваги дітей, а на додачу нативно згадати про застосунки, з якими ви працюєте. Таких підхід дасть змогу охопити більше представників ЦА. Партнерства з інфлуенсерами Рита: Робота з блогерами залишається ефективним інструментом комунікацій. По-перше, такі партнерства простіше оцінювати — і за брендовими метриками (охоплення, залученість тощо), і за перформанс-метриками (конверсія в кліки, завантаження, ріст органічного трафіку тощо). Крім того, для перформансу найкраще працюватимуть партнерства з нішевими блогерами — через 100% влучання в цільову аудиторію. Щоб обрати найбільш ефективний формат колаборації з інфлуенсером, потрібно: сформулювати мету. Наприклад, якщо вам потрібно збільшити brand awareness продукту, колаборації можуть бути більш нативними. Якщо ж мета – перформанс (завантаження, кліки тощо), — важливо додавати чіткий CTA (call to action) у кожному кейсі; зібрати пул блогерів, що вас цікавлять, і проаналізувати їхній контент. Так ви зрозумієте, який формат колаборації пропонувати. Наприклад, ми в AlphaNovel працюємо над колабораціями з TikTok-блогерами, що знімають відео про книги. Проте з пулу booktok-блогерів нам підійдуть не всі — хтось не любить жанри, в яких ми пишемо, або ж надає перевагу паперовим книжкам. обрати релевантний майданчик — Instagram, Facebook, TikTok. Наприклад, в аудиторія в Instagram краще сприймає нативний контент, відтак гарно працює для брендових колаборацій. TikTok добрий для перформансу, проте там складніше прогнозувати, яке відео «залетить» у рекомендації. Персоналізація Ганна: Це слово містить багато сенсів. Якщо говорити про пітчинг медіа, то тут важливі максимально персоналізовані листи на тему, у якій спеціалізується репортер. Наприклад, до того, як написати журналісту, варто перечитати хоча б п’ять його нещодавніх статей, перевірити, коли виходила остання публікація, з якою періодичністю репортер випускає матеріали. Не завадить перевірити Twitter автора — саме там з’являються новини про зміну місця роботи, запити на коментарі тощо. Пропонуючи тему, варто зазначити в пітчі, чому вона може зацікавити конкретно цього журналіста. Можливо, він спеціалізується на темі кар’єри — і тоді ви можете запропонувати йому експерта, що поділиться методами ефективного цілепокладання. Масовий пітчинг і емейли з загальними меседжами не спрацюють у швидкому інформаційному потоці та загубляться в десятках листів, що отримує журналіст на пошту щодня. Медіа треба зацікавлювати. Також персоналізація — це про знання власної аудиторії. Часто потрапляння до нішевих ЗМІ із максимально релевантною аудиторією в кілька десятків тисяч читачів має набагато кращий ефект для бренду, ніж публікація у виданні-мільйоннику. Відповідальність is a new black Рита: Згідно з дослідженням Edelman Trust Barometer Report 2023, бізнес викликає найбільше довіри у людей серед всіх інституцій. Це одночасно чудова новина та велика відповідальність — бізнеси не можуть залишатися осторонь важливих політичних і соціальних проблем. Саме тому не існує неважливих комунікацій: будь-яка реакція, коментар, публічне висловлювання або пост у соціальних мережах матиме вплив на репутацію та на стосунки між брендом і аудиторією. Водночас важливо розуміти, що аудиторія не розмежовує лідерів бізнесу та сам бізнесу, а тому навіть особиста думка СЕО може вплинути на репутацію всієї компанії. Це важливо враховувати: на етапі планування будь-яких стратегічних комунікацій. Цінності бізнесу мають бути спільними для власників і команди; під час публічних комунікацій лідерів. Тут варто уважно слідкувати за меседжами, щоб бути на одній хвилі з порядком денним. Ганна: CSR-проєкти (проєкти з корпоративної соціальної відповідальності — ред.) підвищують лояльність аудиторії. Люди хочуть бути дотичними до компаній, чиї цінності та світоглядні позиції їм близькі. За даними дослідження PR-сервісу Prowly, 31% PR-фахівців визначає соціальну відповідальність головним трендом 2023 року. Але тут важливо не перестаратися: CSR-проєкти мають наближатися до тематики, з якою працює ваш бізнес, аби органічно в неї вписуватися. Створення ком’юніті навколо бренду Ганна: Найкращий канал для побудови ком’юніті — соціальні мережі. Намагайтеся залучати ваших підписників до взаємодії цікавим інтерактивним контентом, якісним опрацюванням коментарів, швидкими відповідями в особистих. Наприклад, ми у Headway на День психічного здоров’я запустили Instagram-маску із підтримуючими цитатами з книжкових самарі. Кільком десяткам підписників із великою активною аудиторією ми пропонували зашерити маску за бонус — тримісячну безкоштовну підписку на Headway. Реакція була дуже теплою, нам вдалося підвищити ER (Engagement Rate — показник залученості, який активну аудиторію вашої сторінки — ред.) і, крім того, отримати щирі відгуки на продукт. Будьте уважними, і ваші підписники в Instagram або ТікТок перейдуть у ранг Lifelong customers, а, якщо пощастить, то й амбасадорів бренду. Більше трендів продуктового ІТ шукайте у ґайді для підписників Gen.Read .

SQL — повноцінна мова розробки чи примітивний інструмент для вибірки даних? У чому різниця між SQL та NoSQL? Чи є актуальною ця технологія для сучасної аналітики, у якій одна таблиця може важити петабайти? Та чому знати конструкції та селекти не дорівнює знати SQL. Катерина Медведська, Data Engineer в Boosters з екосистеми Genesis, спростовує найпоширеніші міфи в цій сфері. > Я вивчив увесь SQL > SQL потрібен тільки для вибірки даних та роботи з селектами > SQL за функціоналом — повноцінна мова розробки, аналогічна Python > В NoSQL немає SQL > Щоби писати ефективні запити, достатньо знати конструкції мови > SQL для аналітики: застаріле рішення, має надто обмежені можливості > Дані — абсолютно точні, з нульовою ймовірністю збою МІФ №1 Я вивчив увесь SQL. Більшість людей, які починають опановувати SQL, навіть не підозрюють, що насправді вивчають діалект. Є певні стандарти SQL, які кожна СУБД (система управління базою даних) бере за основу й чимось доповнює. Діалекти відрізняються у процедурній частині, у написанні функцій, різному процесингу, командах. У деяких СУБД написання процедури навіть підтримується на різних мовах: наприклад, в PL/pgSQL можна писати на стандартному SQL, а можна на С++. Корисно вивчати різні діалекти, адже швидко перейти з одного на інший доволі важко. Деякі діалекти SQL: SQL/PSM (SQL/Persistent Stored Modules) — стандарт процедурного програмування; PL/SQL (Procedural Language / Structured Query Language) — розширення для Oracle; PSQL (Procedural SQL) — розширення для Firebird та Interbase; T-SQL (Transact-SQL) — розширення для Microsoft SQL Server та Sybase; PL/pgSQL (Procedural Language/PostGres Structured Query Language) — розширення для PostGres). МІФ №2. SQL потрібен тільки для вибірки даних та роботи з селектами. Насправді SQL вміщає кілька наборів команд — для маніпуляцій даними, структурами, транзакціями, правами доступу тощо. Їх поділяють на пʼять груп: DDL — Data Definition Language. DQL — Data Query Language. DML — Data Manipulation Language. DCL — Data Control Language. TCL — Transaction Control Language. Селекти — найпоширеніший тип команд у роботі з базами даних. Але це не означає, що всі інші групи команд — лише для бекенду. Аналітики менше займаються обробкою, майже не розробляють структури (команди DDL) і не користуються транзакціями. Але маніпуляція даними — мастхев для всіх, хто працює з SQL. Дата-інженери, дата-аналітики, продакт-аналітики працюють із даними, часто неточними, неякісними, які треба очищувати, обробляти та підганяти під свої стандарти. Тому вони мають знати SQL на досить хорошому рівні. МІФ №3. SQL за функціоналом — повноцінна мова розробки, аналогічна Python. SQL часто потрапляє в рейтинги найпоширеніших мов поряд із JavaScript та випереджає Java, Python, PHP, C# та інші. Це спричиняє багато суперечок. На SQL багато чого можна зробити, особливо, якщо використовувати діалекти в конкретних базах даних. Наприклад, навіть написати HTTP запити. Але ця мова має обмежений функціонал і створена для конкретних задач. МІФ №4. В NoSQL немає SQL. SQL передбачає роботу з реляційними базами даних. Наприклад, Microsoft SQL Server, Oracle, MySQL. У них інформація зберігається в рядках: кожен із них — одна одиниця памʼяті. Вважається, що цей тип баз даних можна масштабувати тільки вертикально, вони працюють на одному сервері, із часом вимагаючи все більше місця та розростаючись до величезних розмірів. Хоча насправді правильно побудована база даних може мати розмір у 8 терабайтів та стабільно працювати. Пізніше зʼявилися нереляційні бази даних — NoSQL. Це ціла сукупність різноманітних СУБД які обʼєднані єдиною ідеєю легкого масштабування на кластер серверів та максимальною відмовостійкістю. Існують різні моделі NoSQL баз даних для вирішення різних завдань. Наприклад, дуже поширені: стовпчикові, документні, ключ-значення та графові БД. Частина з них справді не підтримує стандарт SQL, але є і такі які підтримують його практично на 100%, наприклад, популярні в аналітиці стовпчикові бази даних. Вони розраховані на великі обсяги інформації — тисячі петабайтів. Тому насправді «NoSQL» не означає, що там немає SQL. Оригінальна розшифровка — «not only SQL» або «non relational SQL». Спеціаліст, який знає SQL, може зайти в нереляційну базу й повноцінно працювати — там підтримуються практично всі команди (створення, дроп, зміна, DML). Вони можуть дещо відрізнятися за синтаксисом, але мінімально. МІФ №5. Щоби писати ефективні запити, достатньо знати конструкції мови. Люди часто вивчають конструкції, але не розуміють, що лежить в основі. Для ефективної роботи треба розуміти, як працює база даних під капотом. Кожна СУБД має певний оптимізатор, який працює по-своєму. Фактично запит — це набір інструкцій. У реляційних базах даних ефективність виконання запиту залежить від індексів та статистики (розраховується СУБД на основі попередніх запитів). На основі цієї статистики оптимізатор оцінює, чого йому очікувати від кожної частинки запиту і як це ефективно поєднати. Це великий обсяг інформації: як база даних зберігає інформацію, як обирає в певних конструкціях і як обробляє. Якщо статистика або індекс змінюються, оптимізатор може перестати знаходити правильний план запиту. І конструкція, яка раніше працювала нормально, починає перевантажувати сервер та обробляється дуже довго. У «стовпчикових» базах даних теж є нюанси: наприклад, тут відсутні індекси, а ще можна вибирати та обробляти окремі колонки, що значно економить ресурси сервера. МІФ №6. SQL для аналітики: застаріле рішення, має надто обмежені можливості. Це упередження випливає з тих далеких часів, коли існували тільки реляційні бази даних із суто вертикальним масштабуванням. Зараз воно популярне серед людей, які насправді не дуже добре знають SQL — лише базові конструкції селектів та сучасні інструменти обробки даних. Сьогодні ж для різних завдань аналітики потрібні різні види баз даних, наприклад, вище згадані «стовпчикові» для легкого масштабування системи. SQL — досить потужна мова, яка для деяких завдань навіть зручніша за Python (для обробки даних, дедублікації, збагачення тощо). Велика кількість інструментів побудовані саме на базі ідеології SQL. Знаючи цю мову, можна швидко опанувати Spark SQL чи бібліотеку Pandas в Python — у них під капотом схожі команди. Тому SQL точно не застаріла для аналітики, просто треба використовувати нові продукти. МІФ № 7. Дані — абсолютно точні, з нульовою ймовірністю збою. Усі, хто працюють із великими даними, знають, що проблем із ними дуже багато: неточності, помилки, невідповідність формату, дублі. Як не буває програмного забезпечення без помилок, так і не буває абсолютно точної бази даних. В аналітиці вважають, що похибка у 2-3% — допустима й не має високого впливу на результат.

У жовтні 2022 року екосистема освітніх можливостей Genesis Academy та медіа Vector запустили спільний подкаст « Як вам вдалося? ». Протягом сезону топменеджери відомих українських продуктових компаній ділилися історіями розвитку їхніх проєктів, команд та ідей. Запуск цифрового продукту відбувається в умовах абсолютної невизначеності. Адже ти створюєш те, чого раніше ніхто не робив. Цей шлях не може складатися лише з успіхів, тому в ІТ-сфері традиційно толерантне ставлення до помилок. Їх відкрито обговорюють із колегами, шукають причини та роблять висновки. Можна сказати, що досвід кожного менеджера складається з невдач та помилок, які він зміг визнати та осмислити. Ексклюзивно для блогу Genesis девʼять менеджерів відомих цифрових продуктів в Україні поділилися своїми фейлами, які вплинули на бізнес, а в деяких випадках навіть зруйнували команду. А також роздумами, чому помилятися нормально й навіть корисно, та як перетворити невдачу на «lessons learned». Протягом 2,5 років існування мобільного застосунку Дія складності іноді виникають через людський фактор. З деякими проблемами ми зіткнулися під час роботи сервісу ВПО (отримання довідки переселенця та подача заявки на отримання допомоги). У березні 2022 року мільйони людей були змушені переїхати в інші регіони країни та подали заявки через наш сервіс. Тоді органи соціального захисту обробляли заявки вручну, це було повільно, тому людям доводилося довго чекати. Думаю, ви здогадуєтеся, яка кількість людей написала в службу підтримки та кожному з нас: «Що сталося? Я подав документи, нічого не відбувається». І хоча затримка була не з нашого боку, немає сенсу виправдовуватись. Якщо ти замовляєш таксі, а воно не приїжджає, тобі байдуже, як звати водія. Так само й у нас. Користувач отримує сервіс у Дії. І якщо він поганий, ми маємо робити спільні висновки з нашими колегами. Зараз ми спільно з Мінсоцполітики автоматизували всі процеси — і через застосунок Дія можна також скористатися двома новими послугами – змінити адресу та скасувати статус ВПО. Робочих невдач у проєкту Helsi було чимало. Наприклад, під час презентації меру Києва впровадження системи в перший медичний заклад не працював інтернет. Бо мережеве обладнання відключили, зачинили приміщення, і ключ «пішов» додому з відповідальним співробітником. А під час вакцинації у Верховній Раді постійно вилазили баги: то профіль заступника міністра з протилежною статтю, то некоректне прізвище. Але якщо говорити про стартап загалом, то Helsi — успішний продукт, який пройшов багато стадій та продовжує зростати. Далеко не всім стартапам це вдається. Фейл цього року — фінальний тест для всеукраїнського освітнього курсу « Створення та розвиток IT-продуктів » . Це масштабний проєкт, який ми запустили у вересні 2022 року спільно із ГО «Освітня фундація продуктового IT», студією онлайн-освіти EdEra, Мінцифрою та МОН. У чому полягала проблема: усі попередні навчальні продукти ми робили для вузької аудиторії. Для зовнішніх проєктів Genesis Academy проводили відбори, які проходили зазвичай близько 30 людей із певною базою знань та навичками у сфері. У цей же раз ми працювали з освітнім продуктом на широку аудиторію. Це був курс одразу на двох платформах для понад 5000 людей. Перша версія курсу була створена для студентів ЗВО і пропонувалася у форматі віртуального стажування, а друга — розміщувалася на онлайн-платформі Дія.Цифрова освіта . У неї була вже інша мета — допомогти якомога більшій кількості людей зорієнтуватись у професіях, які можна опанувати в продуктовому IT. Ця версія курсу доступна всім охочим. Але ми не врахували, що в цих продуктах кардинально різні аудиторії, та створили занадто складний фінальний тест для користувачів Дія.Цифрова освіта. У першій ітерації його пройшли всього 1%. Проблему ускладнювало правило платформи, що сертифікат зможуть отримати тільки ті, хто відповів на всі питання правильно. Уявіть, скільки емоційних відгуків було від решти 99% людей. Тоді ми зробили висновки, адаптували тест, зменшили кількість завдань із 25 до 15. Цінність цього фейлу в тому, що є велика відмінність в підходах створення навчального продукту для різних аудиторій та платформ. Хоч ми можемо думати, що користувачі будуть дуже схожі за бекграундом, потрібно детально ще раз перевірити релевантність матеріалів навичкам аудиторії та масштабам виконання. Моя особиста помилка — казати жорстке «ні», відмовляючи в інвестиціях. Краще «залишати двері відкритими» та продовжувати спілкуватися. Якщо в проєкту зʼявиться позитивна динаміка, або щось зміниться, а це буває досить часто — фаундери роблять «півоти», починають працювати над іншою ідеєю, — то у вас буде можливість продовжити діалог. Другий фейл — упереджене ставлення до якості пітчдеків (презентацій для інвесторів). Раніше, якщо він був неякісним, я одразу відмовляв. А потім почав проводити дзвінки з такими фаундерами та переконався, що часто в людини може не бути навички створення якісних презентацій, але натомість вона вміє класно будувати компанію. Це було своєрідне відкриття. Мені здається, помилятися — це робота продакт-менеджера. Психологічно це важко, але очікувано. Для мене справжній фейл — це коли в тебе щось не вийшло, але ти не зміг зрозуміти, чому. На початку своєї карʼєри я запускав продукт YouControl. Перша модель монетизації — ми брали гроші за кожне досьє на компанію. Ця послуга була дешевою, але попиту не мала. І ми ніяк не могли зрозуміти, чому. Адже потенційними клієнтами були великі організації з бюджетами. У якийсь момент ми докумекали, що можна в них просто запитати, що не так із цією послугою. І вони пояснили — бюджети складають на рік уперед. Прогнозувати, скільки досьє компаній їм знадобиться важко, а кожну витрачену гривню доводиться погоджувати. Так з’явилася річна підписка на сервіс. Тобто суть нашої помилки була не в хибній моделі монетизації, а в тому, що ми не могли інтерпретувати, чому користувачі не платять за сервіс. Коли ти вчишся керувати великою командою, тобі треба обирати правильних людей та позиції. Буває так, що ти помиляєшся. І це може коштувати багато грошей, часу, а іноді — команди. Одного разу я зробив помилкове призначення. Людина хотіла отримати конкретну позицію, але виявилося, що вона не була готова до цього. Тому довелося перезбирати команду, багато спілкуватися та фіксити всі процеси. У такій ситуації важливо визнати свою помилку та взяти на себе відповідальність. Мені здається, що наш найдорожчий фейл — це те, що ми не розвивали команду, не масштабувалися протягом доволі довгого періоду. До 2018–2019 років у нас було 10 людей. І хоча ми — адепти маленьких команд, у цьому є певна межа. Коли в тебе розвивається ринок, усе летить, а в тебе вся команда «зашивається», ти не можеш думати про нові формати та проєкти. Ми так довго працювали в режимі «несеться», що просто не могли знайти час для найму. Потім я зрозуміла, що якщо хочу показувати перформанс, мені потрібні люди. Щоби не просто сидіти вичитувати статті, а щось робити — креативити, генерувати ідеї тощо. Тоді ми почали формувати редакцію, розділили команди. І коли почали наймати більше людей, ми змогли запускати нові формати та робити класні нові штуки. Думаю, через цю помилку ми багато втратили. Зараз могли б бути значно далі. Релізи в п’ятницю — через це проходили, мабуть, усі. Це коли ти випустив реліз, а потім починаєш писати команді, що потрібно все терміново виправляти. І всі вихідні проходять за компом. Невдача, що запамʼяталася — коли ми перенесли продукт «доставка» на головний екран. Перед цим ми провели багато сесій юзабіліті-тестування, приходили до користувачів, питали, чи їм усе зрозуміло. Знайшли проблему, що шукати цей сервіс у загальній «каруселі» незручно. Виправили. А коли випустили оновлення, ми отримали масові відгуки в сторах «не можу знайти доставку». Користувачі просто не помічали цей сервіс на головному екрані. Ми почали розбиратися, проводити ретроспективу і зробили три висновки: 1. Треба було додатково проінформувати користувачів, що тепер ця функція знаходиться на головному екрані. Можливо онбординг відволікатиме когось від основного флоу створення замовлення, але тоді користувач знатиме, де знаходиться ця функція — не в каруселі, а на головному екрані. 2. Як би ти не інформував користувача, якщо в нього зʼявився умовний рефлекс, що треба натиснути 1–2–3, то щоб ти не робив, усе одно хтось буде казати «мені незручно, стало гірше». 3. І найголовніше — юзабіліті-тестування не гарантує 100% успіх. Мабуть, найбільша моя помилка — це спроба уникати професійних фейлів. Я досі працюю з відчуттям «відмінниці» всередині, де ти хочеш завжди все робити ідеально з першого разу, швидко та ефективно. Але це суперечить суті стартапу та інновацій, де тільки через помилки можна прийти до чогось, що змінить світ. Тому важливо помилятися, експериментувати, пробувати, але пам’ятати про свою систему цінностей, навіщо ти все це робиш.

Вдале партнерство допомагає зекономити час та кошти, прискорити розвиток бізнесу, вивести продукт на новий ринок, підсилити бренд, і, головне, — отримати додатковий прибуток. За налагодженням всіх процесів та пошуком партнерів стоїть bizdev, або менеджер з розвитку бізнесу. Що це за професія, що саме робить bizdev у ІТ-компанії, де він шукає партнерів та що потрібно, аби ним стати. Розповідаємо у матеріалі разом із Вікторією Булгак, Head of Partnership у Genesis та Ольгою Шаповаловою, Head of B2B в Headway, партнерській компанії Genesis. Вікторія уже 6 років працює з партнерствами у Genesis та закриває угоди на $15 мільйонів. Ольга теж працює в екосистемі уже 6 років, і за цей час побудувала 5 команд з нуля. Хто такий bizdev та як він працює з продуктом Найбільш вдало бізнес-девелопмент описує визначення, яке наводить Ольга Шаповалова, Head of B2B в Headway. Це процес виявлення й залучення нових партнерів та можливостей, що сприяють росту й прибутковості бізнесу. Відповідно, завдання біздева — створити довгострокову цінність для компанії та побудувати стосунки, що конвертуються у прибуток або хоча б можливості для його отримання. Для найкращого результату Bizdev має дуже добре розуміти, як працюють маркетинг, продажі, аналітика, знатися на переговорах та проджект-менеджменті. Поєднувати ці ролі він може на початку, коли компанія ще стартап, а людей не вистачає. Однак далі він скоріше координує роботу відділів. Партнерства при роботі з ІТ-продуктом можуть бути зовсім різними, говорить Head of Partnership Вікторія Булгак. Угоди стосуються і монетизації продукту, і аналітики, і зберігання даних, і розробки тощо. Окрім безпосередньої роботи з партнерами роль біздева може передбачати: покращення операційних процесів та оптимізацію бізнесу, що прямо впливає на витрати бізнесу. швидкий доступ до правильних людей. «Вчора ваші креативи бачили тисячі людей, а сьогодні платформа змінила алгоритми чи відправила акаунт у бан. Без доступу та теплого контакту з відповідальними фахівцями виправляти ситуацію буде важко і дорого», — говорить Вікторія Булгак. PR та роботу з брендом. Bizdev опосередковано впливає на залучення досвідчених фахівців до компанії, адже люди хочуть працювати з організаціями, що співпрацюють з лідерами ринку, зазначає керівниця відділу партнерств та комплаєнcу. Коли компанії потрібен Bizdev Функція біздеву потрібна і маленьким стартапам, і великим глобальним корпораціям, вважає Вікторія Булгак. «Кількість менеджерів та налаштування процесів будуть відрізнятися залежно від масштабів бізнесу. Однак подумати про Bizdev варто уже на етапі запуску. Так ви зможете вдало презентувати свій продукт партнерам навіть на рівні MVP, побудувати з ними грамотну комунікацію, донести свій потенціал зростання, «продати» команду, візію та амбіції», — говорить Вікторія. На початку обов’язки Bizdev може виконувати CEO, фаундер або інший топменеджер команди. Зі зростанням бізнесу збільшується кількість партнерів, з якими треба тримати зв'язок, з’являється необхідність у фахівці на фултайм або навіть цілій команді. Наприклад, в екосистемі Genesis — два десятки бізнесів, які розвивають до сотні продуктів. Один менеджер веде кілька напрямів. Попри те, що робота передбачає планування та стратегію, Bizdev не ухвалює рішення самостійно, а, скоріше, допомагає розкрити потенціал зростання компанії. Тож напрями його роботи можуть відрізнятися — від покращення наявної бізнес-моделі до виходу на міжнародний ринок. Ідеальний Bizdev На своїй посаді біздеву доведеться займатися дуже різною роботою. Аби справлятися з завданнями, йому знадобиться декілька ключових навичок. Досвід у продажах. Тобто вміє шукати потенційні контакти, розуміється на техніках ведення розмови та вдалих презентаціях. Розвиток бізнесу та продажі мають багато спільного, основа відмінність — у меті та предметі розмови. Завдання сейлза — продати товар та заробити кошти, а Bizdev — продати ідею та залучити ресурси партнера. Вміння вести переговори. Закриттю майже будь-якої угоди передують кілька ітерацій переговорів. Далі на Bizdev чекають регулярний моніторинг та оптимізація співробітництва з партнерами. Тому варто навчитися шукати win-win, будувати сильну переговорну позицію та не здаватися, якщо з першого разу угода не відбулася. Здатність керувати складними проєктами. Масштабні завдання, які передбачають партнерства, потребують дуже конкретних скілів проджект-менеджера: стратегічне мислення, управління командою, мультизадачність, розуміння специфіки галузі (і своєї, і партнера), робота з документацією та інші. Трохи аналітики. Що відбувається в тій чи іншій галузі? Які у неї перспективи? Які вільні ніші існують? Які проблеми у цільової аудиторії та як їх вирішують конкуренти? Володіти цією інформацією вкрай важливо для побудови вдалих та надійних партнерств. Збір даних заощаджує час, кошти та інші ресурси бізнесу. Ось який вигляд має повний перелік навичок Bizdev: З чого складається робочий день Bizdev Менеджери з розвитку бізнесу відповідають за зростання компанії, тож їхні завдання змінюються щодня. Типові обов’язки можуть включати: зустрічі з наявними та потенційними партнерами; пропрацювання плану розвитку; підготовку фінансових прогнозів; планування нових маркетингових ініціатив; пошук нових ринків та їх освоєння. Детальніше про щоденні обов’язки Bizdev розповідає Вікторія Булгак: «Мій день починається з перевірки пошти та соціальних мереж. Далі — комунікація щодо нових партнерств, колаборацій, перегляд поточних контрактів, переговори щодо угод на наступний період. Надсилаю фолоуапи — адже є угоди, переговори щодо яких ведуть впродовж року. Завдання із зірочкою — поєднати очікування компаній екосистеми та партнерів під одним спільним знаменником. Як лідер команди я маю також менеджерські обов’язки: синхронізуюся з членами своєї команди, даю фідбек щодо роботи, допомагаю вирішувати спірні питання. Важливо, щоби кожен у команді розвивався, отримував нові челенджі та допомогу. Іноді ми беремо участь в організації вебінарів, пітчів, презентацій, співпрацюємо з партнерами на рівні спільних кейсів. Наприклад, декілька років тому я звернулася до Meta (тоді вони називалися Facebook) і запропонувала зробити спільний кейс, адже Genesis уже тоді був одним із найбільших паблішерів платформи у регіоні. Вони погодилися — і ми разом організували зйомки відеоролика, який Facebook потім розмістив у себе на сайті», — говорить Вікторія Булгак. Як і де Bizdev шукає партнерів Є декілька шляхів, рухаючись якими, Bizdev знаходить нові контакти для співпраці. Зокрема: Отримує у «спадок» від колег чи попередників на посаді. Особливо часто таке трапляється в бізнесах з уже налагодженою функцією Bizdev. Знаходить через нинішніх партнерів. «Нещодавно я шукала контакти в компанії, з якою ми ще не працювали. Безпосередніх знайомств там у мене не було, тому звернулася до своїх партнерів з однієї глобальної організації, а ті — до своїх колег з іншого регіону, у яких мають бути ці контакти. Днями нам мають зробити інтро», — ділиться Вікторія Булгак. Здобуває завдяки нетворкінгу. Чим більша власна мережа контактів, тим простіше достукатися до потрібних людей. Пише «холодні» листи. Тобто шукає необхідні контакти у Facebook, Telegram, LinkedIn та інших каналах. Тут важливо не стільки знайти, скільки зацікавити потенційного партнера. «Для першого контакту складіть персоналізований пітч: подумайте над темою листа, що можете запропонувати, підсвітіть свої сильні сторони. Згадайте спільних знайомих, якщо вони у вас є, або поділіться враженнями від останнього допису у соцмережах. Закінчити листа можна пропозицією про короткий дзвінок чи зустріч», — Вікторія Булгак. Зустрічає на спеціальних заходах. Біздев заздалегідь проглядає список тих, хто буде на заході, аби зрозуміти, кого шукати, завчасно призначити зустріч та зав’язати знайомство. Як стати Bizdev Вхід у професію буде комфортним для людей з дуже різних сфер: юриспруденція; економіка; маркетинг; продажі; фінанси; акаунт-менеджмент; інвестиційний банкінг. Особливо часто до біздев-команди приходять люди з досвідом у компаніях «Великої четвірки». «Фахівці з таким бекграундом вміють мислити системно, зводити докупи багато процесів та налагоджувати контакти з багатьма продуктами та організаціями. У мене самої — юридична освіта, завдяки якій я вмію структурувати свої думки та вести переговори», — каже Вікторія Булгак. Вона додає, що позиція Bizdev передбачає сотні різних процесів: від масштабних проєктів та угод на мільйони доларів до дрібничок на кшталт привітань партнерів з днем народження. Що почитати, подивитися, послухати біздеву: «Ніколи не йдіть на компроміси», Крісс Вос «Як здобувати друзів і впливати на людей», Дейл Карнегі «Ніколи не їжте наодинці», Кейт Ферацці «Продавець взуття», Філ Найт Подкаст про B2B-продажі Make It Happen Mondays «Домовлятися завжди», Ґевін Кеннеді «Як розмовляти будь з ким, будь-коли й будь-де. Секрети успішного спілкування», Ларрі Кінг «Ненасильницьке спілкування. Мова життя», Маршалл Розенберг

Чому мобільна розробка технологічніша за веб? Чи може програміст запустити застосунок без команди? Чи правда, що головний етап роботи над продуктом починається після релізу, та чому всі сперечаються про конструктори інтерфейсів і force unwrap? Артур Майорський, iOS Engineer в Universe з екосистеми Genesis, спростував найпоширеніші міфи в цій сфері на прикладі розробки найпростішого застосунку — мобільного калькулятора. > Мобільна розробка — це примітивне програмування > Застосунок можна створити без коду > Після релізу фаза розробки завершується > Ринок Mobile App — перенасичений, а створення застосунків — затратне > Використання force unwrap в iOS-розробці — так чи ні? > Час програмістів дорожчий, ніж час компʼютерів МІФ №1 Мобільна розробка — це примітивне програмування. Цей міф виник через велику кількість інструментів, що полегшують роботу iOS- та Android-інженерів. А також тому, що в цю сферу досить низький поріг входу. Навіть щойно почавши вивчати розробку, можна написати просту логіку базового калькулятора, додати готовий інтерфейс, — і ваш перший «продукт» готовий. Але водночас у мобільній розробці чимало цікавих завдань і складних технологій. На відміну від вебу тут є доступ до найрізноманітнішого функціонала. Наприклад, доступ до всіх функцій камери та LiDAR на телефоні дає можливість реалізувати функціональність, можливу лише в мобільній розробці. В нашому застосунку ScanGuru це використовується для підказок користувачу при скануванні документа. Це допомагає зробити якісніший знімок, регулюючи відстань, ступінь освітлення тощо. Такі рішення неможливо реалізувати, просто під’єднавши стандартну бібліотеку роботи з камерою. Треба аналізувати потік кадрів, створювати алгоритми, які шукатимуть на кожному кадрі документи та перероблятимуть їх у вигляд, максимально схожий на цифровий. Тому мобільну розробку аж ніяк не можна назвати примітивною. МІФ №2 Застосунок можна створити без коду. В iOS, як і в Android, існують готові рішення, наприклад, конструктори інтерфейсів. Деякі розробники використовують їх, адже це швидше й наочніше. Інші створюють інтерфейси з допомогою коду, тобто прорахуванням кожного елементу на екрані, адже це дає більше гнучкості. Часто це стає предметом суперечок та навіть хейту. Але насправді можна знайти плюси й мінуси в будь-яких рішеннях та архітектурах. В Universe не користуються конструкторами інтерфейсів в iOS. В Android-застосунку доля готових інтегрованих рішень складає максимум 5%. У будь-якому разі це лише візуальна частина. Розробнику все одно доведеться багато працювати з кодом, щоби її налаштувати. Навіть вже згаданий калькулятор неможливо створити готовими рішеннями без коду. МІФ №3 Після релізу фаза розробки завершується. Навпаки, усе тільки починається. Більшість розробників спочатку випускають MVP-версію продукту, щоби перевірити гіпотезу та нішу. На цьому етапі швидкість — найважливіша, тому командам немає сенсу заморочуватися над архітектурою та дизайном. Це може зайняти багато часу та інвестицій, а продукт не злетить. Повернімось до калькулятора. Наприклад, є гіпотеза, що такий застосунок може приносити мільйони. Можна створити його за день, а можна залучити команду продакт-аналітиків, два місяці думати над дизайном, проводити UX-дослідження та за пів року нарешті запустити бездоганний калькулятор. Але виявиться, що в цю нішу дуже дорого приводити людей. Дізнатися про це можна було б, витративши лише один день розробки. Тому після релізу, якщо гіпотеза не підтвердилася, і застосунок нікому не потрібен, фаза розробки справді завершується. Якщо ж продукт злетів, ця фаза починає розганятися: переписується MVP, створюється нова архітектура, набирається команда, планується додатковий функціонал, проводяться тести тощо. Надалі продукт треба буде постійно покращувати — протягом всього його існування. МІФ №4 Ринок Mobile App — перенасичений, а створення застосунків — затратне. В App Store та Google Play — мільйони застосунків. Їхнє число постійно змінюється, адже щодня на платформи завантажуються нові продукти та видаляються старі й неякісні. Водночас загальний обсяг ринку мобільних застосунків щороку зростає. 2021 року користувачі обох платформ витратили $132 млрд, а за прогнозом Sensor Tower , у 2026 році глобальні витрати сягнуть $233 млрд. Тому перенасичений не весь ринок загалом, а окремі його ніші. Натомість є ніші, що поступово зростають без зупинки, або ті, що стрімко зростають, а потім зупиняються. Для багатьох застосунків достатньо одного розробника. Якщо він обрав правильну нішу та зробив конкурентний продукт, у нього є всі шанси на успіх. Не для всіх продуктів потрібна велика команда iOS-розробників, адже 100 людей не зробить кращий калькулятор, ніж одна людина. Створити застосунок насправді можна безкоштовно, інвестувавши лише власний час та 100$ за акаунт розробника в App Store (25$ — в Google Play). Якщо розробник планує запускати продукт самостійно, він має базово розумітися в бізнесі, продакт-менеджменті та маркетингу, інакше не зможе конкурувати та залучати аудиторію. МІФ №5 Використання force unwrap в iOS-розробці — так чи ні? Force unwrap — це дія, яка за певних умов може «крашнути» застосунок. Та тема для запеклих дискусій. Одні розробники вважають, що їх не можна використовувати в коді. Але, з іншого боку, вони космічно заощаджують час розробника в застосунках, складніших за калькулятор. І якщо все робити правильно, шанс, що все впаде, — частіше мінімальний. Тому є думка, що за певних обставин force unwrap можна використовувати. Наприклад, якщо не використовувати force unwrap, а шукати шляхи безпечно приховувати від користувача помилки, як це доволі часто роблять, QA може пропустити баг. Краш пропустити неможливо, тому force unwrap може економити багато часу розробнику та зменшувати кількість багів. МІФ №6 Час програмістів дорожчий, ніж час компʼютерів. Є думка, що всі застосунки працюють занадто повільно, й розробники не докладають достатньо зусиль, щоби зробити їх швидшими. Для мобільної розробки справді немає сенсу робити дуже швидкі програми. Адже в чому сенс супершвидкої операції, якщо здатність екрана «намалювати» її все одно обмежена? Зазвичай розробники у швидкості обробки інформації орієнтуються саме на можливості екрана — 1/120 секунди. Так користувач не помітить, як вона обробляється. Навіть якщо такої швидкості досягнути не вдається, і певна операція обробляється довше, усе одно краще не «вигадувати велосипед» та не писати суперскладний код два тижні, щоби воно працювало швидше. Краще просто намалювати гарний loader, адже два зайвих тижні розробки означають, що на два тижні пізніше вийде реліз. За цей час він міг би приносити +20% виручки щодня. Це потенційно сотні тисяч втрачених доларів просто тому, що в користувача трошки швидше завантажиться екран, і це не принесе глобальної користі ані йому, ані бізнесу. Сучасні смартфони — досить потужні, здатні нормально працювати навіть у застосунках із дуже поганим кодом. Якщо програма працює занадто повільно й зависає, то це відбувається через очевидні баги, а не через те, що розробник не використав якісь складні рішення. Краще просто та швидко написати якісний код, ніж довго працювати над тим, щоби застосунок працював на 1 мілісекунду швидше. У простій зрозумілій структурі коду значно легше шукати баги та фіксити їх. Інший бік складного коду — довгий онбординг нових співробітників. Десь економиться трошки часу, але гальмується вся подальша розробка. Скоро в Genesis планується запуск нового профільного комʼюніті для мобільних розробників, дізнайтес я про інші 12 спільнот.

У новому матеріалі з серії Genesis Crew публікуємо історію генезійця, що нині боронить Україну у складі ЗСУ. SEO Team Lead проєкту Legit з екосистеми Genesis, Олександр Дука, у квітні долучився до підрозділу, що виконує бойові завдання на фронті. В інтерв'ю для блогу Genesis Олександр розповів про те, чим керування бійцями схоже на управління командою, як військові проходять навчання, і як виглядає вдалий день на війні. У сфері SEO я близько десяти років. З 2013 року налаштовував клієнтські сайти. А у 2018 мій друг, що працював у Genesis, запропонував подати резюме у компанію. Я не одразу погодився, був упевнений, що мого професійного рівня буде недостатньо, адже раніше не працював із продуктом. Ба більше, вважав тоді, що новинні сайти — це нудно, одноманітно і нецікаво для SEO-спеціаліста. Але все ж спробував, пройшов всі етапи співбесіди й потрапив у команду Legit. Спершу працював як рядовий SEO-фахівець, а з реогранізацією проєкту перейшов на позицію SEO Team Lead. Ми з колегою Ніною Ромащенко вдвох управляли командою SEO: вона відповідала за контент та менеджмент копірайтерів, а я — за технічну реалізацію, взаємодію з розробниками, а також за нашу стратегію в цілому. Робота в Legit стала якісним левел-апом в порівнянні з тим, що я робив у попередній компанії. Коли в тебе є клієнти, мусиш підлаштовуватись під їх запити, працюєш на замовника, а не для покращення продукту. В SEO для медіа все зовсім по-іншому: безперервно шукаєш ідеї та інструменти для кращого результату, відстежуєш, що там у конкурентів, як зробити ліпший контент, ніж у них. Висока конкуренція — те, що драйвить мене в роботі найбільше. І до того ж команда — у нас зібралася дрімтім, найкращі фахівці, яких я зустрічав. Пишаюся нашою співпрацею і нашими досягненнями. Минулого літа ми успішно вийшли з-під апдейту, показники сайтів значно зросли, і все це в результаті піврічної кропіткої роботи із переформатування процесів, підходів тощо. У лавах ЗСУ У перші дні вторгнення пішов у військкомат. На жаль, мені відмовили через те, що не мав бойового досвіду. Тому взявся волонтерити у складі групи, яка допомагала київській ТрО та ще декільком підрозділам: купували спорядження, шукали рації тощо. І в середині квітня, коли росіяни відійшли з Київщини, один з наших «підопічних» підрозділів оголосив набір у свої лави. Не дивлячись на те, що вони виконували досить специфічні бойові завдання, і людей без досвіду брали не охоче, мені пощастило доєднатися до них. Тоді в підрозділі з'явилися інструктори, стало більше можливостей навчати новачків. Я вже був добре знайомий і з командуванням, і з бійцями, і зрозумів, що цей мій шанс нарешті приєднатися до української армії, другого такого шансу чекатиму ще довго. В підрозділі дуже круте командування: «азовці» ще з першого набору 2014 року — бійці з історією, величезним досвідом. Це була надзвичайна можливість воювати поряд із кращими з кращих. Бойове хрещення У мене не було ілюзій про армію, бо в Genesis я прийшов після року служби на контракті у Києві. Тоді мені дуже не сподобалося, але я отримав уявлення про те, як усе працює в цій системі. Тому в мене не було наївних уявлень про шикарну підготовку та купу адекватних людей в армії. Тож з потраплянням в бойовий підрозділ «розриву шаблону» не трапилось. Спершу було півтора місяця навчання, яке ми проходили в частині біля Києва. У нас були кваліфіковані інструктори із США, вони якісно проводили підготовку, багато чого дали, що потім стало в пригоді. Паралельно ми оформлювали документи, збирали потрібні речі й техніку. Врешті поїхали за місцем призначення. Точка прибуття підрозділу — це, зазвичай, місто за лінією фронту або біля неї. Там ми розселяємося і чекаємо на бойові задачі. Скільки триватиме очікування — завжди невідомо. Це можуть бути тижні, може дні. Специфіка наших задач в тому, що ми виїжджаємо на позиції попрацювати й одразу повертаємося назад. Не всім так щастить, бо є механізовані бригади, які тримають свою ділянку, не залишаючи її. Вони передають, що відбувається, не пускають ДРГ тощо. Це стандартна робота з утримання позицій, але вона передбачає те, що ти можеш місяцями не вилізати з окопів. Перший бойовий вихід точно ніколи не забуду. Як завжди, усе було нашвидкуруч, ми практично не мали уявлення знали, куди йдемо. На місці попали у засідку. Працювали тільки росіяни, летіла арта, а від нас — нічого, була тиша. Ми знали, що якщо зараз вони на нас підуть, то швидко будуть уже у Миколаєві. Я не скажу, що було страшно йти, але це була хоробрість від незнання. Ми просто не знали, куди й на що йдемо. Потім вже стало страшно, ніколи не хотілося так жити, як тоді. Проте вдалося вибратись. Це був цікавий і цінний досвід. В результаті ми вийшли з малими втратами. Після того ми навчали людей без досвіду бойових виходів, і я побачив колосальну різницю. Люди без виходів за плечима дуже погано вчаться і мало розуміють, куди вони йдуть. Перебування в бою кардинально змінює ставлення до навчання та до опанування навичок, які можуть врятувати тобі життя. Солдат до бойового виходу і після нього — це дві різні людини. Ще важливий фактор — команда. Коли ми попали в засідку, то не мали зв’язку з командирами, це був абсолютний хаос. Бій це завжди хаос. Ми пробували відходити правильно, як вчили раніше, але виходило не дуже. Що я для себе усвідомив після перших виходів: злагоджена команда — це найголовніше. Сам по собі ти нічого не вартий в бою, запорука успіху — в командній роботі. Тому вкрай необхідно постійно проводити злагодження, тренування, щоби люди розуміли одне одного не з півслова, а взагалі без слів. Ми зробили дуже багато помилок на тому виході, і на кожному наступному навчанні ми намагаємося їх нівелювати до мінімуму. Це про сотні маленьких деталей: від зв’язку і до порядку в колонах, яка має бути між бійцями взаємодія, яка дистанція, як відстежується ситуація — не злічити всього. До речі, з часу нашого першого виходу багато всього змінилося. Коли ми вдруге нещодавно заїжджали на те саме місце, то чули вже не тишу з української сторони й російську арту, а бачили наші колони техніки за ленд-лізом. Я раніше таку техніку зустрічав лише на картинках в телеграмі. Це дуже великий дисонанс між тим, які були обставини влітку і зараз. Дивишся і думаєш: «О, які штуки катаються, навіть не чули про такі». Крім цього, дуже якісно організована нині медицина. Вони виїжджають на БТРах «на нуль», що десять хвилин, наче маршрутки: швидко туди-назад, все налагоджено максимально ефективно. Спорядження і волонтери Ми намагаємося спростувати один з найбільших міфів, який досі сидить у людей в головах, що їм усе винні, їх мають повністю забезпечити й все видати. Зараз іде повномасштабна війна, на всіх всього не вистачає, бо поки немає відповідних потужностей. Зарплата дозволяє військовим купити самим усе необхідне. Можна чекати, що щось видадуть, але цим ви будете не сильно задоволені, волонтери розбештали екіпіровкою, ми звикли до якісних речей. Ну і нічого якіснішого і комфортнішого, ніж те, що ти вибрав собі сам, не буде. Я прийшов у підрозділ повністю споряджений, купив заздалегідь усе найнеобхідніше. Доки були на навчаннях, докупив дещо. Все вирішувалось і вирішується наразі силами волонтерів і військових. Не знаю, як в інших підрозділах, але у нас забезпечення державою зимовою формою мінімальна. Видали термобілизну і теплі балаклави. Усі печі й генератори — це лише від волонтерів. Завдяки їм ми вже повністю підготовлені до зими. Тимлід і командир Я закінчив військову кафедру, тому маю офіцерське звання лейтенанта. Через це я не можу бути рядовим солдатом, відповідно не можу піти на навчання, наприклад, з управління Javelin. Якщо ти офіцер, то ти повинен управляти групою або підрозділом, жодних джавелінів. Це пережиток радянських часів, і я не дуже задоволений, що не маю змоги вчитися, як солдат, опанувати нову зброю, наприклад. Проте, наскільки мені відомо, зараз це поступово змінюється, і вже є навчальні курси для офіцерів. А поки моє завдання — керувати бійцями. Спочатку це було десять осіб, а зараз я заступник командира роти. Можна сказати, знову тимлід. Це все загалом схоже на команди в бізнесі, просто це люди зі зброєю і вони розв'язують інші питання. А процеси ті самі: інтерв’ю, сканування, кого можна поставити на командира відділення, кого треба прибрати з керівної посади, щоби був кращий клімат в колективі тощо. Найважче — це саме підготовка, коли в тебе є завдання і тобі потрібно усе організувати. Іноді для мене це навіть важче, ніж власне бій. Можливо, ми просто не зіштовхувалися з такими жорстокими боями, як інші, але саме підготовка для нас найважча. Треба усе узгодити, спланувати, розподілити людей, побудувати карти, маршрути, запасні маршрути, запасний зв’язок тощо. Справжній головний біль менеджера. Людей в нас дуже багато і вони дуже різні — і за віком, і за професіями. Наймолодшому — 19 років, найстаршому — 57. Є і будівельники, й IT-фахівці, охоронці, є навіть оперний співак. Важливо, що у нас всі прийшли в Збройні сили добровільно, тобто цілком усвідомлюють, навіщо вони тут. Людей з бойовим досвідом мало — близько п'яти відсотків. За характерами всі дуже різні, як в будь-якій команді. Ми довго уживалися всі разом, але зараз все добре, бо вже пів року пліч-о-пліч. Це, до речі, дуже допомагає тримати емоційну стабільність — коли всі діляться пережитим одне з одним, обговорюють, а не залишаються наодинці зі своїми враженнями й почуттями. Бувають погані дні, бувають кращі – як і в житті. Найкращий день на війні — коли немає втрат.

П’ять років тому команда розробників з компанії JetBrain вирішила, що світові потрібна більш лаконічна та типово-безпечніша мова ніж Java — й створила Kotlin. Мова прижилася, а Android визначив її як рекомендовану мову програмування для розробки застосунків. Тепер програмісти, але уже з Google, думають над тим, щоби переосмислити С++ та пропонують замість неї нову, експериментальну мову програмування Carbon. У липні 2022 року на конференції СPP North C++ в Торонто розробку представив   Чендлер Каррут , який керує напрямом технічних мов програмування в Google. > Навіщо потрібен Carbon > Якою буде нова мова > Де можна протестувати нову мову > А чому не обрати Rust > Як далі розвиватиметься Carbon Раніше у Google уже були подібні проєкти — і успішні, і не дуже. Наприклад, у 2007 році троє розробників компанії спроєктували мову програмування Golang (або просто Go). Нова розробка чудово підійшла для високонавантажених систем, тому вже досить добре проявила себе у бекенді, веброзробці та десктопних застосунках. «Gо — це мова невеликих, але дуже швидких сервісів. Однак, якщо «тягнути» її в enterprise з Agile-проєктами як основну, то може бути халепа зі швидкістю розробки. Зараз Go зайняла нішу атомарних сервісів, в якій раніше була мова С. Втім, попри створення деяких best practice, у ком’юніті не спостерігається якогось сталого фреймворку. Кожна аплікація на Go «особлива», відповідно, кожній команді потрібно робити свій «велосипед» , — говорить Федір Мохонь, Solution Architect. Через чотири роки Google реалізувала мову Dart — її задумували як прогресивну заміну JavaScript, яка на той момент мала проблеми з розширюваністю, продуктивністю та підтримкою роботи складних застосунків. Однак широкого використання ця мова не отримала, і зараз використовується хіба що разом з Flutter. Навіщо потрібен Carbon? На сторінці нової мови на GitHub Керрут пояснює: C++, яку застосовують для критично важливих для продуктивності застосунків, має низку проблем, які заважають сучасним розробникам. Це і десятиліття технічного боргу, і багато застарілих практик, які С++ забрала у своєї попередниці, мови С, і бюрократичний комітет, неповороткість якого значно сповільнювала оновлення та еволюцію мови. Крім того, у С++ немає безпеки пам’яті, яку матиме Carbon. Зараз помилки у доступі до пам’яті є одними з найбільших ризик-факторів у плані безпеки. Розробники Carbon будуть шукати способи кращого відстеження неініціалізованих станів, розробки API та ідіом, які підтримують динамічні перевірки меж, і створювати комплексний режим збірки. Планується, що пізніше дизайнери створять безпечний піднабір для Carbon. Розв'язувати перелічені проблеми за допомогою С++ справді складно, тож після досліджень та оцінки багатьох мов, інженери Google вирішили створити нову. Передбачається, що Carbon позбудеться багатьох недоліків С++, але водночас матиме схожий синтаксис та подібний функціонал. Ось приклади коду, написані на С++ та Carbon: Якою буде нова мова? Carbon побудують на основі сучасних принципів програмування, включно із системою, яка позбавить необхідності переперевіряти код після кожного екземпляру. У ній є компілятор, бібліотеки, інструменти, документи, pavage manager та багато іншого. Компілятор коду написаний з використанням LLVM та напрацювань Clang — компілятора для C, C++, Objective-С й Objective-C+. Відповідно до документації, мова матиме такі характеристики: можливість створювати критично важливе для продуктивності ПЗ; код, який легко читати, писати та підтримувати; здатність взаємодіяти з кодом на С++ та мігрувати з нього; можливість швидкої та масштабованої розробки; підтримка сучасних ОС, апаратних архітектур та середовищ; практична безпека та перевірка механізмів. Команда розробників також збирається створити вбудований package manager, чого дуже бракує C++. Де можна протестувати нову мову? Вихідний код можна завантажити на GitHub. Google прагне зробити Carbon незалежним проєктом, тож всі охочі можуть долучитися до обговорення в Discord . Крім того, потестувати нову мову можна в браузері завдяки інтеграції з Compiler Explorer. Вихідний код проєкту розповсюджують за ліцензією Apache 2.0 . В мережі вже є докладні відеогайди , як встановити собі карбон — з синтаксисом та прикладами. У документації сказано, що мова поки не готова до повноцінного використання. Наразі вона не має конкретної семантики та повноцінної реалізації. Для порівняння, у 2007 році розробники побачили GoLang вже повністю готовим до використання. «Go — це не випадковий успіх, а відповідь на декілька проблем. По-перше, це суттєве ускладнення бізнес-логіки застосунків в останнє десятиліття, що своєю чергою спричинило перехід до мікросервісної архітектури. Моноліт на Java, який компілювався годинами та вимагав гігабайти пам‘яті для роботи просто перестав вирішувати проблеми девелоперів. Для розробки мікросервісів, які швидко обробляють запити й ефективно використовують ресурси системи Go де-факто вже став стандартом. По-друге, на Go, крім вебзастосунків, швидко і зручно писати різноманітний тулінг, написання якого на тому ж C зайняло б набагато більше часу. Щонайменше, через manual memory management» , — говорить Дмитро Гаранжа, Team Lead at Howly . Тож зараз на Carbon можна лише переписати окрему бібліотеку та використати її в наявному проєкті на С++. Однак малоймовірно, що коли розробку мови завершать, її ключові принципи істотно зміняться. А чому не обрати Rust Одразу після презентації Чендлера Каррута в Торонто, в спільноті з'явилися думки про те, що Carbon може грати на полі Rust — ще однієї мови для низькорівневого програмування, яку розробляє Mozilla Research. За структурою мова Rust нагадує «плюси», але істотно відрізняється в деяких деталях реалізації синтаксису й семантики, а також орієнтацією на блокову організацію структури коду. Утім, проєктам, що активно працюють з C++, досить важко перенести проєкт на Rust, адже мова має properties та модулі, яких не має в C++. З одного боку, поки не можна стверджувати, що Rust і Carbon конкуренти. З іншого, якщо Google буде активно промотувати свою мову, і з’являтимуться фахівці, що пишуть нею, Rust може бути посунутий. В чому основні відмінності двох мов? Як далі розвиватиметься Carbon? Відповідно до дорожньої карти, основну версію, яку можна буде використовувати для загальних цілей, планують закінчити до кінця 2022 року. До того часу розробники уже пропрацюють оператори, класи, універсальні шаблони, основні типи інтерфейсів, вказівники, і, власне, відшліфують сумісність з мовою С++. Передбачити, чи замінить Carbon C++ повністю, важко — нова мова поки лише експериментальна. На її впровадження підуть роки, навіть якщо вона «злетить». До того ж достеменно не відомо, який саме рівень С++ Carbon зможе замінити: чи Google C++, чи С++, що містить класи, а від цього буде багато залежати. Однак навіть зараз можна помітити, що потенційний успіх мови лежить у царині використання кодових баз С++, які легко мігрують на Carbon. У спільноті фахівців побутує думка , що запорука потенційного успіху нової мови — можливість компіляції на різних платформах, а для цього Carbon має бути максимально портативним та простим для імпорту й міграції.

Технічне інтервʼю — важливий етап найму. Ми зібрали великий перелік зі 180+ питань на співбесіді QA, які ставлять спеціалістам різних ґрейдів — Trainee, Junior, Middle, Senior. Він містить теорію, практичні завдання, питання про софт-скіли, а також підбірку корисних матеріалів. Звичайно, на жодній співбесіді не ставлять усі ці питання. Але цей список допоможе виявити прогалини в знаннях та вчасно їх заповнити. Богдан Бацмай, Manual QA Engineer в Universe Group та Анна Лущан, QA Engineer OBRIO поділилися з HBJ, як проходить інтервʼю в їхніх компаніях, та що робити, якщо не знаєш правильної відповіді. > Питання для Trainee > Питання для Junior QA > Питання для Middle QA > Питання для Senior QA > Питання для всіх ґрейдів > Практичні завдання > Що почитати та подивитися, готуючись до інтервʼю Питання для Trainee 1. Що таке тестування? 2. Основні цілі тестування? 3. Які типи тестування ви знаєте? 4. Які тестові артефакти ви знаєте? 5. Основні елементи чекліста та баг-репорту та різниця між ними? 6. Що таке тест-кейс? 7. Що таке чекліст? 8. Чим відрізняються чекліст і тест-кейс? 9. Коли їх доречно використовувати? 10. Що таке API? 11. Які ви знаєте API-статус коди? 12. Що таке SDLC? 13. Що таке STLC? 14. Що таке тест-дизайн? 15. Які техніки тест-дизайну ви знаєте? Питання для Junior QA У кандидата на позицію Junior практичний досвід зазвичай мінімальний або взагалі відсутній. Тому питання на співбесіду QA складаються переважно з теорії. «Зазвичай співбесіда QA триває майже 1,5 години та складається в середньому з 20 запитань, переважно теоретичних, але також обов‘язково дають практичні завдання з тестування, організації процесів тощо», — каже Богдан Бацмай, Manual QA Engineer в Universe. «Інтервʼюєр також звертає увагу на те, за який час було опановано ті чи інші знання, з яких джерел та в якому форматі. А також, як кандидат визначає, якій інформації можна довіряти. Може для когось — це дрібниці, але ж мова про тестувальників, тому кожна дрібниця має значення🙂», — пояснює Анна Лущан, QA Engineer OBRIO. ТЕОРІЯ ТЕСТУВАННЯ 16. Поясніть, що таке Quality Assurance та Quality Control? 17. Які знаєте види та рівні тестування? 18. З яких етапів складається процес тестування? 19. Коли слід починати процес тестування? 20. Коли слід закінчувати процес тестування? 21. Що таке критерії входу? 22. Запропонуйте приклад, який пояснює критерії входу тестування ПЗ? 23. Що таке критерії виходу? 24. Запропонуйте приклад, який пояснює критерії виходу тестування ПЗ. 25. Що таке Bug? 26. Що таке Defect? 27. Що таке Error? 28. Як проходить процес верифікації? 29. Наведіть приклади верифікації на різних рівнях тестування? 30. Як проходить процес валідації? 31. Що призводить до багів у ПЗ? 32. Що таке Test Procedure? 33. Що таке програмний компонент? 34. Поясніть, що означає «покриття коду»? 35. Коли можна вважати код завершеним? 36. Що таке емулятор та симулятор? 37. Що таке випробування стабільності? 38. Яка різниця між серйозністю та пріоритетом? 39. Поясніть, що означає «критичність бага»? 40. Які є рівні критичності бага? 41. Що таке тест-кейси? 42. Які найважливіші поля в тест-кейсах? 43. На якій фазі циклу тестування QA Engineer пише тестову документацію, наприклад тест-кейс? 44. Що таке Traceability Matrix? 45. Які існують види баз даних? 46. Які типи звʼязків у БД бувають? 47. Що таке статичний аналіз? 48. Що таке випробування End-to-End? 49. Що таке функціональне тестування? 50. Які існують типи функціонального тестування? 51. Які види функціональних тестів ви знаєте? 52. Наведіть приклади тестів, які включають нефункціональне тестування? 53. Що таке Smoke та Sanity тестування і яка між ними різниця? 54. Що таке тестування Білої, Чорної та Сірої скриньки? 55. Що таке конверсійне (A/B) тестування? 56. Що таке конформаційне тестування? 57. Яка різниця між забезпеченням якості, контролем якості та тестуванням? 58. Розкажіть про тестову документацію: види, цілі. 59. Що робити, якщо немає документації? 60. Що таке план тестування? 61. Що можна включити в план тестування автоматизації? 62. Що таке сценарій використання? 63. Що таке стратегія тестування? 64. Чи є стратегії тестування та плани тестування одним і тим же документом? 65. Які, на вашу думку, переваги ручного тестування? 66. Що таке хороший тест? 67. Наведіть приклад хорошого тест-кейсу? 68. Яка різниця між функціональним і нефункціональним тестуванням? 69. Коли ви знаходите помилку, як переконатися, що помилка буде усунена? 70. Що таке випробування? У чому його сутність як процесу? 71. Поясніть відмінність ретестінга від регресії? 72. Що ви будете робити, якщо у вас обмежений час, але треба пройти регресію? 73. Які бувають кавереджі? 74. Які бувають підходи до тестування? 75. Що таке чекліст і як його оформляти? AQA 76. Автоматизоване тестування — це окремий вид тестування? 77. Який тип/вид клас тестування має сенс автоматизувати? 78. Наведіть кілька інструментів, які можна використовувати для автоматизації тестування. 79. Що таке Selenium? 80. Для чого потрібні TestNG/JUnit? 81. У чому їхня різниця? 82. Які вимоги до тестів існують? 83. Принцип роботи Git? 84. Як автоматичне тестування інтегрується в CI? 85. Які існують види селекторів? WEB 86. Що таке клієнт-серверна архітектура? 87. Чому не відповідає колір кнопки дизайну? 88. Розкажіть про браузерну консоль. 89. Які інтернет-протоколи Вам відомі? 90. Розкажіть, яка між ними різниця? 91. Які вам відомі методи протоколу http, розкажіть коротко про кожен? 92. Чим відрізняється GET від POST методу? 93. Розкажіть про структуру http-запиту та відповіді. 94. Коди стану HTTP — які бувають? 95. Чим відрізняється REST від протоколу SOAP? 96. У чому відмінність XML та JSON? MOBILE 97. Які операційні системи ви знаєте? 98. Які типи мобільних додатків ви знаєте? Опишіть кожен з них. 99. Перелічіть типи тестування, які використовуються в мобільному тестуванні. 100. Що таке тестування установки? 101. Які ви знаєте особливості мобільного тестування? 102. Чи вмієте ви знімати логи з девайсів. Як? Питання для Middle QA Для рівнів Middle та Senior головну роль відіграє практичний досвід кандидата. Інтервʼюєра цікавить, які рішення приймав кандидат, як він діє в стресових ситуаціях, чи відповідальний він, як реагує на фейли. Адже ці позиції містять ще й менеджерські задачі. «Теоретичні питання ставлять кандидатам будь-якого ґрейду, зокрема для того, щоби зрозуміти, чи однією мовою ви говорите та оперуєте однаковими поняттями в роботі. От, уявіть, що ви отримуєте таску, здавалося б, на звичайнісіньку регресію. Але хтось зробить smoke, а хтось — sanity, а все через різні визначення», — ділиться Анна Лущан, QA Engineer OBRIO ТЕОРІЯ ТЕСТУВАННЯ 103. Що означає код помилки 403, 502? 104. У яких сніферах ви працювали? У чому їхня відмінність за фічами? 105. Які багтрекінгові системи ви використовували? 106. Яким чином проходили естимації на проєкті. Які види естимації проєкту ви знаєте? 107. Які важливі характеристики для лідерів у QA? 108. Що, на вашу думку, є найважливішим тестовим показником і чому? 109. Що найважливіше в тест-пленінг фазі? 110. Які є найважливіші секції в тест-плані? 111. У чому відмінність симулятора та емулятора? DEVELOPMENT 112. Три принципи ООП? 113. Чи знаєте ви методи .hashcode() та .equals(), їх реалізацію? 114. Як виглядає реалізація HashMap? 115. У чому різниця інтерфейсу та абстрактного класу? 116. Методи класу Object у java? 117. Перерахуйте паттерни, з якими працювали. 118. Які знаєте внутрішні класи? WEB 119. Що таке реляційні бази даних? Через що вони мають звʼязок? 120. Що таке дістінкт, і де він пишеться? 121. Які основні поля дефект чи баг-репорту? 122. Що таке лог-файл? 123. Розкажіть про життєвий цикл дефекту? Які є статуси дефекту? 124. Що ви будете робити, якщо розробник поставив статус у дефекті «can not reproduce»? 125. Опишіть досвід роботи з базами даних? 126. Для чого використовують системи контролю версій? 127. Що таке Git? Який принцип його роботи? 128. Назвіть основні команди Git та прокоментуйте кожну з них? SCRUM 129. Що таке Agile-методології? 130. У чому відмінність Scrum від Kanban? 131. Поясніть термін «життєвий цикл програмного забезпечення»? 132. Поясніть перевагу використання моделі життєвого циклу розробки програмного забезпечення? 133. Які основні фази моделі життєвого циклу розробки? 134. Методологія розробки ПЗ? 135. Agile та Waterfall методологія — переваги та недоліки? 136. Які є ролі в Scrum, що вони роблять? 137. Які бувають зустрічі в Scrum? 138. Що таке юзер-сторі? 139. Як будується юзер-сторі, який є темплейт? 140. Що таке критерії прийняття? 141. Якщо ви не встигаєте написати тест-кейси до кінця спринту, що ви будете робити? Питання для Senior QA Теоретичні питання для кандидата рівня Senior зазвичай сформульовані таким чином, щоби дізнатися, як саме людина може застосувати ці знання в роботі, як скомбінувати чи доповнити та на який результат розраховувати. 142. Опишіть процес тестування на попередньому проєкті і твою роль у ньому? 143. Яку тестову документацію вели — тест-план, тест-стратегія? 144. З якими процесами CI/CD знайомі? Які інструменти використовували, у яких завданнях? 145. Як розподілялася робота? В естимації брали участь тільки розробники чи тестувальники також? 146. Чи проводили ви оцінку трудовитрат? Які методики використовували? 147. Тестування бекенду: API — інструменти та методи, їхні відмінності та особливості? 148. Опишіть кейси зі складною бізнес-логікою, з якими працювали? 149. Опишіть свій досвід роботи з базами даними (SQL, джойни, підзапити, агрегатні функції, юніан) 150. Які модели інтеграційного тестування знаєте? 151. Які види кешу та кукі знаєте? Як відстежити час кукі, як це змінити? 152. Чи працювали ви з вебсокетами, синхронними вебзапитами? 153. Які типи аутентифікації знаєте? Поясніть, як вони працюють? 154. Що таке тестові двійники? 155. Які види тестових двійників існують? Яка між ними різниця (наприклад, між mock та stub)? «Якщо не знаєш відповіді на питання, то краще в цьому зізнатися, ніж давати занадто загальну відповідь, тобто «лити води». У такому разі інтервʼюєр може підштовхнути, підказати, в якому напрямі варто подумати, щоби дати відповідь на це питання. Якщо людина не відповіла на питання, що стосується додаткових скілів, але дала правильні відповіді на ключові питання, у неї є шанси успішно пройти інтерв’ю», — каже Богдан Бацмай, Manual QA Engineer в Universe Питання для всіх ґрейдів 156. Які функції та обов’язки були на вас покладені у вашому останньому проєкті? 157. Як ви розставляєте пріоритети, коли у вас багато завдань? 158. Розкажіть про свій найскладніший проєкт? 159. Розкажіть про своє найбільше досягнення в минулих проєктах? 160. Розкажіть про факап-ситуацію, які висновки з неї зробили? 161. Які цілі ви ставите перед собою у своїй кар’єрі? 162. Чому ви вирішили стати QA Engineer? 163. Звідки черпаєте нові знання? Які книги, статті, курси, нові інструменти ви пройшли, вивчили за останній рік? 164. Хто відповідає за якість на проєкті? Яка зона відповідальності QA? 165. Що би ви зробили, якщо ви заводите баг, а розробник заперечує, що це він? Що би ви робили, коли на цей баг (функціонал) є документація/вимоги та коли їх немає? 166. На ревʼю вашого коду колеги залишили коментарі, які потребують змін, але ви з цими змінами не погоджуєтесь? Як би вирішували цю ситуацію? 167. Які зміни та ініціативи ви пропонували на попередньому проєкті? Чи прислухалися до вас? Якщо не прислухалися, що ви робили? 168. Моделювання стресової ситуації: сьогодні реліз, у процесі регресії знайдені баги. Які ваші дії? З ким би комунікували? Який вихід би спробували знайти? 169. Наведіть приклад найбільш критичної помилки, якої ви припустилися? Якими були наслідки? Хто, на вашу думку, був винен? Які висновки ви зробили? 170. Уявимо ситуацію: твій колега QA раптово захворів, і ти залишився сам на проєкті на якому завтра реліз, половина тасок — ще не протестовані. Ваші дії? 171. Моделювання ситуації, коли падає тест. Інтервʼюєр надає вхідні дані: тип функціонала, як виглядає помилка (наприклад, форма авторизації користувача). Питання: Чи заводили би баг-репорт? На кого поставили би таску (бекенд чи фронтенд) та чому? Виходячи з відповідей кандидата інтервʼюєр може доповнити тему новини питаннями, щоби перевірити розуміння алгоритмів дій у різних ситуаціях. Практичні завдання 172. Написати чекліст тестування форми введення даних платіжної картки. 173. Як би ви протестували функціонал Х? Які основні тести виконали би, як виглядав би ваш чекліст? 174. Є сторінка логіну з полями: e-mail, password та кнопкою submit. Наведіть якомога більше позитивних та негативних тест-кейсів, якими можна перевірити дану сторінку. 175. Вам необхідно протестувати новий продукт, але немає технічної документації до нього, яким чином будете проводити тестування? Які типи тестування будете використовувати? Яким чином будете пріоритезувати свою роботу? 176. Користувач заходить на сайт конвертування файлів, вибирає файл для конвертування та після завантаження файлу бачить повідомлення: «Failed to send». Це баг? 177. Протестувати «предмет». Які види тестування ви використаєте? Наведіть декілька позитивних та негативних тест-кейсів. 178. Наведіть якомога більше негативних кейсів тестування оплати. 179. SQL: Є таблиця employees з полями: last name, age, gender. Потрібно вибрати всіх співробітників чоловічої статі віком від 20 до 40 років та відсортувати вибірку за спаданням по полю last name. 180. Необхідно відправити фідбек-запит на сервер. Який метод необхідно використати? Яким чином передаватимете дані на сервер? 181. Ми реєструємо нового користувача в додатку, в тілі запиту містяться наступні дані: ім’я користувача, пошта, номер телефону та перелік хобі. Які кейси для перевірки можете навести? Що почитати та подивитися, готуючись до інтервʼю Lessons Learned in Software Testing: A Context-Driven Approach by Cem Kaner, James Bach, Bret Pettichord; Critical Testing Processes: Plan, Prepare, Perform, Perfect by Rex Black; Rapid Testing by Robert Culbertson, Chris Brown, Gary Cobb; A Practitioner’s Guide to Software Test Design by Lee Copeland; How We Test Software at Microsoft by Alan Page, Ken Johnston, Bj Rollison; The Art of Software Testing by Glenford J. Myers, Corey Sandler, Tom Badgett; How Google Tests Software by James A. Whittaker, Jason Arbon, Jeff Carollo Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design by James A. Whittaker How to Break Web Software: Functional and Security Testing of Web Applications and Web Services by Mike Andrews, James A. Whittaker; The Software Test Engineer’s Handbook by Graham Bath, Judy McKay; xUnit Test Patterns by Gerard Meszaros; Popeliuha | Безкоштовний курс з Тестування ПЗ; 7 Steps Guide on How to Prepare for an Interview; How To Prepare For Your First Interview.

У жовтні шукаємо спеціалістів, здатних із хаосу побудувати систему, вирішити будь-який конфлікт та організувати освітні івенти, які будуть сприяти підвищенню рівня спеціалістів та обізнаності про роботу з ІТ-продуктом. Мова про фахівців із рекрутингу та HR. Гортайте підбірку, дізнавайтеся більше про команди і приймайте нові виклики! Recruitment Marketing Specialist (вакансія закрита) Новий фахівець посилить івент-напрям компанії задля найму найкращих кандидатів. Робота передбачає створення та проведення кар’єрних заходів, підготовку рекламних матеріалів, активну роботу з партнерами для підвищення впізнаваності бренду. Для цього ідеально мати від року досвіду у рекрутингу, менеджменті проєктів чи брендингу, навички копірайтингу та ведення переговорів, а також вміти працювати з аналітикою. Student Partnership Manager (вакансія закрита) Також шукають людину, яка буде займатися партнерствами зі студентськими та молодіжними організаціями, щоби залучати кандидатів до бізнесів Genesis. Це включає і презентації компанії на фестивалях, ярмарках вакансій та форумах, і проведення лекцій, семінарів та тренінгів, і розвиток відносин із профільними організаціями та ком’юніті. Найкраще з роботою впорається людина, яка вже рік працює у диджитал-маркетингу, брендингу чи організації івентів, вміє спілкуватися з людьми та вести переговори, й водночас не боїться роботи з аналітикою. People Partner (вакансія закрита) Holy Water — це компанія-паблішер мобільних ігор. Аби виводити процеси на новий рівень, команда шукає People Partner. Це вакансія для мідл-фахівця з трьома роками досвіду, що будував внутрішні HR-процеси, розробляв HR-інструменти в міжорганізаційних та міжфункціональних командах. У Holy Water обов’язки будуть схожими: вивчати та контролювати внутрішні HR-процеси, пропрацьовувати план змін у команді відповідно до запитів керівника та допомагати співробітникам вирішувати професійні проблеми. People Partner (вакансія закрита) У портфоліо Keiki — п’ять застосунків та освітні вебпродукти для малюків від двох до шести років. Ідеальний кандидат має мінімум три роки релевантного досвіду, у тому числі міжорганізаційної та міжфункціональної командної роботи, вміє будувати та впроваджувати HR-процеси. У перші півроку він сфокусується на аудиті процесів та запитів керівника, аби сформувати «дорожню карту» пропозицій та змін. Загалом, потрібно займатися повним циклом управління талантами, допомагати пропрацьовувати корпоративну культуру, а за потреби — скласти для працівників персональний план розвитку та допомогти їм вирішити професійні проблеми. People Partner (вакансія закрита) Фахівець приєднається до команди OBRIO , чиїм флагманським продуктом є астрологічний застосунок Nebula. Що потрібно робити? Брати участь в управлінні талантами, моніторити задоволеність та залученість співробітників, ставити цілі та організовувати освітні заходи відповідно до запиту керівників. Серед вимог — 2-3 роки у HR, з яких мінімум рік в ІТ, досвід у HR-підтримці команд із чисельністю понад сто людей, розуміння, як проводити якісні one-to-one та англійська рівня strong intermediate. Перевагою буде психологічна освіта та знання коучингових підходів. HR Business Partner (вакансія закрита) Компанія Boosters створює мобільні застосунки для покращення якості життя мільйонів людей. До команди потрібен спеціаліст, який сформує ефективну HR-стратегію, зокрема, продумає вдалу структуру команди, план розвитку працівників та топменеджменту й шляхи утримання співробітників, а також запустить роботу з HR-брендом. У майбутньому HR BP збиратиме власну команду, тож найкраще з обов’язками впорається фахівець рівня сеньйор з мінімум чотирма роками досвіду, вмінням формувати HR-стратегії та англійською рівня Advanced. Вакансія партнера: Talent Acquisition Specialist (вакансія закрита) Стартап Codefinity розробляє освітню платформу для навчання програмуванню. Новий фахівець приєднається, аби залучити сильних гравців, які виведуть продукт на перше місце в категорії «Освіта». Серед завдань — не лише робота з різними платформами для пошуку кандидатів, а й удосконалення процесу відбору: дослідження зарплат, аналіз кращих практик, автоматизація взаємодії з пошукачами. Знадобиться принаймні рік у рекрутингу в продуктових, ігрових або аутсорсингових компаніях, досвід в управлінні повним циклом найму та робочі знання англійської мови.

У React зазвичай використовують context’ для інкапсуляції бізнес-логіки. При цьому оновлення будь-якої властивості в одному з контекстів спричиняє оновлення всього дерева компонентів. Від цього страждає продуктивність застосунків. А якщо застосунок із великою кількістю складових, одна з важливих задач — налагодити впровадження нових функцій, витрачаючи мінімум зусиль і часу. Завдання можна вирішити за допомогою архітектури, що робить систему гнучкою при будь-яких масштабах застосунків. Такий варіант запропонував Антон Пінкевич, Front-end Team Lead в Universe, продуктовій компанії з екосистеми Genesis. У матеріалі на DOU він розповів про новий архітектурний патерн, що він розробив та запровадив на edtech-платформі Universe. Публікуємо стислий переказ найважливішого зі статті. Материал буде корисним усім, хто пише на React та хоче покращити свої продукти. > Модуль (Module) > Сервіси (Services) > Сховища (Stores) > Адаптери/Шлюзи (Adapters/Gateways) > Впровадження залежностей (Dependency Injection) > Use cases > Моделі (Models) > Утиліти (Utils) > Обробка помилок/винятків (Exceptions handling) Створений фахівцями з Universe архітектурний патерн зручно використовувати із будь-яким фреймворком для React: create-react-app, Next.js та іншими. Чим він корисний? По-перше, він дає змогу розгорнути залежності застосунку, при цьому бізнес-логіка відповідатиме за презентацію, а не навпаки. По-друге, він розділяє застосунок на незалежні модулі — таким чином більшість написаного коду може використовуватись повторно шляхом змішування модулів. Кожен модуль поділений на уніковані компоненти, тому є можливість писати тести лише для бізнес-логіки. Основна перевага модульності в тому, що вона дає можливість почати з малого і додавати нові складові поступово. З чого складається архітектура? Модуль (Module) Модуль — це основний блок, на якому будується система. Це незалежна одиниця, що містить певну інкапсульовану поведінку, але і може існувати без візуальної презентації. Це дозволяє нам розгорнути стандартні залежності застосунку та зробити так, щоби View не керував усім застосунком, а переорієнтовувався в залежності від необхідної поведінки. За замовчуванням, логіка знаходиться біля кожного модуля. Не всі модулі містять візуальну презентацію. Anonymous та Authenticated виконують логіку, але не відображаються в інтерфейсі. Тому застосунок залежить не від візуального шару, а від логічного. Базовий модуль складається з двох файлів: Index, Interactor. Якщо потрібна візуалізація — додаємо Router. У випадку, якщо візуалізація складна, додаємо один або декілька View. Стрілками позначені залежності між компонентами модулю. Interactor містить бізнес-логіку. Бажано, щоби він був ізольований від зовнішнього простору та отримував необхідні залежності через пропси. type Payload = { authenticationService : IAuthenticationService authenticationStore : IAuthenticationStore router : IRouter } interface IUserSignupByEmailInteractor { redirectToSignin : () => void passwordRecoveryUrl : string children : { signupByEmail : boolean signupByGoogle : boolean } } const useSignupPageInteractor = ({ authenticationService, router, authenticationStore }: Payload ): IUserSignupPageInteractor => { // logic implementation here return { redirectToSignin : () => router. redirect ( '/signin' ), passwordRecoveryUrl : '/password-recovery' , children : { signupByEmail : true , signupByGoogle : canUserSignupByGoogle, } } } Таким чином у нас є необхідне сховище та сервіс із пропсів. Спочатку позначаємо, які дочірні модулі може рендерити даний, а потім виконуємо перевірки та повертаємо бульові значення для кожного з дочірніх модулів. Рендер React-компонентів буде відбуватися в роутері. Router – це файл, який пов'язує бізнес-логіку та візуалізацію. Він отримує всі необхідні залежності через пропси та містить лише логіку перевірок if else, аби визначити чи потрібно рендерити той чи інший модуль. interface IProps { signupByEmail : React .ReactNode signupByGoogle : React .ReactNode interactor : IUserSignupByEmailInteractor } const SignupPageRouter : React .FC = ({ signupByEmail, signupByGoogle, interactor }) => ( <> {interactor.children.signupByEmail && signupByEmail} {interactor.children.signupByGoogle && signupByGoogle} </> ) View — файл, задача якого полягає в тому, щоби групувати різні dumb components. interface IProps { link : string } const ForgotPassword : React .FC = ({ link }) => ( А Index буде збирати необхідні залежності для Interactor і Router. У ньому ми викликаємо усі useContext, завантажуємо необхідні сервіси та сховища. const SignupByEmail = () => { con†st { authenticationService } = useServices () const { router } = useUtils () const { authenticationStore } = useStores () const interactor = useSignupByEmail ({ authenticationService, router, authenticationStore }) return ( } signupByGoogle={} interactor={interactor} /> ) } Index и Interactor — базові файли для побудови модуля. Інші – за необхідністю. Доки нам не потрібно розширювати систему, можна зберігати стан всередині модулів через useState. Для загальних даних можна створити базовий createContext. Сервіси (Services) Сервіс — це простий механізм формату «запит-відповідь». В окремі сервіси ми виносимо логіку отримання даних із зовнішніх джерел, якщо нам треба використовувати її в різних модулях. Сервіс може зберігати внутрішній стан, але лише той, який йому потрібен для виконання запитів. Які сервіси існують? Authentication — перевіряє вхідні дані користувача, дозволяє зареєструватися тощо. Analytics — збирає та надсилає аналітику. Payment — обробляє платежі. Застосунок з підключеними сервісами виглядає так: Сховища (Stores) В поданій архітектурі кожен модуль може зберігати дані всередині, але якщо треба отримати загальний стан, то ці дані краще виносити в сховища. Наприклад: Authentication — зберігає дані аутентифікації: token, refreshToken тощо. User — зберігає дані про користувача: ім’я, email та інші. Такий вигляд має застосунок зі сховищами: Адаптери/Шлюзи (Adapters/Gateways) Коли система розширюється, сервіси та сховища можуть використовувати адаптери. Наприклад, analytics service може використовувати лише Google Analytics для відправлення даних, проте пізніше можуть додатися Facebook Pixel, Amplitude, Mixpanel тощо. Не треба щоразу писати новий сервіс, достатньо лише передати необхідний адаптер у вже написаний. Так у сервісі з’являється нова залежність. Інтерфейс цього адаптера описується в сервісі, а реалізується вже зовнішніми адаптерами. Наприклад: export interface IAnalyticsAdapter { sendEvent : (eventName: string , eventData: unknown) => Promise } export class AnalyticsService { private adapter : IAnalyticsAdapter constructor (adapter: IAnalyticsAdapter) { this .adapter = adapter } // ... implementation } Далі робимо необхідні адаптери: class AnalyticsAdapter implements IAnalyticsAdapter { private adapters : IAnalyticsAdapter[] = [] constructor (adapters: IAnalyticsAdapter[]) { this .adapters = adapters } sendEvent : IAnalyticsAdapter[ 'sendEvent' ] = (eventName, eventData) => { this .adapters. forEach ((adapter) => adapter. sendEvent (eventName, eventData)) } } class GoogleAnalyticsAdapter implements IAnalyticsAdapter { sendEvent : IAnalyticsAdapter[ 'sendEvent' ] = (eventName, eventData) => { // google analytics implementation } } class FacebookPixelAdapter implements IAnalyticsAdapter { sendEvent : IAnalyticsAdapter[ 'sendEvent' ] = (eventName, eventData) => { // facebook pixel implementation } } export const analyticsAdapter = new AnalyticsAdapter ([ new GoogleAnalyticsAdapter (), new FacebookPixelAdapter (), ]) Та застосовуємо у сервісі: constanalyticsService = new AnalyticsService (analyticsAdapter) Наступним чином виглядають адаптери в застосунку: Впровадження залежностей (Dependency Injection) Аби пов'язати сервіси та сховища з модулями, використовуємо контексти React. interface IServices { authenticationService : IAuthenticationService analyticsService : IAnalyticsService } const ServicesContext = createContext ( null ) export const useServices = (): IServices => useContext(ServicesContext ) export const ServicesProvider : React .FC = ({ children }) => { // initialize services return ( {children} ) } В цій архітектурі сервіси та сховища – це класи, які не оновлюються при зміні стану. В такому випадку ми уникаємо будь-яких зайвих оновлень. Застосунок із впровадженням залежностей: Use cases Коли кількість модулів зростає, починає з'являтися загальна логіка. Її можна виносити в Use cases. Вони можуть використовувати і сервіси, і сховища через контексти. Також вони за замовчуванням не можуть використовуватися поза модулями, тому сервіси та сховища будуть завжди доступні. Вигляд застосунку із use cases: Моделі (Models) Якщо ми маємо об’єкти із зовнішніх джерел, які потрібно використовувати в декількох модулях, їх можна виділити в окрему сутність «Модель». Це дасть нам змогу валідувати дані, застосовувати до них загальну логіку та зберігати їх в одному місці. Застосунок із моделями: Утиліти (Utils) Це всі файли, які допомагають в розробці, та яким не потрібно мати доступ до зовнішніх джерел. Їх можна використовувати як в сервісах, так і в модулях. До прикладу, утиліти це: Token parsers. Date formatters. Device type detection. Обробка помилок/винятків (Exceptions handling) Всі помилки мають оброблятися винятково в модулях, тому що логіка обробки має знаходитись лише в одному місці. Для типування використовуємо тип Result, який повертається під час виклику методів у сервісах. export type Result = R | E Наприклад: class MyError1 extends Error {} class MyError2 extends Error {} // example-service.ts class ExampleService { example = (): Result < string , MyError1 | MyError2 > => { // implementation } } // example-module/interactor.ts const useExampleInteractor : React .FC = ({ exampleService }) => { useEffect (() => { exampleService. example () . then ((result) => { // typeof result = string | MyError1 | MyError 2 if (result instanceof MyError1 ) {} // typeof result = string | MyError2 if (result instanceof MyError2 ) {} // typeof result = string // do whatever you want with the pure result type }) }, []) return {} } Модулі — проміжна ланка між отриманням даних та їх зберіганням. В свою чергу use cases та утиліти використовують для спрощення цієї взаємодії. Розділення за зонами дає змогу зробити так, щоби кожна зона системи була відповідальна лише за одну задачу. Такий підхід до розробки дозволяє гнучко розширювати проєкт, залишаючи логіку інкапсульованою та зрозумілою.

Компанія SUITSME, що входить до екосистеми бізнесів Genesis, розвиває інтерактивну платформу для всіх, кого цікавить мода. У застосунку SUITSME кожен може поекспериментувати з одягом та аксесуарами від відомих брендів і стилізувати свого аватара для участі в різноманітних івентах. Усе це побудоване на основі 2D-графіки. Віталій Янчук, Unity-розробник і Tech Artist у SUITSME, в матеріалі для DOU розібрав базові методи розробки візуальних ефектів, теорію шейдерів, а також низку маніпуляцій із текстурами й кольором. Стаття буде корисною для VFX-художників-початківців, розробників усіх рівнів та інших спеціалістів, які цікавляться комп’ютерною графікою. Публікуємо стислий переказ матеріалу. З чого почати. Графічний конвеєр Маємо задачу — вдосконалити візуальний стиль продукту і створити кілька ефектів для тканин, які додали б шарму статичним речам. Так виглядає базовий ефект для тканини: А так — той самий ефект у готових образах: Спочатку всі дані й текстури проходять певний шлях перед тим, як опинитися в готовому вигляді на екрані: спочатку на процесорі комп’ютера (CPU), а потім на графічному процесорі (GPU). Ці етапи називають графічним конвеєром, або ж Graphics Pipeline. Спочатку геометрія, текстури й колір у загальному вигляді обробляються на рівні застосунку в CPU, за інструкціями, написаними C++ чи будь-якою іншою мовою. А далі — потрапляють до графічного процесора. Там спочатку обробляються вершини усіх геометричних фігур, а потім ця геометрія растеризується, тобто попіксельно зафарбовується. Растеризація та обробка геометрії відбуваються за шейдерним кодом, який зазвичай написаний на HLSL або Cg. GPU не дає змоги ефективно проводити складні логічні операції, проте здатний робити масивні паралельні розрахунки. Нижче розглянемо детальніше фрагментний шейдер. Саме на цій стадії прорахована вся геометрія, і маніпуляція з графікою відбувається лише на рівні текстур і кольорів. Текстурні координати. Створюємо форми та розташування Кожен піксель на текстурі має свої координати в UV-просторі (аналогічно до XY-координат) від 0 до 1 з кожної з координат в UnityEngine, починаючи з нижнього лівого кута. Додавання векторної константи до UV відповідає за зміщення текстури. Якщо додати до U-координати UV-простору величину, що дорівнює 0.5, текстура зміститься на половину своєї довжини вправо. Прив’язавши це до таймера, отримуємо латеральний рух текстури. Множення UV відповідає за масштабування текстури. Якщо помножити V на 2, текстура звузиться вдвічі по вертикалі й у той самий квадрат вміститься вже дві такі текстури. Додавання відповідає за зсув текстури, а множення — за деформацію. Розглянемо процес на прикладі ефекту, що імітує рефракцію від гарячого повітря. Він складається з двох шарів: зсув текстури шуму (додаємо векторну константу до UV-координат текстури шуму за таймером, у нас це вектор U=1 V=0 (1, 0), помножений на час одного кадру. Це означає, що текстура зміститься вправо на один період за одну секунду ігрового часу); додавання отриманого результату до UV-координат іншої текстури. Це має такий вигляд: Використана текстура не зовсім проста. Це процедурно згенерований градієнтний шум , тому при анімації чи зміщенні він не повторює себе й водночас не має швів. Якщо ж текстуру шуму розтягнути й дещо зменшити інтенсивність, отримаємо більш м’який ефект, що схожий на розвіювання тканини. Для розтягнення застосовуємо множення UV-координат. Ефект для тканини майже готовий, але треба подбати про деталі. Тканина — складний матеріал, і при утворенні на ній хвиль змінюється її освітленість. Кольорові координати Фрагментні шейдери також допомагають контролювати колір кожного пікселю, що видно на екрані. Майже кожен монітор комп’ютера показує колір у RGB-форматі — як комбінацію червоного, зеленого та синього різної яскравості. Тому й на графічному процесорі кожен піксель описується комбінацією трьох кольорів з яскравістю від 0 до 1. Базово додавання цих кольорів один до одного працює таким чином: В графіці використовуються різні режими змішування шарів, або ж Blend modes . Їх багато, проте всі вони містять хоча б одну з чотирьох базових операцій: додавання кольорів (режим змішування Add або Linear Dodge ) ARGB+BRGB — корисне для засвітлення без змін контрасту; віднімання кольорів (режим змішування Subtract ) ARGB-BRGB — корисне для затемнення з контрастом; множення кольорів (режим змішування Multiply ) ARGB*BRGB — корисне для затемнення без змін контрасту та маскування зображень; ділення кольорів (режим змішування Divide ) ARGB/BRGB — корисне для засвітлення з контрастом. Кілька прикладів однієї й тієї ж маски в різних режимах: Якщо комбінувати ці режими змішування, а також змінювати текстуру маски для кожного кольорового каналу, можна задати окреме значення яскравості та контрастності. Ми використали звичайний градієнт. Маскування також готують для альфа-каналу, змінюючи прозорість певних частин текстури, а не лише колір. Такі маски можна робити процедурними, анімувати й використовувати їх для чого завгодно. Ось що відбудеться, якщо застосувати анімовану маску до текстури із зірочками в режимі Multiply : Маска є текстурою, тому її також можна анімувати, деформувати й накладати на неї додаткові шари масок. Якщо маніпулювати лише кольором і застосовувати маски для кольорів, зображення набуває магічного вигляду: Повернемося до нашого ефекту розвіювання тканини: засвітимо ділянки на вершині хвилі; затемнимо ділянки внизу хвилі. Це допоможе спрощено передати світло і тінь. Для більш коректного зображення варто змінювати освітленість не від висоти хвилі, а від кута нахилу поверхні хвилі. А якщо мова про кут нахилу, то це — математична похідна. Тож якщо ми продиференціюємо текстуру за координатою U (ddx), то отримаємо більш фізично коректну картину зміни освітленості поверхні. Згори — маска для засвітлення, знизу — маска для затемнення. Потрібно намагатись робити ефект так, щоб він не виходив з контексту, відповідав стилю і був доцільним. Отже, зміна текстурних координат дає змогу досягати різноманітних процедурних форм або деформацій текстури, а зміна кольорових координат — індивідуально визначати інтенсивність кожної кольорової складової текстури. Якщо це поєднати, отримаємо повну владу над формою і кольором. Кожен шейдерний ефект у 2D можна розглянути як текстуру, що є результатом поєднання інших текстур за певною логікою. Тому можна нескінченно накладати ці текстури одна на одну, створюючи ще більше унікальних поєднань.

Свій 31-й День Незалежності ми зустрічаємо у суворі часи, проте ми віримо у краще майбутнє, працюємо для своєї країни та не здаємося. Генезійці та колеги із партнерських компаній — від операційного директора до трейні — розповіли про своє відчуття незалежності та бачення майбутнього нашої країни. Genesis вітає всіх зі святом! Артем Копанєв, СОО Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Україна — це країна сміливих людей та небачених можливостей, в якій свобода усіх рівнів — це вибір кожного. Це країна підприємців, які ставлять амбітні цілі, досягають їх та вражають світ своєю стійкістю. Що для вас означає незалежність? Незалежність для мене — це свобода обирати. Обирати шлях розвитку своєї країни, спільноти та себе особисто. Зі свободою приходить і відповідальність, тож це водночас і привілей, і обов’язок. З відповідальності кожного з нас, вчинків (а разом з тим і бездіяльності подекуди) і складається той історичний шлях, яким ми крокуємо. Тож кожен вчинок, кожне слово має значення, важливо про це пам’ятати. Особливо зараз, коли ми виборюємо нашу свободу. Помріємо. Україна у 2032 році. Яка вона? Я особисто вірю в незалежну та сильну Україну — і в 2022, і в 2032, і багато років наперед. Це буде одна з найуспішніших країн світу з високими економічними темпами зростання та громадянським суспільством. Таким, яке зі свого досвіду знає ціну свободи і як її виборювати. Нашими локомотивами та драйверами розвитку, найімовірніше, будуть IT, агросектор і, сподіваюсь, туризм та послуги. Ми обов’язково станемо провідним хабом Східної Європи для комфортного ведення бізнесу. Андрій Боднар, iOS Developer в OBRIO Як би ви описали Україну іноземцю, який ніколи про неї не чув? Україна — це люди. Вони не «розкидаються» усмішками, але радо дарують їх тим, кому готові довіряти. Це люди, що з будь-якої події можуть зробити мем, мерч або марку. Люди, що подарували світу гелікоптер, жорсткий диск та борщ. Що для вас означає незалежність? Як на мене це слово, яке описує само себе. Неможливо підібрати такі слова, що опишуть незалежність краще, ніж вона сама це зробить. Помріємо. Україна у 2032 році. Яка вона? Україна у 2032 році — це не про мрії. Вона буде саме такою, якою ми її зробимо власними руками. Ми можемо надихатись результатами інших країн, частково переймати їх досвід. Але справжній результат залежить від тих самих людей, які і є Україна. Віра Бігановська, Junior Graphic Brand Designer в Universe Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це країна, де живуть люди, для яких немає безвихідних ситуацій. Вони неймовірно працьовиті та кмітливі, зараз серед цих якостей так ясно проявилася ще й волелюбність, яку ні з чим не сплутаєш. Вони вміють зупиняти танки голими голими руками та збивати ворожі дрони банками із томатами. Що для вас означає незалежність? Незалежність — це можливість створювати свої правила на своїй землі разом з людьми, яких об’єднує спільна культура та національна ідентичність. Але в той же час, незалежність — це велика відповідальність, Аби її зберегти, потрібно прикласти чимало зусиль. Помріємо. Україна у 2032 році. Яка вона? Якщо уявити ідеальний світ, то в 2023 році мені б хотілося насамперед бачити Україну повністю звільненою від окупантів та відбудованою. А її громадян — більш свідомими, тобто такими, які винесли всі уроки з цієї війни та зробили правильні висновки. Соломія Яськів, PR-менеджерка PlantIn Як би ви описали Україну іноземцю, який ніколи про неї не чув? Абсолютно вільна, стильна і прогресивна країна. Держава, яка історично мусила відстоювати своє право на незалежність і внаслідок цього стала революційною моделлю для інших країн. А ще — в Україні просто неймовірно мальовнича природа і класні урбаністичні рішення. Що для вас означає незалежність? Це вміння приймати рішення самостійно і нести відповідальність за наслідки цих рішень. Вміння слухати та дослухатися, якщо це відповідає особистим переконанням. Незалежність — це демонстрація того, на що ми здатні. Помріємо. Україна у 2032 році. Яка вона? Самостійна в усіх планах. ІТ-колиска Східної Європи, мистецький центр і туристичний вибір континенту. Країна, де більшість бюрократичних рішень — диджиталізовані, вітчизняні бренди — за доступними цінами, корупція відсутня як явище і лишилась тільки и в розповідях старших поколінь. Денис Попов, Manual QA Engineer в AMO Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це країна, в якій живуть вільні та сміливі люди. В Україні захоплююча природа, найсмачніша їжа, найкращий сервіс і цифрові державні послуги. Але найголовніше — це сильні, відкриті, добрі, талановиті і різні, водночас єдині люди. Що для вас означає незалежність? Для мене незалежність означає мати можливість мені і державі робити свій вибір — із ким дружити, які цінності сповідувати та як жити. Але також це велика відповідальність: кожен із нас повинен поважати один одного, робити усе можливе для захисту і розвитку нашої держави і зберегти усе, що ми здобули, для майбутніх поколінь. Помріємо. Україна у 2032 році. Яка вона? Сильна і квітуча країна, котру всі поважають. Економічний і культурний центр Європи. Ми маємо свою silicon valley, де народились як мінімум із десяток українських «єдинорогів», до України кожен рік приїжджають мільйони туристів, проводяться найкращі фестивалі світу, а українці — назавжди щаслива нація. Анастасія Микитенко, SMM-фахівчиня в Head Office Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це країна вільних, сміливих, запальних, талановитих та безмежно різних людей. Вони не ідеальні, у них багато роботи над собою та країною, але в них багато віри і бажання жити краще, тому вони відбудуються і створять щось неймовірне. Уже створюють. Що для вас означає незалежність? Незалежність – це можливість та обов’язок будувати, згадувати та зберігати своє. І не можна очікувати, що усе зробить влада. Кожен має самостійно докладати зусиль, бути включеним, кричати, коли щось йде неправильно. Країна без своїх свідомих людей навряд чи залишиться незалежною надовго. Помріємо. Україна у 2032 році. Яка вона? Вона вільна від російських впливів, у ній пам’ятають та поважають свою культуру. Вона приймає людей різними і створює для них рівні можливості. Ми без корупції, з якісною освітою, гідно оплачуваною медициною та бізнесами, які впевнено почуваються. Олексій Єрмоленко, Strategy and Investments Associate у венчурному фонді Flyer One Ventures Як би ви описали Україну іноземцю, який ніколи про неї не чув? Це досить колоритна країна зі своєю автентичною культурою та дуже доброзичливими та привітними людьми. Проте ці люди пройшли через низку випробувань, тому вони досить сильні та самодостатні, вони не втрачають оптимізму. А ще це дуже різна, велика та родюча країна, в якій є і степи, і гори, і море, — багато чого є. Що для вас означає незалежність? Основне слово, яке в мене асоціюється зі словом незалежність – це самодостатність. Це свобода вибору, яким шляхом іти та яке життя жити. Я думаю, що це є і привілеєм, і обов’язком. З одного боку, можна самостійно ухвалювати рішення і мати контроль над своїм життям. З іншого боку, це тягар за рішення, які ми ухвалюємо, та наслідки, які приходять після того, як ці рішення виконують. Помріємо. Україна у 2032 році. Яка вона? Це фундаментально сильна країна з національними інститутами, які розвинені на рівні провідних країн у світі, тобто і відсутність корупції, і главенство права, і дуже високий рівень освіті, і сильна економіка. З іншого боку, хотілося б утримати свою самодостатність та незалежність. Я сподіваюся, що громадяни зможуть вирішувати, куди далі рухатися, та будувати своє майбутнє так, як ми його вирішимо. Будувати без натиску будь-якої зі сторін. Я сподіваюся, що з цієї жахливої ситуації ми вийдемо сильніші — як і держава, і як нація, і як кожен громадянин. Уляна Олійник, Creative Writer в Headway, партнерській компанії Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Здається, тепер уже нема іноземців, які не чули про Україну. Та я б описала або «603 700 км², які обов’язково треба побачити на власні очі та дослідити», або «місце народження і становлення спраглих до життя та свободи людей». Що для вас означає незалежність? Незалежність — це про сміливість, відповідальність, свободу, прийняття і боротьбу водночас. Як на рівні країни, так і на рівні людини. Для мене це не про обмеження та підлаштування під наявні рамки, а про взяття відповідальності за своє життя, створення власних візій та принципів і їх обстоювання. Помріємо. Україна у 2032 році. Яка вона? Перше, що спадає на думку, це вільна. А ще відбудована. Зміцніла. Щаслива. Наповнена людьми, ресурсами, результатами. У балансі з природою. Розвинута. Марина Мазур, Product Manager в SUITSME Як би ви описали Україну іноземцю, який ніколи про неї не чув? Наша країна настільки різноманітна та цікава, що опис був би довгенький. Україна — величезна, крута і сучасна. Гори? Є. Море? Є. Старовинні палаци? Є. Сучасні міста? Є. Тут є усе, чого лише можна забажати. Технологічна і автентична, динамічна і спокійна… Україна може бути будь-якою — усе залежить від обраного ракурсу. Що для вас означає незалежність? Для мене незалежність — це можливість робити вибір, яким буде моє завтра, та нести відповідальність за свої рішення. Для країни справжня незалежність — це можливість будувати власне майбутнє і передавати усе найкраще як спадщину. Відповідно, головним обов’язком стає потреба боронити це право та передавати його як настанову з покоління у покоління. Помріємо. Україна у 2032 році. Яка вона? Насамперед хотіла б бачити її мирною та відновленою. Українська технологічна індустрія у самому розквіті, і ми тепер не лише потужна аграрна держава. Переосмислення власної культурної спадщини та зближення з нею дали шалений поштовх культурі сучасній, і тепер весь світ знає українських митців. Через інтеграцію зі світом наша туристична індустрія квітне, а кожен блогер мріє зробити фото на березі Лемурійського озера або на Карпатській вершині. Галина Міськів, Marketing manager в Jiji, партнерській компанії Genesis Як би ви описали Україну іноземцю, який ніколи про неї не чув? Україна — дійсно прекрасна країна, у котрій живе безліч відкритих, вільних і свідомих людей. З маленькими ресурсами ці люди здатні робити великі речі, бо роблять їх з любов’ю. Україна для мене — це про найкращі якості, котрі можуть в нас бути. Це про душевне тепло, відкритість, щирість, щедрість, про красу та ще багато чого. Україна — це про любов. Що для вас означає незалежність? Незалежність — це про бажання мати і розвивати власні опори, власні ресурси, розвивати себе. Як на мене, це стосується як держави, так і людини особисто. Таких собі макро- та мікрокосмів. Проте Незалежність нашого макрокосму, Держави, будується з розвитку нас самих, мікрокосмів. Тому нам треба прагнути до своєї власної Незалежності. А для цього брати на себе відповідальність і жити свідомо. Як мінімум, ми отримаємо Державу з внутрішньо вільною та проактивною нацією. А як максимум… Помріємо. Україна у 2032 році. Яка вона? Я вірю в те, що це буде країна майбутнього. Багато процесів буде реорганізовано і оптимізовано. Масова диджиталізація. Наплив іноземних бізнесів, котрих будуть приваблювати низькі податкові ставки. Розквітне іноземний туризм, буде реалізовано безліч ініціатив з підтримки населення та Збройних Сил України. Це буде нова глава Новітньої історії України. України, котра відстояла себе і пірнула у стрімкий розвиток.