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

Питання грамотного менеджмента, балансу між хард- і софт-скілами, та професійного підходу до побудови процесів всередині команди хвилюють лідів усіх напрямків. Нещодавно на мітапі у MacPaw Space зустрічалися QA-ліди великих українських продуктових компаній. Керівники з AMO, Quarks, MacPaw і Uklon обговорювали найбільш гострі теми, що стосуються управління напрямом тестування. Найцікавіше із доповідей спікерів — у нашому конспекті. > Помилки QA лідів > Горизонтальна система керування тестуванням > Місія, візія і фейли > Комплексний підхід до проведення співбесід Помилки QA лідів Помилка перша. Найняти не ту людину Якщо ви єдиний QA-фахівець на проєкті, і маєте бюджет на другого спеціаліста, то саме ви будете тим, хто найматиме його. Що може піти не так? Людина виявиться не підходящою. По-перше, я б радив найняти ту людину, з якою вам особисто буде зручно працювати і спілкуватись. По-друге, ґрейд нового фахівця має відповідати вашому. Так колега зможе замінити вас у виконанні будь-якої таски за необхідності. Помилка друга. Неправильне планування Якщо ви долучаєтесь, наприклад, до великого проєкту, і вам потрібно найняти вже не одного, а 3-10-15 тестувальників, то проблема може виникнути інша. Нагірше, що може статись, — неправильно сплановане навантаження і невірно визначена кількість людей, яких потрібно найняти та який у них має бути ґрейд. Якщо ви не впевнені, що зможете все грамотно розпланувати, варто звернутись по допомогу до менеджера з досвідом. Помилка третя. Радикальні зміни Якщо ви приходите в уже сформовану команду як QA-лід, можлива помилка — одразу намагатись змінити усі процеси і підходи, які були налаштовані до вас. Спочатку покращуйте щось лише точково і спостерігайте, як все працює. Окрім цього, я б радив провести one-to-one з кожною людиною з команди, спитати її думку — що заважає, що допомагає, що можна покращити. Так ви зможете зібрати основні проблеми, пріоритезувати їх, і вже потім планувати зміни. Помилка четверта. Страх делегування обов'язків Як зрозуміти, що у вас проблеми з делегуванням? Ви ловите себе на таких думках: «лише я знаю, як краще». Пам'ятайте що, на жаль, лід із більшою ймовірністю втрачає технічні навички, тому ваші колеги скоріш за все, знають краще, що треба робити. «без мене все зламається». Це означає, що ви не довіряєте команді повністю. Такий підхід може спричинити «тепличні» умови для команди, коли лід все «розрулює». Ймовірніше, за таких умов команда припинить розвиватися. Помилка п’ята. Мікроменеджмент Мікроменеджмент — це руйнівне управління, від якого страждають усі сторони. Основна задача ліда — дивитись на ситуацію дещо відсторонено, згори, щоби прийняти максимально релевантне рішення. Вам не потрібно вирішувати проблеми за людей, бо це не закінчується ніколи. Часто мікроменеджмент виникає через недовіру до фахівців. Коли ви починаєте дуже сильно контролювати кожен крок спеціалістів, то витрачаєте свій час неефективно та заважаєте їм виконувати свої прямі обов’язки. А у людей від надмірного контролю з'являється відчуття, що вони не справляються, і їх перформанс ще більше просідає. Помилка шоста. Неприйняття рішень Мозок людини працює таким чином, що якщо якусь проблему довго не вирішувати, то починає здаватися, що вона якось вирішиться сама. Головна помилка — коли не приймаються рішення, що вже давно назріли. Як переформувати команду, і чи варто це робити, як відмовитись від певного фреймворку чи підходу до тестування, які ще наче працюють, але вже застарілі, чи варто підвищувати людину в посаді та зарплатні, чи варто звільняти людину, чи вона може змінитись і адаптуватись до вимог проєкту і компанії, чи варто назначати черговий мітинг чи можна обійтись електронною поштою? І ще мільйон різних запитань. Головний обов'язок ліда — прийняття рішень. Якщо вам здається що ваші рішення — неправильні або не найкращі, скоріше за все, ви на вірному шляху, тому що це свідчить про те, що ви рефлексуєте над ними. Інколи варто просто прийняти рішення, подивитись його на результат, відкоригувати за необхідності та рухатись далі. Горизонтальна система керування тестуванням Концепція гільдій Ще коли я лише починав працювати, мене дивувало, що в IT-галузі іноді на одного інженера — два або й більше менеджерів. Нині, в якості ліда, я потроху формую бачення, як зробити так, щоб це нормально працювало. В Quarks структура влаштована таким чином: є три великі команди — продуктова, маркетингова і tech team. В межах перших двох команд у нас є декілька автономних кросфункціональних тімок. Що вони собою представляють? Це команда, де є PM, який вирішує, що робити, які таски тощо. Також там є технічні спеціалісти: аналітики, дизайнери, фронтенд- та бекенд-фахівці, QA. Ще є команда tech team, якою керує CTO. В ній окремо є DevOps, сервісні команди, а також фронтенд,- бекенд- і QA-ліди. Я в якості QA-ліда керую як своєю командою автомейшена, так і по горизонталі всім QA-напрямком нашої компанії. Що це значить? PM в кожній кросфункціональній команді вирішує завдання, пов'язані більше з продуктовим навантаженням, який функціонал буде робитись, яка буде його пріоритетність. А я більше відповідаю зе те, як саме це має бути зроблено. Таким чином QA-інженер в команді має два керівника — PM і ліда QA-напрямку. Саме тому це називається горизонтальною системою або системою гільдій. Переваги горизонтальної організаційної структури: кожною гільдією керує лід, який розуміє специфіку роботи фахівців; кросфункціональна команда орієнтується на свої результати та процеси, їй не потрібно узгоджувати свій флоу з іншими командами; PM команди сконцентрований на продуктових задачах; система «стримувань і противаг». Ніхто не керує всім одноосібно, є декілька центрів прийняття рішень, а це мінімізує ризики; більш об'єктивна оцінка перформансу технічних спеціалістів; уніфікація підходів та стеку технологій. Основні складнощі в системі гільдій Важливо, щоб PM та QA-лід працювали в унісон, розуміли один одного, або хоча б не заважали. Кожна команда має свій темп, і це певною мірою може гальмувати уніфікацію. Треба шукати компроміс між усіма учасниками, аби уніфікація відбувалася, не ламаючи процеси нікому. PM команд мають різний рівень технічних скілів. Важливо комунікувати всі свої рішення та доносити до PM, чому ми робимо саме так. Лід гільдії повинен мати прокачані технічні і комунікативні скіли, тому що більшість проблем і труднощів виникають саме через брак комунікації і досвіду у когось із команди. Основні напрямки роботи QA-ліда гільдії Постійний контроль слідування побудованому флоу тестування. Створення єдиного центра керуванням тестуванням в компанії. Комунікація та роз’яснення процесів, інструментів та всього, що стосується QA. Уніфікація підходів. Це дає змогу суттєво заощадити час і кошти. Оцінка роботи QA в командах. Місія, візія і фейли Що таке місія і чим вона вам допоможе? Місія – певне розуміння того, чим ви будете займатись на тій чи іншій посаді. Як її сформулювати? Відповісти на питання: що ви робите, як ви це робите і навіщо. З ростом і зміною ваших зон відповідальності, зміною команди або проєкту буде трансформуватись і ваша візія. Коли я був інженером, після рев’ю я отримував фідбек про те, що треба розвиватись, шукати свій шлях, вірний вектор руху і таке інше, але що саме треба робити — було незрозуміло. Коли я став лідом, я усвідомив, що це і є моя місія — створити прозорі умови для розвитку інженерів в компанії з дотриманням справедливості по відношенню до компанії. Тобто щоби не лише люди зростали, а й компанія також отримувала профіт. Візія: тримати у фокусі Якщо з місією ви працюєте кожен день, тому що це і є ваша робота, то візія — це така собі лінія горизонту, яка майорить десь далеко, але саме вона змушує вас рухатись і приймати ті виклики, які кидає вам індустрія. Як не втратити візію в рутині? Ви маєте постійно перевіряти, наскільки ваша візія відповідає візії компанії, потребам продукту, індустрії. Її треба постійно розширяти, змінювати відповідно до обставин. Маєте сформулювати те, що ваша візія має дати сьогодні, щоб ви опинились в майбутньому там, куди ви плануєте прийти. Візія — це ваше завтра. Нині моя візія як ліда — рухатися в сторону спрощення з урахуванням тої цінності для бізнесу, яку ми можемо давати як інженери. Три фейли і три уроки, що вони принесли Люди не читають думок. Коли я починав лідити команду, у мене було море ентузіазму, багато ініціатив, я хотів все змінити. Так сталося, що, проговоривши свою місію, візію із тимлідом, я не отримав апрув від своєї команди. Насправді, я навіть не розповів їм про свої ініціативи. Мені здавалось, що все всім очевидно. Тож, коли я почав впроваджувати зміни, то зіштовхнувся із нерозумінням команди. Варто детально пояснювати команді ваш план — що і для чого, створити умови, щоб вони теж могли контрибьютити і бути залученими у реалізацію цієї стратегії. Вам потрібно мати чіткий роадмеп та надавати регулярні апдейти. Будь-які зміни потребують детального планування. Одного разу до мене прийшов один з інженерів і запропонував використати новий трендовий фреймворк. Я подумав — класно. Мені здавалось що це буде корисно і для розвитку команди, і для продукту. Але сталося зовсім по-іншому. Через деякий час частина команди, яка здійснювала цей перехід, мігрувала на інші ролі або у інші продукти. Ми опинились у ситуаціі, коли ми сидимо з новим проєктом, і в нас не так багато інженерів, які можуть використовувати його для роботи. Перш ніж робити серйозні зміни, які можуть вплинути на швидкість делівері продукту, треба оцінити наскільки ці зміни актуальні і потрібні зараз, чи зможете ви знайти спеціалістів, чи зможуть вони не лише підтримувати, а і розвивати продукт. Не толерувати те, що погано працює. Спочатку я був лідом однієї команди, потім — додалась друга, потім ще і ще. В одному продукті в мене було 5 QA-команд, які були досить розрізненими. Я побачив, що такому хаосі це не буде працювати ефективно — були проблеми з документацією, процесами, підходами, із взаємодією QA між собою. Якщо бачите проблему з процесами, не тягніть із рішенням. Може статися, що люди просто не дочекаються поки ви проблему вирішите, і підуть. Також не бійтесь обговорювати проблеми прямо із командою та менеджментом. Комплексний підхід до проведення співбесід У 2021 році Uklon почала швидко зростати: збільшилися поточні команди, одночасно створювалися нові. Нам потрібні були нові фахівці. Щобільше співбесід ми проводили, тим більше бачили, що наш підхід до інтерв’ювання кандидатів не працює. В нас був шаблон розмови, зосереджений на технічних питаннях, їх зазвичай багато в інтернеті. Рішення про найм ми приймали в залежності від професійних скілів. Здавалося б логічно, але це було нашою помилкою. Люди, яких ми обирали таким чином, відмінно підходили нам за професійним рівнем, проте не співпадали ані за цілями, ані за цінностями. Тож деякий час пішов на аналіз та зміну підходу. Я почав аналізувати: що QA-інженери роблять щодня? Приймають рішення — від малих до великих: коли почати тестування, що покривати тестами, які інструменти використовувати в роботі тощо. І я прийшов до того, що підхід кандидата до вирішення завдань для нас має бути важливішим за досвід роботи. Звісно, в новому шаблоні співбесіди технічні запитання нікуди не ділися, але вони стали мати другорядне значення. Нині основний блок запитань у нас на інтерв’ю — про прийняття рішень. Кожному кандидату я пропоную уявити певну ситуацію, наприклад: Інженер взяв задачу в роботу, але її опису немає. Як це можна виправити? Підходить дедлайн релізу, але баги не закінчуються. Що робити? Інженер працює над пріоритетними задачами, але його відволікають. Як змінити ситуацію? Відповіді на такі запитання показують: чи замислювався кандидат над процесами, в яких він працює; чи раніше приймав кандидат рішення самостійно; чи він працював зі своїми помилками; чи може він нести відповідальність за себе та команду. Технічні запитання. Копайте вглиб Оскільки технічні скіли ми у будь-якому випадку маємо оцінити, то для цього блоку співбесіди теж склали декілька вимог до інтерв’юерів: Уникати заготовленого списку запитань на співбесіді. Складати кастомізований список під кандидата — його скіли, досвід тощо. Мати заздалегідь розроблені плани співбесід для кандидатів будь-якого рівня. Під час інтерв’ю орієнтуватися на сильні, а не на слабкі сторони кандидатів. Ми визначили для такі масивні розділи, які важливі для нас: мобільне тестування, бекенд тестування і веб. В залежності від потреб, від команди, куди ми берем інженера, ми можемо спитати: Технічну частину співбесіди ми починаємо тепер окремого масивного блоку — чи то мобільне тестування, чи то бекенд-тестування або веб, — в залежності від позиції, на яку наймаємо. Далі під час розмови заглиблюємося в конкретну тему і намагаємося зрозуміти все, що кандидат про неї знає. Практикуємо щирість Ми хотіли, щоби наша співбесіда не була допитом. Кандидат в стресі не може адекватно оцінити свої знання і нормально відповісти на питання. Йому має бути комфортно протягом всієї розмови. Якщо він не знає відповіді на запитання або не розуміє його належним чином, я відповідаю на це питання, тим самим показуючи йому, що я від нього очікую. Це класно налаштовує кандидата далі. Тож в новій ітерації нашого підходу до співбесід ми вирішили, що віддаємо частину контролю кандидату, аби він: розумів хід співбесіди; отримував відповіді на свої питання міг розраховувати на якісний і своєчасний фідбек. Повний запис мітапу QA-лідів дивіться тут:

