top of page

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

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

  • 7 міфів про SQL. Спростовує Data Engineer в Boosters

    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% — допустима й не має високого впливу на результат.

  • Короткий ґайд продуктовим дизайном від Head of Product Design в Headway

    Чим займається продуктовий дизайнер у бізнесі? Що він проєктує, окрім інтерфейсів? Чому він має бути адвокатом користувача? Відповіді на ці та інші питання про професію продуктового дизайнера ви дізнаєтесь із лаконічного ґайда для початківців, який склав Анатолій Денисюк, Head of Product Design в Headway, партнерській компанії Genesis. Він буде одним із лекторів на Genesis UI/UX School, реєстрація на яку вже відкрита і триватиме до 12 лютого. Хто такий продакт-дизайнер? Дизайн — це розв'язання проблеми людини. Якщо говорити про продуктовий дизайн, то в цьому випадку, крім користувача, є ще бізнес, який має рости, розвиватися, масштабуватися, заробляти гроші. Бізнес не буде успішним без користувача. Грамотний продуктовий дизайн враховує як потреби бізнесу, так і проблеми користувача. Продуктовий дизайнер може відповідати за різні речі залежно від команди, у якій він працює. Можна виділити три основні ролі, в яких він може виступати: Адвокат користувача Йдеться не про захист прав користувача, а про інтерпретацію його потреб і комунікацію з ним. Дизайнер ближче за всіх до користувача, його «болей», до завдання та його вирішення. Він спілкується з користувачем, генерує гіпотези, отримує фідбек, інсайти. Також саме він цю інформацію переробляє і доносить команді. Напарник продуктового менеджера Якщо ви хочете бути продуктовим менеджером, то, ймовірно, часто будете спілкуватися з продакт-дизайнером. Багато в чому навички дизайнера і продуктового менеджера перетинаються. Це робота напарників, причому на різних стадіях розробки продукту. Найдопитливіший у команді Дизайнер, який буде «докопуватися» до істини, до цінної інформації. Це важливо, тому що зібравши первинні дані у користувачів, ми не можемо зупинитися на цьому, потрібно копати глибше, ставити багато запитань, різних і складних. Найчастіше це робить саме дизайнер. Добре, коли тут також залучений продакт-менеджер. У чому має орієнтуватися продуктовий дизайнер? Принципи функціонування бізнесу Продуктова аналітика Користувацькі дослідження Користувацький досвід Проєктування інтерфейсів Від атомів до систем Дизайн — це сукупність елементів, тому проєктування завжди відбувається від найменшого елемента до більших. Одна з найпопулярніших методологій проєктування інтерфейсів — це атомарний дизайн. Вона передбачає, що кожен дизайн-елемент належить до тієї чи іншої групи залежно від складності. Базовий рівень — атом, найпростіший елемент. Це кнопка, іконка і текст. Наступний рівень — молекули, сукупність атомів, які створюють об'єкт, з яким можна взаємодіяти. Він поки ще не поміщений у якесь середовище, не до кінця зрозуміла функція, але це вже інтерактивний елемент. В застосунку Headway це може бути самарі книги, обкладинка та ім'я автора. З молекул складається організм. При цьому молекули можуть бути як одного рівня, так і різних. Організм — це самостійна сутність, яка вже може бути поміщена на екран застосунку, має логіку і контекст. Сукупність організмів, які разом вирішують завдання або завдання користувача, — це шаблон. Наприклад, екран, який зберігає самарі, які відкривав юзер, і трекає його прогрес. Усі згадані елементи та групи елементів у підсумку складаються в дизайн-систему. Це бібліотека найпоширеніших елементів і правил їхнього використання. У будь-якій дизайн-системі мають бути присутні три складові: Дизайн- і UI-кіт, тобто всі елементи, які ми часто перевикористовуємо (кнопки, інпути, чекбокси). Кожен елемент має бути описаний, щоби розуміти, навіщо він потрібен і як з ним можна взаємодіяти Розробка. У програміста має бути такий самий кіт із такими самими елементами Документація Користувацький досвід Досвід — це те, як користувач взаємодіє з продуктом, що він у цей момент відчуває, який фідбек він дає системі. Якщо на певному етапі взаємодія залишить негативне враження, користувач піде і не повернеться. Що впливає на хороший користувацький досвід? Швидкість (швидкість інтернету у користувача, продуктивність його девайса і продукту, швидкість звантаження в AppStore або GooglePlay) Контекст користувача (культурний, соціальний контекст: де живе користувач, який там менталітет, що там прийнято чи ні, якою мовою говорять, які там традиції. Ми можемо створити поганий досвід, якщо, наприклад, невдалим формулюванням зачепимо почуття юзера) Контекст використання (як людина тримає телефон, що робить, коли використовує наш продукт — обідає, їде в машині, вдома розмовляє з рідними тощо) Проєктуючи користувацький досвід, варто відповісти на такі запитання: У чому цінність продукту? Цінність — те, заради чого користувач завантажує застосунок. Деякі відповіді на це питання лежать на поверхні: те, що ми дізналися, поки досліджували конкурентів, як вони доносять цінність і говорять про себе. Неочевидні відповіді підказує маркетинг. Цінність потрібно розуміти, тестувати її, і про неї варто говорити. Для якої роботи користувач «винаймає» наш продукт? Творець легендарної «теорії підривних інновацій» Клейтон Крістенсен розробив концепцію "jobs to be done". Згідно з нею, для створення продукту важливо визначити саме обставини, в яких користувачеві він може знадобиться. Є відомий приклад із McDonald's. У компанії було завдання підвищити продаж мілкшейків. Для цього Крістенсен приїхав у заклад і спостерігав, хто купує мілкшейки, і спілкувався з цими покупцями. Виявилося, найчастіше його купують вранці люди, які їдуть машиною на роботу. Яке завдання вирішує мілкшейк? Втамувати голод під час поїздки. Чому мілкшейк? Він поживний, його зручно тримати за кермом, він не виливається зі склянки. McDonald's отримав інсайт, зробив коктейль ще густішим, і продажі зросли. Що стоїть на шляху до вирішення завдань користувача? І цінність, і розуміння роботи, для якої нас «винаймає» користувач, допомагає нам зрозуміти, які дії він має зробити в продукті, щоби задовольнити свої потреби. Наприклад, у Headway цільова дія — дочитування самарі книжки. Цей показник позитивно впливає на всі метрики. Тому розуміння конкретних завдань і визначення маршруту користувача дуже важливе. Маршрут може бути коротким, а може — довшим: із перешкодами, поп-апами, екранами, які відправлять його не одним шляхом, а десятьма. Ці шляхи потрібно опрацьовувати і тестувати — які дії здійснює юзер, з якими проблемами стикається, де він відчуває нерозуміння, фрустрацію, отримує поганий досвід. Дещо про користувацькі дослідження Щоби зробити продукт максимально функціональним і таким, що відповідає запитам користувача, потрібні інсайти. Отримуємо їх безпосередньо від користувачів у процесі користувацьких досліджень. Корисні книжки для дизайнерів-початківців «Не змушуйте мене думати», Стів Круг «Запитай маму», Роб Фітцпатрік «Спринт», Джейк Кнапп «Коли кава і капуста — конкуренти», Алан Клемент «Дизайн звичних речей», Дон Норман

  • Мозковий штурм: що це таке, які техніки бувають та як брейнштормити ефективно

    У 1940-х роках минулого століття креативник та підприємець Алекс Осборн помітив, що його співробітники краще генерують ідеї разом, ніж наодинці. З цього все почалося. Метод мозкового штурму став однією з найпопулярніших креативних практик, його використовують у багатьох сферах, а техніка проведення з часом еволюціонувала з класичного обговорення до безлічі різноманітних видозмін. У цій статті ми розповімо основне про мозковий штурм, зокрема, як він виник, які є етапи, які техніки використовувати та як провести сеанс найефективніше. Своїм досвідом проведення сеансів брейншторму діляться Олена Васів, Head of Creative Team в PlantIn, Тетяна Шелудченко, Creative Manager в Impulse та Ольга Кисельова, Design Team Lead в Genesis. Олена в PlantIn понад два роки й з нуля побудувала команду з 13 фахівців; зараз вона удосконалює процеси та відповідає за нові напрями. Тетяна понад п’ять років у маркетингу, зокрема, вона працювала з всеукраїнськими проєктами, стартапами та ІТ-компанією, й уже рік керує креативною командою в Impulse. Ольга понад 7 років займається дизайном у IT та ритейлі, й зараз відповідає за візуальну частину комунікацій бренду Genesis та півтора року очолює дизайн-напрям у PR-команді екосистеми. > Що таке мозковий штурм > Історія появи мозкового штурму > Етапи проведення мозкового штурму > Склад групи для мозкового штурму > Популярні техніки мозкового штурму > Помилки під час проведення брейншторму > Поради для проведення успішного мозкового штурму > Що почитати Що таке мозковий штурм Мозковий штурм — це практика для придумування ідей чи вирішення проблем, коли учасники можуть вільно та без критики ділитися своїми думками. Зібраний пул ідей використовують як стартову точку для проєкту чи кампанії, через що мозковий штурм часто проводять на старті роботи. «Над невеликими задачами я волію працювати самостійно, хоча іноді можу обговорити ідею з колегами. Однак, якщо у роботі великий проєкт, то обговорення і пропозиції інших дуже допомагають. Наприклад, нещодавно ми працювали над сайтом. Першу ітерацію макета я робила сама, тож не враховувала деякі важливі для проєкту речі. Тому було корисно, коли ми побрейнштормили з іншими співробітниками, які були залучені до процесу, й кожен висловився, що можна доробити, й чому. Ми щось прибирали, щось об’єднали, й за пару підходів зупинилися на більш-менш остаточному вигляді макета», — говорить Design Team Lead в Genesis Ольга Кисельова. Неочевидні завдання практики — допомогти членам команди налагодити особистісний зв’язок й почуватися комфортніше одне з одним. Історія появи мозкового штурму Попри те, що зараз спосіб здається очевидним, ще 100 років тому мозкового штурму не існувало. Метод вільного та неупередженого генерування ідей придумав підприємець та креативник Алекс Осборн у 40-х роках минулого століття. Працюючи у рекламній агенції BBDO (він був одним з її співзасновників та партнерів), підприємець помітив, що багатьом співробітникам важко придумувати ідеї наодинці, а от групове обговорення часто давало кращі результати. Аби покращити креативний процес, креативник почав експериментувати й врешті-решт розробив ряд правил для ефективного мозкового штурму. Серед них: відсутність критики; чим більше варіантів, тим краще; свої ідеї можна базувати на ідеях інших; шалені й нестандартні пропозиції вітаються. Пізніше методика знайшла відображення в книзі «Керована уява», що вийшла друком у 1953 році. Саме після виходу книги мозковий штурм став популярним та широко використовуваним у багатьох сферах. Етапи проведення мозкового штурму Будь-яка техніка проведення мозкового штурму передбачає декілька основних етапів. 1. Підготовка. Тут ви визначаєте тему або проблему, яку будете «штурмувати», учасників обговорення та модератора. Тему обговорення озвучуйте заздалегідь, аби всі могли її обдумати та почали «накидувати» ідеї одразу після старту брейншторму. 2. Генерація ідей. Це основний етап — учасники мають створити якомога більше ідей за визначений проміжок часу. Техніку можна обрати будь-яку, а керуватися варто тими ж правилами, які сформулював Осборн — відсутність критики, можливість будувати одні ідеї на основі інших, заохочення шалених пропозицій. «Під час брейнштормів ми шукаємо «агресивні» концепції, які точно захоплять увагу потенційного користувача. Наш продукт пов’язаний з рослинами, тож є декілька тем, які будуть повторюватися від сезону до сезону. Наприклад, полив. Одна з найпоширеніших помилок полягає в тому, що люди переливають чи не доливають свої рослини. PlantIn має рішення: у функціоналі застосунку є калькулятор, який вираховує необхідну кількість води відповідно до сезону, півкулі, розміру горщика, віку рослини тощо. Однак просте зображення поливу на креативі навряд чи зачепить увагу людини. Тому під час брейнштормів ми шукаємо сміливіші та креативніші концепції — а потім робимо, наприклад, динамічне моушн-відео, де рослину зрошують зі шланга й усюди летять бризки», — говорить Head of Creative Team в PlantIn Олена Васів. 3. Обробка ідей. Ось на цьому етапі пропозиції вже можна оцінити — наскільки вони актуальні, значущі, нові, можливі для реалізації своїми силами тощо. Згрупуйте їх за категоріями — це допоможе побачити перспективні ідеї та далі працювати саме над ними. 4. Розробка ідей. На цьому етапі група зосереджується на роботі з найбільш перспективними ідеями. Вона може полягати у визначенні наступних кроків, створенні детального плану, пошуку додаткової інформації тощо. Власне етапи можна підлаштовувати під себе. Наприклад, обробку ідей часто пропускають, обираючи натомість більш підходящий для конкретної ситуації варіант. Після штурму група переходить до реалізації ідеї. Склад групи для мозкового штурму Він залежить від теми та мети заходу, втім, деякі рекомендації щодо учасників все ж є. 1. Ідеальна кількість учасників брейншторму — 6-10 осіб. Якщо людей більше, то хаос обговорення дуже важко контролювати, а якщо менше — то ідей на фінальному етапі може бути достатньо. 2. Залучіть до брейншторму людей з різним досвідом, професією та знаннями. Завдяки цьому спектр ідей, які запропонують учасники, буде набагато ширшим. «У людей, що працюють з креативами, іноді замилюється око, тож виникають бар’єри, що заважають розвивати конкретну ідею. А ті, хто менш дотичні до цього, бачать ситуацію під іншим кутом, і можуть порадити прості та геніальні рішення. Тому корисно залучати на брейншторм не тільки креативників, а, наприклад, розробників», — говорить Creative Marketing Manager в Impulse Тетяна Шелудченко. 3. Співвідношення між тими, хто не соромиться активно генерувати ідеї, й тими, хто воліє більше слухати, має бути приблизно 50/50. 4. Якщо людина скептично ставиться до мозкового штурму, не варто наполягати чи змушувати. Краще залучити її до участі в іншій практиці. 5. Деякі джерела радять не залучати на обговорення керівників, адже так, група начебто відчуватиме себе більш скуто. Втім, кожна команда може застосовувати це правило залежно від своєї культури. «В нашому брейнштормі завжди беруть участь СЕО та СМО, адже вони найглибше розуміють продукт, його специфіку та технологічні тонкощі», — каже Тетяна Шелудченко. Окрему увагу варто приділити ролі фасилітатора або модератора події. Його, як і учасників брейншторму, обирають завчасно. «Ми намагаємося робити так, щоби кожен член креативної команди побув модератором та запропонував якусь нову механіку брейншторму», — зазначає Олена Васів. На початку сесії він формулює тему чи проблему, а далі заохочує усіх брати участь в обговоренні й стежить за тим, щоби не було критики. Якщо всі відхилилися від курсу — він повертає їх у потрібне русло. Крім того, завдання модератора — простежити, аби всі взяли участь у дискусії, і менш активні учасники теж висловили свою думку. Інколи модератор і сам приєднується до дискусії. Він накидує сміливі та ідеї, показуючи, що так можна. Наприкінці його завдання — підсумувати ключові моменти й окреслити наступні кроки. Популярні техніки мозкового штурму Починати мозковий штурм можна з різних креативних технік, щоби учасники обговорення могли «розігрітися». Ось декілька практик, які використовують в команді Impulse. Вона є частиною компанії Headway, і розробляє мобільний EdTech-продукт: «що можна покласти у трилітрову банку». За 30 секунд треба назвати предмет, який можна покласти у трилітрову банку. Завдання, можна ускладнювати, наприклад, просити учасників називати предмети на різні букви. «що я беру з собою на море». Учасники сідають у коло, й один з учасників каже, що бере на море. Наступна людина має повторити те, що назвали усі попередні. Так проходять три кола. вправа на прикметники. Наприклад, модератор показує фотографію апельсина, і кожен має за певний проміжок часу накидати варіанти, який він: помаранчевий, смачний, соковитий тощо. розшифровка. Модератор називає абревіатуру, а учасники за декілька хвилин мають придумати розшифровку до неї. Така розминка допомагає відволіктися від інших робочих задач та налаштувати мозок на креативний процес. А ось власне техніки. 📢 По черзі Найпростіший варіант, коли модератор озвучує тему брейншторму, а інші одне за одним висловлюють свої ідеї. Кожна наступна може спиратися на думки попередніх. 📝 Процедура Шаретт Учасників ділять на групи, в кожній з яких призначають лідера. Кожна група обговорює обрану тему, а окрема людина робить нотатки з ідеями. Далі записи передають іншій групі, й у наступному колі вона переосмислює думки колег та привносить щось своє. Після декількох повторів записи передаються модератору, який підбиває підсумки та обирає найкращі рішення. Процедура Шаретт передбачає, що всі групи можуть обговорювати і одну тему, і декілька. 🖇️ Сходова техніка Тут навпаки: учасник озвучує свої ідеї до того, як почує ідеї інших. Наприклад, у кімнаті залишаються двоє людей. Вони обмінюються ідеями, а потім до приміщення входить хтось третій. Він каже свою ідею, а потім слухає думки попередніх учасників. Поступово висловлюються всі. 🎭 Метод Уолта Діснея Методика, названа на честь легендарного мультиплікатора, полягає в тому, що учасникам команди призначають ролі, з позиції яких потрібно глянути на продукт, проблему чи проєкт. Тетяна Шелудченко розповідає, що перед брейнштормом досліджує ринок, аналізує конкурентів та готує пул ідей та пропозицій до обговорення. «Усього є три ролі — мрійники, реалісти та критики. Перші «мріють», як переосмислити якусь концепцію та втілити її у нашому застосунку. Другі стежать, щоб ідеї були реальні в плані виконання, та пропонують, що змінити, аби вони такими стали. Треті — наводять аргументи, чому пропозицію взагалі не варто розглядати», — пояснює вона. Коли всі висловилися, команда обирає ідеї, які варто реалізувати, визначає терміни та відповідальних. 🐟 Діаграма Ішікави Інша назва техніки — метод риб’ячої кістки, адже сам графік має вигляд риб'ячого скелета. «Хребет» риби представляє проблему або наслідок, а гілки — різні категорії можливих причин. Обговоріть із командою кожну та визначте чинники, які могли вплинути на ситуацію. Зобразіть їх, як тонкі лінії, що виходять з основних «кісток» риби. Проаналізуйте всі причини, знайдіть закономірності, аби зрозуміти корінь проблеми, — так ви зможете точно сформулювати шляхи її вирішення. 💡 SCAMPER Візьміть ідею креативу, логотип, слоган, процес, продукт — це ваш шаблон. Видозмінюйте його сімома основними способами — вони зашифровані в абревіатурі. Substitute — замінити. Замініть елемент у шаблоні. Combine — поєднати. Поєднайте шаблон будь-чим іншим. Adapt — адаптувати. Додайте новий елемент до шаблону. Modify — скорегувати. Змініть розмір, форму, колір чи інший атрибут шаблону. Put to another use — знайти інше застосування. «Прикладіть» шаблон до іншого ринку, сфери, країни, продукту тощо. Eliminate — виключити. Видаліть елемент з шаблону. Reverse — зробити інверсію. Виверніть шаблон навиворіт. Цю техніку можна застосувати і в групі, і наодинці. Проаналізуйте отримані ідеї, оберіть найбільш вдалу, допрацюйте її — та беріться до реалізації. 🤔 Зворотний мозковий штурм У цій техніці учасники концентруються не стільки на пошуку свіжих ідей, скільки на недоліках продукту чи сервісу. Замість питання «Як можна це покращити?» запитайте у групи «Що може статися у найгіршому випадку?» Ви здивуєтеся кількості різних варіантів! Зафіксуйте всі пропозиції, а далі подумайте, які з них сприятимуть вирішенню проблеми. 🖋️ Письмовий мозковий штурм Суть процесу полягає у записуванні ідей, що спадають на думку — знову таки, без критики та цензури. Так можна подолати, наприклад, страх чистого аркуша або інші перешкоди для творчості. Серед способів письмового мозкового штурму — фрірайтинг, складання списків й навіть ведення особистого щоденника. Втім, письмовий мозковий штурм не означає індивідуальний. Ось практика для групи, якою поділилася Олена Васів. «Є тема, наприклад, догляд за рослинами взимку. У групі з шести учасників кожен бере аркуш паперу та записує ідею, що пов’язана з темою. Далі людина передає свої нотатки сусіду, й завдання наступного учасника — розвинути та доповнити цю ідею. Так повторюється, доки всі не доповнять кожен з шести аркушів. Наприкінці маємо шість деталізованих ідей». ⏳ Метод 6—5—3 Цією методикою поділилася Тетяна Шелудченко, її часто застосовують у команді Impulse. В середньому залучають шестеро (чи більше) людей, які за п’ять хвилин генерують мінімум по три ідеї, а потім обмінюються ними. 🧠 Індивідуальний мозковий штурм На відміну від колективного мозкового штурму, індивідуальний допомагає вирішити проблему більш особисто та цілеспрямовано. Можна використовувати тексти чи малювання, або поєднати їх і скласти ментальну карту — техніку візуалізації, що дозволяє зафіксувати та обробити інформацію. «Іноді я можу просто виписувати асоціації, занотовувати їх, фіксувати все, що пов’язане з цією темою. Але так не вийде побачити додаткові зв'язки між всіма елементами та глибше в них зануритися. Натомість завдяки ментальній карті весь безлад у голові, пов’язаний з темою, розкривається як квітка, і видно, що навіть у різних напрямках твоїх думок є спільні елементи. Так можна побачити всі ідеї одночасно та подумати, як скомбінувати їх між собою», — говорить Ольга Кисельова. ✅ NUF-тест Це не техніка брейншторму, а метод оцінки ідей, які виникли в ході нього. Перевірте кожну пропозицію за трьома категоріями: N (new) — чи нова ця ідея; U (useful) — чи вона корисна; F (feasible) — чи можна її реалізувати. На основі результатів залишіть найкращі пропозиції. Помилки під час проведення брейншторму Існує кілька поширених помилок, які можуть виникнути під час сеансу мозкового штурму. Зокрема: 1. Обмежувати творчий процес. Модерувати дискусію можна і треба, але встановлення суворих правил чи рекомендацій може «задушити» креатив та загальмувати вільний обмін ідеями. 2. Критикувати ідеї. Смішки, скептичний вираз обличчя, зневажливі коментарі ідей, що вибиваються з загального потоку може знівелювати потенціал сеансу мозкового штурму. 3. Не записувати ідеї. Є ризик, що ви їх не помітите чи забудете. 4. Не втілювати ідеї. В цьому випадку в сеансах мозкового штурму немає жодного сенсу. 5. Залучати тільки найактивніших. Це може призвести до того, що вдалі ідеї від більш спокійних співробітників так і не будуть озвучені, а вони самі відчуватимуть себе вигнанцями. 6. Не забезпечити комфортне середовище. Приміщення з незручними меблями та поганою звукоізоляцією може ускладнити процес, заважати учасникам зосередитися та ефективно штормити. 7. Обрати невдалого модератора. Завдання модератора — бути уважним спостерігачем та водночас стимулювати активність. Важливо обрати людину, яка гармонійно поєднає обидві ролі. Поради для проведення успішного мозкового штурму 1. Заохочуйте участь усіх членів групи. Переконайтеся, що кожен має можливість внести свої ідеї. Досягти цього можна, надавши кожному час для висловлення та відмовившись від критики під час обговорень. 2. Визначте конкретні цілі та завдання. Так ви зможете тримати обговорення сфокусованим та рухатися за планом. «Ми у команді оцінюємо якість брейншторів за кількістю ідей для реклами, які потім сконвертувалися в покупку, щоби не було так, що ідей багато, але жодна не дала результату. Ми заносимо всі ідеї у спеціальну табличку, визначаємо пріоритетність, а потім фіксуємо, що «зайшло», а що ні», — говорить Олена Васів. 3. Заохочуйте шалені та нестандартні ідеї. Найменш нереалістичні та незвичні ідеї часто можуть призвести до найбільш креативних рішень. 4. Використовуйте візуальні елементи. Діаграми, стікери, малюнки зроблять ваше обговорення ще більш дієвим. 5. Будьте гнучкими. Мозковий штурм рідко схожий на прямолінійний процес, а етапи та техніки можуть змінюватися в процесі обговорення. 6. Робіть перерви. Вони важливі, щоби розум не перевтомлювався. 7. Реалізуйте ідеї після мозкового штурму, щоби переконатися, що час і зусилля були витрачені недаремно. Що почитати «21 спосіб мислити креативно». Майкл Мікалко «Думай як митець». Вілл Гомперц «Посібник із креативного мислення». Кріс Ґріффітс, Меліна Кості «Кради як митець». Остін Клеон «Гнучкий розум. Як бачити речі інакше і думати нестандартно». Естаніслао Бахрах

  • Хто такий Solution Architect: роль, навички та компетенції

    Архітектор в ІТ відповідає за дизайн системи або її частини. У зоні відповідальності Solution Architect — розробка, яка зосереджена на задоволенні бізнес-вимог, її якість і продуктово-технічне бачення продукту. Про роль архітектора рішень у компанії та місце в команді, навички та компетенції розповідає Сергій Касянчук, Solution Architect у Solidgate, партнерській компанії Genesis. Він перейшов на цю позицію, попрацювавши техлідом протягом трьох років та архітектором протягом року в іншому продукті. Сергій розповів, як створюється архітектура системи та чому цей спеціаліст має безперервно навчатися та тренувати надивленість. > Роль Solution Architect в команді > Як стати архітектором рішень > Хард- і софт-скіли > Чотири міфи про Solution Architect > Як створюються архітектури > Що таке хороша архітектура > Як архітектор знаходить рішення > Книги та корисні ресурси Роль Solution Architect в команді Популярна метафора Грегора Хопа порівнює роботу на цій позиції з ліфтом. Уявіть, що ІТ-компанія — це будівля, у якій кожен поверх — окрема команда, а керівництво розміщується в пентхаусі. «Архітектор — це ліфт, який тримається окремо від усіх команд, але переміщується від одного поверху до іншого. Він отримує продуктові вимоги стейкхолдерів до системи, переводить їх у технічні та транслює відділу розробки. І навпаки — переводить технічні проблеми в потенційний вплив на бізнес і на продукт», — Сергій Касянчук. У багатьох компаніях Solution Architect — це роль, яка передбачає технічне лідерство всієї команди розробки. Ще не CTO, але і вже не інженер, який лише пише код. Найближча до архітектора рішень позиція — техлід, але в нього рівень відповідальності значно менший. Як правило, він керує командою до 10 людей, залежно від компанії. Натомість в архітектора часто в розпорядженні кілька команд, у кожної з яких є свій техлід або тимлід, які йому підпорядковуються. Сам архітектор звітує C-level менеджерам, найчастіше — CTO. Ключові компетенції Solution Architect: забезпечення технічної якості продукту; задоволення бізнес-вимог і зобов’язань перед користувачами; відповідальність за загальний дизайн системи та її стан; моніторинг системи; вибір або зміна стеку технологій залежно від того, які проблеми вони вирішують; аналіз проблем, з якими стикається бізнес, і ретрансляція їх на команду розробки. Крім Solution Architect в ІТ існує чимало інших видів архітекторів: Application Architect, Enterprise Architect, System Architect, Infrastructure Architect, Quality Architect, Data Architect тощо. Останнім часом набирає популярності Cloud Architect. Як у компанії зʼявляється архітектор? Найчастіше просто настає етап, коли вирішують, що їм потрібен цей спеціаліст. Зазвичай це відбувається, коли продукт перейшов рубіж у 3–4 роки та продовжує зростати. У цей час у нього зʼявляється потреба змінюватися, нові вимоги, і потрібна людина, яка все це контролюватиме. Але насправді в кожному проєкті є людина, яка де-факто виконує роль архітектора. Навіть у маленькій компанії з командою в 15 людей хтось збиратиме всю продуктову інформацію, матиме бачення, як побудувати продукт та відповідатиме за розробку загалом. Тому можна стверджувати, що архітектура потрібна всім продуктам, а от архітектор — не всім. Як стати архітектором рішень Найкоротший шлях до цієї професії — для Senior Software Engineer, який має лідерські якості або бажання щось змінювати. Також часто архітекторами стають DevOps інженери розробники, адже ця роль також вимагає рішень комплексних та інфраструктурних задач. Особливість нашого ринку — архітектори акумулюють у собі різні обовʼязки. Це можуть бути архітектори, які багато часу витрачають на код. І навпаки — такі, що займаються переважно документацією, аналізом, дизайном системи, але код уже не пишуть. Чи працює архітектор із кодом, залежить від стадії розвитку продукту й розміру команди. Якщо в невеликій команді техлід виконує роль архітектора, він може бути повністю зануреним у продукт і роботу з кодом. Але коли команда велика, архітектор відповідає за стратегію і тактику. У такому випадку свій внесок у код він здійснює через код-ревʼю. «Мій перехід від техліда до архітектора відбувався в межах однієї компанії і одного продукту. Тому він був досить простим. Не потрібно було охоплювати колосальну кількість нової інформації», — згадує Сергій Касянчук. З іншого боку, за його словами, архітектура — це окрема дисципліна зі своїми стандартами та методиками, а також фреймворками (наприклад, SEI, TOGAF тощо). Тому, маючи досвід та навички, ще доводиться освоювати нові вміння саме з дизайну систем. Архітектор має постійно вчитися, охоплювати чималу кількість різних кейсів, ситуацій та рішень. Хард- і софт-скіли На певному етапі розвитку спеціаліста хардові скіли стають менш важливими. Чим вище за ієрархічною структурою зростає спеціаліст, тим більше важать софт-скіли. Архітектор — не виняток. Якщо в техліда співвідношення навичок складає 60/40, де переважають хард-скіли, то в архітектора — навпаки. Нижче перераховані деякі з них. Хард-скіли: розуміння принципів побудови архітектури та її патернів; знання етапів розвитку систем; досвід розробки з використанням різних інструментів та підходів; знання сучасних найкращих практик розробки. Софт-скіли: здатність доносити думки; вміння презентувати ідеї; здатність слухати, аналізувати, ретранслювати; готовність до безперервного навчання. Чотири міфи про Solution Architect Стану архітектором і не буду керувати людьми. Може здаватися, що це суто технічна спеціальність, але зазвичай це не так. Архітектор комунікує з усіма командами, найбільше — з технічною та продуктовою. Стану архітектором і не буду думати про процеси, буду займатися винятково технологіями. Це неправда, часто процеси й будуються із залученням архітектора. Ба більше, є архітектори, які займаються лише побудовою процесів. Більшість розробників мріють стати архітекторами. Насправді далеко не всі. Бути просто сеньйорним фахівцем — досить комфортно й не вимагає такої кількості ментального ресурсу та відповідальності. Цей шлях саме тому не такий уже й популярний. Архітектор потрібен на першому етапі запуску продукту. Якщо на першому етапі наймати архітектора, формувати команду, описати всі вимоги, порахувати потенційні витрати, то розробка займатиме не дні або тижні, а місяці. Натомість завдання команди — швидко випустити MVP, щоби протестувати ідею. Як створюються архітектури Architecture development lifecycle — це процес створення архітектури систем. Зазвичай він складається із семи етапів: Визначення стейкхолдерів бізнесу — тих, хто впливає на продукт. Збір продуктових вимог — функціональних та нефункціональних. У такий спосіб вибудовуються рамки. Пріоритезація вимог та формування архітектурного плану, з урахуванням даних із попередніх етапів, ризиків та обмежень. Створення дизайну системи, звʼязків між компонентами, вибір стека технологій та плану розробки. Спираючись на бізнес-вимоги, Solution Architect аналізує, які компоненти системи в нього є, переміщує, компонує їх, створює звʼязки, додає нові та виводить з експлуатації ті, що існують. Формування команди. Розробка. Оцінка, чи задовольняє система вимоги з етапу №2. Часом у компаніях застосовують нетиповий цикл розробки, спрощуючи деякі етапи. Наприклад, етапу формування команд у продуктових компаніях найчастіше немає, натомість просто створюється роадмап. Що таке хороша архітектура Продуктові компанії працюють у нестабільному середовищі. Вимоги можуть змінюватися вже в процесі розробки, а в готові рішення з високою ймовірністю вноситимуться зміни. Архітектор має враховувати це, вміти вчасно пригальмувати та змінити курс, щоб рухатися до скоригованої цілі. Поняття хорошої архітектури — доволі субʼєктивне. Її завдання — задовольнити певні вимоги. Архітектуру тоді можна вважати хорошою, коли вона дозволяє легко реалізовувати новий функціонал без кардинальної зміни системи. Обовʼязковими складовими є наявність постулатів, осмислених звʼязків між компонентами та найголовніше — документації, яка дозволить іншому архітектору зрозуміти причину ухвалення тих чи інших рішень, щоби цю систему можна було підтримувати. «Я прийшов у проєкт із готовою архітектурою. Уже чотири місяці я вивчаю її та щодня дізнаюся щось нове. Кожне рішення має причину, підґрунтя та історію, і за короткий проміжок часу неможливо все охопити. Процес знайомства із системою — досить довгий, але водночас дуже цікавий», — Сергій Касянчук. Як архітектор знаходить рішення Складність роботи Solution Architect в продуктовому ІТ полягає в тому, що більшість задач — нетипові. Навіть два продукти в одній предметній області розвиватимуться по-різному та матимуть різні челенджі. Отже, не можна просто взяти за основу шаблон і допрацювати його. «Як би ми не старалися одразу створити гнучку масштабовану архітектуру, нічого не вийде. Головні виклики — постійна готовність шукати нові рішення, аналізувати величезну кількість інформації та визнати, що знати все неможливо. Рано чи пізно всі стикаються з проблемою, яку раніше не вирішували», — каже Сергій Касянчук. Перше, що має зробити архітектор, чітко визначити, у чому полягає проблема. Пошук рішень починається з ґуґла. Це складна подорож у дивовижний світ чужого досвіду й намагань зрозуміти, чи релевантний це досвід. Адже ніхто не описує, як влаштована його система, кількість мікросервісів, користувачів, трафік. Натомість статті починаються з формулювання проблеми. Такі ресурси як stackoverflow, ютуб, презентації, воркшопи, конференції дають величезну кількість варіацій рішень. Жодне з них не підійде на 100 %, але може дати по пазлику від загальної картини. Його можна адаптувати, поєднати з іншими рішеннями й застосувати до своєї системи. «У нас ніколи немає 100 % впевненості, що це рішення підійде, але є життєздатна гіпотеза, яку ми можемо реалізувати з мінімальними витратами часу й побачити результат, отримати фідбек від системи. І це в роботі архітектора — найважливіше», — Сергій Касянчук. Архітектор може зростати за грейдом. У цій сфері майже не зустрічається рівень джуніор, натомість є Solution Architect та Senior Solution Architect. У такому випадку спеціаліст розвиватиметься в замкнутому середовищі, зростатиме та вчитиметься будувати більш гнучкі та стабільні системи. Можна працювати у великих командах, де є Lead Architect і розвиватися там. Часом архітектори займаються консультаційною діяльністю — як технічний радник, який може допомогти в певних ситуаціях. Якщо є бажання керувати технічними командами, можна зростати до CTO, Vice President of Engineering. Книги та корисні ресурси: Microservices Patterns: With examples in Java, by Chris Richardson (автор книги — автор ресурсу microservices.io); Clean Architecture: A Craftsman's Guide to Software Structure and Design, by Robert C. Martin; Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems, Martin Kleppmann; Fundamentals of Software Architecture: An Engineering Approach, by Mark Richards, Neal Ford; Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures, by Mark Richards, Neal Ford, Pramod Sadalage, Zhamak Dehghani; https://microservices.io http://www.developertoarchitect.com.

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

    Headway, партнерська компанія Genesis, потрапила до списку найвпливовіших компаній у світі, що трансформують цифрове навчання та навички спеціалістів, — GSV 150 від інвестиційної платформи Global Silicon Valley (GSV). Headway опинилася у списку 150 топкомпаній світу, що впливають на освітні технології у 2023 році. Лідерів обирали з понад чотирьох тисяч приватних бізнесів за такими критеріями: масштаб та зростання, кількість користувачів, представленість у різних регіонах та прибуток. За оцінками GSV, 150 компаній переліку охоплюють близько трьох мільярдів людей, тобто майже половину населення світу, та генерують приблизно 25 мільярдів доларів доходу щорічно. Компанії GSV 150 допомагають розвиватися як дітям, так і дорослим. 33% бізнесів зосереджені на освіті протягом усього життя, 32% фокусуються на навчанні дітей, а 5% зосереджені виключно на вищій освіті. Найбільш представлений регіон — Північна Америка, США. На нього припадає 60% компаній списку, 14% компаній походять з Індії, 11% з Європи та 7% з Латинської Америки. Загалом до переліку GSV 150 у 2023 році потрапили компанії з 30 країн. «Те, що Headway потрапив до переліку взірцевих світових EdTech компаній, вкотре доводить, що українці багато в чому найкращі у світі. Пишаюсь результатами нашої команди й тим, що незабаром ми представимо Україну на ASU+GSV Summit 2023», — коментує СЕО та засновник Headway Антон Павловський. У 2010 році Global Silicon Valley спільно з Університетом штату Аризона (Arizona State University — ASU) заснували ASU+GSV Summit, щоб створити рівний доступ людей у світі до майбутнього. Щороку подія об'єднує провідні компанії та експертів у сфері освітніх технологій, що трансформують суспільство. Цього року ASU+GSV Summit пройде у квітні у Сан-Дієго. Headway — IT-компанія, що створює EdTech-продукти. Заснована у 2019 році. За 3,5 роки компанія зросла з 3 до 150+ людей у команді та відкрила офіси у Києві, Варшаві, Нікосії та Лондоні. Продукти Headway допомагають розвиватися мільйонам людей у світі через лаконічні формати освітнього контенту: курси, відео, ігри, інфографіки, самарі. Основний — застосунок Headway app. Він входить до десяти освітніх топзастосунків 2022 року в США.

  • «Почну з понеділка»: дайджест вакансій для QA

    Сьогодні у фокусі нашої уваги — QA-фахівці. Робота з мобайл-продуктами, зокрема з грою та платіжним провайдером, налаштування процесів з нуля, цікава співпраця з командою розробки. Може, ваша ідеальна вакансія саме тут? Бонусом — корисні матеріали для QA-спеціалістів. З них дізнаєтесь, як готуватись до технічної співбесіди та чому більшість загальновідомих фактів про QA — це міфи. Manual QA Specialist Компанія SUITSME розробляє однойменну фешн-гру, де можна створювати образи для віртуальної моделі з одягом понад ста реальних брендів. Зараз до команди шукають фахівця, який буде тестувати новий та наявний функціонал, знаходити баги й причини їх виникнення, та писатиме відповідні документи. Ви чудово впораєтеся, якщо вже тестували мобільні продукти на iOS, Android, а також у вебі, працювали з Postman, Charles чи іншими сніферами, маєте базові знання Git та SQL. Буде плюсом, якщо ви знаєте Unity та працювали з сокетами. Manual QA Маєте досвід ручного тестування продуктів у вебі та мобайлі? Знаєте, як працює HTTP-протокол та розумієте клієнт-серверну архітектуру? Слова «тест-план», «тест-дизайн», «тест-кейс», «баг-трекінгові системи», «життєвий цикл ПЗ» асоціюються у вас із робочими завданнями? Тоді ця вакансія для вас. Будувати процеси тестування потрібно з нуля, тому матимете змогу налаштувати все відповідно до свого бачення. Серед завдань — ручне тестування застосунків на Android, iOS й у вебі, та написання тестової документації (QA-процеси, чеклісти для функціонального та регресійного тестування тощо). Manual QA Engineer На цій позиції в Genesis Growth Accelerator фахівець буде впливати на якість продукту-лідера в style-tips ніші. Ви будете тестувати новий функціонал та підтримувати наявний, займатися API та інтеграціями продукту, а ще — оберете оптимальний шлях для реалізації технічних завдань разом з командою розробки. Вам потрібні знання основних принципів тестування і SDLC, та розуміння клієнт-серверної архітектури. Ви будете використовувати Chrome Dev Tools, АРІ-тестуванням та інструментами для тестування, тому важливо мати досвід роботи з ними. Ідеальний кандидат працював ранз мобільними застосунками та знайомий з техніками тест-дизайну. Вакансія партнера QA Engineer Партнерська компанія Genesis Solidgate створює платіжний провайдер, що надає онлайн-підприємцям можливість приймати всі види популярних платежів. Новий QA-Engineer буде тестувати АРІ, інтеграції продукту, а також вебзастосунки, створить та підтримуватиме документацію, аналізуватиме результати автотестів. Знадобляться півтора року комерційного досвіду й такі навички: розуміння клієнт-серверної архітектури, досвід АРІ тестування, знання Software Development Life Cycle. На позиції можна вирости до Automation QA Engineer або System Analyst. А зараз трохи корисного про QA: 180+ питань на співбесіду QA для Trainee, Junior, Middle, Senior Щоби якомога краще підготуватися до співбесіди, рекомендуємо ознайомитися зі списком питань, які ставлять на технічному інтерв’ю. У переліку є приклади на теорію, про розробку, про веб, мобайл та автоматизацію, а також про софт-скіли. Крім того, фахівці Genesis пояснюють, чому теоретичні питання ставлять всім, навіть сеньйорам, і що робити, коли не знаєте відповіді. Ви точно не зіштовхнетеся з усіма питаннями, але, орієнтуючись на список, зможете вчасно заповнити прогалини в знаннях. 5 міфів про тестування. Спростовує QA-техлід компанії AMO Також корисно буде ознайомитися з міфами в спільноті — щоби точно знати, чого очікувати від роботи. QA вже давно перестала бути трампліном в ІТ з мінімальними вимогами, а перетворилася на комплексну сферу з непростими завданнями. Так, вже на старті бажано знати хоча б одну мову програмування та бути готовим до автоматизації. А от витрачати час на тестову документацію не завжди доцільно, адже темпи розвитку проєктів можуть бути шаленими й постійно підтримувати актуальність документа просто не можливо. Докладніше про ці та інші міфи читайте в тексті.

  • 5 порад керівнику від операційного директора Genesis Артема Копанєва

    У масштабній освітній програмі Genesis StartUp Academy 2.0 together with Meta взяли участь 50 підприємців-фаундерів з усього світу. Менторські сесії, зустрічі з топовими підприємцями, можливість залучити інвестиції, та звичайно — навчання від практиків. Про різні етапи створення, управління та масштабування технологічного бізнесу учасники дізнавалися на лекціях від найкращих фахівців Genesis, Меta та інших компаній. Редакція блогу публікує конспект однієї з найзатребуваніших лекцій програми — «Управління командою» від СОО Genesis Артема Копанєва. Артем успішно керує командами та операціями на менеджерських позиціях понад п'ять років. У матеріалі ми зібрали його найважливіші поради про мотивацію, делегування, підвищення й інші управлінські лайфхаки, якими він ділився з учасниками стартап-академії. Реєстрація на наступний потік Genesis StartUp Academy почнеться незабаром, а попередню заявку вже можна залишити на сайті академії. Віднайдіть правильну мотивацію Мотивація співробітників дійсно сприяє розвитку бізнесу, коли вона обрана на правильному рівні. Ви можете обирати з трьох варіантів: Матеріальна мотивація — гроші й бенефіти Я не прибічник того, що для мотивації компанія має обов'язково платити вище за ринок. Стартап має надихати людей своєю візією та амбіціями. Якщо ви маленька компанія і переплачуєте співробітникам, це не дуже ефективний шлях залучення людей у команду. У такому випадку вони будуть відчувати себе лише робітниками: зробили роботу — отримали гроші. Набагато краще, коли люди бачать, що вони є частиною справжнього ком'юніті, яке працює спільно над чимось дуже важливим. На перших кроках бізнесу ідея та візія продукту чи компанії важить більше, ніж матеріальні заохочення. Особиста мотивація Професійне зростання, набуття нових навичок, досвіду, робота з класними людьми. З цих переваг робота із суперпрофесіоналами — найкраща мотивація. Насправді саме це допомагає людям швидше вчитися, зростати та досягати кращих результатів. Соціальна мотивація Якщо цілі, місія та бачення компанії збігаються із цінностями й цілями людини, це найкраща мотивація, яку вона може отримати. Кожному члену команди важливо розуміти, як його особисті цілі поєднуються із загальною візією компанії — чи це отримання нових навичок або бажання стати частиною великої історії. Важливо створити переконливу історію, яка допоможе залучати людей. Варто завжди пам'ятати, що найкращі фахівці можуть отримати будь-яку позицію, яка їм сподобається. Тому, якщо хочете створити команду топгравців, зверніть увагу на амбіції та цілі, які ваша компанія може задовольнити. Великі гроші й бенефіти A-players отримають будь-де, а от класна візія — це те, чим ви маєте вирізнятися, і те, що допоможе вам їх залучити. Підвищення Якщо співробітник претендує на підвищення, або ж менеджер вирішує, що хтось із команди має змінити позицію, варто ухвалювати рішення, враховуючи декілька факторів. Кого треба підвищувати? Співробітника, що має серйозні досягнення. Важливо, що тут йдеться про досягнення у вашій компанії, а не в попередній. Наприклад, якщо людина щойно прийшла, і ви одразу підвищуєте її на сеньйорну позицію через її попередні досягнення — це погана ідея. Так ви лише демотивуєте співробітників, які показали класні результати у вашій компанії, і це може призвести до внутрішніх конфліктів. Співробітника, який готовий до підвищення — як із точки зору навичок, так і з точки зору репутації в компанії. Людину, що відповідає культурі компанії, розділяє її цінності, знаходиться на тому ж рівні, що й компанія. Наприклад, людина з корпорації навряд чи підійде стартапу, і навпаки. Співробітника, що сам ініціює підвищення. Буває, що компанія підвищує людину, яка не хотіла цих змін. Класичний приклад — розробник, який досяг високих професійних успіхів, але не хоче бути менеджером. Запитайте у людини, чого вона хоче. Якщо виявиться, що вона не рада підвищенню — це не червоний прапорець або поганий знак. Сприймайте це лише як вказівку на те, що співробітник знає, що він хоче робити, і варто дати йому цю можливість. Абсолютно нормально, коли в компанії є люди, які експертні у своїй сфері, але не керують командами. Реалізуйте підвищення максимально прозоро та зрозуміло для компанії та самого працівника. В комунікації з людиною узгодьте всі очікування, дізнайтесь, яких ресурсів вона потребуватиме на новій позиції. Підвищення — складний виклик у будь-якому випадку, тому надайте всю необхідну підтримку. У комунікації для команди окресліть причини підвищення, нові сфери відповідальності співробітника. Наприклад, коли ми підвищуємо людину, я зазвичай надсилаю імейл на всіх співробітників, що дотичні до людини, де розповідаю про її досягнення, обов'язки на новій позиції. Крім того, прошу підтримати колегу у новій ролі та всіляко допомагати їй адаптуватися. Якщо замість листа ви зробите оголошення на зустрічі all hands — теж ок. Без звільнень не обійтись Одна з ключових помилок менеджерів — не звільняти тих, хто показує низький рівень перформансу. Це спричиняє дві проблеми. По-перше, залишаючи цих людей, ви знижуєте загальний рівень виконання задач. По-друге, ті, хто справляється зі своїми завданнями, демотивовані колегами, у яких не виходить досягати поставлених цілей. Водночас звільнення не має бути сюрпризом для людини. Якщо співробітник показує низький перформанс, приділіть йому увагу, дізнайтеся, чому так стається. Якщо людина певний час не досягає своїх цілей, ви маєте це з нею обговорити, запропонувати підтримку, допомогу, можливо, додаткові ресурси. Крім того, частіше перевіряйте проміжні результати. В Genesis ми практикуємо випробний період (2-3 місяці) для тих колег, у кого є складнощі з перформансом. Ми обговорюємо, в чому проблема, і визначаємо час, протягом якого вона має вирішитись. Комунікуйте прозоро Більшість проблем у комунікації компанії стаються саме через недостатню прозорість, а не через надмірну комунікацію. В режимі стартапу це нормально комунікувати багато, обговорювати ідеї та виклики разом із командою. Саме прозорість комунікації значним чином впливає на мотивацію або демотивацію співробітників. Передусім, це доступ до інформації про бізнес-метрики. Всі великі технологічні компанії надають співробітникам доступ до всіх бізнес-показників. По-друге, це чітка і зрозуміла трансляція візії компанії, пояснення дій і рішень менеджменту. Чим «молодша» стадія розвитку компанії, тим більшу роль це відіграє. Найкраще про це розповідати на зустрічах all-hands. One-on-one Прозору та послідовну комунікацію забезпечують також зустрічі one-on-one (або чекпойнти). Це ключове зобов'язання менеджера. Я раджу проводити чекпойнти з усіма, хто безпосередньо вам підпорядковується, щотижня або хоча б раз на два тижні. Ця регулярна зустріч проводиться не лише для менеджера, щоби зрозуміти, як людина перформить, а й для співробітника. На ній він має змогу адресувати менеджеру свої виклики й потреби, питання, які його турбують. Обов'язковий пункт для ефективного чекпойнту — перевірка статусів по задачах, які виконує співробітник, обговорення його стратегічних планів і цілей. Менеджер має поцікавитись, чи комфортно людині зараз в компанії, чи достатньо їй ресурсів, чи вона мотивована. Крім цього, варто обмінятися новинами або апдейтами по компанії або відділу. Критерії ефективного one-on-one: регулярність; якісна підготовка — як із боку менеджера, так і з боку співробітника; відкритість — на чекпойнті можна обговорити все, що турбує. Не забувайте делегувати Бізнес — командний спорт, тому ви маєте постійно розвивати співробітників та робити їх сильнішими. Делегування задач — один з ефективних інструментів для цього. До того ж делегування вдосконалює структуру компанії та додає працівникам більше мотивації. Керівник, своєю чергою, не витрачає час на поточні задачі, а може зосередитись на розв'язанні стратегічних питань. Замість висновків. 5 розповсюджених помилок менеджера Недостатньо чітко сформульовані цілі та критерії оцінки кожного співробітника; не звільняти low-перформерів. Це знижує загальний рівень якості роботи та вмотивованості в компанії; не приділяти увагу комунікації — як загальній, так і особистій. Іноді це здається нудним, але варто регулярно робити ці речі, бо вони впливають на розвиток компанії загалом; брак можливостей росту для співробітників (відсутність делегування, недостатнє розширення обов'язків та відповідальності). Варто приділити увагу і дійсно поцікавитись, чого хочуть ключові люди в компанії, які їх довгострокові цілі; вибудовувати структуру, базуючись лише на інтересах компанії і не беручи до уваги довгострокові інтереси співробітників. 4 книжки для менеджерів «Високоефективний менеджмент», Ендрю Гроув «Ефективний керівник», Пітер Друкер «Принципи», Рей Даліо «Ми — те, що ми робимо», Бен Хоровіц

  • 9 чесних історій про бізнес-фейли від топменеджерів Genesis, Дія, Helsi, Uklon та інших

    У жовтні 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% успіх. Мабуть, найбільша моя помилка — це спроба уникати професійних фейлів. Я досі працюю з відчуттям «відмінниці» всередині, де ти хочеш завжди все робити ідеально з першого разу, швидко та ефективно. Але це суперечить суті стартапу та інновацій, де тільки через помилки можна прийти до чогось, що змінить світ. Тому важливо помилятися, експериментувати, пробувати, але пам’ятати про свою систему цінностей, навіщо ти все це робиш.

  • Genesis-2022. Рік у цифрах і фото

    У 2022 році генезійці, як завжди, працювали над диджитал-продуктами, стежили за метриками, зустрічали нових колег в командах, проводили чек-пойнти, епізоди і тимбілдинги. У 2022 році генезійці також робили те, що не доводилось робити ніколи раніше — евакуювали родини з українських міст, донатили на ЗСУ, плели маскувальні сітки, боролися на інформаційному фронті й на реальному. Наприкінці цього складного року ми вирішили згадати, що вдалося зробити нашим командам. Найважливіші цифри і найяскравіші моменти в фотографіях — у спецпроєкті блогу Genesis. OBRIO Компанія, що розвиває власні цифрові продукти у трьох напрямах: застосунки, вебпродукти та SaaS. Як описали OBRIO свій рік: PlantIn Компанія, що розробляє застосунок-помічник для розпізнавання рослин на основі штучного інтелекту — лідер у своїй ніші у світі. Ось як провели цей рік в PlantIn: SUITSME Компанія, що розробляє однойменну мобільну фешн-гру, де кожен може відчути себе стилістом, готуючи свого аватара для участі у модних челенджах. В перші дні після релізу гра потрапила до рекомендацій Apple у 44 країнах. Як компанія SUITSME завершує цей рік: Boosters Компанія створює мобільні застосунки для вивчення мов та покращення якості сну і здоров'я. Флагманський продукт — додаток Promova. Що трапилось в компанії за рік: Lift Компанія-розробник однойменного мобільного фоторедактора на основі штучного інтелекту, що допомагає створювати візуальний контент невеликим підприємцям і диджитал-фахівцям. Рік для Lift був таким: Keiki EdTech-компанія, що розробляє застосунки та вебпродукти для дітей віком від 2 до 6 років. Сумарно продукти Keiki завантажили понад 5 млн користувачів. Головні цифри і факти про Keiki в 2022 році: Universe Компанія, що створює бізнес-утиліти та розвиває власний R&D-центр. Флагманські застосунки Universe — утиліти Translator Guru і Scan Guru, а також освітня онлайн-платформа Wisey. Чого досягла компанія за рік: GMEM Найбільша диджитал-медіакомпанія у Субсахарській Африці. Включає новинні сайти Legit.ng (Нігерія), TUKO.co.ke (Кенія), YEN.com.gh (Гана) та Briefly News (ПАР). Щомісяця понад 30 млн читачів приносять 100 млн переглядів. Як проходив 2022 для GMEM: Genesis Internal Education Напрям в екосистемі Genesis, мета якого — створити ефективну систему неперервного learning environment, з можливістю розвитку співробітників протягом всього періоду їх роботи в компанії. Команда Internal Education займається навчанням спеціалістів Genesis і організовує такі освітні проєкти: Schools/Courses, Communities, Edutainment Events. Що відбувалося у генезійських освітян: Headway Партнерська компанія Genesis, що розробляє мобільні EdTech-продукти, які допомагають навчатись мільйонам людей через лаконічний (bite-sized) контент. Освітній застосунок Headway завантажили понад 12 млн людей зі 140+ країн. Як хедвеївці розповіли про свій рік: Impulse Окремий напрямок Headway. Компанія розвиває застосунок для тренування мозку, що покращує пам’ять, увагу та логічне мислення за допомогою bite-sized ігор. Jiji Компанія, яка створює продукти електронної комерції в Африці з 2014 року.

  • 170 питань на співбесіду з JavaScript для Junior, Middle та Senior

    Ми зібрали великий перелік зі 170 питань на співбесіду з JavaScript для спеціалістів різних ґрейдів — Junior, Middle, Senior. Він охоплює такі теми як основи JavaScript, фронтенд, бекенд, безпека, архітектура та фреймворки. На технічних інтервʼю ставлять лише невелику частину питань із цього переліку, але він буде корисним для підготовки до співбесіди та допоможе виявити прогалини в знаннях. Олександр Барило, Full Stack Developer в Boosters та Микита Мачехін, Node.js Developer в OBRIO, які проводять співбесіди у своїх компаніях, поділилися, чим відрізняються інтервʼю на різні позиції. А також пояснили, для чого на співбесідах питати те, що не використовується на практиці, та чи можна обійтися без тестових завдань. > Питання для Junior Developer > Питання для Middle/Senior Developer > Що почитати, готуючись до інтервʼю Питання для Junior Developer Технічне інтервʼю зазвичай триває близько години. За цей час мають перевірити хард- і софт-скіли кандидата. Інтервʼюєри починають із базових загальних питань щодо мови програмування JavaScript, поступово ускладнюючи їх. Далі переходять до нішевих питань із фронтенду або бекенду — іноді їх ставлять різні спеціалісти. У бекенді обовʼязково перевіряють знання про бази даних, архітектуру, безпеку. У фронтенді — про HTML, CSS, JavaScript тощо. Іноді розробники жаліються, що на співбесідах питають здебільшого теорію. І частина тем вкрай рідко використовується на практиці. Але самі ці питання дозволяють визначити базовий рівень кандидата, з чим він стикався, а також його бажання приєднатися саме до цієї команди. «Рівень підготовки до співбесіди показує, на скільки кандидат вмотивований. Ти можеш бути класним розробником, але як ми це визначимо, якщо ти не можеш витратити час на підготовку до співбесіди? Смішно, але навіть коли в деяких компаніях заздалегідь скидають питання, все одно чимало кандидатів приходять на інтервʼю непідготовленими — ділиться Олександр Барило, Full Stack Developer в Boosters. — Також теоретичні питання допомагають запобігти неприємним сюрпризам, коли ви найняли джуна, а він не знає, що таке система контролю версій (а це має знати кожен розробник)». Закінчує інтервʼю блок запитань з технологічного стека, з якими працює компанія. «Ця частина інтервʼю дуже відрізняється в кожній компанії. Але навіть, якщо кандидат не ідеально знає деякі фреймворки — це те, з чим він може розібратися під час онбордингу. Чим більш кастомні питання, тим меншу вагу вони мають» — пояснює Микита Мачехін, Senor Node.js Developer в OBRIO. Основи JavaScript 1. Що таке оператор &&? 2. Для чого використовується оператор ||? 3. У чому різниця між операторами == та ===? 4. Для чого використовується оператор "!!"? 5. Що таке use strict і як використовується? 6. Що таке тернарний оператор? 7. Для чого використовуються оператори break і continue у JavaScript? 8. У чому різниця між spread- та rest-оператором? 9. Навіщо використовується оператор new? 10. Навіщо служить оператор for... in? 11. Чому результатом порівняння двох однакових обʼєктів є false? 12. Що таке область видимості (Scope)? 13. Що таке arguments? 14. Що таке шаблонні літерали Template Literals? 15. Як визначити наявність поля в обʼєкті? 16. Як можна клонувати обʼєкт? 17. У чому різниця між var, const та let? 18. Що таке клас у JavaScript? 19. Чим клас відрізняється від обʼєкта JS? 20. JavaScript – це типізована мова? 21. Як визначити, чи заморожено обʼєкт? 22. Як перевірити, чи є число кінцевим? 23. Що робить метод eval()? 24. Що таке NaN? Як перевірити, що змінна дорівнює NaN? 25. Що таке деструктуризація? 26. Як перевірити, чи існує підрядок у рядку? 27. Що таке тимчасова мертва зона? 28. Для чого призначені методи setTimeout та setInterval? 29. Що таке типи посилань? 30. У яких випадках застосовуються анонімні функції? 31. Що повертає promise? 32. У чому відмінність promise від callback? 33. У чому різниця між атрибутами та властивостями? 34. Що таке файли cookie у JavaScript? 35. У чому різниця між localStorage, файлами cookie та sessionStorage? 36. Яка різниця між параметрами та аргументами? 37. Що таке деструктуризація обʼєкта (Object Destructuring)? 38. Що таке модулі (Modules)? 39. Що таке обʼєкт Set? 40. Що таке параметри за замовчуванням (Default Parameters)? 41. Що таке обʼєктна обгортка (Wrapper Objects)? 42. Що робить конструкція try...catch? 43. Що таке XSS? 44. Навіщо використовується WeakSet? 45. У чому різниця між Set та WeakSet? 46. Які методи доступні у WeakSet? 47. Навіщо використовується WeakMap? 48. У чому різниця між Map та WeakMap? 49. Які методи доступні у WeakMap? 50. Що таке рекурсія? 51. Навіщо використовується метод seal()? 52. У чому головна відмінність методів Object.keys(), Object.values() та Object.entries()? 53. Що таке ціль події чи цільовий елемент (event.target)? 54. Що таке поточна мета події (event.current Target)? Дані 55. Які існують типи даних у JS? 56. Що спільного між null та undefined? 57. У чому різниця між undefined та is not defined? 58. Розкажіть коротко про Symbol? 59. Що таке JSON? 60. Що робить JSON.stringify()? 61. Методи перетворення простих примітивних типів даних в число? 62. Як можна клонувати масив? 63. Як перевірити, чи є обʼєкт масивом? 64. Як можна додати елемент на початок і в кінець масиву? 65. Назвіть методи масивів (які згадаєте)? 66. Знайти перетин двох масивів? 67. Як можна викликати методи масиву на arguments через call, apply? 68. Як би ви реалізували метод Array.prototype.map? 69. Як би ви реалізували метод Array.prototype.filter? 70. Як би ви реалізували метод Array.prototype.reduce? Функції 71. Що таке IIFE або Immediately Invoked Function Express? 72. Що таке функції найвищого порядку (Higher Order Functions)? 73. У чому різниця між function expression та function declaration? 74. У чому різниця між class і function constructor? 75. Що таке Hoisting? 76. Як використовується метод Function.prototype.apply? 77. Як використовується метод Function.prototype.call? 78. Як використовується метод Function.prototype.bind? 79. Що таке this? 80. Що таке функція зворотного виклику (Callback Function)? 81. Що таке замикання (Closures)? 82. Навіщо потрібна функція fetch? 83. Як організувати інкапсуляцію через замикання? 84. Що таке чиста функція? 85. У чому різниця між звичайною функцією та функціональним виразом? 86. Що таке Arrow Functions? Фронтенд 87. Що таке Document Object Model? 88. Які теги зʼявились в HTML5? 89. Як відбувається центрування блоку по вертикалі? 90. Назвіть погані практики в HTML? 91. Що таке BEM? 92. Які існують способи CSS оптимізації? 93. Що таке Media Queries? 94. Що таке Box Object Model? 95. Поясніть, що таке псевдокласи (first-child, last -child, active, checked), псевдоелементи (before, after) та псевдоселектори (hover)? 96. Що таке calc, vh, vw, rem, em? 97. Які ви знаєте способи організації трьохколоночного лейаута? 98. Що таке Flexbox? 99. Для чого потрібні margin, padding, positioning? 100. Що таке Float? 101. Що таке Sticky footer та footer always on bottom? 102. Що таке поширення події (Event Propogation)? 103. Що таке спливання події (Event Bubbling)? 104. Що таке занурення події (Event Capturing)? 105. У чому різниця між методами event.preventDefault() та event.stopPropagation()? 106. Як дізнатися про використання методу event.preventDefault()? React 107. Що відбувається, коли ви викликаєте setState? 108. Що таке refs в React? 109. Що таке keys в React та в чому їхнє значення? 110. У який момент життєвого циклу застосовуються запити AJAX і чому? 111. Опишіть, як в React обробляються події? 112. Який другий аргумент можна опціонально передавати в setState і як це зробити? 113. Як правильно звернутись до поточного стану при виклику setState? 114. Яку задачу вирішує React? 115. Як організовується потік даних у React через дерево компонентів? Питання для Middle/Senior Developer Питання для спеціалістів рівнів Middle та Senior зачіпають здебільшого ті самі теми, але стосуються більше досвіду кандидата, під які завдання він заточений, чи розуміється на архітектурі. Хард-скіли для обох ґрейдів визначають приблизно однаковими запитаннями. Межа між ними досить розмита, хоча від сеньйора очікують глибших знань та комплексних рішень, які можуть легко масштабуватися. Загалом різниця між цими ґрейдами — скоріше в софт-скілах, вміння керувати командою тощо. «Ми моделюємо ситуації й питаємо, як би він виконав те чи інше завдання — реалізував якусь функціональність, побудував логіку відновлення пароля, налагодив взаємодію з фронтом, взаємодію з сервісами (Facebook, TikTok). Відповіді дадуть зрозуміти, чи може людина під ключ розвʼязати конкретну задачу» — каже Микита Мачехін. «Замість тестових завдань, які ніхто не любить виконувати, ми часто проводимо простий лайфкодінг. Здебільшого це приклад коду та питання: що відбудеться? Такий підхід показує стресостійкість кандидата, як він поводить себе, коли помиляється. Одразу видно його сильні та слабкі сторони. Є ряд задач від простих до складних, які дають можливість подивитися, як кандидат мислить» — ділиться Олександр Барило. Загальні питання 116. Що таке Event Loop? 117. У чому різниця між forEach і map? 118. У чому різниця між оператором «in» та методом hasOwnProperty? 119. У чому різниця між proto та prototype? 120. У користувача вимкнено JavaScript у браузері. Як ми запустимо код у його браузері? 121. Чому type of null повертає object? Як перевірити, чи є значення null? 122. Що таке currying в JS? 123. Що таке promise object, promise methods? 124. В чому різниця між Gulp та Grunt? 125. Що таке module bundlers? 126. Як ви використовуєте GIT? 127. Що таке Vanila JS? 128. Чи є використання унарного плюса (оператор "+") найбільш видним способом перетворення рядка на число? 129. Що таке CORS і для чого він потрібен? 130. Чим відрізняється поведінка isNaN() і Number.isNaN()? 131. Чим async/await відрізняється від Promise? 132. Чому obj.someprop.x призводить до помилки? 133. У чому різниця між явним та неявним перетворенням чи приведенням до типу (Implicit and Explicit Coercion)? 134. Як перевірити, чи є значення масивом? 135. Як перевірити, що число є парним, без використання поділу по модулю чи поділу із залишком? 136. У чому різниця між методами Object.freeze та Object.seal? 137. Які прийоми роботи з асинхронним кодом у JS знаєте? 138. Що таке запамʼятовування чи мемоізація (Memoization)? Коли її варто використовувати? 139. Як би ви реалізували допоміжну функцію запам'ятовування? 140. Як видалити дублікати з масиву? 141. Як перевірити, що обʼєкт порожній? 142. У чому різниця між обʼєктом та мапом у JS? 143. Чи є req, потрібно додати наскрізне поле, як? 144. Як працювати з вбудованими Node.js функціями реалізованими через callback інтерфейс в async/await стилі? 145. Розкажіть про досвід налаштування інструментів Webpack, Jest, Eslint? Бази даних 146. Припустимо в базах даних зберігається список товарів, їх вартість та категорія. Як швидко для кожного товару отримати його порядковий номер у його категорії у списку вартості? 147. Допустимо до нашої моделі для кожного товару додається рік та місяць його постачання. Як отримати суму вартості всіх товарів у всіх можливих розрізах – категорія, рік постачання, місяць постачання? 148. Навіщо потрібна нормалізація? 149. У якому порядку бази даних видають записи з таблиці? 150. Яка структура даних дозволить індексувати географічні дані? 151. Чи можна використовувати Kd tree для трьохмірного простору? 152. Різниця між WHERE and HAVING 153. Припустимо, що клієнти стали дуже довго чекати відповіді від сервера. Існує припущення, що проблема з продуктивністю БД. Як перевірятимеш цю гіпотезу? 154. Які подальші дії робитимеш? 155. Як працює Garbage Collector? Безпека 156. Як швидко дізнатися, що в якомусь із пакетів, які ми використовуємо в проєкті, виявлена вразливість безпеки? 157. Паролі в базах даних: шифруються, кодуються чи хешуються? 158. Чи підійде, наприклад, SHA256 для шифрування паролів? 159. Припустимо, у нас використовується застарілий алгоритм хешування для паролів, нам потрібно оновити це на новий алгоритм. Як це зробити? 160. Чи можна робити прехеш паролів перед тим, як хешувати їх через KDF? 161. TLS – як працює, як підтверджується кореневий сертифікат? 162. Яка проблема може виникнути, якщо ми використовуємо порівняння секретних даних, збережених у нас? Архітектура 163. Назвіть основні принципи ООП? 164. Які ви знаєте патерни ООП у програмуванні? 165. В чому різниця між implements та extends? 166. В чому різниця між інтерфейсом та абстрактним класом в Typescript? Live code 167. Є асинхронний метод, який повертає масив даних. Як отримати тип цих даних? 168. Що виведе цей код? 169. Як переписати код, щоб він вивів true? 170. Чи можливе використання implements ? Що почитати, готуючись до інтервʼю JavaScript. Детальне керівництво, Девід Фленаган Сучасний JavaScript для нетерплячих, Кей С. Хорстман JavaScript з нуля, Кірупа Чіннатамбі Як влаштований JavaScript, Дуглас Крокфорд Розробка на JavaScript, Адам Д. Скотт {Ви не знаєте JS} Замикання та обʼєкти, Кайл Сімпсон Javascript і jQuery. Інтерактивна веброзробка, Джон Дакетт JavaScript. Шаблони, Стоян Стефанов Виразний JavaScript. Сучасне вебпрограмування, Марейн Хавербеке Рефакторинг коду на JavaScript: поліпшення проєкту існуючого коду, Мартін Фаулер The Joy of JavaScript, Luis Atencio JavaScript Cookbook, Adam D. Scott, Matthew MacDonald, Shelley Powers jQuery. Докладне керівництво по просунутому JavaScript, Бер Бібо, Ієгуда Кац

  • Із адвокатів – у диджитал-бізнес. Як світчнутись у продакт-менеджмент і не пожалкувати про це

    Ще декілька років тому Юлія Гур’єва мала успішну юридичну кар’єру в Україні. За короткий час вона змінила місце проживання, професію та стиль життя. Спеціально для блогу Genesis Юлія написала колонку про свій шлях від адвоката до продакт-менеджера в IT та про досвід навчання в School of Digital Business by Genesis & SET University & KSE. Це курс зі створення цифрових продуктів для усіх, хто почав або збирається почати кар’єру в продуктовому IT. В його межах топменеджери Genesis, а також викладачі закладів вищої освіти розповідали, як перетворити ідеї в план дій та створити ефективну модель бізнесу. Як сеньйор стає джуном Нещодавно я з родиною переїхала з України до Швейцарії, і спочатку планувала продовжити свою юридичну кар’єру там. У Києві в мене був адвокатський офіс, великий досвід роботи у сфері legal, напрацьовані клієнти та нетворкінг. Мені подобалось те, що я роблю, і я не хотіла це втрачати, тож я не можу сказати, що я світчнулась через те, що стара професія мені набридла або я була чимось не задоволена. Проте з юриспруденцією довелось попрощатися із декількох причин. По-перше, щоби працювати адвокатом у Швейцарії, я мала знову вступати на юридичний факультет у місцевому університеті, п'ять років вчитися, потім два роки стажуватися. Мені здалося дивним сім років йти до того, щоби знов стати джуном у своїй сфері. По-друге, я дуже люблю подорожувати, і мені важливо не бути прив'язаною до постійної локації через роботу. Вибір був досить очевидним — IT-сфера дає можливість бути мобільним, змінювати країни, не змінюючи роботу і спосіб життя. Я почала з досить стандартного шляху, спробувала програмування: вивчила HTML, почала опановувати JavaScript. У той час мій чоловік, що теж працює в IT, надіслав мені лінк на онлайн-школу продакт-менеджменту, мовляв, і таке в цій індустрії є. Так почалось моє навчання. Спочатку я взагалі нічого не розуміла — незнайомі терміни, хто такий бекенд, фронтенд, я гуглила терміни майже в кожному реченні. Але поступово почала розбиратись і зрозуміла, що мені дуже цікаві задачі продакт-менеджера. Ба більше, це насправді дуже схоже на роботу адвоката. Дослідження ринку, які роблять продакти, схожі на те, з чим стикаються юристи. Закони України цікаво корелюються із законодавством європейських країн. Коли я не могла знайти, як розв'язати своє питання за допомогою українських законів, шукала схожі практики в рішеннях Європейського суду, а потім йшла і «пітчила» це судді. Бізнесове мислення адвокатам теж вкрай потрібне, оскільки правовий шлях часто розтягується на довгий термін, під час якого бізнес-процеси клієнта будуть заморожені, прибуток падатиме. Іноді буває так, що якщо клієнт на 100% правий, але доведення цієї правоти займе три роки заморозки активів, то чи не краще шукати компроміс? Для цього теж потрібно вміти рахувати метрики, розуміти value, вміти пояснювати складні речі простою мовою, домовлятись і мати купу інших софт- і хард-скілів. Після навчання в онлайн-школі продакт-менеджменту я потрапила на стажування в ірландську компанію Bookmate, що розробляє досить популярний у світі застосунок для читання книг. На роботу до них я не потрапила, але вони дали мені класний фідбек, це надихнуло мене йти далі. Спочатку я працювала як продакт-фрилансер, робила кастдеви та дослідження ЦА для онлайн-шкіл. Згодом мене покликали проводити кастдеви для застосунку графічного редактора. Їм сподобалась моя робота, і вони покликали мене на фултайм. Genesis Product School мені порадив друг продакт-менеджер. Він сказав, що кращого місця для розвитку джуніора не знайти. Перша моя спроба вступити до школи провалилася. Коли я відкрила завдання першого етапу відбору, то зрозуміла, що не знаю жодної відповіді. Я юрист за освітою, і звісно, ніколи не вчила вищу математику. На другий набір я підготувалась краще — як мені здавалось. Тоді набрала 50% правильних відповідей на першому етапі, пройшла на другий, а там — задачі з відкритими питаннями. Знову невдача. Я з тих людей, хто не звик відступати. Тому я домовилась про заняття із двома викладачами з вищої математики, і все літо присвятила вивченню цього предмета. І вже до третього набору була впевнена у своїх силах. Так стала учасницею School of Digital Business by Genesis & SET University & KSE. Погляд із метаконтексту Чому я так наполегливо намагалася потрапити до генезійської школи? Мені як джуну в продакт-менеджменті подобається екосистемний підхід компанії. Коли це розгалужений холдинг із багатьма проєктами — ти маєш змогу рости й учитись всередині закритої системи. Наприклад, проводиш тести, потім можеш проконсультуватись із колегами з інших проєктів, запитати, обмінятись думками. Це пришвидшує твій розвиток та навчання. Я звикла до шаленого темпу, мені все цікаво, хочеться швидше розбиратися, вивчати нове — цей ритм мені підходить. Від початку навчання у мене було відчуття, що маю достатньо досвіду, я все ж таки не новачок, а стронг-джун, щось вмію. Почала слухати лекції й зрозуміла, що я насправді нічого не вмію. Підхід у школі був ґрунтовний, і починався він з аналізу ринку. Взагалі то я розумію, які задачі маю виконувати як продакт-менеджер, але я ніколи не дивилась на це з ширшої позиції. Цінність школи для мене в тому, що лектори виводять учасників в метаконтекст, показують, як твоя робота впливає на роботу інших колег у команді. Раніше я взагалі не думала про те, що продакти якось впливають на ринок. Думала, що десь там є абстрактний ринок, у ньому є певна ніша, і я просто роблю шматок своєї роботи, щоб продукт міг існувати у цій ніші. Виявилось, що ринок не існує у вакуумі, там є певні тенденції, і коли ти їх починаєш відстежувати, можеш їх схопити першим і принести додаткову цінність та успіх своєму продукту. Окрім лекцій та домашніх завдань, у нас був основний проєкт, над яким ми працювали у «сімках» — кожна команда мала розробити концепцію диджитал-продукту. Ми з колегами працювали над проєктом у сфері mental health. У нас було декілька версій продукту: ми почали як проста no-code платформа з контентом, потім вирішили зробити півот у платформу з коучами. В результаті до захисту ми набрались сміливості і досвіду, щоби запропонувати маркетплейс для фахівців із психологічного здоров’я. Своєрідний Uber для психологів. До фінального захисту проєкту ми мали декілька попередніх презентацій для лекторів школи. Наші напрацювання серйозно критикували, лектори не давали розслабитись і ставились до нас не як до групи новачків, а як до потенційних стартаперів — питання були такими, які зазвичай ставлять інвестори. Відверто говорили, якщо презентація та пітчинг були слабкими. Звісно, саме це покращило наш потенційний продукт. У школі була доступна опція «спитати у лектора», і я активно її використовувала — багато писала лекторам із питаннями у соцмережах. Це виявилось дуже цінно — можливість звернутися за порадою або допомогою з фінальним проєктом до людини, яка пройшла той самий шлях із реальним продуктом. Коли наша команда десь буксувала, лектори завжди приходили на допомогу. Я б сказала, вони були й менторами для нас у цей період. Чотири головних інсайти, що я отримала на School of Digital Business Ринок — це основа Студенти юридичного факультету мають вивчати філософію, і зазвичай не розуміють навіщо це їм потрібно. Те, що філософія важлива, вони усвідомлюють через роки юридичної практики. Те саме із вивченням ринку для продакт-менеджерів. До навчання в школі аналіз ринку здавався мені чимось не дуже важливим, хоча й обов’язковим. Виявилось, що саме грамотне вивчення ринку безпосередньо впливає на продукт і на його розвиток. Відповідальність за продукт — на всіх членах команди Мало просто зробити продукт, який працює. Навіть якщо ти продакт, а не фаундер або СЕО, тобі теж важливо розуміти, як правильно пітчити, залучати інвестиції. Формально це не входить в мої обов'язки, тому залишалося поза зоною уваги, але я зрозуміла, що це потрібно всім, хто дотичний до продукту. Отримати інформацію можна навіть із найнеочікуваніших джерел Раніше мені здавалося, що дані про поведінку користувачів і, наприклад, конкурентів, можна дізнатися з обмеженої кількості джерел: публічних звітів, відкритої інформації в мережі тощо. Насправді варіантів безліч. Головне – проявити креативність. Можна навіть тимчасово влаштуватися на роботу до конкурентів, чому ні? Ця творчість і пошук нових шляхів у професії мене надихає. Публічний виступ/пітч має утримувати увагу слухачів весь час Під час занять мене вразило, як лектори утримують увагу студентів. Найцікавіші приклади в презентаціях я навіть скринила. До прикладу, один спікер, розповідаючи про високі й низькі конверсії, проілюстрував тезу картинками з двома кониками — один приплюснутий, другий високий. Останнє, що очікуєш на лекції про конверсії, — це коники. Такі несподівані речі запам’ятовуються. Інший спікер почав лекцію з вправи для студентів — ми з іншими учасниками дуже активно дискутували, коли її вирішували. Це все мотивує слухати й шукати для себе якісь приклади — як я можу утримувати увагу аудиторії, якій мені потрібно буде запітчити продукт або фічу. Школа мене змінила. За такий короткий час я отримала практичного досвіду більше ніж за рік роботи, і це неоціненно. Школа і лектори постійно повертали увагу студентів саме до суті бізнесу, до того, що ми будемо фактично робити з продуктом. Це не просто навчання з дипломом у фіналі, а занурення у фултайм-роботу над реальним продуктом, з реальними метриками, без милосердя і жалю, все по-дорослому. Звісно, не планую зупинятися на досягнутому. Навчання стало звичкою, я побачила свої слабкі місця і почала над ними працювати.

  • Підготовка до Google Core Updates. Як відновити трафік та знайти точки зростання

    Кілька разів на рік Google вносить масштабні зміни в пошукові алгоритми — Google Core Updates. Ці оновлення призначені для того, щоб Google міг виконувати свою місію — надавати користувачам корисні та надійні результати пошуку. Але для SEO-фахівців ці оновлення — виклик. Адже в результаті сайт може перестати ранжуватися, а всі метрики — «впасти» в рази. Якщо не адаптувати сайт до нових алгоритмів, після наступних оновлень він може «просісти» ще більше. Ніна Ромащенко, SEO Content Team Lead в медіахолдингу GMEM, який входить до екосистеми бізнесів Genesis, пояснює, як працюють ці оновлення, що робити в кризовій ситуації та як стати ресурсом, який «полюбить» Google. Ніна очолює SEO-команду, яка займається просуванням контенту на ринках Субсахарської Африки, де проєкти GMEM є лідерами, а також Tier-1. > Як працюють Google Core Updates > EAT, YMYL та інші патерни — як їх шукати > Чому не можна нехтувати змінами. Історія сайту, що «впав» удвічі > Що робити після релізу Google Update: алгоритм дій Як працюють Google Core Updates Насправді Google постійно оновлює алгоритми, щоразу повідомляючи про це на офіційному сайті. Найбільші з них — Core Updates, які відбуваються приблизно раз на квартал. Зазвичай вони тривають близько двох тижнів. Протягом цього часу видача може бути нестабільною, а позиція сайту та інші метрики — різко коливатися. Перш ніж робити висновки, варто зачекати, коли оновлення завершаться та ситуація стабілізується — приблизно за місяць. Один зі способів зрозуміти, як працює Core Update, — уявити, що ви написали статтю «15 найбагатших реперів 2021 року». 2024 року цей список уже не буде актуальним, тому алгоритм виведе в топ свіжішу статтю конкурента. Основний результат Google Core Updates — пониження у видачі сайтів із менш корисним контентом. Йдеться про ресурси, де мало унікальних текстів, вони застарілі або сумнівної якості, є спам. Але навіть якщо ваш сайт — взірець актуального та корисного контенту, він також не застрахований від погіршення ранжування. Загалом Google подає ці зміни, як налаштування, які не фокусуються на якомусь конкретному контенті. У реальності, можна припустити, що є певна кореляція щодо тематик, які зачіпає Google Update — YMYL-контент та сторінками, які порушують Publisher Policies, Publisher Restrictions та стандарти EAT. EAT, YMYL та інші патерни — як їх шукати Стандарти EAT — експертиза, авторитетність та надійність. За ними Google оцінює всі сторінки та визначає, які з них показати у видачі першими. YMYL-контентом (Your Money or Your Life) називають той, що може потенційно вплинути на життя користувача: його здоровʼя, фінансовий стан, безпеку тощо. Наприклад, до 2018–2019 року можна було вільно писати статті на теми фінансів чи медицину. Зараз Google сприймає їх як потенційно небезпечний контент. Тому варто уникати таких тем, якщо у вас немає авторитетних авторів-експертів. Старі статті краще видалити або оновити сторінки авторів — це дасть сигнал пошуковій системі, що вони мають експертизу в такому контенті. Відповідність стандартам EAT та використання тем YMYL — перше, що SEO-фахівці аналізують після оновлень. Усі інші патерни вони мають знайти самостійно — вивчати дані (свої та конкурентів), слідкувати за спеціалістами. Наприклад, Лілі Рей, Senior Director of SEO в Amsive Digital проаналізувала оновлення у вересні 2022 та визначила Winner/Losers. Так, оновлені алгоритми сильно «посадили» сайти, на яких можна завантажити музику. Також сильно постраждали новинні сайти — наприклад, такі світові медіа як Bloomberg, CNN або WSJ. Сумарно вони втратили понад 137% трафіку. Новинний контент входить до категорії YMYL, який Google сприймає як той, що потенційно може впливати на життя людей. Чому не можна нехтувати змінами. Історія сайту, що «впав» удвічі Якщо йдеться про великий сайт, то падіння навіть у декілька відсотків може суттєво позначитися на кількості користувачів та сесій, у результаті чого втрачається заробіток. Тому щоразу по завершенню оновлень SEO-спеціалісти намагаються зрозуміти, чому все «впало» на цей раз, і якнайшвидше виправити помилки, готуючись до наступних оновлень. Фактично це постійна гонитва нон-стоп: якщо не встигнеш виправити наслідки минулого оновлення, під час наступного ваш сайт може «впасти» ще більше. Так, один із сайтів із групи GMEM значно просів під час апдейту в кінці 2021 року. Ми проаналізували причини та визначили план дій. Але через російську агресію були зайняті операційними завданнями, тому не встигли адаптувати сайт до нових алгоритмів. Через це падіння продовжилося. Ми витратили близько девʼяти місяців, щоб зупинити спадний тренд. Після вересневого оновлення Google нас «пробачив», почалося поступове зростання до рівня січня 2022. Але не завжди оновлення спричиняє падіння. Трапляється, що змін майже немає. А іноді сайт починає швидко зростати. Наприклад, стаття раптом з 13 місця у видачі піднялася на друге, тому що Google вирішив, що ви — авторитетніші, ніж конкуренти. У цьому випадку варто шукати точки зростання, аналізуючи конкурентів. Що робити після релізу Google Update: алгоритм дій 1. Формування гіпотез Незалежно від того, виріс трафік після апдейту чи впав, важливо проаналізувати зміни та визначити, що їм передувало. Аналізуємо: Загальну органіку. Органіку за країнами. Якщо ви таргетуєте різні ринки, наприклад, Африку та Tier-1, може трапитися зростання в Африці та водночас просідання на Tier-1 і навпаки. Органіку за категоріями. Визначаємо, які тематики просіли найбільше. Позиції конкурентів. Як у дослідженні Лілі Рей, визначаємо «переможців» та «невдах» оновлення, а також конкурентів, у яких не відбулося змін. «Невдахи» допоможуть вам остаточно визначити, яких тем варто уникати, а «переможці» та стабільні конкуренти — знайти точки зростання. Для побудови гіпотез варто також стежити за передовими SEO-спеціалістами. Блоги, YouTube-канали, твіттер — одні з основних джерел натхнення після Google Update. 2. Аналіз контенту на відповідність EAT-стандартам Чекліст для визначення якості контенту: Чи надаєте оригінальну інформацію, звіти, дослідження, аналіз? Вичерпний опис теми? Якщо контент спирається на інші джерела, чи уникає він простого копіювання або переписування цих джерел і натомість забезпечує істотну цінність та оригінальність? Надає глибокий аналіз чи цікаву інформацію, яка не є очевидною? Чи передає заголовок зміст сторінки? Чи не є перебільшенням або клікбейтом? Чи є в статті граматичні/стилістичні помилки? Чи є ваш контент копірайтом інших наявних у видачі сторінок конкурентів? Чекліст для визначення експертності: Чи надаєте чіткі джерела, докази експертизи, довідкові відомості про автора чи сайт, який його публікує, наприклад, через посилання на сторінку автора чи інформацію про сайт? Чи можете ви назвати себе авторитетними в цій темі? Чи написав цей контент експерт або спеціаліст, який добре знає тему? Чи містить контент будь-які фактичні помилки, які легко перевірити? Чи зачіпаєте YMYL-теми? Якщо так, чи достатньо ви авторитетні для цього? Більше питань для перевірки можна знайти на офіційному сайті Google. 3. Аналіз сторінок на зворотні посилання та основні метрики Чи є на цих сторінках зворотні посилання? Якої вони якості? Спамні чи ні? Чи збирають ваші сторінки Clicks та Impressions? 4. Розставлення пріоритетів та імплементація Сформувавши беклог завдань, розділіть їх за типом (Tech SEO, Content), командою (DevTeam, SEO, Content Team), пріоритетністю та часом на реалізацію. До наступного апдейту важливо виконати найважливіші завдання, щоб мати шанс зупинити падіння. Тому краще почати роботу з найбільш пріоритетних завдань із короткими/середніми термінами реалізації. Що далі Найпоширеніше питання — скільки часу потрібно для відновлення після Core Update? Щоби побачити зміни в трафіку, треба чекати новий Core Update за 3–6 місяців. Google також проводить невеличкі оновлення без анонсів, які можуть допомогти повернути трафік. Але зазвичай зміни після таких оновлень ледь помітні. Майте на увазі, що внесені зміни не є гарантією відновлення. Якщо в конкурентів кращий контент, він і надалі матиме високі позиції в Google. Що робити, якщо Google Update анонсували, а ви нічого ще не імплементували? Уникайте необміркованих рішень. Коли починається процес оновлення, від вас нічого вже не залежить, оскільки до уваги беруться зміни, здійснені як мінімум за місяць до цього. Дочекайтесь кінця апдейту. Поки оновлення не будуть до кінця імплементовані, не варто робити передчасних висновків. А тепер плануйте. Час приступати до аналізу змін та шукати патерни. Отже, алгоритми Google постійно навчаються, світ змінюється, як і фокус апдейтів. Періодичне падіння трафіку після оновлень — нормальне явище. Ваше завдання — мінімізувати ризики та працювати комплексно: постійно слідкувати за трендами, знаходити вузькі місця проєкту. Оскільки відповідність EAT-стандартам — це один з основних сигналів для алгоритму, недостатньо писати якісний контент та зробити технічно оптимізований сайт. SEO-спеціалістам треба заглиблюватися в роботу інших команд та посилювати бренд. І на останок — критично мислити: correlation is not causation. Ресурси та SEO-спеціалісти, за якими варто слідкувати під час Google Core Updates: Блог Google Moz Блог Ahrefs Backlinko Bruce Clay Ryan Darani Search Engine Journal Barry Adams Brian Dean John Shehata Lily Ray Cyrus Shepard Aleyda Solis John Mueller Koray Gubur

bottom of page