Фронтенд — це легкий вхід в ІТ чи один з найскладніших напрямів розробки? Щоб розвиватися, потрібно вивчати якомога більше бібліотек, заглиблюватися в дизайн чи в патерни програмування? Чи завжди нативні застосунки кращі за веб? Мікрофронтенд вирішить усі проблеми вебзастосунку чи додасть нових? Найрозповсюдженіші міфи спростовує Микола Носенко, Front-end Developer в OBRIO з екосистеми Genesis. > Фронтенд — це легкий старт в ІТ > Робота на фронтенді складається з однотипних задач > Для розвитку потрібно вивчати більше сучасних фреймворків та бібліотек > HTML, CSS та JavaScript — це технології, які не розвиваються та не змінюються > Нативні застосунки завжди будуть зручнішими за веб > Фронтенд-девелопер має обовʼязково добре розумітися в дизайні > Сторінки та вебзастосунки стають занадто складними > Мікрофронтенд — універсальне рішення, за яким майбутнє та яке підходить усім МІФ №1 Фронтенд — це легкий старт в ІТ. Історично склалося, що початківцям легше вивчати фронтенд, аніж бекенд чи інші види розробки. Але це зовсім не означає, що цей напрям — простий. Раніше вивчення HTML та CSS було достатньо, щоби почати реалізовувати якісь проєкти. Загалом робота фронтенд-девелопера потребувала значно менше знань у програмуванні. Але щороку цей напрям ускладнюється: як інтерфейси, так і самі рішення. Джуніор уже навряд зможе знайти роботу та бути корисним на проєкті, якщо не знає JavaScript та як мінімум один із фреймворків. Бекенд — не легший і не складніший, а просто має свою специфіку. Робота з інтерфейсом командного рядка, терміналами, базами даних може здаватися занадто складною та незвичною для світчерів. Також тут неможливо отримати фідбек та побачити результат своїх зусиль так швидко, як у фронтенді, де більшість твоїх дій повʼязана зі взаємодією з користувачем. МІФ №2 Робота на фронтенді складається з однотипних задач. Насправді у фронтенд-розробника різноманітні задачі. Це не тільки створення інтерфейсів окремих компонентів або сторінок, а ще й робота з анімацією, написання автотестів, бізнес-логіки, налаштування аналітики, інтеграція нових технологій та багато чого іншого. Також це постійна комунікація з багатьма командами: дизайну, бекенду, QA, SEO, менеджерами, замовниками та іншими. МІФ №3 Для розвитку потрібно вивчати більше сучасних фреймворків та бібліотек. Часто розробники переконані, що шлях розвитку в цій сфері полягає у вивченні якомога більшої кількості бібліотек: чим більше їх знаєш, тим краще. При цьому в них залишаються прогалини у фундаментальних знаннях, без яких складно уявити подальший розвиток девелопера. Йдеться про основи та принципи програмування, парадигми, патерни — на будь-якому складному проєкті без цих основ буде дуже важко працювати ефективно. Принципи програмування допомагають краще організовувати код, робити його зрозумілим для інших розробників. Патерни — це підходи до вирішення абстрактних проблем. Більшість із них не пов'язані з конкретним доменом або сферою знань, але допомагають розуміти програмування загалом. Вміння їх використовувати допомагає позбавитися багатьох проблем, які можуть виникати в процесі розробки, та забезпечують якість коду. Маючи ці знання, фронтенд-девелопер може швидше розвиватися вертикально або ж опановувати бекенд, фулстек чи інші сфери розробки. Крім того, такі навички допомагають розробнику обирати найефективніші інструменти та бібліотеки для його потреб. МІФ №4 HTML, CSS та JavaScript — це технології, які не розвиваються та не змінюються. Це твердження абсолютно невірне. Щороку в CSS, HTML та JavaScript виправляються недоліки та додаються нові можливості. Наприклад, з найцікавішого, що з'явилося в CSS за останній час, можна виділити: @layer — нарешті дозволяє вирішити одну з найскладніших проблем в CSS, а саме контроль над каскадом та конфліктами між селекторами. :has() — дає перевірити, чи містить батьківський елемент хоча б один із вказаних елементів. Цього дуже не вистачає в роботі. Умовні конструкції when/else — цікавий напрям розвитку, який ймовірно може стати стандартом. З останніх помітних нововведень у JavaScript — private fields та розширення синтаксису static, що наближають JS до класичних мов ООП, таких як Java, C# тощо. МІФ №5 Нативні застосунки завжди будуть зручнішими за веб. Дійсно, нативні застосунки можуть бути зручнішими для користувача ніж вебзастосунки, якщо дають доступ до певних функцій пристрою, яких не має браузер. Одна з їхніх переваг — швидкість. Однак це змінилося з появою прогресивних вебзастосунків (Progressive Web Apps) та зростанням їхньої популярності. Вони можуть працювати в режимі офлайн та мати багато функцій, які раніше були доступні лише в нативних застосунках. Після встановлення на головний екран, вони працюють швидше, ніж у браузері. Крім того, PWA значно дешевші та простіші у розробці та підтримці. Наразі їх можна публікувати в Google Play та Microsoft Store серед інших продуктів. Водночас існує багато інструментів, які дозволяють фронтенд-розробникам створювати гібридні застосунки на JavaScript для різних платформ. Наприклад, Electron можна використовувати для створення продуктів для десктопу, а React Native — для мобільних пристроїв. Цей напрям розробки також активно розвивається, постійно з'являються нові технології. Наприклад, фреймворк Tauri, що поєднує швидкість Go з легкістю розробки за допомогою HTML, CSS та JavaScript для створення десктопних застосунків. Але PWA та гібридні застосунки не є ідеальним рішенням, яке може повністю замінити нативні. Все як завжди залежить від складності застосунку та потреб бізнесу. МІФ №6 Фронтенд-девелопер має обовʼязково добре розумітися в дизайні. Фронтенд-розробник має вміти взаємодіяти з дизайном. Особливо на ранніх етапах проєкту, коли треба закласти дизайн-систему в коді для подальшого успішного розвитку продукту. Але з іншого боку, одна з цінностей фронтенд-девелопера полягає в тому, що він може поставити себе на місце користувача. Він — та людина, яка першою буде взаємодіяти з інтерфейсом. Дизайнерський досвід та фокус на правилах прийняття тих чи інших рішень можуть обмежувати його у судженнях. МІФ №7 Сторінки та вебзастосунки стають занадто складними. З одного боку, вебзастосунки з кожним роком стають все складнішими, що призводить до проблем з продуктивністю. З іншого боку, стандарти швидкості від Google надають жорсткі критерії, яким мають відповідати сайти для успішного SEO-просування. У відповідь на це зʼявляються технології, що вирішують проблеми оптимізації, які вже не можна ігнорувати в Single-page Application (SPA). З новими фреймворками можна не витрачати багато зусиль на самостійне вирішення проблем перформансу. Серед них, наприклад, Next.js, який вже став майже стандартом для створення нових продуктів на React, або новачки, такі як Astro, що пропонують поглянути на створення сайтів під новим (старим) кутом Multiple-page Application, розробляючи їх на улюблених SPA-фреймворках. МІФ №8 Мікрофронтенд — універсальне рішення, за яким майбутнє та яке підходить усім. Проблеми, для вирішення яких підходить мікрофронтенд, зʼявляються, коли вебзастосунок стрімко зростає разом з командою. Або ж йому вже стільки років, що його надто складно підтримувати та треба ітеративно покращувати. Мікрофронтенд — це підхід, що дозволяє працювати з певними частинами проєкту, незалежно від інших. Наприклад, одна команда може створювати логіку пошуку, а інша сфокусована на профілі користувача. Вони не перетинаються у виборі технологій і не залежать одна від одної. З одного боку цей підхід призводить до «зоопарку технологій», а з іншого — додає гнучкості у формуванні команд, наймі, підходах, які використовуються на проєктах. Чи ефективний такий підхід? Так, але підходить він не всім. Не варто використовувати його без потреби та конкретної проблеми, яку треба вирішити.

Genesis посіла перше місце у рейтингу найкращих роботодавців воєнного часу за версією видання Forbes Ukraine. Це перше дослідження вітчизняного ринку роботодавців під час війни, яке стало наймасштабнішим в історії рейтингу Forbes — участь у ньому взяли 28 663 респондентів. Genesis вперше брав участь у рейтингу роботодавців та набрав 87 балів зі 100 можливих. Максимальну оцінку компанія отримала в категоріях «Можливості для розвитку», «Відчуття захисту» та «Соцпакет». «Це визначне досягнення для нас — можливо, більше, ніж інші бізнес-результати. Вважаю, що для будь-якої компанії під час війни те, що вона робить для своїх співробітників, членів їхніх родин (зокрема, тих, хто на фронті) — це пріоритет. Як кофаундингова компанія ми багато ресурсів інвестуємо в розвиток бізнесів нашої екосистеми, а також у людей та їхню безпеку. Ми вдячні колегам, які віддали такі високі оцінки під час голосування, що свідчить про взаємну підтримку та довіру. Вдячні всій команді, яка з 24 лютого зробила все можливе і неможливе, щоби компанія продовжила працювати», — коментує CEO Genesis Володимир Многолєтній. З IT-галузі до рейтингу також потрапили 12 бізнесів, що становить майже чверть учасників (24%). Це засвідчує стійкість галузі під час війни та її фокус на збереженні максимально сприятливих умов праці для своїх співробітників, наскільки це можливо у воєнний час. Видання Forbes спільно з сайтом пошукту роботи Work.ua вже втретє організовують національний рейтинг роботодавців. Дослідження було відкритим — співробітники бізнесів із різних сфер могли номінувати свою компанію. Учасників оцінювали за наступними критеріями: бренд роботодавця, винагорода, умови праці, соцпакет, внесок у перемогу, інформаційна відкритість, відчуття захисту, можливості для розвитку тощо.

Сьогодні всі, хто має бажання та хист до викладання, перебувають у вигідній позиції. Завдяки різноманітним онлайн-платформам, інструментам і, власне, мережі інтернет запуск власного курсу стає складною, але цілком досяжною метою. Однак для успішного освітнього продукту потрібно не лише мати знання у своїй галузі, а й розуміння, як спроєктувати курс з точки зору проджект-менеджменту. Ключові моменти процесу ми й розглянемо в цій статті. Усі нюанси розробки власного освітнього продукту формулювала та пояснила Internal Education Lead в Genesis Вікторія Прищепа. Вікторія понад сім років створює освітні проєкти, близько трьох — займається навчанням співробітників, а нещодавно стала лідом напряму та будує систему корпоративного навчання в Genesis. Своїм досвідом також ділиться Олесь Дібрівний, Unity Developer у Keiki з екосистеми Genesis. У продукті він закриває всі завдання пов’язані з грою — від ігрових механік до аналітики та оплат, а також поєднує роботу розробником із викладанням в університеті, де свого часу запустив власний курс > Визначаємося з мотивацією > Аналізуємо ринок > Обираємо тему > Тестуємо гіпотезу > Обираємо формат > Готуємося до виступу > Оцінюємо прогрес студентів > Просуваємо готовий курс З чого почати: визначаємося з мотивацією Найперше, що потрібно для запуску свого онлайн-курсу — зрозуміти, навіщо вам викладання. Ось декілька можливих причин: ви хочете поділитися досвідом. З часом у людини виникає бажання передавати свої знання та допомагати розвиватись іншим; ви прагнете «прокачувати» особистий бренд. Викладання допомагає збільшити власну видимість у галузі, заявити про себе як про експерта та розширити коло своїх контактів; вам потрібно спростити процес онбордингу. Наприклад, ви — єдиний розробник у продукті, й збираєте свою команду. Курс зменшить витрати часу та сил на знайомство новачків з процесами, практиками та технологічним стеком проєкту; ви розробили специфічний функціонал і його треба пояснити. Якщо нещодавно ви зарелізили нову унікальну фічу, курс допоможе зекономити час на її пояснення для команди або зовнішньої аудиторії. Свій курс можна записати з будь-яким ґрейдом на будь-якому етапі роботи в компанії, впевнена Internal Education Lead Вікторія Прищепа. «Відмінними будуть специфіка та глибина інформації, якою ви прагнете поділитися. Фахівці рівня джуніор можуть підготувати теоретичний матеріал та вже готові фреймворки, тоді як мідл-розробники розкажуть про особливості роботи з продуктом конкретного спрямування. Сеньйори, зі свого боку, відфільтрують неприкладну теоретичну інформацію, дадуть глибші практичні вправи та розкажуть про унікальні речі з власного досвіду». Про свій не зовсім типовий досвід розповідає Олесь Дібрівний Unity Developer у Keiki. Маючи бекґраунд у мові програмування С#, він почав викладати розробку ігор та працювати з рушієм Unity, а потім став профільним розробником. «Мені цікаво працювати зі студентами та брати участь у розвитку молодшого покоління. Крім того, викладання стимулює власний розвиток, адже щоб пояснити матеріал, потрібно добре розібратися в темі. Тому коли в аспірантурі мені запропонували викладати основи геймдеву, я погодився. Спочатку ми робили простий 2D-платформер, надихаючись каналом Brackeys. В основному займались ігровими механіками й навіть не думали про архітектуру коду чи інші правила побудови проєкту», — говорить він. Аналізуємо ринок Перед запуском курсу варто впевнитися, що матеріал знайде своїх слухачів та буде актуальним. Ось з яких кроків може складатися аналіз ринку: Дослідження конкурентів. «Перегляньте, що пропонують освітні платформи, як-от Coursera чи Udemy. Дослідіть, до якої аудиторії вони звертаються, чим вони унікальні, які підходи використовують для запуску своїх курсів тощо», — говорить Вікторія Прищепа. Робота з відгуками студентів курсів конкурентів. «Там теж можуть знайтися цікаві інсайти. Наприклад, в цілому, тема цікава, але матеріал краще запакувати не в цілий курс, а в компактний ґайд. Якщо попит на курси конкурентів загалом високий, то, ймовірно, ваш також знайде свою аудиторію », — говорить Вікторія Прищепа. Використання моніторингових інструментів. Якщо ви визначилися з напрямом, але сумніваєтеся щодо спеціалізації, потрібно оцінити ринкові тренди. Згодяться інструменти на кшталт Google Trends та Google Keyword Planner. Вони дадуть змогу вивчити попит на конкретний термін у певний час, порівняти, ключові слова на предмет збільшення чи зменшення популярності, визначити середній обсяг пошуку слів на місяць. Від цього також можна відштовхуватися. «Коли я починав роботу над своїм курсом з Unity, аналогічних пропозицій на українському ринку майже не було. Тож я переглядав матеріали на іноземних платформах, підглядав практики та підходи там. Потім, уже маючи розробника в геймдеві, я міг чіткіше визначити, який матеріал, й у якому форматі давати, що пояснити конче необхідно, а чим можна знехтувати», — каже Олесь Дібрівний. Обираємо тему Найперше, що потрібно врахувати — це ваші компетенції, говорить Вікторія Прищепа. «Те, що ви робите на роботі кожного дня, може стати абсолютно новим знанням для іншої людини», — зазначає вона. Далі ідею варто перевірити за кількома іншими критеріями — відповідність потребам ринку, рівень складності, унікальність, новизна тощо. Ідеальна тема має бути комплексною, тобто поєднувати різну інформацію в єдину логічну структуру. Тоді автор зможе дати декілька теоретичних лекцій, практичні завдання, запропонувати кейси, вправи, додаткові матеріали тощо — і студенти краще засвоять матеріал. Наприклад, на курсі з темою «Архітектура мікросервісів» можна розповісти про відмінності мікросервісів від монолітів, архітектурні патерни та принципи, на яких вони базуються, потрібні технології, як-от Docker, Kubernetes, Amazon ECS, Google Kubernetes Engine тощо. А потім запропонувати самостійно розгорнути мікросервіс у «хмарі» або розробити систему моніторингу. Тестуємо гіпотезу Щоб не втрачати час та зусилля на продукт, який не підходитиме цільовій аудиторії, варто зробити MVP, впевнена Вікторія Прищепа. Вона радить підготувати одну лекцію на відповідну тему та протестувати її на колегах або, якщо вдасться, запросити людей, що не працюють із вами. Або можна зробити драфт курсу та запропонувати його пройти декільком людям. Орієнтуватися далі допоможе фідбек — скільки людей зареєструвалося, чи були вони активними, які питання ставили, як загалом оцінили матеріал та наскільки ваша тема актуальна для аудиторії. «Без такої перевірки ви ризикуєте витратити час, сили, кошти на продукт, який буде не релевантним для обраної аудиторії. А щоб його переробити потрібно буде витратити у два рази більше ресурсів. Звичайно будь-який продукт потрібно вдосконалювати з часом. Але з MVP ви точно знатимете, що під час запуску зробили максимум», — говорить Вікторія. Обираємо формат Рідко буває так, що курс створений повністю в одному форматі — наприклад, тільки відеоуроки або тільки текст. Зазвичай їх комбінують між собою, аби студенти краще засвоювали матеріал. Ось декілька найбільш розповсюджених варіантів. Вебінари Онлайн дає змогу взаємодіяти зі студентами в режимі реального часу: презентувати матеріал, відповідати на запитання, брати участь у дискусіях. Тут зручно ділитися екраном та показувати, як працює та чи інша технологія, розбирати кейси та обговорювати домашні завдання. Найбільший виклик цього формату — залучити аудиторію та утримати її увагу, адже зберігати концентрацію впродовж години чи більше може бути непросто. Є багато способів, як це зробити: наприклад, говорити про аудиторію «ви», «вам», «у вас», залучати слухачів до дії, розмірковувати вголос та ставити запитання, уточнювати, чи все зрозуміло. Більше про утримання уваги можна почитати тут, тут і ось тут. Оптимальна тривалість вебінару — година-півтори. Заздалегідь записані уроки Один із найбільш оптимальних форматів — він дає студентам змогу передивлятися матеріал у своєму темпі в зручний час. Якщо ви пояснюєте складні концепції чи фреймфорки, в учнів завжди буде змога переглянути лекцію ще раз, аби точно розібратися в предметі обговорення. На відміну від живого вебінару, записана лекція не вимагає від викладача викласти матеріал без помилок з першого разу, тож переписувати та вдосконалювати відео можна, поки ви не будете задоволені фінальним результатом. «Останні декілька років мої пари проходять так: я відкриваю Unity, показую, що і як я роблю, і записую все це на відео. Досвід із вебінарами показав, що користь від них менша: багато слухачів не можуть бути присутніми в певний час. До того ж мені зручно записувати лекції рано вранці чи пізно ввечері, щоб не переривати робочий день — а в такий час не всі можуть нормально сприймати новий матеріал. Якщо накопичуються питання, ми плануємо «живу» консультацію», — розповідає Олесь Дібрівний. Текстові матеріали Зазвичай різноманітні ґайди, інфографіки, статті та інструкції пропонують для додаткового опрацювання. Наприклад, коли потрібно заглибитися в документацію, розібратися в певних аспектах роботи технологій тощо. Втім, система з таких документів може стати й окремим освітнім продуктом — якщо лектор впевнений у здатності студентів до самостійного навчання. Сильною стороною подібних матеріалів стає унікальний дизайн, організація та структура. Подкасти Хороший варіант для тих, хто любить вчитися на ходу. Він не підійде для дуже «технічних» тем, які вимагають багато графіків, схем, коду та фреймворків, але вдало доповнить курс розмовами з експертами, дискусіями, порадами. Також формат підійде для запису питань та відповідей. Головне, про що треба пам’ятати — хороший мікрофон, адже комфорт слухачів у цьому випадку дуже залежить від якості звуку. Власні проєкти Формат може поєднувати всі перелічені вище та давати студентам змогу вирішувати реальні завдання. На курсах від Genesis подібним проєктом може стати застосунок, гра або власне медіа. «Наприкінці мого курсу студенти мають показати готову гру. Для цього я проводжу їх усіма етапами створення подібного продукту — від встановлення Unity до завантаження на Google Play Market. Перші шість лекцій — це основи: ми знайомимося з тим, як працює двигун, мовою програмування C#, звикаємо писати код згідно код-стайлу. Далі, коли ми вже маємо персонажа, який ходить вліво-вправо, я дивлюся, що потрібно для завершення гри. Якщо це, наприклад, RPG (Role-Playing Game — гра, де потрібно керувати одним персонажем), то потрібні вороги та NPC (Non-Player Character — персонажі, за яких грає комп’ютер), зброя, якою може скористатися персонаж, продумані рівні. Я намагаюся зробити так, щоб вони працювали над проєктом у середовищі, наближеному до робочого. Для цього ми, наприклад, користуємося системами контролю, як-от Jira та Bitbucket від Atlassian» — говорить Олесь Дібрівний. Формуємо програму На цьому етапі потрібно визначити мету, зміст, структуру, методи та засоби навчання, а також сформулювати очікуваний результат. На основі останнього ми визначаємо, які саме знання потрібно дати людям, уточнює Вікторія Прищепа. Це називається методологія створення курсу. Зазвичай курс ділиться на модулі, у кожному з яких є декілька тем. Спочатку викладається теорія, потім практика, яка підкріплюється домашніми/практичними завданнями. Вікторія радить відвести на теорію не менше 10% усього курсу, і додавати до модулів невеликі вступні лекції. Підхід дасть глядачам змогу налаштуватися на тему та ознайомитися із запропонованою термінологією. Перевірку прогресу та домашні завдання можна гейміфікувати. Наприклад, зробити загальний рейтинг слухачів чи начисляти бали-зірочки за виконані вправи. «Курс, який я веду передбачає перехресну перевірку робіт, тобто спочатку домашнє завдання студента переглядають однокурсники. Вони знаходять частину помилок, а далі вже підключаюся я — дивлюся фінальну версію через Pool Request. Наприкінці студенти уже готують презентацію свого фінального продукту — розповідають, як і над чим вони працювали протягом семестру та показують готову гру», — розповідає Олесь Дібрівний. Готуємося до виступу Ось обладнання, яке вам знадобиться, щоб записати уроки: комп'ютер (в ідеалі, з двома моніторами) зі стабільним інтернет-з'єднанням; вебкамера; мікрофон; навушники або колонки; клікер; мікшер (опціонально). Далі треба визначитися із софтом та сервісами. Щоби записати відеоряд знадобиться Zoom чи OBS Studio, відредагувати звук допоможе Audacity, якщо плануєте монтувати відео — можна скористатися Adobe Premiere Pro чи Final Cut Pro. Існують також цілісні платформи для навчання — LMS-системи на кшталт Academy Ocean. Їх не обов'язково використовувати на етапі MVP. Такі ресурси підійдуть, коли ви запускатимете повноцінний курс чи забажаєте масштабувати власні освітні проєкти. «Спочатку краще обрати простіші інструменти, а LMS використати, коли вже матимете вдосконалений після першої ітерації курс», — говорить Вікторія Прищепа. Оцінюємо прогрес студентів Виміряти його можна за допомогою тесту на перевірку знань — на початку й наприкінці навчання. Така практика допоможе зрозуміти рівень засвоєння теоретичних та практичних навичок студентів. Найкращий варіант визначити рівень студентів після курсу — це груповий чи індивідуальний проєкт, впевнена Вікторія Прищепа. Вона радить заздалегідь сформулювати критерії для його оцінки, визначити, скільки балів «важить» кожний із них та поділитися інформацією зі студентами. «Без чітких критеріїв люди не розумітимуть, що ви маєте на увазі під «успішним проєктом». Кожну оцінку варто декомпозувати та пояснити. Тобто, якщо за функціональність проєкту ви ставите від 1 до 5 балів, то людина має знати, що на 2 бали проєкт може працювати з помилками, а щоб отримати 5 — всі баги потрібно почистити». Олесь Дібрівний оцінює роботи студентів за п’ятибальною шкалою. Ось як він пояснює вибір оцінки. «Я маю три рівні, щоб відстежити прогрес студентів. У першому випадку я бачу, що завдання виконували з інтересом. Наприклад, я попросив зробити персонажа, який ходить вправо-вліво, а студенти зробили так, що він ще і стрибає. Другий тип я називаю «цього достатньо» — коли люди подивилися мої відеоуроки, скопіювали код (разом із помилками), підставили іншу графіку та здали. Третя категорія характеризується фразою «здав і здав». Тут люди просто знайшли готовий шматок коду в мережі, не розібралися, чи він взагалі робочий, і надіслали, як виконане завдання. Я вже всі ці шматки впізнаю, й можу у відповідь надіслати посилання, звідки він взятий». Просуваємо готовий курс Без просування аудиторія просто не дізнається про продукт, тому це важлива частина його створення. Є декілька варіантів, як саме розказати аудиторії про ваш курс. «Перший передбачає, що у вас уже побудований сильний особистий бренд. Тоді люди розуміють, у чому ви експерт. Тут можна розпочати з безкоштовної лекції або серії таких, і поступово просувати меседж про курс. Наприклад через особисті соцмережі чи в межах команди», — розповідає Вікторія Прищепа. Якщо ж особистий бренд ще не сильно розвинений, просування потрібно будувати повністю з нуля. «Я раджу почати з LinkedIn — це професійна соцмережа, тому, ймовірно, ваша аудиторія саме там, — говорить Вікторія Прищепа. — Можна використати робочі канали комунікації, завести блог на Medium, попросити ваших колег та знайомих поділитися інформацією про курс, записати безкоштовну лекцію. Це дасть людям змогу дізнатися про вас та поступово ставати вашою аудиторією». Особистий бренд можна розвивати також через YouTube та публікації в профільних медіа, говорить Олесь Дібрівний. «У мене є невеличкий канал, де я викладав записи лекцій для студентів, зараз планую його розвивати та оновлювати матеріали. Крім того, у мене є публікація на DOU, і зараз я готую ще одну статтю. Такі освітні матеріали добре заходять», — говорить він. Ще один варіант — звернутися напряму до освітніх платформ та запропонувати себе як експерта в певній темі. Майданчиком може стати Coursera, Udemy, Khan Academy або українські Prometheus, Projector тощо. Зазвичай платформа бере на себе організацію продакшену та просування. Єдине — перед стартом роботи варто дізнатися про всі політики платформи та зрозуміти, які матеріали вони шукають. Інакше може виявитися так, що ваш заздалегідь записаний чи продуманий курс не підійде за характеристиками платформи.

Застосунок PlantIn, який розробив однойменний стартап з екосистеми Genesis, посів першу сходинку у ніші Education у App Store семи країн. Він став лідером за кількістю завантажень у США, Франції, Швеції, Швейцарії, Польщі та Саудівській Аравії. PlantIn випередив такі додатки як Duolingo, Elevate, Photomath, Google Classroom. За словами CEO стартапу, Михайла Гринця, такий результат сприяє підвищенню знання про бренд, приросту органічного трафіку та полегшує фічеринг в App Store. Наприклад, у Польщі PlantIn очолює вже дві рекомендації — «Найпопулярніші безкоштовні застосунки» та спеціальну підбірку «Hero List». «Цього вдалося досягти завдяки цілеспрямованій роботі команди маркетингу, налаштованій аналітиці, а також продуктовій команді, яка постійно покращує контент у застосунку та розширює його функціонал», — говорить Михайло Гринець. PlantIn — це застосунок-помічник для розпізнавання рослин і догляду за ними на основі технології штучного інтелекту. Нині алгоритм ідентифікує понад 25 000 видів рослин та понад 100 видів їхніх захворювань. За два роки PlantIn завантажили понад 12 млн людей, а команда зросла з двох до 50 людей.

Тест-менеджмент системи (TMS) допомагають оптимізувати процес тестування та налагодити спільну роботу між командами. Натомість неправильний підхід може спричинити появу «сірих зон» у продукті та виникнення дефектів уже після релізу. Володимир Матвійченко, Automation QA Engineer у партнерській компанії Quarks, має шестирічний досвід у тестуванні, понад п’ять років — в автоматизації. Він поділився досвідом команди у побудові процесів тестування, розповів, для чого потрібна тест-менеджмент система у продукті, коли варто її змінити, та що дав перехід на Allure TestOps. > Для чого потрібна TMS > Робота з TestRail: що пішло не так > «Переїзд» на Allure TestOps. Новий тестовий процес > Як в Allure TestOps підтримуються параметризовані тести > Інтеграція з фреймворком автоматизації та інші фічі Allure TestOps Для чого потрібна TMS Тест-менеджмент система використовується для зберігання документації та відповідає на питання, як саме відбувалося планування та тестування продукту. Вона показує якість релізу, який готується до деплоя на продакшн, на скільки той чи інший функціонал закритий тестовою документацією. Основні функції тест-менеджмент системи: створення тестової документації на основі тестових вимог; підтримка виконання тест-кейсів; створення смоук/регресійного тестового набору; запис інформації щодо успішності виконання тест-кейса; збір метрик продукту на основі проведеного тестування; управління дефектами у продукті. Мені доводилося працювати з різними TMS: ALM, TestLink, TestRail, Allure TestOps тощо. Їхні переваги та недоліки за різними критеріями зібрані в таблиці нижче. Донедавна ми використовували TestRail для проєктів у Quarks. У порівнянні з ним Allure TestOps надає наступні переваги: Відкритість. Allure TestOps є повністю відкритою платформою з відкритим вихідним кодом, що дозволяє розробникам та тестувальникам налаштовувати та розширювати функціональність за потреби. Простота інтеграції з фреймворками автоматизації, можливість збирати та відображати додаткову інформацію про результати тестів. Зручна візуалізація результатів тестів за допомогою графіків і діаграм, що дозволяє швидко орієнтуватися в статусі тестів. Інтеграція з іншими інструментами, такими як JIRA, Git, Slack, Docker, Jenkins та багатьма іншими. Це дозволяє забезпечити повну автоматизацію тестового процесу та максимальну ефективність роботи команди тестування. Можливість створювати та зберігати описи тестів, пов'язувати їх з тестовими скриптами та відповідними багами. Крім того, можна додавати до тестів скріншоти та інші зображення, що забезпечує більш детальну документацію результатів тестування. Робота з TestRail: що пішло не так Як виглядав тестовий процес під час використання системи TestRail: Manual QA детально описував тест-кейс для певного функціонала. AQA-команда переводила мануальні кроки в автоматизовані за допомогою певної мови програмування. Далі ці сценарії пушили в BitBucket, після чого їх забирав Jenkins, запускав на ремоут-сервері, формував тестові звіти. Мануальний та автоматизований сценарій поєднувався через анотацію Test Case ID — це вказувало, що цей сценарій автоматизований. І далі з допомогою API TestRail ми проставляли статус для автоматизованого тест-кейса у Test Run (passed/failed). Але в цього процесу була низка недоліків: 1. Оновлення тестової документації. Наприклад, коли в одному з ланцюгів ламався тест-кейс, ми вносили правки у фреймворк автоматизації, а не в TestRail. І через декілька циклів релізів автоматизований тест-кейс відрізнявся від мануального тест-кейса, описаного в TMS. В результаті, в TestRail документація не оновлювалася і зберігалася неактуальною. 2. Підтримка версійності тест-кейсів. Наприклад, в TestRail у нас була одна реалізація тест-кейса, у фреймворку автоматизації — друга, а при тестуванні нового функціоналу — третя. І під час випуску нового релізу щоразу виникало питання, де ж актуальна документація, на що орієнтуватися. 3. Генерація тестової документації на основі автоматичних тестових сценаріїв. Наприклад, у нас є реалізація автотестів, але не написана документація. 4. Робота з параметризованими тестами. Доволі часто в процесі автоматизації використовуються параметризовані тести. Але TestRail не підтримував можливості проставляти через API декілька статусів для мануальних тест-сценаріїв. 5. Інтеграція тестового фреймворку з TMS. Для автоматизації ми використовуємо Java та тестовий фреймворк JUnit 5. Але інтеграція тестового фреймворку з TestRail — непросте завдання, адже необхідно добре розуміти публічну API самої TMS, та саме яким чином в Test Run проставляти статуси для тест-кейсів, як при цьому TMS взаємодіє з фреймворком тестування. У випадку якщо ви вирішите переїхати з одного тестового фреймворку на інший, наприклад з TestNG на JUnit 5, то вся інтеграція у вас зламається і потрібно буде переписувати інтеграцію з TMS. Щоразу ми думали: чому це так складно й немає плагіна, який би «з коробки» зробив інтеграцію з TMS? Але найголовніший недолік Test Rail полягав у тому, що ми не могли створити Test Run, який би обʼєднував автоматичні та мануальні сценарії. Кожна з команд QA орієнтувалася на власні тест-кейси, і тестування зводилося до двох паралельних процесів. Виходило, що зʼявлялися «сірі зони», взагалі не покриті тестами, і після релізу виникали дефекти на продукті. «Переїзд» на Allure TestOps. Новий тестовий процес В новому тестовому процесі, організованому з допомогою Allure TestOps, коли проходить задача на тестування нового функціоналу, Manual QA в першу чергу створює Test Launch, який включає автоматизовані та мануальні тестові сценарії. Якщо в рамках нового функціоналу продукту необхідно актуалізувати документацію, її дописують у межах цього Test Launch. Allure TestOps може автоматично взаємодіяти з CI, тобто Manual QA не потрібно звертатися до Jenkins. Єдине, що має зробити тестувальник — створити Launch та включити в нього тести, які необхідно перевірити в рамках розробки нового функціонала. Він може містити як автоматизовані тестові сценарії, так і мануальні. Після запуску Allure TestOps автоматично проставляє статуси про успішність виконання тестових сценаріїв. Якщо якісь з них не покриваються автоматизацією, Manual QA перевіряє логіку та визначає статуси самостійно. Також Allure TestOps дозволяє на основі автоматизованих тест-кейсів створювати документацію. Наприклад, якщо мануальна команда завантажена, а AQA Engineer добре ознайомлений з функціоналом продукту, він може написати автосценарій і на його основі згенерувати тест-кейс, який буде використовуватися обома QA командами. Актуальна документація на проєкті — дуже важлива, адже допомагає мінімізувати час на автоматизацію нових сценаріїв. Як в Allure TestOps підтримуються параметризовані тести В проєкті автоматизації над параметризованим тестом додаємо анотацію DataProvider. Вона є врапером над анотацією ParameterizedTest. Далі додається анотація Allur ID — фактично вона зʼєднує мануальний та автоматизований сценарій в Allure TestOps. І далі нам достатньо додати рядок «parameter», описати вхідний параметр наприклад title і додати вхідний параметр, який ми приймаємо з анотації MethodSource. На основі цих даних Allure TestOps побудує таблицю вхідних параметрів для тестового сценарію. Отже, достатньо написати один мануальний тестовий сценарій замість шести. Для цього і використовуються параметризовані тести. Ще один приклад, як можна реалізувати параметризовані тести в Allure TestOps: в анотації СsvSource вказується ID тест-кейс. Тоді один автоматичний сценарій проставить статуси для двох мануальних сценаріїв і побудує таблицю. Інтеграція з фреймворком автоматизації та інші фічі Allure TestOps Для інтеграції Allure TestOps з фреймворком достатньо встановити плагін IntelliJ IDEA та в Jenkins файл додати інформацію про посилання на Cloud Allure TestOps. Єдина умова — ви маєте використовувати репортинг Allure. На відміну від TestRail, на стороні фреймворку не треба нічого знати про Public API TMS, заглиблюватись у нюанси та писати додатковий код — інтеграція працює «з коробки». Allure TestOps має інтуїтивно зрозумілий та легкий в навігації інтерфейс. Головний екран містить панель навігації зі списком доступних модулів: Test Cases — список усіх тест-кейсів з можливістю створення нових та редагування вже існуючих. Test Runs — список усіх Test Launches, що дозволяє запускати, переглядати результати та аналізувати стан тестування. Defects — список дефектів, що дозволяє стежити за ними та відслідковувати стан їх виправлення. Reports — різноманітні звіти та діаграми на основі результатів тестування. Integrations — налаштування інтеграції з різноманітними інструментами для автоматизації тестування. Крім цього, в Allure TestOps є можливість швидкого пошуку тест-кейсів, тестових ланчів та дефектів за ключовими словами чи тегами. Також застосунок підтримує можливість створення проєктів та управління правами доступу до них. Усі ці функції дозволяють швидко та ефективно організовувати процес тестування та відстежувати стан різних проєктів та їхніх компонентів. У цій TMS є можливість створення кастомних дашбордів, наприклад, для регресійного та смоук-тестування. Вони можуть показувати інформацію про епіки (унікальний функціонал для певного продукту) — наскільки вони покриті тестами. Коли відбувається оновлення функціонала, ми одразу на дашборді бачимо нові сценарії, фільтруємо за статусами та переходимо до автоматизації. Ще одна перевага — Allure TestOps «з коробки» підтримує матрицю покриття. Наприклад, у кожному епіку є окремі фічі, за кожною з яких показується, скільки автоматизованих сценаріїв, скільки мануальних. З допомогою кольорів підсвічуються статуси, завдяки чому зручно слідкувати за покриттям функціонала. Наприклад, темнозелений — усе закрито тестами. Червоний — ця фіча не закрита автоматизованими сценаріями, тут треба автоматизувати певну кількість мануальних тест-кейсів тощо. Зміна тест-менеджмент системи та перехід на Allure TestOps допоміг нам оптимізувати деякі процеси, налагодити ефективну взаємодію між командами AQA та Manual, забезпечити краще покриття тестами та підвищити якість продукту.

В ідеальному світі розробники, тестувальники та DevOps-інженери злагоджено працюють разом, інфраструктура завжди стабільна, процеси ніколи не ламаються, а технології обираються тільки за стандартами індустрії. Втім, реальність не така чудова, й різні фахівці часто зіштовхуються з однаковими проблемами. Про найпоширеніші болі DevOps-інженерів, робочі процеси, вибір технологій та загальне розуміння методології розповів Микита Глушак, DevOps Team Lead в Solidgate, партнерській компанії Genesis. Микита вісім років працює в ІТ-індустрії, шість з яких — на посаді DevOps-інженера. Уже понад рік він керує інфраструктурною командою в Solidgate та разом з колегами налагоджує інженерні процеси в компанії. БІЛЬ №1 Технології, обрані на початку роботи, стають проблемою у довгостроковій перспективі. Обираючи нові інструменти, DevOps-інженер відповідає собі на питання: «Зараз потрібно спроєктувати цілісну систему чи вирішити конкретне завдання?» Буває так, що на старті роботи ви обрали технічне рішення, бо воно було не дорогим, нескладним або задовольняло конкретні потреби. Ви почали ним користуватися, команда адаптувала його під свої потреби, але з часом на ринку з’явилися нові технології, які краще підходять під ваші запити. Нові та старі підходи не завжди добре поєднуються між собою. Наприклад, для поглибленого моніторингу наших систем ми використовуємо продукт Elastic APM. Раніше він ефективно вирішував наші завдання, але коли бізнес масштабувався, а вимоги до системи змінилися, ми звернули увагу на юзабіліті стеку і на те, як всі елементи інтегруються між собою. Саме ця система не достатньо гармонійно поєднувалася з іншими, й мала чужорідний вигляд в інфраструктурі. Попри те, що вона добре функціонує, її несумісність з іншими елементами стала проблемою. У такому випадку DevOps-інженер має два варіанти: писати «костилі», або змінювати інструмент, а це буває ще болісніше, ніж щось «костилити». Втім, ми все ж таки обрали другий варіант та розглядаємо альтернативні продукти, які повністю відповідатимуть нашим потребам і зараз, і у майбутньому. БІЛЬ №2 Технології, з якими хочеться працювати, не відповідають потребам і обставинам у бізнесі. Наприклад, команда працює з SAAS-рішеннями від Google чи Azure, але є альтернативні варіанти від інших вендорів, які виглядають цікавіше — за ціною, кількістю фіч, наявністю інтеграцій з іншими продуктами. Здавалося б, чому просто не перейти на них? Причини відмови від будь-якого «цікавого» продукту чи інструменту можуть бути різними: від вимог комплаєнсу та нестачі необхідних сертифікатів до відсутності певних фіч чи підтримки технічного стека, який використовується в компанії. БІЛЬ №3 Документація до інструментів написана не для тих, хто вперше знайомиться з ними. У роботі DevOps-інженерів бувають специфічні завдання, пов’язані з даними, як-от забезпечення обміну даними між різними системами або їх трансформація у режимі реального часу. Для подібної задачі потрібно налаштувати data-пайплайн за допомогою специфічних інструментів, наприклад, Apache Airflow, ETLworks, Matillion. Розгортання подібних продуктів може стати справжньою проблемою, бо часто процес зводиться до варіанту «на колінці», й навіть невеличкий крок убік від такого сценарію приводить до годин дебагінгу. І якщо розібратися в документації, щоб налаштувати пайплайни даних, ще вийде, то проблеми з експлуатацією, масштабуванням та підтримкою можуть стати викликом для всіх користувачів. БІЛЬ №4 DevOps-інженери складають документацію до внутрішніх інструментів, але команді зручніше запитати напряму. Впроваджуючи нові інструменти, технології або процеси, DevOps-інженери супроводжують їх записами в базі знань з прикладами використання, описом роботи інструмента тощо. Завдяки документації розробники, тестувальники та інші учасники процесу мають уявлення про процеси, інструменти та конфігурації, що використовуються в компанії, код розгортається узгоджено, а кількість помилок зменшується. Саме завдання не можна назвати цікавим, проте DevOps витрачає на нього час та зусилля: намагається описати процес якомога зрозуміліше, аби документом могли користуватися навіть ті, хто тільки-но приєднався до компанії. Однак трапляється так, що розробник почав працювати з новим інструментом, але з документацією не ознайомився. Як наслідок, він приходить до DevOps-інженера з питаннями, які або уже описані, або легко гугляться. Подібний підхід непродуктивний, бо затягує реалізацію продукту. Втім, це не завжди свідчить про ігнорування або неуважність. Подібні випадки трапляються під час зміни інструментів, перебудови процесів або поповнення у команді. Процес адаптації буває болючим для всіх, але з часом все налагоджується. БІЛЬ №5 До DevOps-інженерів звертаються з питаннями, які знаходяться в зоні відповідальності інших команд. Навряд чи вийде знайти компанію, де методологія DevOps інтегрована у чистому вигляді. Але коли відділ системних адміністраторів просто перетворили на департамент DevOps — це проблема. Так само й навпаки: неправильно перекладати на команду DevOps завдання, які мають виконувати системні адміністратори. Це як мінімум дорого, як максимум — неефективно. Через погане розуміння методології час команди, яка мала б займатися оновленням інфраструктури, підвищенням її витривалості або рефакторингом, може розпорошуватися на завдання на кшталт «поламаної» електронної пошти або налагодження Wi-Fi. Це не означає, що проблема з мережею менш важлива — просто вона знаходиться в зоні відповідальності іншої команди. Зараз тенденція втішна: все більше компаній розуміють, чим саме займаються DevOps, а межа між ними та системними адміністраторами розмивається здебільшого в маленьких або «молодих» бізнесах. БІЛЬ №6 Код, який передають у роботу, неперевірений чи містить помилки. Цей біль стосується задач, коли підготувати інфраструктуру потрібно на основі результатів роботи розробників. Наприклад, вони написали код для нового сервісу, а DevOps-інженери готують під нього платформу на AWS, підіймають базу даних або роблять зміни в уже наявній системі. Коли ви вже розгортаєте ПЗ, виявляється, що код «сирий» — він не виконується або падає з незрозумілими помилками. Через це процес, який мав би працювати як безперебійний конвеєр, ламається. Доводиться писати розробникам, з’ясовувати, в чому проблема, перевіряти все наново — і витрачати на це робочий час як мінімум двох фахівців. БІЛЬ №7 Загальний та короткий запит. DevOps-інженер прагне автоматизувати більшість процесів, але деякі задачі, як-от, видача доступів, автоматизувати складніше. Відволікатися від нагальних завдань на подібні запити — не найприємніша частина роботи, особливо якщо ТЗ для завдання надано некоректно. Ідеально, коли людина чітко, по пунктах описує — навіщо їй доступ, якого рівня, тривалий чи постійний. Тоді все просто й ефективно. Окреме розчарування — коли DevOps створює шаблон в Jira з полями, які слід заповнити, а отримує запит з описом в один рядок. Доводиться звертатися за уточненнями та деталями — а це теж гальмує роботу. БІЛЬ №8 Завдання, пов’язані з оптимізацією фінансів. Один з прикладів подібного завдання — оптимізація хмарної інфраструктури для мінімізації витрат. Така задача може вимагати спеціальних навичок, заглиблення в особливості різних інструментів інфраструктури, а ще — вона менш цікава, порівняно з розгортанням ПЗ. Але я не можу сказати, що це біль всіх DevOps-інженерів — радше, окремих представників професії. До того ж завдання має суттєву приємну частину — приносити керівникові гарні новини про те, що твоя оптимізація зекономила компанії купу грошей.

TypeScript — це одна з найулюбленіших мов програмування серед розробників. Згідно з дослідженням DOU, вона має найвищі темпи зростання популярності та є лідером уподобань (18% девелоперів обрали б саме цю мову, якби починали комерційний проєкт). Її використовують близько 40% фронтендерів, 5% бекендерів та 16% фулстек-девелоперів. Схоже, що розробники нарешті розібралися в головних перевагах та почали використовувати її за призначенням. Хоча в комʼюніті досі продовжуються суперечки, чи наздожене TypeScript доля CoffeeScript, або ж це і є та сама універсальна мова програмування, на яку всі чекали? Віктор Галочка, Front-End Developer в Lift, який у свій час перейшов з JavaScript на TypeScript, розповів, як пережити мовний «джетлаг» та не припуститися помилок. У колонці для блогу Genesis Віктор прокоментував, чому TypeScript — це дещо більше, ніж просто анотація типів, а використовувати стилістику JS у проєктах TS — те саме, що колоти горішки девайсами Dyson. А також пояснив, чому забути про 'undefined' is not a function — безцінно. І тільки за це можна пробачити цій мові всі недоліки. TypeScript — мейнстрим чи необхідність На початку 2010-х команда Microsoft шукала рішення, яке б дозволило створювати на JavaScript великі та складні програми. На той час JS активно зростала та розвивалася, здобуваючи прихильність розробників. Ця мова давала багато свободи й водночас недостатньо контролю. Щоразу, коли проєкти починали зростати, у командах змінювалися люди, підтримувати код на JS ставало все складніше. TypeScript був розроблений під керівництвом Андерса Хейлсберга, надихаючись іншими мовами програмування — Java, C# і Objective-C. За словами Райана Кавано, Lead Engineer в Microsoft та одного з творців TypeScript, команда бачила концептуальний розвиток JS саме через статичну типізацію. Попередні експерименти із синтаксисами та створенням нових мов, на кшталт Script# чи CoffeeScript, не вдалися. На цей раз вони вирішили просто взяти JavaScript і додати статичні типи поверх нього. Так 2012 року зʼявився суперсет TypeScript, який дозволяв розробникам написати більш масштабований і легкий у підтримці код, надаючи такі функції, як статичний тип, інтерфейси, класи та модулі. Це рішення мало покращити якість коду та зменшити кількість помилок у фінальній збірці продукту. А головне — забезпечити більшу надійність, водночас зберігаючи гнучкість і простоту JavaScript. Спершу спільнота сприйняла TypeScript без ентузіазму. Скоріше за все, мало хто зрозумів, навіщо так ускладнювати звичний JavaScript. Переломним моментом став 2016 рік, коли вийшла друга версія Angular — популярного фреймворку із відкритим вихідним кодом для створення вебзастосунків. Спочатку він працював на JavaScript, але 2016 року був переписаний на TypeScript, після чого їхня популярність почала пропорційно зростати. Це добре видно у статистиці запитів на Stack Overflow. За що програмісти люблять TypeScript З моменту розробки TypeScript активно розвивається. Сьогодні складно уявити великий складний проєкт на фронтенді, написаний на JS без використання TS. Звичайно, хороший розробник може створити чітку архітектуру на JS, але, з мого досвіду, ця мова частіше використовується тоді, коли для задачі критична швидкість. Наприклад, потрібно зробити лендінг і покрутити пару днів рекламу, щоби потестити якусь ідею. У такому випадку недоцільно прописувати його на TS, закладаючи перевикористану логіку та витрачаючи дорогий час розробки. Головна цінність TypeScript — можливість писати стабільні та масштабовані проєкти. Розробникам, що прийдуть у проєкт пізніше, буде легше розібратися в задумці тих, хто його створював. Коли бачиш прописану сувору типізацію, чітко розумієш, за що відповідає той чи інший компонент. Якщо раптом один із них не відповідає певній задачі, можна створити інший та закласти в це певну логіку, без утворення безладу. У проєкті, написаному на TypeScript малоймовірна ситуація, що в коді одна функція робить половину всього. Переваги TypeScript: Має добре реалізовану підтримку ООП, дозволяє розробникам ефективніше використовувати класи, інтерфейси. У результаті код виходить більш структурним та цілісним. Надає можливість писати модульний код, придатний для повторного використання. Простіше працювати в команді та підтримувати код, розуміти, яку логіку закладав попередній розробник. Завдяки редактору IDE є можливість виявляти та виправляти помилки ще під час розробки, а не на етапі тестів чи ще гірше — після релізу. Підтримка на рівні всіх платформ — у вебі, мобільних та десктоп застосунках. Інтеграція з різними бібліотеками та фреймворками JavaScript. Крім Angular, може використовуватися з такими популярними інструментами, як React, Vue. Перехід з JS на TS: як подолати джетлаг Я починав свій шлях на фронтенді з вивчення JavaScript. Пізніше працював на Angular, де познайомився з TypeScript. Із цього й почалося «доросле» програмування. Коли довгий час пишеш на JS, а потім різко переходиш на TS, виникає джетлаг. Ти звикаєш до певної швидкості написання коду, а тут усе складніше й довше: підготовка, написання, виправлення помилок, пошук відповідей. Наприклад, коли знаходиш цікаве рішення на Stack Overflow, написане на JS, знадобиться додатковий час, щоби конвертувати його під свій проєкт та вимоги. Поріг входу до TS вищий. Це той випадок, коли для того, щоби писати на TypeScript, треба знати дві мови — JavaScript та безліч нюансів статичного набору тексту, додаткового синтаксису, дженериків та інтерфейсів. Бажано бути в курсі специфікації, але найголовніше — розуміти концепцію, для чого був створений TS. Я стикався з багатьма проєктами, написаними джуніорами та мідлами. У момент, коли їх треба було масштабувати, виявлялося, що на старті про це не подумали. Після такого досвіду не виникає питань, навіщо проєкту типізація та інтерфейси. Тип ‘any’ та локальні пожежі Зниження швидкості розробки при переході на TS спричинює найпоширенішу помилку — розробники починають писати, зберігаючи стиль JS. Наприклад, створюючи компонент, прописували тип ‘any’. Це як гаджетами Dyson колоти горіхи — у тебе є крутий інструмент, але ти його не використовуєш за призначенням. Буває, що немає часу повноцінно адаптувати знайдене рішення на JS під усі вимоги TS, тому його швидкома переписують за принципом «щоб працювало». Але важливо це помічати й обовʼязково потім фіксити. Бо якщо таких «вставок» буде багато, неодмінно почнуться локальні пожежі, і ви втратите головні переваги проєкту на TS — стабільність та масштабованість. Раджу одразу звертати увагу на сувору типізацією, намагатися використовувати й інтерфейси й типи, дженерики й декоратори. Фокус на тому, що ці зусилля — не даремні, і в майбутньому ваш проєкт бути швидким, стабільним та зрозумілим для інших розробників, може допомогти. Їсти на сніданок вівсянку теж не хочеться, але бенефіти обовʼязково прийдуть. Недоліки TypeScript: Складність входу. Для розуміння та ефективного використання додаткового синтаксису та функцій може знадобитися час. Довший час розробки. Складніші налаштування проєкту TS, може потребувати додаткових інструментів і конфігурацій. Довгий час компіляції: оскільки TypeScript вимагає етапу перетворення коду у JavaScript, це може ускладнити швидку ітерацію. Проблеми сумісності при використанні сторонніх бібліотек або фреймворків. Ускладнений найм. Чотири міфи про TypeScript 1. TS гарантує надійність коду. Використання TypeScript є одним із компонентів, який надає йому стійкість, як і покриття юніт-тестами. Жодною із цих складових не варто нехтувати. TS не захищає від помилок архітектури або механічних, корнер-кейсів, того, що розробник щось не врахував, і в результаті застосунок «склався». Він не вирішить усіх проблем, але точно додасть певний відсоток стабільності. 2. У великих проєктах на TS код стає занадто складним, дублюється. TS — це просто інструмент. Ручкою можна писати охайно та не дуже. Так і тут. Повтори фрагментів коду — це питання стилістики, і неважливо, якою мовою ви пишете. Можна на TS писати дуже поганий код, а на JS — хороший. Інтерфейси є потужною функцією TypeScript, яка може допомогти зробити код більш придатним для повторного використання та модульним. З їхньою допомогою можна зменшити кількість зайвого коду та полегшити його обслуговування. 3. Аналізатор помилок лише заважає. При переході на TS редактор IDE може дратувати, збивати та ще більше сповільнювати й так нешвидку розробку. Ніби у вас на смартфоні раптом включили Т9. Але на дистанції це дає перевагу, бо є змога на ранньому етапі врахувати та виправити помилки. Також не забувайте, що можна налаштувати конфігурацію під свій проєкт, наприклад, що редактор вважатиме помилкою, а що ні. 4. Проєктувати на TS — дорого. Розробка на TS збільшує етап написання коду, але спрощує інші процеси, наприклад, код-ревʼю, та економить час на виправлення помилок. Не боятися побачити після релізу 'undefined' is not a function — безцінно. Тож ця інвестиція значною мірою окупається. Отже, довгий час TypeScript сприймався як мейнстрим та використовувався не за призначенням. Але коли розробники справді зрозуміли його цінність та філософію, він почав швидко зростати. На мою думку, на цей час немає технології, яка б могла його затьмарити. З кожним оновленням, розробники намагаються зменшити його недоліки, зробити простішим та швидшим. Так, нещодавно вийшов TypeScript 5.0. Основні зміни стосуються вдосконалень у структурі коду, алгоритмах та роботи з даними. Оновлення вийшли не глобальними, але є цікаві речі, з якими варто ознайомитися: Загальне покращення швидкодії коду на 10-20%. Оптимізація використання памʼяті. Розмір самого пакету суттєво зменшився — на 41% (з 63,8 mb до 37,4 mb) порівняно з TypeScript 4.9. Декоратори (інструмент, що дозволяє розширити поведінку класів і методів). Якщо попередні версії підтримували експериментальні версії декораторів та вмикалися лише за допомогою флагів experimentalDecorators, то тепер вони вбудовані в TS і можна ознайомитись, як вони працюють. Ймовірно, на цей крок пішли, щоби зберегти сумісність, якщо декоратори стануть частиною стандарту ECMAScript. ModuleResolution bundler. Щоби оновити застарілі moduleResolution node, node16 і nodenext, які мали проблеми з експортом, були незручними та громіздкими, в TypeScript 5.0 додали сучасний --moduleResolution bundler. Він має гібридну стратегію, чудово ладнає з класичним Node-style та підтримує правила експорту та імпорту. Підтримка кількох конфігураційних файлів у extends. Ця фіча використовується, коли треба звернутися до певних файлів 'tsconfig.json', що містять ті чи інші налаштування. В останньому оновленні зʼявилася можливість звертатися одразу до кількох файлів.

У квітні компанії з екосистеми Genesis шукають розробників, що працюватимуть з технологічними продуктами різного спрямування. Є пропозиції для фахівців з PHP, Unity, а також тих, хто розуміється на Android та iOS. Завдання — складні, але цікаві. Гортайте підбірку та знаходьте пропозиції саме для вас! А ще — декілька корисних матеріалів для співбесід. iOS Developer (вакансія закрита) У Holy Water, паблішера застосунків та рольових мобільних ігор, ви будете працювати у команді, яка розвиває гру в жанрі інтерактивних історій. Завдання — розробляти застосунки та покращувати користувальницький досвід: тестувати нові фічі, працювати над новим функціоналом та вдосконалювати наявні продукти. Для цього знадобиться досвід в iOS-розробці не менше 2 років, вміння працювати зі SwiftUI та знання архітектурних рішень (Swift, UIkit, core data/realm і т. д.). PHP Developer (вакансія закрита) Компанія Sendios працює з великими та малими підприємцями і допомагає їм досягати бізнес-цілей за допомогою email-маркетингу. Наразі команда шукає PHP-розробника з мінімум чотирма роками відповідного досвіду, що працював із фреймворками Laravel та Symfony, добре знає інженерні моделі та принципи SOLID, а також технології Memcached/Redis, RabbitMQ. Плюсом буде досвід декомпозиції завдань та розробки нових функцій, робота з високонавантаженими системами та будь-яким ESP. Серед завдань — покращенням архітектурних рішень продукту, аналіз та впровадження технічних рішень для потреб бізнесу, участь у декомпозиції завдань та виборі технологій. DevOps Engineer (вакансія закрита) Також Sendios шукає DevOps-інженера рівня сеньйор. На посаді він допоможе команді впоратися з основними службами сховища даних та оптимізує рішення щодо їхньої доступності, затримки та перформансу; «переселить» програми на інфраструктуру на основі Docker, автоматизує процеси розгортання інфраструктури та вдосконалить систему моніторингу. Що для цього потрібно? Хороша технологічна підкованість: сильні навички адміністрування Linux, розуміння систем Unix/Linux, розуміння систем віртуалізації KVM (Proxmox), VMware, досвід роботи з MySQL та системами моніторингу на кшталт Zabbix, Grafana, Prometheus. iOS Developer Lift — це компанія-розробник мобільного фоторедактора на основі штучного інтелекту, що допомагає створювати візуальний контент малим підприємцям і диджитал-фахівцям. Її технічну команду посилить iOS-розробник рівня сеньйор, що працюватиме з функцією обробки відео, створить новий функціонал та обере оптимальні технології для стабільної роботи застосунку. Команда очікує, що людина вже знає Swift, Xcode Profile, розуміє багатопотоковість, а ще має досвід роботи з AVFoundation та Metal. Останнє стане перевагою під час найму. Android Developer (вакансія закрита) Команда Impulse розвиває застосунок для тренування мозку. Його версія на платформі iOS уже стала лідером у ніші Health&Fitness. Шукають фахівця, що з нуля зробить аналогічний продукт на Android. Не самотужки — в команді будуть ще 1-2 фахівці. Щоби приєднатися, важливо мати хороші знання з Kotlin та Java Core, Multithreading, Android SDK, попрацювати з Android Architecture Components та технологіями Coroutines + Flow й Jetpack Compose. Також згодяться розуміння принципів ООП, патернів проєктування, SOLID-принципів, а ще — досвід роботи з кастомними View, анімацією та Canvas. Не зайвими стануть приклади реалізованих застосунків у Google Play Market. Unity Developer (вакансія закрита) SUITSME розробляє інтерактивну платформу, яка об’єднує ігри та моду в одному застосунку. Розробник, що приєднається до команди, буде займатися ігровим процесом та функціями інфраструктури, братиме участь у розробці та впровадженні бекенд API та тісно співпрацюватиме з командою дизайнерів. Йому знадобиться мінімум 4 роки досвіду з Unity 3D і C#, знання найкращих практик збірки та контролю версій. Крім того, потрібен досвід інтеграції різних SDK в Unity, зокрема, Firebase, аналітики, рекламних мереж та вміння працювати з UniRX, UniTask, Zenject. Перевагу нададуть кандидатам, що менторили інших розробників, знають F2P, а також вміють оптимізовувати пам'ять та простір. Не знайшли вакансії для свого технологічного стека? Можливо, вона є серед інших вакансій компанії. Перегляньте їх за посиланням наприкінці тексту, а перед цим ознайомтеся з можливими питаннями на співбесіду для різних ґрейдів — у нас є матеріали про Golang, QA та JavaScript. Що почитати? 6 міфів про мобільну розробку. Спростовує iOS Engineer в Universe Мобільна розробка часто здається простішою, ніж інші, «серйозніші» напрями програмування. Але це не так — там чимало цікавих завдань і складних технологій. А ще багато хто думає, що застосунок можна зробити без коду, наприклад, через готові рішення в конструкторах інтерфейсів. Утім, розробникам так чи інакше доведеться працювати з кодом, аби все налаштувати. У матеріалі за посиланням — ще декілька міфів та їхнє спростування. Читати всім, хто думає, що ринок мобільних застосунків перенасичений і там більше нічого робити. 30 подкастів для техногіків і техногікинь Добірні подкасти для тих, хто уже загубився в різноманітті пропозицій від Apple Podcasts, Spotify та інших стримінгових сервісів. Тут і про венчур, і про штучний інтелект (так, ми теж від нього втомилися), і про останні новини. Окремий блок — подкасти із жінками в головних ролях. Одним словом — ось контент для дороги на роботу або для відпочинку наприкінці тижня.

Що питають на співбесіді у Golang розробників? В цьому тексті зібрано великий перелік поширених питань з теорії та практики для спеціалістів різних ґрейдів — Junior, Middle, Senior. Він буде корисним для підготовки до технічного інтервʼю та допоможе виявити прогалини в знаннях. Зазвичай кандидатам ставлять лише невелику частину питань із цього списку. Євген Кострика, Golang Developer у Boosters та Володимир Корнієнко, Back-end Engineer у Headway, партнерській компанії Genesis, поділилися, чим відрізняються співбесіди на різні позиції, а також пояснили, чого очікують інтервʼюери від кандидатів та на що звертають увагу. > Питання для Junior > Питання для Middle > Питання для Senior > Що почитати, готуючись до інтервʼю Питання для Junior Співбесіда для ґрейду «джуніор» зазвичай починається з низки загальних теоретичних питань. «На мою думку, це гарний спосіб почати інтервʼю. Це дає змогу зрозуміти, що ви говорите однією мовою. Наприклад, якщо кандидат не знає, що таке взагалі ООП, то, можливо, навіть немає сенсу продовжувати співбесіду, — ділиться Євген Кострика, Golang Developer у Boosters. Далі інтервʼюеру варто переходити до більш практичних питань, або таких, що корелюють з фактичною роботою, з якою стикнеться розробник. «Якось на співбесіді на попередню роботу мене протягом години «ганяли» винятково по теорії, щоби визначити мій ґрейд. На мою думку, це не зовсім обʼєктивно. Вважаю, що іноді тестові завдання можуть значно більше сказати про бекграунд розробника, ніж теоретичний квіз», — пояснює Євген. Робота джуніорів — суцільні стресові ситуації, з якими вони стикаються майже щодня. Тому на співбесідах інтервʼюери часто перевіряють реакцію — це можуть бути завдання з лайфкодингу або доволі складні питання. «В такому випадку звертають увагу не на саму відповідь (правильна вона чи ні), а на те, як кандидат реагує на труднощі, хід його думок та мотивацію», — каже Євген Кострика. Загальні питання 1. Які бувають типи баз даних? 2. Що таке HTTP-протокол? Як він працює? 3. Що таке статус-код у HTTP? Назвіть статус-коди, які знаєте? 4. Що таке патерн програмування? Які патерни ви знаєте? 5. Що таке процеси та потоки в операційній системі? 6. Які основні принципи ООП? 7. Що таке SOLID? 8. Поясніть, що таке Docker? 9. Що таке контроль версій і чому він важливий у розробці програмного забезпечення? 10. Опишіть життєвий цикл розробки програмного забезпечення? 11. Що означають різні фази життєвого циклу та які дії виконуються на кожній з них? Go 12. Які переваги має Go перед іншими мовами програмування? 13. Чи можете ви пояснити концепцію каналів у Go? 14. Як в Go реалізовано ООП? 15. Що таке goroutine? Навіщо вона потрібна? 16. В чому різниця між goroutine та потоками? 17. Назвіть види лапок в Go? Чим вони відрізняються? 18. Що таке slice? Як він влаштований? 19. Чим slice відрізняється від масиву? 20. Чи потрібно передавати slice по ссилці у функцію? 21. Як передаються змінні в Go? 22. Який розмір масиву виділяється під slice при його розширенні? 23. Що таке runtime? 24. Що являють собою рядки в Go? 25. Як можна оперувати рядками? 26. Чи можна змінити певний символ у рядку? 27. Що відбувається при склеюванні рядків? 28. Як визначити кількість символів для рядка? 29. Як працює базова функція append? 30. Якщо у функції є return, чи обов'язково вона поверне те, що зазначено в return? 31. Що таке пакети в Go? Які пакети ви знаєте? 32. Як працює сортування? Які знаєте допоміжні функції для сортування? 33. Поясніть, як працює оператор defer? 34. Який порядок виконання для кількох операторів defer у Go? 35. Чим defer відрізняється від інших операторів потоку керування в Go, таких як return і panic? 36. Як ви розумієте процес garbage collector в Go? 37. Що таке асинхронність? 38. Що таке конкурентність? 39. Що таке паралельність? 40. З якими сторонніми пакетами та фреймворками працювали? Опишіть свій досвід. Чому обрали саме їх? 41. Який порядок виконання операцій case у select? 42. Що таке type switch? 43. Як повідомити компілятор, що наш тип реалізує інтерфейс? 44. Яке у slice zero value? Які операції з ним можливі? 45. Чим відрізняється int від uint? 46. Що таке типовий int і які є аспекти його реалізації?" 47. Як перетворити рядок на int і навпаки? Чи можна зробити int(string) та string(int) відповідно? 48. Що таке константи? Чи можна їх змінювати? 49. Де константи розташовані в памʼяті? Map 50. Що таке map в Go? Чим відрізняється від інших структур даних? 51. Які є особливості синтаксису отримання та запису значень у map? 52. Як відбувається пошук по ключу в map? 53. Як додавати та видаляти пари ключ-значення з map в Go? 54. Що станеться, якщо ви спробуєте отримати доступ до ключа, якого немає в map в Go? Як це можна вирішити? 55. Чи можна зробити map з ключами різних типів у Go? Якщо так, то як це зробити? 56. Як перевірити, чи існує ключ в map? Який найефективніший спосіб це зробити? Інтерфейси 57. Що таке інтерфейс у Go? Яке його призначення та чим він відрізняється від структури? 58. Наведіть приклад реалізації інтерфейсів в Go? 59. Як ви оголошуєте інтерфейс у Go? 60. Чи можете ви навести приклад інтерфейсу, який визначає метод? 61. Як визначити тип інтерфейсу? 62. Що таке порожній інтерфейс? Як його можна використовувати? 63. Як переконатися, що ваш інтерфейс сумісний із кодом, який його реалізує? 64. Що таке поліморфізм у Go? Як інтерфейси підтримують поліморфізм у Go? Практичні завдання 65. Що виведе цей код? Чому? Які зміни треба внести, щоби програма вивела 42 и 13? 66. Що виведе цей код? Чому? 67. Що виведе цей код? Чому? Як його виправити? 68. Що виведе цей код? Чому? Як його виправити? 69. За який час умовно виконається програма — за 3 секунди чи за 6? Що потрібно змінити, щоби код працював за 3 секунди? Питання для Middle Ґрейд Middle — перехідна ланка. Тому в кандидатів так само можуть запитати теорію, дати завдання на кодинг. Від них очікують знання різноманітних нюансів горутин, тестування, синхронізації, роботи з мікросервісами та garbage collector. Також інтервʼюери часто мають спільний список питань для Middle / Senior, просто не очікують від мідла такої глибини аналізу та досвіду. Тому радимо кандидатам цього ґрейду також переглянути наступний розділ. 70. Які технічні недоліки Golang можете назвати? 71. Як зробити з масиву slice? Чи відсортується масив у сортуванні slice? 72. Припустимо, ваша функція повинна повертати деталізовані Recoverable та Fatal помилки. Як це зробити? 73. Що таке пакет testify? 74. Що таке пакет Mock? Для чого він потрібен? 75. Який мінімальний і максимальний розмір горутин? 76. Що буде, якщо розмір горутини перевищив допустимий максимум? 77. Чи однаково горутини ділять між собою процесорний час?" 78. Які є способи зупинити горутини? 79. Як налагодити зв'язок між горутинами? 80. Чи можна використовувати один і той самий буфер []byte у кількох горутинах? 81. Яка різниця між монолітною архітектурою та архітектурою мікросервісів? Наведіть приклад, коли варто кому віддати перевагу? 82. Які існують загальні стратегії кешування? 83. Поясніть концепцію рефлексії в Go. Як її використовувати для реалізації загальної структури даних або алгоритму? 84. Поясніть концепцію інтерфейсів у Go? Наведіть приклад, як ви використовували інтерфейси в проєкті, та як вони допомогли досягти ваших цілей? 85. Чи є для Go хороший ORM? Аргументуйте свою відповідь. Канали 86. Як можна використовувати канали для реалізації паралельного програмування, і які найкращі практики для цього? 87. Яких поширених помилок слід уникати під час використання каналів у Go? 88. Як можна використовувати буферизовані канали в Go для підвищення продуктивності, і які компроміси слід враховувати при цьому? 89. Як можна використовувати оператори select для обробки кількох каналів і уникнути блокування? 90. Які є альтернативи каналам для паралельного програмування у Go? Коли можна вибрати один підхід замість іншого? 91. Що таке буферизований та небуферизований канал? 92. Назви чотири аксіоми каналу? 93. Що буде, якщо писати/читати в nil канал? 94. Що буде якщо писати/читати/з закритий канал? 95. Що буде якщо писати/читати в/з буферизованого каналу? 96. Що буде якщо писати/читати в/з небуферизованого каналу? 97. Як закрити канал? Що з ним відбувається? Контексти 98. Що таке контекст? Для чого застосується? 99. Чим він важливий для паралельного програмування? 100. Чим відрізняється context.Background от context.TODO? 101. В чому різниця між context.WithCancel, context.WithDeadline, context.WithTimeout?" 102. Як можна використовувати контекст у Go для керування термінами та тайм-аутами? 103. Яких поширених помилок слід уникати під час використання контексту в Go? Памʼять 104. Як реалізовано сховище пам'яті Go? 105. Що означає * і &? 106. Як передаються параметри у функцію? 107. Чи є особливості поведінки під час передачі map і slice у функцію? 108. Як функції діляться пам'яттю? Garbage collector 109. Що таке garbage collector і за яким алгоритмом він реалізований в Go? 110. Коли запускається garbage collector?" 111. Які ресурси споживає garbage collector?" 112. Які переваги та недоліки має garbage collector? 113. Як можна налаштувати garbage collector в Go, щоби оптимізувати продуктивність і мінімізувати використання пам’яті? 114. На які типові проблеми продуктивності слід звернути увагу під час використання garbage collector? 115. Які є альтернативи garbage collector в Go для керування пам’яттю? Коли можна вибрати один підхід замість іншого? Синхронізація 116. Що таке пакет Sync і що він надає? 117. В чому різниця між Mutex і WaitGroup у пакеті Sync? 118. Що таке змінна Once і як вона використовується в пакеті Sync? 119. Що таке пакет atomic? Як використовується в пакеті Sync? 120. Як можна використовувати WaitGroup у пакеті Sync для синхронізації виконання кількох готурин? 121. Що таке Mutex і для чого він використовується? 122. Які існують типи Mutex? 123. Яка різниця між Mutex і RWMutex у Go? 124. Чи можете ви пояснити, як Mutex допомагає синхронізувати доступ до спільних ресурсів у Go? 125. Як Mutex отримує та знімає блокування в Go? 126. Що таке взаємоблокування і як його можна уникнути, використовуючи Mutex у Go? 127. У яких сценаріях ви б використали Mutex над WaitGroup у Go? 128. Чи можна реалізувати sync.Mutex та sync.WaitGroup у каналах? У який спосіб? Мікросервіси 129. Що таке мікросервіси? Чим вони відрізняються від монолітних архітектур? 130. Які переваги та недоліки використання мікросервісів? 131. Чи працювали ви з будь-якими фреймворками мікросервісів у Go? Опишіть свій досвід? 132. Як би ви вирішували наскрізні проблеми, такі як authentication and logging, в архітектурі мікросервісу? Опишіть моделі та інструменти, які ви б використовували? 133. Як би ви підійшли до тестування та налагодження архітектури мікросервісу? Опишіть стратегії та інструменти для виявлення та усунення проблем? 134. Як би ви впоралися з узгодженістю даних і транзакціями в архітектурі мікросервісу? Чи можете ви описати деякі шаблони та інструменти? Тестування 135. Що таке модульне тестування? Чим воно відрізняється від інтеграційного тестування та наскрізного тестування? 136. Як написати модульний тест у Go? Наведіть приклад простого модульного тесту для функції? 137. Як ви використовуєте mocking у своїх тестах? Наведіть приклад ситуації. 138. Як ви вимірюєте покриття коду у своїх тестах? Який інструмент ви використовуєте та як інтерпретуєте результати? 139. Як ви обробляєте залежності у своїх тестах? 140. Як написати тест для паралельного коду в Go? Наведіть приклад тесту для паралельної функції? 141. Як ви автоматизуєте свої тести? Який інструмент використовуєте та як інтегруєте його з пайплайном CI/CD? Практичні завдання 142. ​​Дано масив n x n, поверніть елементи масиву, розташовані від крайніх елементів до середнього елемента, рухаючись за годинниковою стрілкою. array = [[1,2,3], [4,5,6], [7,8,9]] snail(array)#=>[1,2,3,6,9,8,7,4,5] 143. Дано додатне число n > 1. Знайдіть розклад n на прості множники. Результатом буде рядок такого вигляду: "(p1**n1)(p2**n2)...(pk**nk)" з p(i) у порядку зростання та n(i) порожнім, якщо n(i) дорівнює 1. Example: n = 86240 should return "(2**5)(5)(7**2)(11)" 144. Реалізуйте функцію, яка отримує дві адреси IPv4 і повертає кількість адрес між ними (включно з першою, за винятком останньої). Усі введені дані будуть дійсними адресами IPv4 у вигляді рядків. Остання адреса завжди буде більшою за першу. * With input "10.0.0.0", "10.0.0.50" => return 50 * With input "10.0.0.0", "10.0.1.0" => return 256 *Withinput"20.0.0.10","20.0.1.0"=>return246 Питання для Senior Питання для розробників рівня сеньйор зазвичай стосуються архітектурних рішень, оптимізації, безпеки та вирішення різноманітних проблем системи. Інтервʼюер звертає увагу, які технології обирає кандидат для запропонованих рішень, як аргументує свій вибір, які бачить плюси й мінуси. Загалом від нього очікують глибокого розуміння, як працюють сучасні сервіси, та як їх будувати. «Мова програмування Golang дизайнилася, як проста та мінімалістична. Це не С++, в якому сеньйор і мідл дуже відрізняються за рівнем знання мови. Можна сказати, що починаючи зі «strong junior» до «senior» в Golang вже немає великої різниці у якості коду. Просто сеньйор більш концептуально розуміє проблеми, має глибокі знання, як все працює під капотом, ширше бачить проблеми та може запропонувати рішення на рівні архітектури — це ми перевіряємо на System Design інтервʼю», — пояснює Володимир Корнієнко, Back-end Engineer у Headway. 145. Як можна оптимізувати роботу програми Go? Опишіть поширені «вузькі місця», з якими ви стикалися, і як ви їх вирішували? 146. Розкажіть про ваш підхід до дебагінгу в Go? Які інструменти та стратегії вважаєте найбільш ефективними? 147. Як би ви впоралися з concurrency в програмі Go? Наведіть приклад використання вбудованих функцій паралелізму? 148. Розкажіть про ваш підхід до тестування коду Go? Які фреймворки та інструменти використовуєте? 149. Чи можете описати складну проблему, яку ви вирішили за допомогою Go? 150. Чи працювали з розподіленими системами в Go? Опишіть свій підхід до вирішення проблем мережі та узгодженості між кількома вузлами? 151. Як би ви розробили стійку до збоїв розподілену систему за допомогою Go? Які архітектурні моделі та стратегії ви б використали для забезпечення надійності та масштабованості? 152. Як би ви оптимізували вебзастосунок з високим трафіком? Опишіть поширені вузькі місця продуктивності та як ви їх вирішували? 153. Чи можете ви описати складну проблему паралелізму, яку ви вирішили за допомогою Go? Розкажіть про своє рішення? 154. Як би ви підійшли до налагодження складної багатопоточної програми Go з численними залежностями та службами? Які інструменти та стратегії ви б використали? 155. Скільки часу у хвилинах у вас займе написання процедури звернення однозвʼязного списку? 156. Що таке thread pool, якого він розміру та для чого потрібен? 157. Який, на вашу думку, найкращий спосіб зробити dependency injection? 158. Яка функція використовується для хешування в map? 159. Чому інтенсивна конкурента модифікація atomic призводить до помітного зниження продуктивності? 160. Ваші критерії вибору між GRPC та OpenAPI? 161. Який у вас улюблений логер? Які переваги має zerolog? Кешування та БД 162. Як реалізувати кешування в Go за допомогою популярних систем кешування? 163. Як можна оптимізувати запити до бази даних у Go і яких поширених пасток слід уникати? 164. Які існують стратегії обробки збоїв бази даних і як можна забезпечити високу доступність і відмовостійкість у розподіленому середовищі? 165. Як реалізувати LRU cache? 166. Які типи баз даних ви знаєте? Для яких кейсів кожна з них підходить? 167. Як масштабувати базу даних? 168. Які є методи зберігання даних? 169. Що таке індекси для бази даних? 170. Як можна виправити ситуацію, коли в системі велике навантаження? 171. Як використовується CD? 172. Як використовується load balancer? 173. Назвіть способи організації бази даних для зберігання медіа? Архітектура 174. Які шаблони проєктування ви використовуєте у своїй кодовій базі? Наведіть приклад. 175. Як ви керуєте залежностями у своїй кодовій базі? 176. Поясніть концепцію шлюзів API в архітектурах мікросервісів і як їх можна використовувати для покращення масштабованості та надійності? 177. Чи працювали ви з будь-якими фреймворками шлюзу API в Go? 178. Як би ви підійшли до розробки архітектури мікросервісу для нового проєкту? Які фактори ви б врахували, і яких шаблонів проєктування ви б дотримувалися? 179. Як ви гарантуєте, що ваш код масштабований і підтримується? 180. Як би ви гарантували безпеку програми Go з точки зору запобігання зовнішнім атакам і захисту конфіденційних даних? Розкажіть про свій досвід впровадження автентифікації та авторизації в Go? 181. Як вимірюєте продуктивність вашої архітектури? Які інструменти використовуєте для моніторингу та оптимізації системи? 182. Як ви гарантуєте, що ваша архітектура є гнучкою та адаптованою? Наведіть приклад того, як ви змінили свою архітектуру у відповідь на нові вимоги? Що почитати, готуючись до інтервʼю Книги An Introduction to Programming in Go, Caleb Doxsey The Go programming language, Alan A. A. Donovan, Brian W. Kernighan Go Design patterns, Mario Castro Contreras Level Up Your Web Apps With Go, Mal Curtis Concurrency in Go, Katherine Cox-Buday Go in Action, William Kennedy, Brian Ketelsen, and Erik St. Martin Learning Go, Jon Bodner Блоги https://microservices.io/ https://blog.Go.org/ https://grpc.io/ ​​https://tour.golang.org/ https://dave.cheney.net/

Нині у Spotify або іншій стримінговій платформі можна загубитися у чисельній кількості подкастів — авторських, колективних, з епізодами по 20 хвилин і бесідами на три години. Серед них є безліч подкастів про світ технологій. Аби скоротити нашим читачам час на пошук найкращих подкастів, ми запросили PR-менеджерку інвестиційного фонду Flyer One Ventures Еліну Коченко скласти список із 30 найкращих подкастів, які точно сподобаються усім, хто дотичний до IT. Еліна має власний досвід створення подкасту про міжнародний PR «Як це опубліковано», цікавиться розвитком та ринком подкастів. Ось підбірка за її рекомендаціями. Венчурний капітал і стартапи Стартап-кухня Аутсорс vs продукт, «скляна стеля» для жінок в IT, український венчурний ринок — деякі з тем, що зачіпає у подкасті автор Саша Ремінний у бесідах із героями. Саша — фаундер стартапу, який свого часу успішно придбав гігант автоматизації UiPath, та нинішній директор UiPath Ukraine. Буде цікаво послухати айтівцям, які планують реалізовувати власні ідеї у бізнесі та фаундерам-початківцям. Закрив раунд Головред AIN Ілля Кабачинський та директор клубу інвесторів ICLUB Global Антон Полєсков обговорюють tech-індустрію та новини світового й українського венчуру. Хочете дізнатись, як заробляють та скільки коштують найуспішніші технологічні компанії? Два класних сезони цього подкасту чекають на вас. Nextech Кожен випуск цього подкасту — півгодинний ґайд складовими стартапу. Можна дізнатись про все: валідацію ідей, роадмап, MVP, бізнес-стратегії тощо. Окремо рекомендую великий випуск про CustDev. Автор — український підприємець і бренд-стратег Влад Ноздрачов. How I Built this New York Times назвала кореспондента NPR Гая Раза найпопулярнішим подкастером в історії. Він досліджує історію успіху найбільших компаній у світі, зокрема технологічних. Можна дізнатися багато цікавого про те, як Dell, Cisco, Dropbox та інші стали гігантами індустрії. a16z Podcast Один із провідних венчурних фондів світу — Andreessen Horowitz — публікує власний подкаст про венчур і технологічну індустрію. Особливість подкасту — відсутність постійного ведучого. Для кожного випуску запрошують стартаперів, розробників, аналітиків, інвесторів, які розповідають про свої індустрії, технологічні рішення, обговорюють актуальні тренди на кшталт ШІ, метавсесвіту, хмарних технологій, креативної економіки тощо. The Twenty Minute VC Гаррі Стеббінгз записав перший подкаст у 17 років — запросив Гая Кавасакі в якості героя першого випуску. З того часу Гаррі попрацював у венчурному фонді Stride.VC, а згодом запустив власний фонд — 20VС. При цьому Стеббінгз не полишає місця ведучого подкасту і регулярно запрошує провідних фахівців із топових технологічних компаній — Meta, Uber, Ring, Canva, — аби поговорити про їх виклики та новини венчурної індустрії. 'The Future of Everything' by The Wall Street Journal Як алгоритми підкорюють світ і чи треба із цим боротися? Як люди в Арктиці отримують швидкісний інтернет? Навіщо потрібні технології та інновації у футболі? Як зміняться застосунки для навігації в майбутньому? Цей подкаст — неочевидний вибір для техногіків, проте в ньому обговорюється важливе — ідеї й тенденції, які в майбутньому будуть визначати вектор розвитку світової економіки. Штучний інтелект і машинне навчання In Machines we trust У майбутнє машин вірять у подкасті від MIT Technology Review — власного медіа Массачусетського технологічного інституту. Ведуча і продюсерка подкасту Дженніфер Стронг запрошує учених та фахівців із технологічних компаній, що працюють зі штучним інтелектом, щоби обговорити усі можливі аспекти використання й існування ШІ. Мене зацікавили випуски про розпізнавання облич, майбутнє голосових асистентів та використання ШІ у наймі. No priors Нещодавно створений подкаст (поки лише 8 епізодів) вийшов на новий рівень обговорення ШІ. Венчурні інвестори та підприємці Сара Гуо та Елад Гіл розмовляють із розробниками та бізнесменами про можливість перетворення штучного інтелекту (AI) на штучний сильний інтелект (AGI). Чому це цікаво? AGI — ступінь розвитку машини, коли вона здатна виконувати абсолютно всі задачі, на які спроможна людина. Так от, у подкасті шукають відповідь — коли AGI замінить AI? Які фактори до цього призведуть? Як це вплине на бізнес та суспільство загалом? На перший погляд, звучить нереалістично, проте герої подкасту переконають вас, що майбутнє ближче, ніж здається. Eye on AI Раз на два тижні кореспондент New York Times Крейг Сміт запрошує фахівців із провідних компаній, що займаються технологіями штучного інтелекту, і збирає інсайди та думки про майбутній вектор розвитку індустрії. Тут можна послухати бесіду із представниками Open.AI, які випустили той самий ChatGPT або ж астрофізика з Гарварду, який за допомогою ШІ створив віртуальні копії чорних дір, аби вивчати їх природу. Проєкт Інтелект Подкаст, створений українським науково-популярним медіа Куншт і компанією SQUAD. У перших двох «довоєнних» сезонах у подкасті вийшла низка цікавих епізодів про опанування ШІ українськими компаніями Respeecher, Petcube, Grammarly та іншими. У «воєнному» сезоні 2022 року ведучі обговорюють кібервійну, дрони, екзоскелети й подібні технології і рішення, якими б ми не цікавились за інших обставин. Тим не менш, раджу цей подкаст усім, кого цікавить прикладне значення ШІ і машинного навчання тут і зараз. Podcast.ai В цьому подкасті ви не почуєте нічого про штучний інтелект, проте можете послухати інтерв’ю легендарного фізика Річарда Фейнмана або Опру Вінфрі, яка розповідає про те, як бореться зі стресом. Теми епізодів різні, але об’єднує їх одне — всі вони створені штучним інтелектом. Текст, мова, звуки: цей подкаст повністю створила машина. Чотири круті епізоди — до вашої уваги. До речі, на сайті подкасту можна пропонувати теми та героїв для наступних випусків. Продуктове IT Product Thinking with Melissa Perri Консультантка зі створення цифрових продуктів та лекторка Harvard Business School Мелісса Перрі веде один з найпопулярніших англомовних подкастів про продуктове IT. Він точно зацікавить тих, хто вже розвиває власний продукт або планує розвивати. Є епізоди з фахівцями із різних доменів — від фінтеху до healthcare. Також рекомендую рубрику, де Мелісса сама відповідає на питання щодо різних аспектів IT-продукту: в неї є чому повчитися. Product&Growth Show Певно, один з найбільших українських подкастів про створення IT-продуктів. Топові фахівці з українських і світових tech-компаній «засвітились» в гостях у ведучих, Павла Педенка із Wise та Ярослава Степаненка із MacPaw. Серед героїв — спеціалісти із продукту в Google, Affirm, Genesis, Readdle, Restream, Awesomic, Competera та інших компаній. Яка б тема з продуктового IT вас не цікавила, ви знайдете відповідний епізод для себе в цьому подкасті. TechToloka Podcast Подкаст створила платформа TechToloka, яка розвиває культуру продуктового IT в Україні. Цікаво, що епізоди діляться на рубрики: у TechToloka Talks обговорюють різні аспекти створення і розвитку цифрових продуктів, у TechToloka Books — профільну літературу для розробників, продакт-менеджерів та фаундерів. TechToloka News — дайджест новин індустрії. Серед героїв випусків — СTO Readdle, Senior iOS Engineer в American Express, продакт-менеджер із Grammarly та багато інших цікавих фахівців. Як вам вдалося? Медіа Vector і Genesis Academy записали сезон, в якому топ-менеджери великих продуктових українських IT-компаній і фондів діляться своїми історіями успіху і невдач. Тут є класний епізод з Олексієм Єрмоленко із Flyer One Ventures, де можна дізнатися все про роботу інвестиційного фонду в Україні. Також мені сподобався випуск про те, яка команда працює над сервісом Дія, і яких оновлень слід в ньому чекати. Product Market Fat Українські продакт-менеджери Марк Опанасюк і Іван Чайка запрошують своїх колег-продактів із різних компаній та обговорюють все, що цікавить фахівців цієї спільноти — продуктова аналітика і стратегія, кастдеви, робота на ремоуті, продакт-кемпи, менторство та багато іншого. Якщо ви міддл+ спеціаліст у продакт-менеджменті, вам буде цікаво. В епізодах беруть участь продакти із Wix, Tumblr, Genesis, Jooble, Readdle тощо. Бульбашка Шоу Новий подкаст від Ігоря Соколова (LetyShops, Grammarly) та Євгена Плохого (Readdle). Обидва автори — директори с продукту з великим досвідом. У подкасті вони обговорюють болі і радощі фахівців із продуктового IT, намагаються зясувати, чи варто їм стерегтися ChatGPT, діляться досвідом застосування гейміфікації в неігрових продуктах та багато чого іншого. Наразі опубліковано чотири великі епізоди, рекомендую підписатися на оновлення, аби не пропустити наступні. Жінки у технологіях Woman in tech hosted by Espree Devora Еспре Девора — засновниця tech-ком’юніті WeAreLATech, яке з 2012 року організовує зустрічі для спільноти стартаперів і tech-підприємців Лос-Анджелесу. У подкаст вона запрошує жінок із технологічної індустрії — програмісток, фаундерок, інвесторок, які діляться своїми професійними історіями. Думаю, що історії про розробницю із Salesforce, аналітикиню з Loomio, продакт-дизайнерку із MIT можуть надихнути українських IT-фахівчинь із різних сфер не бачити «скляної скелі» та впевнено йти вперед. Advancing women in tech Американська громадська організація Advancing women in tech допомагає жінкам на сеньорних позиціях розвивати свою кар’єру в IT. Вони організовують менторство, освітні курси та нетворкінг для тих, хто вперше обіймає лідерську позицію або запускає свій стартап. Фокусуються на фахівчинях в розробці та продакт-менеджменті. В однойменному подкасті героїні обговорюють як прикладні теми, на кшталт бізнес-моделей, півотів, так і соціальні — сталий розвиток, diversity та багато іншого. Подкаст буде цікавий як жінкам-лідеркам, так і чоловікам — аби мати уявлення, з якими проблемами стикаються фаундерки та жінки-сеньори на професійному шляху. HerVantage У цьому подкасті беруть участь жінки-лідерки з бізнесу, науки, спорту у регіоні Південно-Східної Азії (SEA). Для тих, хто цікавиться технологіями, рекомендую епізод про фінтех-експертку з Сінгапурського фінтех-ком’юніті, а також засновницю венчурного фонду Capital A та її глобальну кампанію із залучення жінок з Азії (Малайзія, Сінгапур) у розробку та інші технічні спеціальності в IT. Новини технологій ​​DOU podcast Мій список рекомендацій буде неповним без найпопулярнішого подкасту про новини українського IT від ком’юніті DOU. Крім регулярних оглядів останніх подій в індустрії, бувають цікаві герої, обговорення професій в IT, а також є книжковий клуб, де фахівці із різних компаній і різних спеціальностей обговорюють профільну літературу. Reply All Легендарний подкаст про те, як інтернет впливає на людство, а людство — на інтернет, вже залишився в історії. Епізоди виходили з 2014 по 2022 рік. Якщо дослідити історію випусків, то можна знайти багато неочікуваних тейків про все в мережі: алгоритми TikTok, пошукова історія браузера як джерело даних, системи фільтрації контента на YouTube і так далі. Одним словом, все, що ви хотіли знати про інтернет. До випусків автори додають посилання на класні матеріали по темі у Vox, Bloomberg та інших топових виданнях. Exponent fm Подкаст від аналітика Бена Томпсона, автора блогу Stratechery, та Джеймса Олворта, директора з інновацій Cloudfare. Експерти обговорюють останні тренди світу IT і технологій зі стратегічної точки зору — що відбуватиметься із метавсесвітом, як змінює Substack споживання контенту, нову еру розвитку cloud computing тощо. Ведучі дискутують про складні речі, але добирають прості і зрозумілі тези і аргументи, при цьому зберігаючи здатність аналізувати події або тренди ґрунтовно. Технічні огірки Ведучі «огірків» — android-розробник, solution architect та CTO. Звичайно, більша частина тем і обговорень — навколо технічних тем, що буде точно цікаво розробникам рівнів middle і senior. Для нетехнічних фахівців — можна дізнатися багато цікавого про світ IoT, наприклад. Pi Tech В кожному епізоді подкасту постійні ведучі — розробник, technical writer і СЕО компанії Postindustria, — обговорюють новини IT і технологій в Україні й світі. Багато корисного тут для себе отримають саме технічні спеціалісти, а для тих хто не знає, що таке Linux, Azure і Unity — є цікаві епізоди про вплив світової економіки на розвиток технологій, розбір найгучніших кейсів із FTX і Twitter. Є й епізоди із запрошеними гостями — розробниками та дизайнерами. Spark with Nora Young Канадська tech-репортерка Нора Янг обирає не найочевидніші теми для свого подкасту про технології, і це робить його особливо цікавим. Наприклад, розкриває термін «диджитал-репресії», розповідаючи про те, як влада Ірану використовувала Інтернет, або збирає незвичайні кейси використання великих масивів даних в мистецтві (!). Нора, до речі, написала книгу про віртуальні дані та цифровий слід, який залишає в мережі кожен з нас. WSJ Tech News Briefing Якщо немає часу читати новини, можна їх послухати. Репортерка The Wall Street Journal Зої Томас випускає новий епізод щодня по буднях — із самарі та аналізом найважливіших новин. З останніх новин — Зої цікаво розповідає про причини падіння SVB, про те, як європейські регулятори планують організовувати законодавчу базу для метасвітів та продуктів на основі ШІ, про неформальний альянс американських tech-компаній, що об’єднуються проти поширення конкурентів з Китаю на ринку США. Кожен епізод триває 10-15 хвилин, достатньо для того, аби зрозуміти найважливіше. Tech Won’t save Us Теза про те, що технології — рушійна сила світу, вже вкорінилась настільки міцно, що альтернативні думки вважаються дивацтвом, особливо в технологічній спільноті. Тим не менш, подкаст канадського письменника Періса Маркса із досить скептичним поглядом на світ технологій, вже більше трьох років завойовує прихильників. Щотижня Періс запрошує гостей, які досить критично ставляться до IT-індустрії, і залишаються в опозиції до світу венчуру і технологій. Найвлучніше цей незвичайний подкаст описав ресурс Mashable — «здорова доза реалізму у ідеалістичному світі тотального панування технологій, який сконструювали всередині Кремнієвої долини». The French Futurist Цікавий і дуже relatable для українців подкаст від французького tech-підприємця Жана-Крістофа Боні. У березні 2022 року він заснував ГО «Team4UA», яка займалася впровадженням технологічних рішень для вирішення гуманітарних питань після початку війни в Україні. Сам Жан-Крістоф доставляв гуманітарну допомогу, і залишився в Україні, аби допомагати й фіксувати все, що відбувається. У кожному епізоді подкасту він спілкується із українськими технологічними підприємцями та чиновниками — про бізнес, війну, виклики та надії.

Перші хвилі обговорень ChatGPT уже вщухли, тож настав час поговорити про те, як новий інструмент вписався в робочі процеси. Фахівці компаній екосистеми Genesis також протестували чат у своїх доменах. За допомогою нового ШІ-інструменту вони автоматизували рутинні завдання, знайшли помилки в коді, розібралися в нових технологіях та знайшли відповіді на інші специфічні запити. Втім, у чату є і недоліки, які варто врахувати під час роботи. Разом зі співробітниками компанії розповідаємо, як ChatGPT покращує та інколи погіршує робоче життя. ChatGPT вміє агрегувати, редагувати та збирати інформацію, й, загалом, найкраще підходить для роботи з будь-якими текстами. Код — це теж текст. Втім, чату добре вдаються лише прості завдання. Зазвичай я використовую його, аби поверхнево ознайомитися з технологіями — наприклад, працюємо з AWS, а потрібно розібратися з Google Cloud, — або якщо потрібно вирішити точкову задачу на кшталт отримання методу чи класу. Це досить зручна альтернатива десяткам посилань у Google, на кожне з яких треба витратити мінімум пару хвилин. Сам запит варто формулювати якомога конкретніше, в ідеалі — з прикладами. Зараз уже є цілий сайт, на якому можна купити готові prompts (тобто мовні конструкції-запити) до ChatGPT за $3-4. Поясню, як вони працюють на простому прикладі. Припустимо, що ви створили презентацію, але формулювання занадто сухі та офіційні. Можна довго описувати зміни до кожного слова, а можна використати персонажа. Тобто, сказати чату: «Уяви, що зараз ти — Стів Джобс. Перепиши презентацію в його стилі». Чат добре впишеться й у повсякденність. Наприклад, за допомогою prompts я створив собі діалог з рекомендаціями фільмів: пояснив, у якому форматі потрібно надавати рекомендацію, та зазначив, що хочу оцінювати кіно через лайк та дизлайк. Важливо! Часто написати код вручну буде швидше й простіше, ніж детально описувати контекст. Наприклад, у запиті «напиши алгоритм сортування числового масиву» ChatGPT зрозуміє кожен термін та надасть ідеальну відповідь. От тільки подібних завдань у реальній роботі майже немає — все організовано більш комплексно з купою нюансів. Код ніколи не пишеться у відриві від цілей компанії. Їх розумітиме розробник, але поки не ясно, як описувати бізнес-логіку, аби її зрозуміла нейромережа. Тому, ChatGPT можна використовувати для написання окремих шматочків коду, але точно не для об’ємних класів чи цілих додатків. До того ж він може помилятися та фантазувати. Нещодавно я намагався згенерувати код, який буде визначати «якість» фото з урахуванням багатьох параметрів, як-от різкість, контраст тощо. В результаті отримав метод, який навіть не хотів запускатися. У OpenAI говорять, що база знань обмежується 2021 роком, проте фактично це не так — чат навчається у режимі реального часу. Однак я б не радив користуватися ним для роботи з інформацією, що може оновитися або втратити актуальність. Взаємодія з ChatGPT схожа на те, як Тоні Старк працював із Д.Ж.А.Р.В.І.С. Це такий собі розумний помічник, що може виконувати різноманітні команди. Нещодавно я почав користуватися ним майже щоденно. Як він може допомогти в роботі? Провести автотести. Раніше їх делегували фахівцям рівня трейні чи джуніор, зараз цим чудово може впоратися ChatGPT. Ізольований файл можна «завантажити» у чат, «попросити» зробити юніт-тести. Він далі сам створює mock і пише тест для коду, показує, яке у нього покриття тощо. Задокументувати код. У нас є стандарт — прописувати самарі до всіх файлів з кодом. Так кожен розумітиме, для чого потрібен той чи інший документ. Писати їх — досить буденне завдання, й воно часто робиться за залишковим принципом. Втім, його можна делегувати ChatGPT — він непогано аналізує та описує готовий код. «Підхопити» рутинні чи одноманітні завдання. Наприклад, у нас є запит на E2E-тести з тестувальниками. Для них потрібно зробити підготовчу роботу, тобто визначити різні конфігурації користувачів. І от я написав одну конфігурацію, додав у чат і попросив зробити інших 15 технік за аналогією. Ще один приклад — нещодавно я хотів зробити перформанс-тести, перевірити, наскільки швидко працює алгоритм. І щоб не писати ці тести, я «згодував» ChatGPT вимоги — й він досить швидко все автоматизував. Виправити помилки. Як виявилося, ChatGPT може допомогти зі «свіжими» кейсами, попри те, що його знання про світ після 2021 року досить обмежені. Наприклад, нещодавно ми зіштовхнулися з багом в оплатах Apple. Відповідно до документації, дані, мають віддаватися у певному форматі. Ми його дотримуємося, однак іноді підписки у деяких користувачів обробляються неправильно. Я описав проблему ChatGPT і виявилося, що це поле віддається тільки за певних обставин, не завжди, хоча в документації Apple цього не зазначали. Пояснити складний код, тобто підсумувати та описати, що саме він робить. GPT-4 працює з цим краще, вона загалом більш помічна для розробників. Зокрема, добре справляється з рефактором та підходить для складних завдань з великою кількістю даних. Важливо! З ChatGPT потрібно бути обережним у всьому, що стосується оновлень та нових даних, не покладатися повністю та завжди перевіряти написане. Він запросто поділиться неактуальною документацією чи згенерує стару версію, яка не буде працювати. Тому я б не радив фахівцям рівня джуніор та трейні писати код разом із ним — поки в них немає достатньо досвіду, аби відрізняти достовірну інформацію. Навряд чи нас всіх замінять роботи, але мені здається, що майбутнє саме за штучним інтелектом. ChatGPT як інструмент допомагає пришвидшити та оптимізувати купу процесів, а сліпе копіювання відповідей без розуміння, що ви робите, одразу впадає в око. Ось декілька кейсів, де чат допоміг… …знайти помилки. Якось я мала побудувати дашборд у DataStudio. Потрібно було вивантажити дані з MS Excel, а перед цим — розподілити їх за категоріями та відфільтрувати. Однак Excel категорично відмовлявся працювати коректно. Я ніяк не могла знайти причину проблеми, й вирішила «запитати» ChatGPT. Спочатку детально описала своє завдання, потім — формулу, яку використовую, і помилку, яку видає. Експеримент виявився вдалим — чат допоміг зрозуміти, де проблема. Єдиний нюанс — у подібних запитах потрібно прописувати, з якою версією Exel ви працюєте, бо синтаксис різних версій не однаковий. Іншим разом я мала виправити баг у нашій HR-системі. Вона написана на специфічній мові програмування, яка призначена конкретно для цієї платформи. Я точно розуміла, у чому баг, але не знала, як його виправити. Тут мені знову таки допоміг ChatGPT — він «вказав» на проблемне місце та надав варіанти рішень. …попрацювати з малознайомим інструментом. Колись давно я обрала для себе мову програмування Java. Однак для дипломної роботи в університеті вирішила використовувати Dart — вона кросплатформна і більш гнучка. І от мені потрібно знайти найкоротший шлях у зваженому графі, я знаю, яким має бути алгоритм, але не розумію, як прописати його саме на Dart. Я знову-таки звернулася до чату, щоб зрозуміти, як діяти. Окремо попросила задокументувати код та надати приклади використання, аби розуміти, що відбувається у кожному рядку. Формулювати запит влучніше допомагають тригерні фрази. Наприклад, «Дій, як [хтось]» або питання «Чи потрібні тобі якісь додаткові дані?» Тоді він надасть більш ґрунтовну відповідь на запит. Важливо! Проблема ChatGPT в тому, що він занадто самовпевнений й не завжди визнає свої помилки. Він може придумати статті або надати «биті» посилання, причому на пристойні сайти. Було таке, що з 15 посилань, які він надав, працювали лише три — всі інші вели на сторінки з помилкою 404. Або інша ситуація: нейромережа згенерувала відповідь на запит, але посилання на інформацію надавати «не хоче», пояснюючи це тим, що текст, який вона згенерувала, повністю унікальний. Тому це корисний інструмент, але не надто досконалий, щоб використовувати його без уваги людини. ChatGPT дуже прискорює процес ознайомлення і пошуку. Звичайно ж, всі відповіді потрібно перевіряти, але це точно швидше, ніж «чистий» пошук. В певний момент я зрозуміла, що уже не гуглю те, що мені цікаво, а просто «закидаю» питання у ChatGPT. Ось декілька завдань, з якими може допомогти ця нейромережа. Підготувати річний звіт. Точніше, запакувати його в патерн дизайн-мислення. Я готувала приклад для креативної техніки, мала готовий матеріал, але вирішила поцікавитися, чи може допомогти чат. Спочатку змоделювала ситуацію: «У мене є завдання — підготувати річний звіт. Хочу спроєктувати його за методикою дизайн-мислення. Що я маю зробити?». У відповідь чат досить непогано адаптував фреймворк до мого завдання: розказав про всі основні етапи, та пояснив, як працювати зі звітом на кожному з них. Написати скрипти для Adobe Illustrator. Програма дає змогу автоматизувати ряд процесів за допомогою скриптів. Більшість можна знайти у мережі, але не завжди вони підходять до конкретних специфічних завдань. Дизайнер, у якого я підгледіла цей метод, мав опрацювати декілька інфографік різними мовами: уніфікувати написання деяких символів та замінити шрифти. Він створив скрипт через ChatGPT й додав у Illustrator, трохи відредагувавши. На завдання пішло хвилин 30 замість декількох годин. Вирішити дрібні дизайн-завдання. Потрібно створити гіфку на прозорому фоні, колеги сплять, а Google видає дивні варіанти? Немає питань — ChatGPT сформулює два детальні та зрозумілі алгоритми, щоб вирішити це завдання. Знайти відповідь на специфічні запити. Нещодавно я почала працювати з Webflow й мала купу питань, в яких потрібно розібратися. Але є запити, коли навіть не розумієш, як краще це загуглити. Наприклад, треба було зробити анімацію елемента під час наведення мишки. Google тоді не дуже допоміг, а от ChatGPT — цілком. Я описала, яка анімація потрібна і запитала, як я можу це зробити. І отримувала покроковий мануал. Навчитися нового. Підібрати матеріали про розвиток дизайн-команди, доповнити лекцію про креативне мислення, розповісти про професію Design Ops, яку Google ще погано знає — з цим усім ChatGPT здатний впоратися. Важливо! Сильна сторона чату — це текст, а от у візуальному контенті він слабкий. Нещодавно я працювала над сайтом, і ніяк не могла придумати вдале оформлення блоку «Команда» на головній сторінці. Якраз тоді ChatGPT став доступним в Україні, і я вирішила його протестувати — хотіла знайти релевантні референси. Попри те, що я формулювала максимально конкретні запити з урахуванням дизайн-характеристик, належні варіанти нейромережа так і не знайшла. Думаю, що ChatGPT підбирав референси на основі коду, але навіть попри схожу структуру, дизайн подібних сайтів може суттєво відрізнятися. Знаю, що GPT-4 краще працює з зображеннями. Ми працюємо з SEO-контентом на новинних медіа сайтах, тому наші запити повʼязані з оптимізацією текстів під пошукові системи та кластеризування, а також написанням самарі, листів, повідомлень, метаданих, постів для соціальних мереж та JSON-LD скриптів. Можу сказати, що чат досить непогано генерує списки питань та відповідей на основі наших текстів, а далі може створити скрипт JSON-LD. У цьому випадку наш алгоритм такий: Даємо готовий текст і запит на п’ять запитань та відповідей на основі статті. Одержуємо список, редагуємо його за потреби. Надсилаємо запит на створення скрипту JSON-LD (FAQs). Отримуємо готовий код, який можна додати в CMS. Підхід для створення текстів для соціальних мереж дуже схожий, але можна ще «гратися» з tone-of-voice та створювати інтригу. Ось декілька інших сильних сторін чату, які я помітила: NLP-модель ChatGPT правильно інтерпретує запити користувача. Текст написаний дуже грамотно (хоча не ідеально). Є можливість придумувати ідеї для свого контенту. Відповіді досить релевантні — завдяки системі NLP, ключовим словам і механізму генерації відповідей. Під капотом — хороша база загальних знань та здатність пояснювати складні теми простими словами. Найскладніший виклик минулого місяця — це тестові завдання, виконані ChatGPT. Ми не проти використання штучного інтелекту для роботи — він чудово пришвидшує та автоматизує процеси. Однак якщо людина просто копіює те, що він написав, не перевіряючи — ми маємо відмовити такому кандидату. Помилки дуже легко відстежити, як і «авторство» нейромережі. Наприклад, одне з наших завдань звучить так: «Оцінити сайти з точки зору алгоритмів E-E-A-T and YMYL». ChatGPT в цьому випадку генерує неправильну відповідь, тому що знає лише модель E-A-T (розшифровується як Expertise, Authoritativeness, Trustworthiness — три фактори, які Google використовує для вимірювання ступеня довіри до сайту). Однак у грудні 2022 року Google оновився — і до алгоритму додалася ще одна E (тобто experience). У завданні кандидата другої E бракувало — ось і фактична помилка. Важливо! Чат має і низку слабких сторін. Ось вони: Основний масив даних зібрали до кінця 2021 року, тож інформація у відповідях на запити може бути застарілою. Буває так, що ChatGPT генерує неправдиву інформацію, й не каже про це, доки не запитаєш напряму. Іноді ChatGPT посилається на статистику та джерела, але якщо перейти за посиланням, то виявляється, що воно або дуже застаріле, або ніколи не існувало. ChatGPT добре вміє давати нечіткі описи та визначення, але рідко надає реальні деталі. Чат не здатний створювати контент на основі досвіду чи глибоких знань теми. А це необхідна складова стандартів контенту для пошукових систем. Нейромережа просто об’єднує уже доступну інформацію й сама собою не генерує унікальний контент — а це ще один «червоний прапорець» для Google. Ми декілька разів запускали один запит, і отримували майже однаковий текст, який при цьому ідентифікувався як матеріал з високим відсотком оригінальності. Якщо багато компаній почнуть використовувати подібні тексти, Google, ймовірно, песимізує весь такий контент. Якщо ви керуєте командою копірайтерів, потрібно обовʼязково прокомунікувати, яким чином можна використовувати ChatGPT в роботі. Він не годиться для генерації контенту з нуля, а якщо ним зловживати, матеріал можуть потрапляти під Google Update та опускатися нижче у видачі. Я використовую ChatGPT у двох напрямах — це робота з текстом та менеджмент освітніх проєктів. Перший підхід зрозумілий — чат допомагає дібрати більш вдалі формулювання, відстежити комунікаційні патерни, скоротити чи розширити текст або підкоригувати tone-of-voice. Наприклад, моя команда працює з університетами, тож буває, що нам потрібен академічний стиль. Другий кейс цікавіший — нейромережа допомагає брейнштормити «дорожню карту» освітніх курсів та ефективніше супроводжувати subject-matter experts (це професіонали, що мають провідні знання у своїй галузі) у їхній підготовці до лекцій та воркшопів. Як проєктні менеджери в освітній сфері, ми маємо конвертувати досвід та експертизу спеціалістів компанії в учбову програму. Водночас курси мають відповідати багатьом критеріям: вимоги партнерів та університетів, підготовка слухачів, навчальні цілі. Створення подібних програм — це багатоетапний процес, де потрібно вивчати десятки референсів, брифувати експерта, тож треба бути готовою хоча б приблизно орієнтуватися в його доменній експертизі. Це важливо, бо не завжди людина може декомпозувати свою експертизу, накласти на рівень підготовки аудиторії й запропонувати «дорожню карту» навчання. Це — задача проджект-менеджера, який також застосовує методичні та методологічні принципи для формування навчального шляху студента. Власне, ChatGPT виявився крутим інструментом, який допомагає якісно оптимізувати етапи дослідження та підготуватися до спілкування з доменними спеціалістами. Як це працює? Ось, наприклад, завдання — скласти програму з вивчення PHP для студентів. Раніше я робила величезне дослідження, переглядала десятки курсів, аналізувала логіку донесення матеріалу. Підготовка попереднього плану, який ми потім допрацьовували з доменними спеціалістами, займала від тижня до місяця. Зараз, завдяки ChatGPT, я сформувала його в десятки разів швидше. Спілкуватися починала з простого запиту на кшталт «склади програму для вивчення PHP», на що очікувано отримала досить загальну відповідь. Тоді поставила питання: «Які модулі потрібно включити до програми з вивчення PHP для початківців?». Чат видав більш конкретну відповідь й окреслив потрібні блоки. Далі я звужувала контекст: просила його надати короткі самарі навчальних програм найбільш популярних курсів PHP для початківців, питала, за яким принципом їх будують, та які навчальні цілі закладають. Паралельно я все одно робила власне дослідження та збираю референси. І до розробників уже йшла з готовим проєктом та проханням його валідувати. Звичайно, цей інструмент не зможе замінити ні проєктного менеджера, ні доменного спеціаліста, але він точно допомагає працювати швидше та якісніше. Важливо! При роботі з чатом варто пам’ятати принципи роботи моделі, на якій він побудований. Зокрема, що це генеративна модель. Тому, особисто я зараз приділяю час розвитку навички prompt engineering. Наприклад, один із базових прийомів — це «звуження контексту». Модель не може думати самостійно та враховувати всі обставини, тож свої питання важливо формулювати деталізовано. Наприклад, якщо я роблю запит «згенеруй план воркшопу на певну тему», я також одразу зазначаю, які навчальні цілі закладаю у такий воркшоп, які знання мають мої слухачі, і яких у них немає. ChatGPT — це мій асистент у створенні креативних ідей. Найефективніше — застосовувати його в роботі з різноманітними текстами. Наприклад, генерувати креативні заголовки. Чат дає безліч варіантів, які можна доповнювати чи адаптувати до певної тематики, треба тільки детально описати специфіку продукту та цільову аудиторію. Так само і з іншим неймінгом. Скоро ми плануємо зарелізити нашого маскота й зараз шукаємо ім’я. Нейромережа згенерує багато цікавих, якщо детально описати характер персонажа, продукт та загалом дати розгорнуте ТЗ. Поки ми не зупинилися на жодному, але маємо дуже класне джерело додаткового креативу. Що стосується менеджерської частини роботи, чат допомагає писати розгорнуті та дуже структуровані рев‘ю. Звичайно ж, подібні документи потрібно редагувати, надавати більшої персоналізації та деталей. Ще один підхід, який я використовувала — це самарі профільної книги. Її також можна оформити в презентацію, виділити основні тези — все це скорочує час та допомагає оптимізувати робочі процеси. А от ідеї для сценаріїв та ТЗ для моушн-дизайнерів виходять не надто оригінальні. Тут перевага точно за людиною, адже креативник має більше досвіду, експертність та надивлене око. Важливо! За чотири місяці роботи я дуже часто зустрічала помилки у відповідях. Буває так, що ChatGPT просто вигадує історії та видає їх за факти. Тому це класний допоміжний інструмент, але ставтеся до нього, як до бездоганно достовірного джерела. До того ж є сумніви щодо безпеки та захисту даних. Навіть сам ChatGPT застерігає від того, аби поширювати йому робочий код та інформацію з корпоративними даними.