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

Продакт-менеджери першими знаходять болі користувачів, та роблять все, аби їх позбутися, та вдосконалити продукт, з яким працюють. Однак вони й самі мають чимало складних моментів у роботі: нечіткі посадові інструкції, відповідальність за команду, невизначеність на шляху до ідеальних показників та інше. Про найбільш розповсюджені болі продакт-менеджерів розповідає Борис Куликовський, Product Manager у Keiki. Борис має чотири роки досвіду в продакт-менеджменті, розпочинав карʼєру з edtech-продуктів. В Keiki прийшов зі стартапу, де був кофаундером та займав позицію продакта. Будь-хто з продуктової команди може прийти до продакт-менеджера з ідеями. В ідеалі треба не просто запропонувати зміну, а й пояснити, навіщо вона потрібна і чим буде корисна. Проте часто люди приносять «сирі» ідеї в форматі «а давайте додамо ще один екран». Коли я починаю розкручувати думку й ставити навідні запитання, виявляється, що гіпотеза не збігається з бізнес-цілями або не приведе до очікуваного результату. Я займаюся вебпродуктом, де після першої покупки юзеру показуються екрани з апсейлами. Нещодавно один з членів команди запропонував збільшити delay для показу цього екрану на 10 секунд. Мовляв, тоді користувач трохи краще познайомиться з продуктом та зрозуміє, чи потрібні йому апсейли. Однак після обговорень ми зрозуміли, що за 10 секунд юзер не встигне дізнатися нічого суттєвого. Крім того, специфіка продукту така, що користувач після покупки має скачати матеріал, щоб почати взаємодію з застосунком, тож він не повертається у вебкабінет певний час. Відповідно, у нас є декілька секунд після для апсейлу — поки юзер знаходиться на туторіалі й тільки знайомиться з функціоналом. Переконати продакт-менеджера реалізувати свою ідею допомагає апеляція до найсильніших конкурентів («Вони нещодавно реалізували ось таку фічу, давайте теж спробуємо») або Customer Development, коли ми знаємо, що користувачів зацікавлять нові зміни. Уявімо, що ми плануємо додати ще один екран з опитуванням на онбордингу користувача, аби краще кастомізувати контент у застосунку. Однак, це може як збільшити залучення, так і спричинити обвал цієї метрики. Тест може бути як успішним, так і не дуже — і з цим нічого не поробиш. На початку це може демотивувати: тобі здається, що ідея класна, ви всією командою з ентузіазмом над нею працюєте, а результату немає. Однак невдалі тести — це така ж частина робочого процесу, як і інші завдання. Важливо вчасно відмовлятися від неробочих ідей та рухатися далі, а не пояснювати собі та іншим, чому все мало працювати інакше. Продакт-менеджер краще за інших розуміється на потребах бізнесу, тому його завдання — визначити, куди рухається команда, над чим варто працювати зараз, а що можна відкласти на потім. Інакше кажучи, розробити стратегію, або, як мінімум, сформулювати план дій і цілі. Буває так, що сам продакт не знає, який напрям виявиться успішним — треба просто пробувати. Водночас це не знімає з нього відповідальності за роботу команди. У людей виникатимуть питання — під час чи після реалізації змін — і продакт має знайти релевантні відповіді, аби мотивувати тих, хто з ним працює. У подібних випадках можна «поділити» відповідальність і чесно зізнатися, що ви робите щось уперше разом з усіма, і поки не знаєте, що буде далі. У книзі «Мислення швидке й повільне» Девід Канеман наводить історію про пожежників. Вони увійшли в охоплене полум’ям приміщення, й раптом їхній керівник закричав: «Йдемо звідси!». Щойно пожежники вибігли, підлога під ними обвалилася. Як виявилося потім, пожежа виникла поверхом нижче, у підвалі. Керівник одразу відчув небезпеку, проте у моменті не зміг пояснити, в чому вона проявлялася. Лише потім він усвідомив, що спека в приміщенні не співвідносилася з силою вогню. У продакт-менеджерів бувають схожі ситуації. Data-driven підхід дуже важливий, але іноді ти на 100% впевнений в успішності рішення, відповідних аргументів бракує — і їх доводиться винаходити. Таке трапляється, коли, наприклад, треба протестувати нове позиціювання, а грошей і часу для повноцінного, статистично значимого тесту нема. В такі моменти доводиться ухвалювати рішення на інтуїції або, як ми говоримо, «на чуєчку». Чим більше досвіду та надивленості, тим більше подібних рішень будуть вдалими. Втім, зловживати не варто. Я завжди намагаюся знайти пояснення, що ми робимо, та чому. Тоді, якщо тест спрацює, ми зможемо масштабувати результати, а якщо ні — зробити відповідні висновки та уникнути помилок у майбутньому. Під час custdev я можу запланувати собі на вечір десь п’ять інтерв’ю з юзерами. Скасовую всі інші зустрічі, підлаштовую плани, припускаю, якими будуть подальші кроки. А в результаті жоден не приходить на зустріч — хтось забув, у когось важливіші справи тощо. І це боляче. Та треба розуміти що це теж частина процесу. Для того, щоб мінімізувати такі кейси, перевірте воронку, за якою юзер реєструється. Можливо, з нею щось не так — і користувач хоче прийти, але не може. Я багато працював зі стартапами, які ще тільки шукають Product Market Fit або щойно знайшли й намагаються масштабуватися. На цьому етапі у вас тільки формується чітке уявлення про юзерів — хто вони, чим займаються, що їм подобається тощо. Це, по суті, експерименти, і, відповідно, результат, який важко або неможливо спрогнозувати. Далі, коли з’являється краще розуміння ринку та більший обсяг даних, стає простіше. Якщо продакт-менеджер недосвідчений, йому також буде важко спрогнозувати метрики чи фінансові показники, до яких приведе та чи інша зміна. Втім, з досвідом вам уже простіше пояснювати команді свої рішення. Ідеально, щоб змін, які ви не можете спрогнозувати ставало менше, ніж тих, які можете. Щодня продакту потрібно ухвалювати з десяток різноманітних рішень. Деякі з них прості та майже непомітні, як-от, перефарбовувати кнопку в інший колір чи ні. Деякі — комплексні та складні, наприклад, чи потрібно зараз виходити на ринок Латинської Америки. Останні можуть визначити успіх (чи поразку) на роки вперед. Ставки високі — і рівень стресу також. Часто нервове напруження спричиняє страх помилки: якщо гіпотеза буде невдалою, є ризик втратити довіру та авторитет. Однак якщо ви оберете шлях продакт-менеджера, ухвалення рішень та перевірка гіпотез стануть вашими щоденними робочими тасками. Тому уже на старті варто усвідомити: від помилок нікуди не дітися. Набагато важливіше, які висновки ви зробите. Я ділю невдачі на помилки й факапи. Перші робляться через незнання, другі — уже траплялися й повторюються постійно. Відповідно, варто приймати помилки та уникати факапів. Аби ухвалювати рішення швидше, я виділяю для себе декілька ключових принципів, які важливі для бізнесу просто зараз. Наприклад, чи принесуть конкретні зміни прибуток? Якщо на даному етапі гроші важливіші, всі рішення потрібно розглядати через цю призму. Можна зробити собі декілька подібних принципів, і вам буде простіше. Потрібно знайти Product Market Fit і розібратися з метриками? Чи треба ще й налагодити процеси та синхронізувати між собою усіх стейкхолдерів? У підпорядкуванні буде один розробник чи потрібно буде керувати цілою дев-командою? На старті продакт-менеджер має домовитися про те, чим він займатиметься в продукті чи бізнесі. Інакше кожен крок потрібно буде постійно проговорювати або серед тасок з’являтимуться додаткові завдання — а це боляче. У продакт-менеджерів можуть бути різні обов’язки. В одних бізнесах вони фокусуються на прибутку, тестують безліч воронок та роблять так, щоб сходилася юніт-економіка. У інших половину робочого часу займає управління ресурсами: поставити ТЗ розробникам, оцінити час на завдання, оптимізувати роботу QA-інженерів та дизайнерів. Обидва напрями можуть уживатися в одній компанії й навіть конкурувати між собою. Трапляються вакансії, де продактам треба відповідати й за гроші, і за процеси, але одній людині буде важко показати якісний результат за таких умов. Одне з завдань продакт-менеджера — скласти технічне завдання, за яким діятимуть розробники, коли будуть реалізовувати конкретну ідею та оцінити терміни виконання завдання. Щоби ґрунтовно описати суть завдання та сформулювати чіткі acceptance criteria, продакту потрібно набити руку. Інакше стається так, що розробник зрозумів завдання неправильно, деталі не узгодили — і на виході виходить зовсім не те, що очікувалося. А це призводить до зірваних термінів або конфліктів в команді. Must-have у подібних випадках — чіткі ґайдлайни для постановки завдань та acceptance criteria. У себе в команді ми випрацювали детальні шаблони, якими мають користуватися всі стейкхолдери, якщо чогось хочуть від розробників. Крім того, ми послідовно доносимо думку: коли є навіть мінімальні сумніви щодо того, як виконувати завдання — краще не соромитися та перепитати. Декілька набитих шишок — і ви вже знаєте, де слабкі місця у командній комунікації. Інший челендж — підтримувати уже відпрацьований механізм. Буває так, що всі про все домовилися, ТЗ гарні, acceptance criteria чіткі, але якесь завдання оформили пізніше, ніж потрібно — і процес поламався. Не те, щоб це критично впливало на продукт, але на «ремонт» доводиться витрачати додатковий час та ресурси.

9 жовтня стартує School of Digital Business 2.0 — курс від Genesis і Київської школи економіки (KSE) про створення та просування IT-продуктів. Учасники зануряться у сферу продуктового ІТ, опанують інструменти валідації ідей та побудови прибуткових бізнес-моделей. Практичною експертизою ділитимуться спеціалісти та топменеджери компаній з екосистеми Genesis, досвід академічного середовища — на стороні викладачів KSE. Курс підійде досвідченим менеджерам середніх та великих компаній, які прагнуть зрозуміти процес створення IT-продукту, навчитися інноваційних підходів до створення бізнесів та управління командами. «Обмін знаннями та досвідом — головний драйвер розвитку спеціаліста, сфери, ринку, економіки в цілому. School of Digital Business 2.0 надає унікальні знання та нетворкінг фахівцям із досвідом, які шукають можливості реалізуватися у технологічній сфері або перейняти найкращі практики світового IT-ринку для розвитку бізнесів, у яких вони працюють», — коментує Олексій Ніщик, Education Operations Director у Genesis. Програма обʼєднає підходи академічної освіти та бізнес-експертизу. Серед спікерів — керівники компаній з екосистеми Genesis, що займають лідерські позиції у світі у своїх нішах, та випускники PhD-програм найкращих університетів світу. «KSE вже не вперше виступає партнером Genesis у School of Digital Business. Це дуже якісна програма для розвитку талантів і підприємців в IT-секторі. Технології та інновації є важливими для нашої економіки під час війни й Genesis виховує майбутніх лідерів індустрії, тому ми щасливі бути партнерами в цій школі», — зазначає Тимофій Брік, ректор KSE. Курс містить 18 лекцій та 5 практичних завдань про цифрові продукти, маркетинг, аналітику, запуск та управління технологічними бізнесами. Учасники отримають особистий зворотний зв'язок, працюватимуть із менторами-спеціалістами у сфері, що зацікавить кожного учасника, і захистять фінальний проєкт — власний IT-продукт. Робота під час курсу буде як командною, так індивідуальною. Навчання відбуватиметься у гібридному форматі — онлайн та офлайн у київських офісах Genesis та KSE. Курс безоплатний, однак потрібно пройти конкурсний відбір із трьох етапів. Як потрапити Заявки на участь приймаються до 15 вересня 2023 року включно. Навчання розпочнеться 9 жовтня і триватиме до 8 грудня. Подати заявку та ознайомитися з деталями курсу можна за посиланням.

Гра SUITSME від однойменної компанії з'явилась в App Store і Google Play Market у листопаді 2021 року, й одразу потрапила до списку застосунків, рекомендованих Apple та Google у 44 країнах світу. Тисячі віртуальних предметів одягу від світових та українських брендів користувачі мають змогу приміряти на цифрову модель та складати безліч феншн-образів у грі. Нині застосунок завантажили понад 7 млн юзерів з усього світу, а загальний виторг компанії за два роки існування склав близько $10 млн. Створила і керує компанією Галина Єфремова, менеджерка проєктів за освітою та ідейна натхненниця геймдев-стартапів за покликанням. Про свій професійний шлях, історію створення SUITSME, а також про те, на що користувачі готові витрачати десятки тисяч доларів, Галина розповіла спеціально для корпоративного блогу Genesis. Зі стабільності корпорацій — у непередбачуваність стартапів Нині мені вдається розмовляти однією мовою з усіма технічними фахівцями в нашій компанії, проте моя власна математична підготовка завершилась ще у школі. Мій досвід у вищій освіті — суто гуманітарний. Спочатку я вступила на факультет перекладу Харківського політехнічного інституту, але швидко зрозуміла, що кар’єра перекладача мені не до вподоби. Магістратуру завершила за фахом «управління проєктами та програмами». Власне, саме проєктному менеджменту у різних сферах я присвятила багато років. Спочатку працювала у GlobalLogic, P&G, а згодом потрапила в управління телеком-проєктами: працювала в аутстафінгу, який створював великий телеком-продукт для данської компанії Telenor. Данці найняли дві компанії: українську для розробки фронтенду та китайську — для створення бекенду. На позиції департмент-менеджера я відповідала за всю розробку middle-layer та фронтенду, над якими працювали 150 фахівців. Це був дуже важливий досвід для розуміння процесів розробки, їх оптимізації, найму та скорочення команди тощо. Тоді мене цікавило управління командами, тому коли отримала запрошення на позицію менеджера з трансформації до іншої IT-компанії, не відмовилась. За пів року я переформатувала команду, змінила процеси, провела sales-аудит тощо. Згодом приєдналася до геймдев-стартапу Bini Games як консультант з управління проєктами. В той час їх команда швидко зросла з п’яти до 50 фахівців, а процеси й менеджмент не встигали адаптувати під такі стрімкі зміни. За деякий час топменеджмент стартапу запросив мене перейти до позиції СОО, і це дало можливість відкрити для себе інший бік IT-бізнесу, який зацікавив мене значно більше. Менеджмент команд різного рівня і конфігурацій я вже реалізовувала, це були знайомі й зрозумілі алгоритми, відпрацьовані купу разів. А от орієнтація на бізнес-складові, такий дух стартапу був для мене чимось новим і цікавим. В корпоративному світі є свої переваги, але потяг до підприємництва все ж таки визначив моє майбутнє. Геймдев-євангелістка У Bini Games я опікувалась, окрім операційки, ще й біздевом і маркетингом. Тоді ми починали запускати дитячі мобільні ігри та просувати їх через Facebook. Саме партнери з європейського офісу Facebook познайомили мене з топменеджерами Genesis, які також вивчали ринок дитячих застосунків. Вони запросили мене як консультантку для освітнього проєкту Keiki, який тоді тільки-но запустили. За пів року я мала допомогти команді досягти цільових KPI. У мене була вже непогана експертиза в застосуванні App Store Optimization для застосунків, а у Genesis — великий досвід у перформанс-маркетингу. Крім цього, мені дуже імпонував бізнес-орієнтований підхід до створення продуктів генезійських топменеджерів. Так я переїхала з Харкова до Києва. Консультувати стартап було і цікаво, і складно — ідей купа, але у проєкту є свій менеджмент, і нам доводилося шукати багато компромісів. Однак, я виконала свої KPI у Keiki, і до того ж у мене з’явилася власна ідея у сфері геймдеву, у яку Genesis був готовий проінвестувати. Я переконана, що ігри можуть потенційно заробляти більше, аніж застосунки. В останніх монетизація відбувається через підписки, а апсейлити — справа непроста. У грі основне джерело монетизації — внутрішньоігрові покупки, яких користувач може здійснити дуже багато, якщо гра його «затягує». Нині ми маємо кейси, коли користувачі в SUITSME реалізували покупок на десять тисяч доларів за пів року або рік. Звичайно, продукт, що монетизується шляхом покупок в грі, а не через підписку, робити непросто — треба багато працювати над довготривалим утриманням юзерів. Не дивлячись на це, ми не сумнівались, що нашою нішею має бути геймдев. Інша справа: я хотіла створити таку гру, в яку б із задоволенням грала сама — цікаву і якісно спроєктовану. Тоді однією з ігор, механіка якої мені подобалась, була скандинавська гра, де можна було створювати віртуальні інтер’єри. Робити аналог і вступати в перегони з продуктом, який вже отримав купу інвестицій і пішов далеко вперед у розвитку, не мало сенсу. Тому я вирішила створити гру зі схожими принципами, але у сфері моди. Це ж одвічне питання для багатьох жінок (та й чоловіків теж): не знаю, що одягнути; купила сукню/костюм, не можу знайти під них взуття й так далі. Із самого початку ми вирішили створювати ігровий застосунок, де користувач може експериментувати з аутфітами, брати участь в інтерактивних челенджах типу «Який одяг обрати для подорожі в Париж?» або «Як вдягнутись на інтерв'ю». Одразу стали розвивати ідею про те, щоби додати поради стилістів, можливість створювати віртуальні капсульні гардероби тощо. Це такі фічі, які дозволили б користувачам бачити, як та чи інша річ виглядає на моделі, перед купівлею. У серпні 2020 року ми запустилися з цим фешн-проєктом всередині екосистеми Genesis. Віртуальна шафа з брендовими сукнями В ніші фешн-ігор на ринку з 2013 року господарювала компанія CrowdStar та її гра Covet Fashion. Декілька років тому їх купив гігант геймдеву Electronic Arts. Covet Fashion має класні показники — близько $5 млн виторгу на місяць, величезну аудиторію, що «сидить» в ній по три-п'ять років. Здавалося б, гігантський конкурент, складно змагатись. Але, по-перше, їх історія дала нам важливе розуміння: в нашому жанрі можна затримати гравців на багато років. Retention — показник, в підвищення якого ми вкладаємо багато зусиль. По-друге, дизайн Covet Fashion все ж більше тяжіє до стилістики 2010-х років, а ми зрозуміли, що можемо робити сучасніше й цікавіше візуально. Крім того, ми проаналізували їх маркетинг, і знайшли точки росту, які Covet обійшли увагою, а ми змогли реалізувати. Майже одразу після початку роботи над SUITSME ми стикнулися з двома ботлнеками. По-перше, звідки брати віртуальний одяг? Для його створення потрібні фотографії реальних речей, а для їх використання потрібен дозвіл. Маючи лише прототип гри, ми почали стукатись до різних брендів із пропозиціями співпраці. Першим погодився надати фото італійський ритейлер Luisaviaroma. Таким чином у SUITSME з’явилися віртуальні копії одягу від Gucci, Prada та інших люксових брендів. Другий ботлнек, а радше неочікуваний інсайт: цільова аудиторія гри виявилась не зовсім такою, як ми її собі уявляли на початку. «Наші» жінки (звісно, більшість користувачів — жіночої статі) — це не дівчата двадцяти років, які слідкують за останніми трендами у моді та вдягаються у речі з найсвіжіших колекцій. В SUITSME грають жінки, що таким чином проявляють свою креативність. Здебільшого, це користувачки 35+, у яких часто є родини, діти, і немає великої кількості часу або ресурсів на те, щоби наряджатися в ультрамодні речі в реальному житті. Ми часто бачимо сесії по 30-40 хвилин всередині гри — стільки часу вони обирають речі, поєднують їх одне з одним, аби одягти віртуальну модель. У нас велике ком’юніті, наприклад, у Facebook, де юзери обговорюють свої образи в грі, обмінюються враженнями тощо. Вони дійсно сприймають це як можливість реалізувати творчі здібності та проявити свою індивідуальність. Найбільше користувачів — із США та Канади. Також багато грають з Австралії, Великої Британії та країн Західної Європи. Ще є досить велика спільнота гравців у Бразилії та Індонезії. SUITSME локалізована вісьмома європейськими мовами, включно з українською. Левова частка нашого заробітку — мікротранзакції всередині гри. Аби одягти модель, користувач має купити речі за внутрішньоігрову валюту. Він може або заробити її в процесі гри, або купити за реальні гроші, якщо не хоче витрачати час на «заробіток». Ще близько 15% нашого виторгу — рекламна монетизація. Нетипові генезійці SUITSME — не зовсім класичний генезійський стартап. Дещо нас відрізняє від колег з інших проєктів. По-перше, ми full-remote компанія. Ще до повномасштабної війни ми частково перейшли на віддалену роботу, а після лютого 2022 року — повністю. Нині у нас в команді працюють фахівці з різних куточків світу. Напевно, ми вже не повернемось до офісного формату. Так сталося частково через те, що від початку у нас майже не було джунів на проєкті. Я свідомо наймала фахівців міддл+, тому що переконана, що з джунами важко будувати стартап з нуля. А фахівці з досвідом, яким вже давно не двадцять років, менш зацікавлені в офісних тусовках і подіях, їм здебільшого комфортніше працювати віддалено. Такий підхід склався у нас органічно, виходячи зі складу команди й обставин. Ми налагодили всі процеси на ремоуті не гірше, ніж офлайн, робимо віддалені тимбілдинги, використовуємо Jira, Slack та інші інструменти, аби все ефективно заметчити. По-друге, основна мова спілкування і ведення документації в SUITSME — англійська. Так теж було від початку, тому що одним з перших фахівців на проєкті був геймдизайнер-грек. Одразу було зрозуміло, що корпоративною мовою треба обирати найбільш універсальну. Я завжди працювала в міжнародних компаніях, і мені здається, що мультикультурність в команді — це додаткова цінність, яка дає змогу людям побачити різні підходи, різний майндсет, дізнаватись нове і ділитись досвідом одне з одним. Крім того, це дає можливість наймати різних спеціалістів по всьому світу — з досвідом роботи в компаніях-юнікорнах, наприклад. По-третє, у нас абсолютно пласка структура — в мене немає співзасновників, немає С-левела взагалі. Спойлер: я планую це змінювати в майбутньому, але для такого підходу були свої причини. Я вважаю, що авторитет не можна отримати автоматично, коли тебе назначили тимлідом, його можна лише заслужити серед колег. До того, як в компанії стало 15-17 співробітників, у нас взагалі не було жодної ієрархії. Була я і всі репортили безпосередньо мені. З ростом команди я виділила тимлідів: тих, хто вже зарекомендував себе у команді. Поки я не поспішаю призначати або наймати CTO, CMO та СОО. Якщо призначати С-левел у команді з 50 фахівців, то може статися так, що, коли команда зросте до 100 або 200 людей, потреби й запити до С-левела будуть зовсім інші, ніж раніше. Нині у нас близько 40 співробітників, і попереду перехідний період, коли треба буде операційно переформатовувати процеси й команди. Більшість фахівців працюють у SUITSME із самого початку, вони значно виросли професійно, тому мені важливо зробити так, аби їм було комфортно працювати й вони могли реалізовувати свій потенціал. Одна з цінностей компанії — people for people, і це не лише про наш продукт, а й про простір для реалізації всіх членів команди.

Як проходить співбесіда з Unity Developer? Ми зібрали великий перелік поширених питань для спеціалістів різних ґрейдів — Junior, Middle, Senior. Він допоможе виявити прогалини у знаннях та заповнити їх, готуючись до співбесіди. Сергій Потапов, Head of Engineering в Keiki та Юра Нероба, Unity Tech Lead в Holy Water поділилися, як проходять технічні інтервʼю в їхніх компаніях, на які хард та софт-скіли звертають увагу, чому в геймдеві знадобиться прикладна математика, UI та бізнес-логіка. > UI, оптимізація та бізнес-логіка — як наймають в Keiki > Прикладна математика та UI — як наймають в Holy Water > Питання для Junior > Питання для Middle > Питання для Senior UI, оптимізація та бізнес-логіка — як наймають в Keiki Keiki — освітній застосунок для дітей, і ми маємо досить специфічні вимоги до найму розробників, пов'язані зі специфікою ніші. У нашому проєкті немає складних ігрових механік, тому для нас не так важливі глибокі знання фізики, роботи з 3D, мультиплеєром, що може бути невід'ємною складовою для роботи над AAA ігровим проєктом. Водночас кількість контенту в застосунку — велика, і постійно збільшується. Через це для нас важливо, щоб кандидат знав, як оптимізувати продуктивність і вагу застосунку. Також ми прагнемо забезпечити зручну і приємну взаємодію користувача з продуктом, тому необхідно, щоби розробник вмів збирати складний та адаптивний UI. Ми не використовуємо фіксований перелік питань і формуємо його, виходячи з вимог до позиції, досвіду кандидата, виконаного тестового завдання. Водночас кожна співбесіда складається з питань про Unity, C#, архітектуру. Від кандидатів ми очікуємо розуміння того, як працює двигун Unity: життєвий цикл об'єктів, їхні види, принципи роботи ієрархії та розміщення об'єктів на сцені. Важливо, щоби кандидат розумів, як працює рендеринг, робота з пам'яттю, і вмів оптимізувати ці процеси. Також ми перевіряємо знання C#, принципів та патернів програмування. Навіть джун повинен вміти писати чистий і зрозумілий код, який можна масштабувати. Окрему увагу звертаємо на підхід кандидата до розробки й вміння розв'язувати проблеми. Наприклад, як кандидат діятиме в умовах нестачі часу? Що є першочерговим — вирішення бізнес-задачі чи дотримання принципів програмування та чистого коду? Де треба приділити більше часу і зробити якісно, а де треба зробити швидко і «брудно». Ми шукаємо людей, які за допомогою своїх знань можуть приймати ефективні рішення і виконувати задачі бізнесу. У Keiki ми приділяємо багато ресурсу розвитку команди та культури розробки. Тому на співбесіді звертаємо увагу на мотивацію людини, її софт-скіли і Team Fit. Нам важливо, щоб людина знала, чого хоче, прагнула розвиватися разом із командою, привносити нові знання і рішення у продукт й при цьому вміла знаходити спільну мову з колегами, критикувати та пропонувати рішення. Прикладна математика та UI — як наймають в Holy Water Зазвичай технічне інтервʼю складається з питань з розробки, C#, Unity, Математики. Крім навичок програмування та інструментів, в геймдеві важливо мати базові знання з лінійної алгебри та тригонометрії. Важливо бути знайомим з концепцією кватерніонів, знати, як відбуваються операції з векторами, матрицями. Але ключове тут — розуміти, як ці знання застосувати на практиці. Кандидат має не просто вміти обчислити скалярний добуток векторів, а знати навіщо це в розробці. Питання з математики допомагають правильно оцінити рівень розробників, зокрема тих, хто опановував професію самостійно. Кандидатам, які вивчали лише код, зазвичай складніше знайти рішення, вони часто вирішують проблеми через вигадування велосипедів або методом «милиць». Питання залежать від ігрового жанру та напряму, в якій працює компанія. В певних компаніях буде фокус на роботу з 3D, а в інших з цієї теми не поставлять жодного питання. Holy Water створює продукт в жанрі візуальних новел. Ми використовуємо єдиний список питань для всіх ґрейдів різної складності. Кожне інтервʼю проходить індивідуально, спираючись на досвід кандидата та його відповіді. Питання можуть варіюватися: більш заглиблюватися в окремі теми або пропускати нерелевантні. Кандидат має добре знати, як працює мова C#, середовище Unity, відповідно до свого рівня вміти пояснити принципи SOLID, DRY, KISS тощо. По Unity ми питаємо про власний комерційний досвід, на яких проєктах працював, чим займався, який досвід роботи з UI-елементами. На багатьох проєктах UI — це те, що робиться зазвичай в останню чергу і поспіхом, але для нашого проєкту це важливо. Тому один з критеріїв відбору — наскільки добре кандидат знає, як працювати з UI, як його налаштовувати, які в цьому процесі є підводні камені тощо. Якщо кандидат не знає відповіді, можна просто зізнатися в цьому. Або спробувати прикинути: «якщо щось інше працює за схожим принципом, це повинно працювати так само». Той, хто шукає відповідь, проводить аналогії та старається сформувати гіпотезу, завжди отримує додатковий плюс, навіть, якщо дає неправильну відповідь. Питання для Junior C# 1. Які принципи ООП ви знаєте? Як вони реалізовані в C#? 2. Що таке класи, структури даних та колекції? 3. Яка між ними відмінність? Поясніть місця використання кожного поняття. 4. Поясніть, що таке масиви? 5. Є два масиви: на 200 та на 2000 елементів. Якщо з першого треба взяти 190 елемент, а з другого 1900, ці операції займатимуть різний чи однаковий час? Чому? 6. Чи можна додати елементи до масиву? Як? 7. Якщо у нас є змінна, яка має тип абстрактного класу, об'єкти якого типу ми можемо помістити в неї? 8. Для чого потрібні інтерфейси? Наведіть приклади використання. 9. Що таке модифікатори доступу та ключові слова? 10. Readonly, const, virtual, override, abstract, ref, out, lock — що це означає? Де використовується? 11. Що таке Generic методи? Наведіть приклади використання? 12. Як відбувається перевантаження таких методів? 13. Які структури даних ви знаєте? 14. Array, List, Dictionary, Queue, Stack — яка між ними різниця? 15. Як вони влаштовані та де які структури краще використовувати? 16. Яка різниця між event та delegate? 17. Для чого використовуються Action Func i Predicate? 18. JSON — що це? Для чого використовується? 19. Що таке серіалізація та десеріалізація? 20. Які ви знаєте атрибути? Як вони працюють? 21. Що таке івенти? Як вони викликаються? Git 22. Як влаштований репозиторій? 23. Які команди ви використовували? 24. У чому різниця між commit та push? 25. Чи є досвід вирішення конфліктів в Git? Які стратегії використовували? Unity 26. Що таке Unity і які його основні особливості? 27. Що таке ігровий двигун? 28. Що таке gameobject? 29. Що таке сцена? 30. Префаби — що це і для чого? 31. У чому різниця між сценою та префабом в Unity? 32. Що репрезентують префаби? В чому відмінність від ScriptableObject? 33. Які є компоненти в Unity? 34. Яка послідовність виклику методів в скриптах Unity? 35. Що таке життєвий цикл Unity? 36. Що таке MonoBehaviour? Опишіть його життєвий цикл? 37. В чому різниця між Update, FixedUpdate та LateUpdate? Які з ними є проблеми та які існують альтернативи? 38. Які є базові класи в Unity? Для чого вони використовуються? 39. Що таке Coroutine, де вони «живуть»? 40. Для чого використовується IEnumerator? 41. Як використовуються GetComponent, Find? 42. Які є плюси та мінуси використання GetComponent, Find? Які є схожі методи? 43. Як ви реалізуєте рух об'єкта в Unity? 44. Які є основні кроки для створення анімації в Unity? 45. Як ви реалізуєте зіткнення (collision) об'єктів в Unity? 46. Як ви використовуєте скрипти для взаємодії з об'єктами в Unity? 47. Як ви реалізуєте мультиплеєр в Unity? Math 48. Sin, Cos, Tan, Cotan — як знайти та для чого використовуються? 49. Що таке вектор, як його знайти? 50. Що собою представляє довжина вектора? 51. Що таке нормалізація вектора? Як її обчислити? 52. Як відбувається додавання та віднімання векторів? 53. Що таке скалярний добуток? 54. Що таке кватерніон? Як він репрезентується? 55. Яким чином кватерніон можна використовувати замість кутів Ейлера? 56. Що таке матриця? Прикладне використання в геймдеві? 57. Як здійснюється множення та додавання матриць? 58. Як обчислити матрицю повороту на кут? Питання для Middle C# 59. Чого вам не вистачає в С#, що є в інших мовах? 60. Чим відрізняється модель пам'яті С#? 61. Назвіть принципи розробки клієнт-серверних застосунків на прикладі ігор? 62. У чому відмінність інтерфейсу від абстрактного класу? 63. У чому відмінність між значеннями та посиланнями в C#? 64. Що таке namespaces в C#? Як вони використовуються? 65. Які є особливості наслідування в C#? 66. Як ви реалізуєте поліморфізм в C#? 67. Інкапсуляція — поясніть, як застосовували на практиці? 68. Абстракція — поясніть, як ви застосовували на практиці? 69. Що таке делегати? Як вони використовуються в C#? 70. Які є особливості обробки винятків (exception handling) в C#? 71. Як ви керуєте пам'яттю в C#? 72. Як працює Garbage Collector в C#? 73. Що таке async/await Task? 74. Як працює механізм асинхронності в C#? 75. Як працює механізм рефлексії, де використовується? 76. Що таке компілятор? Які основні функції він виконує в C#? 77. Що відбувається під час компіляції C# коду? 78. Які вихідні файли виходять після компіляції? 79. В чому різниця між компіляцією та інтерпретацією програмного коду? Які переваги та недоліки кожного підходу? 80. Що таке Intermediate Language (IL)? Як він використовується в C#? 81. Розкажіть, що таке Common Language Runtime (CLR). Як він впливає на виконання C# коду? 82. Як ви можете перевірити, чи правильно компілюється ваш C# код перед запуском програми в Unity? Unity 83. Які плюси та мінуси Unity ви можете назвати? 84. Опишіть свій досвід роботи з Particle System, його механізм роботи. 85. Опишіть свій досвід роботи з вбудованими анімаціями та твінами. Які проблеми можуть виникати під час використання перших і других? 86. Що таке Camera.main? 87. Які є види камер в Unity та налаштування до них? 88. Що таке Матеріали, для чого використовуються? 89. Як працює механізм Layers? Яка різниця з Тегами? 90. Що таке профайлер? 91. Як працює фрейм дебагер? 92. Які є налаштування текстур в Unity? 93. Як працює серіалізація об'єктів? 94. Що відбувається на старті гри? 95. Що таке шейдери (shaders) і як вони використовуються? 96. Як створити новий шейдер? Опишіть свій досвід використання. 97. Що таке API Editor? Поділіться досвідом написання власних допоміжних засобів в Unity. 98. Які є можливості рендерингу в Unity? 99. Як ви створюєте скелетні анімації (skeletal animations) для персонажів в Unity? 100. Як ви використовуєте механіку зв'язків (constraints) для контролю руху об'єктів? 101. Як ви реалізуєте перехід між анімаційними станами (animation states) в Unity? 102. Чи користувалися ви компонентом Rigidbody в Unity? Опишіть свій досвід. UI 103. Назвіть основні компоненти Unity UI? 104. Опишіть досвід роботи з різними UI компонентами? 105. Які є методи групування об'єктів в Unity UI? 106. Опишіть можливі проблеми використання вбудованих компонентів? 107. Що таке Canvas? Опишіть його плюси і мінуси? 108. Опишіть свій досвід верстки адаптивного інтерфейсу. 109. Що таке LayoutGroup? 110. Який порядок відмалювання UI елементів? 111. Яке призначення систем подій (event systems) в Unity UI? 112. Як системи подій допомагають забезпечити взаємодію між елементами інтерфейсу та сценаріями? 113. Як ви реалізуєте власний елемент інтерфейсу (наприклад, панель здоров'я) з використанням системи інтерфейсу Unity? 114. Розкажіть про відмінності між компонентами UI Text в Unity та TextMeshPro. В якому випадку який з них ви б обрали? 115. Поясніть значення порядку сортування Canvas Sorting Order. Як він впливає на відображення елементів інтерфейсу? Бізнес-логіка 116. Опишіть свій досвід роботи з Third Party Services. 117. Розкажіть про досвід інтеграції рекламних сервісів (наприклад, AdMob) в ігрові застосунки. 118. Розкажіть про досвід інтеграції аналітичних сервісів (наприклад, Firebase Analytics) для збору даних? 119. Як ви керуєте соціальними сервісами (наприклад, Facebook SDK) для обміну даними та досягненнями між гравцями? 120. Як ви оновлюєте сторонні пакети на Unity до новіших версій? Які підходи ви використовуєте, щоб уникнути конфліктів і несумісностей? 121. Як можна використовувати ремоут-конфіги для налаштування геймплею, механік гри або інших параметрів? 122. Які інструменти або сервіси ви використовували для налаштування ремоут-конфігів? 123. Що таке Unity Web Requests? 124. Опишіть свій досвід роботи з клієнт-серверною взаємодією. Математика 125. Які математичні принципи використовуються при розрахунку траєкторій руху об'єктів в грі? 126. Як обчислити відстань між двома об'єктами в тривимірному просторі? 127. Як розрахувати кут між двома об'єктами або векторами? 128. Як обчислити інтерполяцію між значеннями для плавних анімацій у грі? 129. Як ви розрахувати оптичні ефекти у грі, такі як відображення reflection чи refraction світла? 130. Як знайти вектор, перпендикулярний двом векторам? 131. Запропонуйте алгоритм, який видає елемент з масиву, залежно від вірогідності його випадіння. Архітектура 132. Розкажіть про досвід реалізації MVC, MVP, шарів в архітектурі. 133. Що таке події в C# і Unity3D? 134. Що таке ObjectsPool в проєктуванні? 135. Патерни Commands, ServceLocator, Singletone — опишіть суть та як використовувати? 136. Принципи SOLID — опишіть своїми словами, для чого навіщо вони потрібні. 137. Що таке Dependency Injection (DI)? Яка його роль в розробці ігор або додатків на Unity. 138. Розкажіть про основні переваги використання IoC-контейнера. 139. Як ви імплементуєте IoC-контейнер в Unity? Питання для Senior Оптимізація 140. Які є способи оптимізації під різні платформи? 141. Опишіть головні виклики, які виникають під час оптимізації ігор для мобільних пристроїв. Як ви їх вирішували? 142. Розкажіть про техніки управління розміром текстур та компресії зображень для зниження використання пам'яті. 143. Як ви використовуєте Level of Detail (LOD) для забезпечення оптимізованого рендерингу на мобільних пристроях? 144. Яким чином ви оптимізуєте шейдери для підтримки різних мобільних пристроїв? 145. Які підходи ви використовуєте для управління об'ємом об'єктів на сцені для оптимізації продуктивності? 146. Як ви тестуєте продуктивність гри на різних мобільних пристроях, і які критерії використовуєте для оцінки продуктивності. С# 147. Розкажіть про асинхронне програмування в C#. Які ключові слова та механізми ви використовуєте для роботи з асинхронним кодом? 148. Яким чином ви здійснюєте обробку винятків в C#? Розкажіть про рекомендовані підходи до керування винятками у ваших проєктах. 149. Які прийоми ви використовуєте для забезпечення безпеки та захисту даних? 150. Поясніть концепцію качиної типізації. Як цього досягти в C#? 151. Яка різниця між методами GetHashCode і Equals у C#? 152. Поясніть клас Tuple і варіант його використання в C#. 153. Що таке локальні функції в C# і як їх можна використовувати? 154. Що таке LINQ (Language Integrated Query) і як ви його використовуєте для роботи з колекціями та запитами у C#? Архітектура 155. Які принципи архітектури програмного забезпечення ви застосовуєте у своїх проєктах Unity? 156. Розкажіть про архітектурні шаблони, які ви використовуєте в ігровій розробці. 157. Як ви розділяєте логіку гри та інтерфейс відображення (UI) у своїх проєктах? 158. Яким чином ви розбиваєте ваші проєкти на модулі або підсистеми для полегшення розробки та підтримки? 159. Як ви організовуєте комунікацію між різними системами або модулями? 160. Які інструменти або фреймворки ви використовуєте для побудови архітектури у своїх проєктах Unity? 161. Як ви керуєте станом (state management) гри та об'єктів у вашій архітектурі? 162. Як ви розгортаєте і керуєте системами у вашій архітектурі, такими як система аудіо, система фізики тощо? 163. Як ви здійснюєте інтеграцію зовнішніх сервісів та сторонніх SDK у своїх Unity-застосунках? 164. Як ви організовуєте систему обробки івентів та реакції на різні геймплейні події у своїх іграх? 165. Розкажіть про свій досвід у впровадженні аналітики та збору даних про поведінку користувачів для аналізу продуктивності та удосконалення геймплею. 166. Як ви підходите до тестування гри або застосунку в Unity? Розкажіть про використані методики. 167. Як ви оцінюєте ефективність геймплейних механік та ігрових систем? 168. Як ви обробляєте аудіо у своїх ігрових проєктах? Розкажіть про використання звукових ефектів та музики. 169. Як ви реалізуєте систему керування гравцем у вашому ігровому проєкті? 170. Як ви створюєте систему збереження прогресу та управління станами гри? 171. Як використовуєте алгоритми для генерації рівнів гри?

Добірка вакансій серпня — пропозиції для аналітиків. У різних командах бізнесів екосистеми Genesis фахівці на цих позиціях шукають цінні продуктові інсайти, будують гіпотези, працюють із маркетинговими кампаніями та відстежують стабільність приймання платежів. А головне — допомагають бізнесу приймати data-driven рішення та зростати. Гортайте підбірку та знайомтеся з можливостями! Payments Analyst Команда OBRIO шукає аналітика платежів. Людина на цій позиції відповідатиме за розробку системи відстеження, яка забезпечить стабільність приймання платежів при мінімізації збоїв. Серед завдань — розробка ефективних підходів до аналізу платежів та усунення недоліків платіжної інфраструктури. Ідеальний кандидат має 1+ рік досвіду в аналітиці, глибокі знання SQL, статистики, володіє Python (Pandas+) для агрегації даних та розуміється на вебплатежах. App Product Analyst (вакансія закрита) Компанія Keiki працює на перетині EdTech та GameDev у дитячій категорії. App Product Analyst відповідатиме за проведення A/B тестів, пошук залежностей та точок росту застосунку, а також розвиток аналітичних інструментів та процесів. Від кандидата очікують досвід аналізу A/B-тестів, роботи з даними за допомогою SQL, Python, Amplitude або аналогами. Знання маркетингової аналітики та атрибуції, а також досвід роботи з моделлю «freemium» буде плюсом. Web Product Analyst (вакансія закрита) Також Keiki шукає Product Analyst, який буде надавати цінні продуктові інсайти, робити продуктові або маркетингові дослідження, генерувати гіпотези, працювати з експериментами. Щоби приєднатися до команди, потрібно мати досвід на позиції Product Analyst, розуміння принципів теорії ймовірності, статистики, регресії, досвід роботи з SQL або Python, з Amplitude або аналогами. Product Analyst (вакансія закрита) Promova — платформа для вивчення мов, яка складається із мобільного застосунку, вебсайту, групових курсів та індивідуальних уроків з репетиторами. Команда шукає Product Analyst, який розвиватиме систему продуктової аналітики в компанії. Головне завдання — допомагати ухвалювати продуктові та бізнес-рішення. Для цього кандидату знадобиться 1,5+ року досвіду в data-driven продуктовій розробці, досвід роботи з аналітичними інструментами, глибокі знання статистики й математики, а також досвід роботи з великими масивами даних. Це вакансія для тих, хто вміє знаходити оптимальні та нестандартні рішення. Вакансії партнерів Product Analyst Solidgate — це B2B-платформа у сфері онлайн-платежів. Команда будує фінтех-екосистему для швидкого, безпечного та вигідного приймання оплат в усьому світі. Шукають продакт-аналітика, який розвиватиме культуру продуктової аналітики у технічних командах. Головні виклики цієї позиції — побудова ключових B2B-метрик бізнесу, розробка та впровадження ВІ-рішень для аналізу, а також розвиток напряму продуктової аналітики в компанії. Щоби приєднатися до команди, потрібно мати 3+ років досвіду роботи в аналітиці, вміти працювати з BI-системами, знати SQL та реляційні бази даних, вміти планувати та розподіляти задачі, аби досягати поставлених цілей. Технічна освіта та досвід реалізації задач на Python будуть перевагою. Marketing & Operations Analyst Компанія Impulse, частина партнерської компанії Headway, вже понад чотири роки розвиває застосунок для тренування мозку Impulse — Brain Training. Він став №1 в категорії Health&Fitness у світі (iOS). Щоби продовжувати зростати, в команду шукають Marketing & Operations Analyst. Серед його завдань — аналіз конкурентів, оптимізація рекламних кампаній, операційні завдання, пов'язані з маркетингом, та пошук додаткових точок росту продукту шляхом тестування різноманітних маркетингових гіпотез. Ідеальний кандидат має досвід від одного року у «великій четвірці», консалтингу або FMCG, аналітичні здібності, розвинуте критичне мислення та крутий track record з поточного/попередніх місць роботи. Що почитати про роботу аналітика: Приборкати дані: хто такий аналітик в ІТ Як зрозуміти, що рекламна кампанія працює коректно, а користувачі проводять у продукті більше ніж хвилину? Відповідь на питання допоможе знайти аналітик. Він збирає та обробляє дані про поведінку користувачів, на основі яких команда приймає подальші бізнес-рішення. В матеріалі за посиланням описано, які навички потрібно мати, щоби потрапити до сфери, які завдання чекають на аналітика в різних бізнес-доменах, та як побудувати кар’єру. Юніт-економіка та аналітика продукту: що потрібно рахувати стартапам Що таке юніт-економіка, чому всі прагнуть, щоби вона «зійшлася» та навіщо взагалі її потрібно рахувати? За посиланням — ознайомчий ґайд із фінансової моделі, на якій базуються всі технологічні стартапи. 7 міфів про SQL. Спростовує Data Engineer в Boosters SQL — повноцінна мова розробки чи примітивний інструмент для вибірки даних? У чому різниця між SQL та NoSQL? Чи є актуальною ця технологія для сучасної аналітики, у якій одна таблиця може важити петабайти? Та чому знати конструкції та селекти не дорівнює знати SQL. У матеріалі за посиланням спростовують найпоширеніші міфи в цій сфері.

Керівник відповідає за те, яким вийде кінцевий продукт, стежить за термінами та наявністю всіх необхідних ресурсів. Однак найголовніше й водночас найскладніше завдання управлінця — перетворити групу людей з різними навичками, запитами та амбіціями на злагоджений механізм. Це передбачає і найм, і онбординг, і цілепокладання, і розвиток своєї команди. У матеріалі розглядаємо найпоширеніші труднощі, з якими зіштовхуються тимліди, й намагаємося розібратися, як їх подолати. Перелік допоміг сформулювати Олександр Барило, Front-end Team Lead в Boosters. Він уже півроку керує командою з шести розробників, яка розвиває продукт для вивчення іноземних мов Promova. Особисто у мене не було ситуації, коли потрібно вивчати нову технологію, аби розібратися, як влаштований продукт. Майже усі проєкти я починав самотужки, тому розумію, як влаштований той чи інший інструмент, принаймні на базовому рівні. Для цього достатньо хоч трохи попрацювати з кожним — і ухвалювати рішення та розподіляти навантаження між членами команди стає простіше. Нещодавно я консультувався з СТО однієї з компаній екосистеми Genesis, і він пояснив, що потреби досконало знати, як працює кожна дрібниця, немає. Ідеально, коли в команді є спеціалісти, які відповідають за конкретні напрямки, тож питання по реалізації (що і як працює) адресуватимуться саме цим фахівцям. У нашому продукті є кілька напрямів, за кожен з яких відповідає окрема людина. Вона розуміє, як саме розробляла фічу, що потрібно допрацювати, що додати, де які фреймворки та бібліотеки. Якщо раптом розробник випадає з процесу — наприклад, через відпустку чи хворобу — іншим буде важко підхопити завдання, пов’язані з цими фічами та доробити функціонал. Це bus-фактор — показник, яким вимірюють залежність бізнесу від конкретних людей. Не можу сказати, що за відсутності одного зі спеціалістів у нас все зламається, проте внести зміни буде складно. Аби нівелювати ризики, ми впроваджуємо документацію, де фіксуємо всі нюанси пов’язані з кодом, архітектурою, функціями та іншими аспектами проєкту. Подібне трапляється, якщо в компанії є декілька технічних команд, але вони не достатньо обізнані в зонах відповідальності одне одного та не бачать, що робиться по сусідству. Поясню на прикладі нашого продукту. Ми працюємо над застосунком для вивчення мов Promova. Коли людина заходить в особистий кабінет, вона бачить декілька секцій. Є функціонал для самостійного навчання, є розділ, де можна бронювати заняття та навчатися з вчителем, є секції для того, щоб проходити тести. Окремо йдуть головна сторінка та статті блогу. Це все — абсолютно різні напрями, за які відповідають різні люди. І от певна кнопка, візуальний компонент чи логіка можуть бути спільними для декількох секцій. Однак розробники різних відділів можуть не знати, що працюють над однаковими компонентами й мають змогу перевикористати те, що уже реалізовано. Подібні похибки вирішуються документацією чи дизайн-системою. Ми обрали другий шлях: винесли окремо всі компоненти, що повторюються, аби їх можна було перевикористати. Поки що все працює не ідеально, однак, думаю, що завдяки деталізації процесів та комунікації ми повністю позбавимося проблеми в майбутньому. Буває так, що цілі на півроку сформовані, декомпозовані та розподілені на команду — і начебто все йде за планом. Однак минає кілька місяців — і ми розуміємо, що робимо геть інакшу роботу. На борді зафіксована купа різних тасок, але вони зовсім не збігаються з першочерговими цілями. Виходить, що більш пріоритетні завдання витіснили першочергові цілі — і вони так і залишилися «на папері». За таких обставин виникає питання: «Чи справді це було важливо для бізнесу? Чи насправді вони необхідні для нашого функціонування, якщо кожного дня знаходилося щось важливіше?» Тимлід має не лише розподіляти навантаження, давати рекомендації для покращення роботи та стежити за дедлайнами, а й ставити цілі своїй команді та дбати про розвиток людей. Зазвичай програмісти не ставлять цілі самі собі, однак підвищення до тимліда передбачає нове завдання: стратегічні цілі потрібно декомпозувати в індивідуальні. Завдання із зірочкою — зробити так, щоб вони надихали команду та збігалися з особистими цілями кожного. Без досвіду подібний процес може бути складним та болючим. Іноді складнощі в цілепокладанні спричинені оргструктурою. Наприклад, наша технічна команда розподілена на скводи відповідно до напрямів роботи бізнесу. На практиці різні люди з команди працюють над різними частинами проєкту. Хтось відповідає за функціонал для користувачів, хтось — за адмінку для тьюторів, за SEO або за фінанси та платежі. Минулого разу довелося постаратися, аби встановити цілі для людини у певному скводі, адже продакта, який міг сформулювати стратегічне бачення, куди ми рухаємося, не було. На позиції розробника легко виміряти свою результативність — наприклад, у кількості завершених задач або написаного за один день коду. Однак якщо ви тимлід, усе складніше. Трапляється так, що увесь робочий день минає на зустрічах та обговореннях — і наприкінці здається, що нічого важливого зробити не вдалося. Однак тут я знайшов для себе рішення. По-перше, результат тимліда полягає не лише в тому, що зробив безпосередньо він, а й у тому, до яких результатів прийшла команда під його керівництвом. По-друге, в деяких випадках написання коду взагалі не входить до обов’язків тимліда, він фокусується суто на управлінні людьми. Коли розробник стає тимлідом, його робота та графік очікувано змінюються. Завдання програміста — розібратися у задачі, яку йому поставили, та зробити її якомога краще. Так, увесь робочий день можна витратити на написання коду, отримавши повідомлення від декількох людей щонайбільше. На позиції тимліда інший челендж. Начебто так само є завдання, до яких потрібно підступитися, але зустрічі починають займати більшу частину календаря — і їхня кількість постійно зростає. Паралельно є купа повідомлень у чатах — і на них потрібно відповідати. У результаті до написання коду або вирішення технічних задач виходить дістатися в найостаннішу чергу. Втім, тут потрібно зробити власний вибір та розставити пріоритети: розвиватися у бік people management чи ставати техлідером і поглиблювати технічні знання. Для мене вибір був неочевидним: з одного боку, подобалося вирішувати технічні завдання, а з іншого — я бачив перспективи у позиції тимліда.

CI/CD — методологія розробки, яка передбачає безперервну інтеграцію (CI) та безперервну доставку (CD) програмного коду. Її суть полягає в тому, що збірка та тестування відбуваються в автоматичному режимі. Навколо цієї поширеної DevOps-практики виникло чимало міфів та упереджень. Це складний затратний метод, який підходить лише для великих інноваційних продуктів? Чи ці принципи можуть застосовувати навіть найпростіші проєкти, на кшталт сайтів-лендингів? Запровадження CI/CD передбачає 100% автоматизований пайплайн чи без ручних перевірок не обійтися? Налаштування за принципом IaC — мастхев чи можна все зробити через інтерфейс? У цьому матеріалі Ілля Ільїн, DevOps Engineer в Jiji, партнерській компанії Genesis, спростовує найпоширеніші міфи про CI/CD. > CI/CD — занадто складно і затратно, простіше зробити «руками» > CI/CD підходить не всім проєктам > Кінцева точка СІ — це реліз > Якщо конвеєр не автоматизовано повністю, і в ньому є «ручні» кроки, — це не CI/CD > CI/CD краще налаштувати через вебінтерфейс > Пайплайни CI/CD негнучкі, важко вносити в них зміни МІФ №1 CI/CD — занадто складно і затратно, простіше зробити «руками» Впровадження та налаштування процесів CI/CD може здаватися складним та затратним, нібито вимагати чималих ресурсів, зокрема якщо передбачається використання платних послуг та інструментів. Іноді на автоматизацію якогось процесу, який займає годину-дві щодня, може піти кілька місяців. Чи раціонально інвестувати в це час та ресурс, коли ручні методи виглядають простішими та економнішими? Такі упередження виникають у розробників із недостатнім досвідом в інструментах і процесах автоматизації. Насправді CI/CD має безліч переваг: допомагає зменшити ризики та помилки, прискорити реліз, автоматизувати рутинні процеси, щоби команда могла зосередитись на розробці функціонала. Уявімо, що є сайт, на якому під час реєстрації користувач вказує номер телефона, на який приходить код. Розробники припустилися помилки, залишивши у відкритому доступі реквест до API відправки СМС. Тобто можна відкрити консоль браузера, взяти цей реквест, скопіювати і почати відправляти СМС у великій кількості. Так за кілька годин можна легко «злити» бюджет у кілька тисяч доларів. Для порівняння: річна вартість утримання інфраструктури, яка могла б перешкоджати подібним помилкам — близько $1000. Тому витрати на CI/CD лише умовно можна назвати дорогими. Економія на інфраструктурі може спричинити значно більші втрати. МІФ №2 CI/CD підходить не всім проєктам Насправді ж процеси CI/CD можна легко масштабувати для проєктів будь-якого розміру. Зокрема, кожна команда має працювати через систему контролю версій — від студентських практичних завдань до великих глобальних продуктів. Навіть прості лендинги зі зростанням проєкту стикаються з потребою в автоматизації. Наприклад, є звичайний статичний сайт на декілька сторінок і з кнопкою «Подзвоніть нам». Ніякої автоматизації, тестування, системи контролю версій немає. Розробник просто заходить на сайт через SSH або FTP, і кидає статичну сторінку на сервер. Якщо трапляються помилки — виправляє їх вручну. Але щойно відвідуваність сайту починає зростати, до його роботи треба ставитися прискіпливіше — додавати контур тестування, щоби було менше помилок, або покращувати безпеку чи конфіденційність. Найпростіший варіант це зробити — обмежити доступ розробників до прода. А для цього треба налаштовувати автоматичне завантаження коду. А якщо ти розумієш, як це працює, то в принципі це налаштовується доволі швидко і просто. МІФ №3 Кінцева точка СІ — це реліз Реліз продукту часом помилково сприймають як основну мету та кінцеву точку. Це свідчить про неправильне розуміння суті CI/CD, адже це циклічні безперервні процеси, у яких немає кінцевої точки. CI/CD містить такі етапи: автоматична збірка та компіляція коду при кожному коміті в репозиторій; запуск тестів після кожної збірки; розгортання оновленого програмного забезпечення на тестові та стейджингові середовища для перевірки; реліз; постійний моніторинг для виявлення проблем. Отже, постійне тестування й оновлення коду продовжується навіть у проєктах, розвиток яких призупинений — просто вони оновлюються не фічами, а виправленнями багів. Кінцевою точкою проєкту може бути тільки його повне закриття. МІФ №4 Якщо конвеєр не автоматизовано повністю, і в ньому є «ручні» кроки, — це не CI/CD Якщо розробнику під час релізу треба заходити на сервер по SSH, щось вмикати/вимикати, копіювати код вручну — це не про CI/CD. Проте натиснути на кнопку, щоби запустити скрипт або перевірити, чи немає помилок при деплої — цілком відповідає принципам CI/CD. Деякі процеси не можуть бути автоматизованими на 100%. Наприклад, коли при релізі треба додати зміни до структури бази даних, ви не зможете автоматично протестувати, чи не виникло блокування патчів. Найпростіше — перевірити локи у напівручному режимі. Девопс-інженер може одразу пофіксити їх з допомогою спеціальних інструментів або звернути увагу розробника на цю проблему. Іноді повна автоматизація, зокрема релізного бранчу, може спричинити падіння проєкту та великі втрати. Саме так 2021 року впала соціальна мережа Facebook. До інциденту команда хизувалася автоматичним тестуванням мережевих правил, маршрутизації, трафіку — все це автоматично накатувалося на прод без ручної перевірки. Під час інциденту 2019 року, який тривав вісім годин, у них впало все — внутрішня мережа, зовнішня мережа, канал комунікації між менеджерами, який був у їхньому месенджері, резервний канал спілкування у Slack, авторизація в якому проходила через акаунт Facebook. Також впала авторизація входів в дата-центри, які працювали через Facebook-ID, тому в деяких місцях їх відкривали фізично. Також це падіння вплинуло на чимало процесів користувачів та бізнесів — SDK, API, статистики тощо. Аналіз інциденту в post mortem свідчить, що це сталося через помилку, яку можна було б легко помітити, якби система не була на 100% автоматизована. МІФ №5 CI/CD краще налаштувати через вебінтерфейс Налаштування CI/CD-процесу через інтерфейс (наприклад, Jenkins чи TeamCity) здається більш простим, зрозумілим та зручним підходом, ніж використання конфігураційних файлів (наприклад, YAML). Вважається, що налаштування «кодом» потрібно лише для складних спеціалізованих потреб розробки. Водночас, коли вся інфраструктура керується за принципом IaC (Infrastructure as Code), розробникам фактично можна не вести документацію. Хто б не прийшов до проєкту, він зможе просто відкрити репозиторій, подивитися код, побачити всю історію змін і все зрозуміти. Подбати про правильний спосіб налаштування потрібно якомога раніше — коли проєкту 5-10-15 років, і весь цей час його налаштовували через юзер-інтерфейс, перейти на IaC буде доволі складно й дорого. МІФ №6 Пайплайни CI/CD негнучкі, важко вносити в них зміни Налаштований пайплайн CI/CD часом сприймають як непроникний процес, будь-які зміни та оновлення якого є складними та ризикованими. Насправді ж пайплайни мають бути гнучкими та адаптивними, щоби команди могли їх легко змінювати, відповідно до нових вимог та потреб. Здатність CI/CD-пайплайну до змін передусім залежить від складності узгодження цих самих змін, розміру проєкту та ступеня забюрократизованості сфери. Наприклад, якщо це маленький стартап, DevOps і розробник можуть просто домовитися протестувати певний сервіс, одразу реалізувати, і цього ж дня він буде на проді. У фінансово-банківській сфері будь-які зміни мають бути узгоджені з сек'юріті-відділом або з регуляторами. Є банки, де перед тим, як відправити код на прод, треба його роздрукувати та поставити мокру печатку відповідальної особи. До речі, з початком повномасштабної війни більшість українських банків перевели ключові операції до хмарної інфраструктури, щоби менше залежати від апаратного забезпечення в локальних дата-центрах. Вони зробили це у досить швидкі терміни, не зупиняючи поточну роботу. Найшвидше з цим впорався monobank, переїхавши в AWS за кілька тижнів. Для цієї сфери такий термін можна вважати миттєвим.

20 липня в офісі Meta у Варшаві відбувся Pitch Day, де 21 стартап презентував свій бізнес понад 40 найбільшим фондам Центральної та Східної Європи. Pitch Day відбувся по завершенню двомісячної програми Genesis StartUp Academy together with Meta. У Pitch Day взяли участь технологічні стартапи з СЕЕ-регіону, які успішно завершили безоплатну онлайн-програму Genesis StartUp Academy together with Meta про масштабування та управління технологічним стартапом. «Для Meta в регіоні Центральної та Східної Європи важливим пріоритетом є підтримка стартапів. Протягом останніх трьох років ми запускаємо StartUp Academy разом з українською ІТ-компанією Genesis, щоби ще більше підприємців отримували знання, ідеї та наставництво від провідних технологічних експертів», — зазначив Станіслав Біров, Meta’s Client Partner у регіоні ЦСЄ. Упродовж двох місяців ІТ-підприємці та фаундери переймали досвід засновників глобальних компаній, а також отримали менторську підтримку та деталізований фідбек від експертів із Genesis, Meta, Amazon Web Services (AWS), Horizon Capital, Flyer One Ventures, Deel, Zendesk та інших компаній-лідерів на світовому ринку у своїх нішах. «Технологічна галузь нині переживає «венчурну зиму», що призводить до значного зменшення обсягу інвестицій, зокрема, в регіоні Центральної та Східної Європи. Саме тому команда StartUp Academy цього року зосереджується на допомозі засновникам у визначенні можливостей зростання та доступі до венчурного капіталу. Genesis і Meta виступили посередниками між ідеями та капіталом, об’єднавши на Pitch Day понад 20 стартапів і понад 40 венчурних фондів», — прокоментував Артем Копанєв, COO Genesis. Pitch Day є фінальним етапом у StartUp Academy. Цього року на Pitch Day взяли участь 21 перспективних стартапів з України, Естонії, Польщі, Німеччини, Нідерландів, Грузії, Молдови, Сербії, Вірменії, Азербайджану. Переможцем Pitch Day став memoryOS — український застосунок для покращення пам'яті. «Для нашої команди велика честь бути відібраними серед 1600 стартапів та отримати перше місце на Pitch Day. Ця подія стала фіналом трансформаційної та найціннішої освітньої програми для стартапів у регіоні Центрально-Східної Європи. Завдяки менторській підтримці та досвіду експертів, за два місяці ми змогли масштабувати свій стартап. А тепер продовжуємо зростати, допомагаючи прокачувати памʼять наших користувачів», — поділився Алекс Руж, CEO memoryOS. Також на події були присутні 46 представників найбільших венчурних фондів регіону Центрально-Східної Європи. Серед них: Flyer One Ventures, Horizon Capital, SMOK Ventures, Inovo VC, Market One Capital, TA Ventures, Practica Capital, 500 Emerging Europe, ffVC тощо. Це вже третя хвиля StartUp Academy, яку реалізує українська кофаундингова ІТ-компанія Genesis спільно з Meta з 2020 року. Щороку до участі запрошують 50 відібраних технологічних стартапів із регіону Центральної та Східної Європи, від seed-стадії розвитку та вище в напрямах EdTech, FinTech, B2B SaaS, Mobile applications. Для українських стартапів резервують 15% місць. За цей період програма отримала понад 5000 заявок із 60+ країн, а понад 120 стартапів-учасників отримали досвід від експертів найкращих tech-команд у Європі. За результатами торішньої академії загалом шість компаній отримали інвестиції в період з 2022 по 2023 рік у розмірі від $100 тисяч до $1 мільйона. Крім цього, організатори та партнери Genesis StartUp Academy together with Meta щороку інвестують у стартапи-учасники програми близько $5,5 мільйонів негрошової підтримки у вигляді кредитів на користування хмарними сервісами, безоплатного доступу до продуктів, послуг та консультацій. Вже незабаром стартує нова хвиля на міжнародну онлайн-програму Genesis StartUp Academy together with Meta. Ознайомитись з умовами участі та програмою можна на сайті.

Транзакція — це основна робоча одиниця при взаємодії з базою даних. Катерина Медведська, Data Еngineer в Boosters, на мітапі генезійського бекенд-ком’юніті розповіла про особливості транзакцій в базах даних, гарантії, які надають AСID-транзакції та про те, навіщо потрібні різні рівні ізольованості транзакцій. Катерина працює в Boosters більше року. Раніше вона понад десять років працювала в сфері автоматизації торгових підприємств. Відповідала за автоматизацію торгових і складських процесів, обліку залишків. Працювала з оптимізацією баз даних — як для збільшення пропускної здатності конкурентного доступу, так і для вирішення проблем з блокуваннями. Публікуємо конспект з найважливішими тезами з виступу спікерки. Проблема паралельного доступу Уявімо, що в нас є інтернет-магазин, назвемо його «Ruletka». В нього є сайт, через який здійснюються всі продажі. У магазина є також склад, і інформація про наявні товари на цьому складі зберігається в певній реляційній базі даних (БД). Склад додає інформацію про товари в БД, а сайт вичитує її з цієї бази, аби відобразити користувачам. Уявімо, що магазин отримує партію із тисячі штук відомих всім марок «воєнний корабль». Склад, відповідно, вносить ці дані в базу, і вони через певний час відображаються на сайті. Одразу набігає більше п'яти тисяч охочих купити марку. Що ж при цьому відбувається в базі даних інтернет-магазину? Для кожного користувача, який додає товар в корзину, сайт повинен запросити дані з БД про наявність товару, одразу заблокувати його під користувача, і лише після цього «сказати» сайту, що все успішно, можна показувати сформоване замовлення клієнту. На кожну одиницю товару у нас по п'ять користувачів, які одночасно намагаються забронювати собі цей товар. На рівні бази даних це виглядає наче вони всі намагаються змінити таблицю вільних залишків в БД складу. Тут важливо, щоби всі користувачі, які замовили раніше, отримали свій товар першими, при цьому магазин не продав нічого в мінус, а база даних витримала таке навантаження. В цьому процесі може бути безліч проблем і складних ситуацій. Програмне або апаратне забезпечення БД може відмовити, при чому це може статись в будь-який момент, наприклад, посередині операції запису. Інша ситуація: розриви мережі неочікувано відріжуть ваш додаток від БД. Кілька користувачів зможуть виконати записи операції одночасно, при чому перезаписати один одного, і хтось не отримає свою марку. Ще одна потенційна проблема: клієнт може прочитати дані, які не матимуть сенсу, тому що вони були оновлені лише частково. Навіщо потрібні транзакції? Протягом десятиліть транзакції вважались оптимальним механізмом вирішення всіх вищеописаних проблем. Транзакція – це спосіб групування додатком кількох операцій запису та читання в одну логічну одиницю. По суті, всі операції запису і читання в ній виконуються як одна, і вся транзакція або цілком виконується успішно з фіксацією змін, або завершується невдало з перериванням і відкатом. І якщо відбувся збій, додаток може спокійно спробувати виконати операцію ще раз, бо він знає, що ніяких часткових операцій запису не було виконано. Це значно спрощує обробку помилок, оскільки не потрібно пам'ятати, що там щось могло частково записатись або не записатись взагалі. Гарантії функціональної безпеки, які надаються транзакціями, часто описуються абревіатурою ACID, яка розшифровується як Atomicity, Consistency, Isolation and Durability. Це атомарність, узгодженість, ізоляція та довговічність відповідно. Атомарність — це неможливість розбиття на менші частини. В контексті ACID атомарність транзакції гарантує, що будуть або виконані всі операції, які беруть участь в транзакції, або не буде виконано жодної. Тобто, якщо операції запису згруповані в атомарну транзакцію і її не вдається завершити через збій, то вона переривається, і в базі даних необхідно відкатити всі вже ці виконані зміни перед тим, як відповісти юзеру, що транзакція була перервана. Узгодженість. Під цим поняттям мається на увазі, що БД перебуває з погляду додатка в хорошому стані, тобто система має перебувати в узгодженому, несуперечливому стані до початку дії транзакції і по її завершенню. Що саме вважаємо узгоджений станом? До прикладу, при переведенні коштів з рахунку на рахунок, кошти необхідно спочатку зняти з першого рахунку, після чого нараховувати на другий. Відповідно, після зняття коштів, але до їх нарахування система перебуває в неузгодженому стані: коштів немає на жодному з рахунків. Але після завершення транзакції повна сума перебуватиме на другому рахунку, або, якщо сталась якась помилка, на першому, що буде узгодженим станом. Ізоляція. До більшості баз даних звертається одночасно кілька клієнтів. І в цілому це не викликає проблем, поки вони читають і записують дані в різні частини бази, в різні таблиці, в різні рядки. Але якщо вони звертаються до одних і тих самих записів, то тут можуть виникати проблеми конкурентного доступу, які називаються race condition або стан гонитви. Ізоляція існує саме для уникнення таких проблем. БД повинна гарантувати, що результат фіксації кількох конкурентних транзакцій такий самий, як наче вони виконуються послідовно, одна за одною. Довговічність. Основна задача СУБД — це надати надійне місце для зберігання даних. Під довговічністю мається на увазі зобов'язання бази не втратити успішно зафіксовані дані транзакції, навіть в разі якогось апаратного збою чи фатального збою самої БД. Чотири рівні ізоляції B ідеальному світі ізоляція повинна була б полегшити життя розробників, які б могли зробити вигляд, що жодного конкурентного виконання взагалі не відбувається. На практиці витрати на серіалізовану ізоляцію досить високі, і багато баз даних не згодні платити таку ціну. Саме тому були створені слабші рівні ізоляції, які захищають лише від частини проблем конкурентного доступу, але при цьому мають значно кращу продуктивність при паралельному виконанні транзакцій. Стандарт SQL-92 визначає чотири рівні ізоляції. Це Read Uncommitted, Read Committed, Repeatable Read і Serializable. Всі ці рівні відрізняються певними мінімально допустимими гарантіями, які повинна надавати СУБД, і описуються в документації через присутність конкретних проблем паралельного доступу. Більш високий рівень ізольованості підвищує точність даних, зменшує кількість проблем, але при цьому знижує кількість паралельних транзакцій. Відповідно, чим нижчий рівень ізольованості, тим більше транзакцій може виконуватись паралельно, але при цьому може знизитись точність даних, якщо ви все не врахували. Read committed Базовий і найпоширеніший рівень ізоляції транзакцій — read committed. Він забезпечує дві основні гарантії. Перша — жодних брудних операцій читання (dirty read). Це означає, що при читанні з БД клієнт бачить лише зафіксовані дані. Тобто якісь середні, неузгоджені дані він не може прочитати. І друга гарантія — це жодних брудних операцій запису. Тобто при записі в БД можна перезаписувати лише зафіксовані дані. Для запобігання «брудним» операціям запису частіше за все бази використовують блокування рядків. Перш ніж модифікувати конкретний об'єкт, транзакція повинна спочатку встановити блокування на цей об'єкт. Дане блокування має утримуватись аж до фіксації або переривання транзакції. Утримувати блокування на конкретний об'єкт може тільки одна транзакція одночасно. Іншим транзакціям, які хочуть виконати операцію запису в цей об'єкт, доведеться дочекатися фіксації або переривання першої транзакції і лише потім отримати блокування і продовжити свою роботу. Подібні блокування виконуються базами автоматично в режимі читання зафіксованих даних (і на сильніших рівнях ізоляції). Більшість БД запобігають «брудним» операціям читання за допомогою підходу, коли база запам'ятовує для кожного об'єкта, що записується, як старе зафіксоване значення, так і нове, яке встановлюється поточною транзакцією. А в цей час всім іншим транзакціям, що читають об'єкт, просто повертається старе значення. І тільки після фіксації транзакції запису інші транзакції починають одержувати нове значення. Repeatable read Коли в нас є якісь аналітичні запити або перевірки цілісності, то зазвичай сканують велику частину БД і сканування виконується певний час. Якщо такі запити будуть бачити, частину старих даних, а потім додавати частину нових даних, то в результаті ми отримуємо неузгоджені дані, які не матимуть жодного сенсу і вважатимуться помилковими. В таких варіантах рівень read committed не підходить, а для запобігання цим проблемам існує рівень ізоляції знімків стану — snapshot isolation, який ще називають repeatable read. Основна ідея полягає в тому, що кожна транзакція читає дані з узгодженого знімка стану бази, тобто це повний зріз даних на певний момент часу. Навіть якщо дані потім були змінені іншими транзакціями в моменті читання, то наша транзакція не буде бачити цих змін. Механізм ізоляції знімків стану підтримується багатьма СУБД. Як і в read committed, в реалізації snapshot isolation зазвичай використовується блокування запису для запобігання брудним операціям запису. Але при цьому операції читання не вимагають жодних блокувань. Отже, основним принципом ізоляції знімків стану є «читання ніколи не блокує запис, а запис ніколи не блокує читання». Завдяки цьому БД здатна виконувати тривалі запити на читання і в цей же час виконувати операції запису. Цей рівень ізоляції використовується найчастіше. Для реалізації ізоляції знімків стану бази використовують такий механізм, який називається Multi-Version Concurrency Control (MVCC). В ньому кожен SQL-оператор бачить знімок даних — повну версію БД на певний момент часу, незалежно від поточного стану даних. При читанні застосовується окремий знімок стану для кожного запиту, а для транзакцій — один і той самий знімок для всієї транзакції. Розглянемо детальніше, як реалізується цей механізм на прикладі PostreSQL. На початку виконання транзакція отримує свій унікальний, монотонно зростаючий ідентифікатор, який називається txid. Будь-які дані, записані цією транзакцією, позначаються цим номером. В кожному рядку таблиці є поле created by, що містить ідентифікатор транзакції, в якій був доданий в цей рядок. І в кожному рядку також є поле deleted by, яке початково порожнє. Коли транзакція змінює дані, вона насправді залишає старі в своєму рядку, дописуючи в нього свій txid в поле deleted by. А також додає рядок з оновленими даними, зі своїм txid в полі created by. Пізніше, вже коли жодна транзакція точно не звернеться до цих даних, vacuum в PostgreSQL почистить ці видалені рядки. БД не збирає фізичний знімок бази, щоби надати його кожній транзакції. Читання узгоджених знімків стану реалізується завдяки ідентифікаторам та низці правил видимості. Нижче перерахую основні: На початку кожної транзакції БД створює список всіх інших транзакцій, які ще не завершились на поточний момент, і всі зміни, які виконуються цими транзакціями, просто ігноруються для поточної транзакції. Усі операції запису, які виконані перерваними транзакціями, також ігноруються. Усі операції запису виконані транзакціями з більш пізнім ідентифікатором, також ігноруються. Результати всіх інших операцій запису видимі для поточної транзакції.

Соціальна мережа LinkedIn збирає найбільш неоднозначні відгуки. Для одних це осередок рекрутерів із недоречними пропозиціями роботи та коучів із постами про успіх у стилі Тоні Роббінса. А для інших LinkedIn — це спосіб розвивати карʼєру, знаходити корисні знайомства та безліч можливостей. Якщо ви в першій команді, ймовірно, ви не розібралися, як працює LinkedIn. Юрій Мокрушин, СТО Universe та Софія Татунчак, Recruitment Team Lead в Quarks, партнерській компанії Genesis, поділилися кейсами використання цієї соціальної мережі, розповіли, як правильно заповнити профіль, чому тут не можна постити меми та як будувати комунікацію з «холодними» контактами, щоби отримати відповідь. > Що таке LinkedIn > Як працювати з LinkedIn: кейс CTO > LinkedIn для рекрутерів: як налагоджувати ефективну комунікацію > Як правильно заповнити профіль LinkedIn Що таке LinkedIn LinkedIn — це одна з найстаріших соціальних мереж. 2002 року Ріду Гоффману, який на той момент був виконавчим віцепрезидентом PayPal, прийшла ідея обʼєднати професіоналів з усіх галузей за допомогою інтернету, — і наступного року він запустив LinkedIn. 2004 року, коли на світ зʼявився Facebook, LinkedIn вже мав перший мільйон користувачів. Своє двадцятиріччя в травні 2023 соціальна мережа відсвяткувала, перетнувши мітку в 900 мільйонів користувачів. Місія LinkedIn проста: створити найбільше професійне комʼюніті та допомогти кожному його члену розвивати карʼєру та бути продуктивнішим. Перші версії соціальної мережі не передбачали найму та розміщення вакансій. Тоді профілі складалися лише з імені, актуальної посади та освіти, а сама платформа була схожою на простий сайт для пошуку користувачів та обміну повідомленнями. У потужний інструмент для рекрутингу та нетворкінгу LinkedIn перетворився пізніше. Від самого початку менеджери компанії робили ставку на дорослу аудиторію та не спонукали її проводити в соціальній мережі якомога більше часу. «Класичний LinkedIn — це простір, де обговорюють суто професійні питання. Здебільшого тут не діляться статусами, мемами, смішними «тіктоками», не сперечаються на хайпові теми. Facebook переповнений лютими політичними суперечками, а в LinkedIn ви побачите, як розробники емоційно дискутують про оновлення Docker. І це безцінно», — ділиться Юрій Мокрушин, CTO Universe. Основні джерела прибутку LinkedIn — це реклама, преміум-акаунти (до речі, вони одними з перших випробували цей спосіб монетизації) та сервіси для бізнесів: Recruiter (надає платні послуги для кадрових відділів компаній), Sales Navigator (продажі та лідогенерація). Маючи профіль у LinkedIn, можна: знайти спеціаліста з унікальною вузькою експертизою для нетворкінгу; знайти вакансію будь-якої компанії чи стартапу світу; будувати особистий професійний бренд; проводити дослідження; просувати бренд компанії чи стартапу; знаходити професійні курси та навчальні програми. Як працювати з LinkedIn: кейс CTO Перш ніж створити сторінку в LinkedIn, треба визначити, для чого вона вам потрібна. Цей інструмент може допомогти з реалізацією різних цілей: особистий бренд, найм, пошук роботи або клієнтів. Я зареєструвався в LinkedIn понад шість років тому. Чув, що це комʼюніті, де представлена ІТ-спільнота, але першою реакцією було: «а що тут взагалі робити?». Довгий час я туди майже не заходив. Пізніше акаунт знадобився для дослідження ринку, коли я запускав стартап для рекрутерів. Так у мене з‘явилося 25 000+ зв‘язків, але навіть тоді я не використовував усіх можливостей соціальної мережі. Нещодавно я взяв участь у тренінгу з нетворкінгу, під час якого зрозумів, наскільки важливо розвивати особистий бренд, та що я втрачаю, ігноруючи спілкування. В Україні майже не розвинутий професійний нетворкінг в ІТ. Вкрай рідко трапляються маленькі локальні івенти, але можливості завести корисні знайомства зі спеціалістами в інших країнах обмежені. Водночас LinkedIn — це соціальна мережа, де люди готові спілкуватися. Якщо ви напишете незнайомій людині в Facebook: «Привіт, у тебе цікавий досвід, давай звʼяжемося і поспілкуємося?», з високою ймовірністю вас заблокують. У LinkedIn це сприймається більш дружньо, — тут люди відкриті, готові ділитися експертизою, відповідати на питання. Так я завів кілька дуже корисних знайомств із CTO інших компаній. Зараз я стараюся бути активнішим, писати як мінімум кілька постів на місяць. LinkedIn — не дуже зручний для постійного обміну повідомленнями: зазвичай ти знайомишся і переходиш до звичних форматів спілкування. У середньому я витрачаю на цю соціальну мережу 5–15 хвилин на день. Це дуже невелика «плата» за ту цінність, яку вона приносить. Особисто я не наймав людей, але це корисний інструмент для менеджерів, щоби знаходити таланти. Якщо правильно оформити профіль, можна безкоштовно дотягтись до великої кількості спеціалістів. Часто СТО самі пишуть потенційним кандидатам. Технічному спеціалісту завжди цікавіше поспілкуватися з можливим керівником, аніж із рекрутером. Мені досить часто пишуть люди, які цікавляться вакансіями в Universe. Пропозиції роботи від рекрутерів мені не заважають — я просто чемно відмовляюся. А от хто докучає, так це менеджери з продажів. Коли вони бачать посаду CTO, то застосовують усі можливі способи «продати» сервери, залізо, послуги хостингу тощо. LinkedIn для рекрутерів: як не спамити, а налагоджувати ефективну комунікацію Я використовую LinkedIn насамперед для найму: пошуку кандидатів, публікації вакансій, для поширення інформації про наш бренд та компанію, а також для розвитку особистого бренду. Також можна провести дослідження інших компаній: подивитися, які люди там працюють, як сформовані команди. Особливо цінно це для вивчення іноземних компаній. Основна зручність для рекрутерів у тому, що тут можна прописати складні запити із багатьма критеріями: локацією, досвідом, освітою та певними навичками. Система може фільтрувати кандидатів не тільки за назвою посади, яку вони вказали, але й за попереднім бекграундом, наприклад, роботою в певній компанії. Можна шукати як на українському ринку, так і поза ним. Заповнений профіль може дати багато інформації про кандидата, а його професійні звʼязки та рекомендації допомагають верифікувати скіли. За останні три місяці в мене було вісім наймів. Три з них — через LinkedIn. Щоразу комунікація складається по-різному. Інколи я пишу сама, але часто ініціатива йде від кандидатів. Якісний найм — це завжди комплексне поєднання різних інструментів, але я вважаю LinkedIn одним із найкращих для пошуку «холодних контактів». Втім, іноді з боку рекрутерів це перетворюється на масову розсилку пропозицій роботи та суцільний спам, що закономірно викликає негативну реакцію. Рекрутер має застосовувати індивідуальний підхід — вивчити сторінку людини, її досвід та написати персоналізоване повідомлення. Для кандидата це буде знаком, що ним справді цікавляться, а не надіслали типове повідомлення. Перш ніж кидати вакансію, краще завʼязати знайомство та спитати дозволу. Такі делікатні повідомлення значно рідше залишаються без відповіді, а якщо людина не зацікавлена в роботі, то охоче може порекомендувати когось із колег. Це не раз допомагало мені закрити вакансії. Як правильно заповнити профіль LinkedIn Найпопулярніший профіль в LinkedIn має Біл Гейтс (понад 34,7 млн фоловерів). Крім того, що він — засновник корпорації Microsoft, яка 2016 року придбала LinkedIn за $26,2 млрд, він також активно веде сторінку. Еталоном правильно заповненого профіля можна вважати сторінку Ріда Гоффмана, засновника LinkedIn. Є чотири ключові поля в профілі, за допомогою яких алгоритми зможуть знайти вас серед сотень мільйонів людей: Headline, About, Experience, Skills. Headline Заголовок розміщується під іменем, і це перше, що бачать про вас на сторінці пошуку або в профілі. Найчастіше тут вказують актуальну посаду та назву компанії. Також можна зазначити сферу роботи, ключові компетенції. Джуніори часто залишають тут примітку «відкриті до пропозицій». Важливо писати тут лише ключові фрази, які допоможуть вас знайти. Поширена помилка — абстрактний заголовок, коли замість посади пишуть кредо життя або дотепний жарт. У Ріда Гоффмана в заголовку вказані його ключові сфери діяльності. About Напишіть коротке самарі про свій досвід, вміння та мету. Можна коротко описати проєкт, у якому зараз працюєте, з якими викликами стикаєтеся. Також у цей розділ доречно додати посилання на портфоліо чи сайт. Experience Тут створюється таймлайн вашого робочого досвіду. Щоби він був релевантним, важливо обирати назви посад та компаній з автоматичного списку, який пропонує система. Якщо писати їх довільно, ваш профіль може не відображатися в пошуку. У цьому розділі можна прописати ключові обовʼязки, при цьому варто уникати перенавантаження інформацією. Якщо у вас багаторічний досвід у різних компаніях, краще детально розписати лише останнє місце роботи. Також зверніть увагу не тільки на дату початку роботи, але і звільнення, інакше система сприйматиме це, наче ви працюєте на різних позиціях одночасно. У Ріда в профілі вказано 32 місця роботи, починаючи з 1994 року. З них більшість описані коротко, а останнє місце роботи — детальніше (зазначені ключові сфери відповідальності). Skills У цьому розділі можна додати до 50 навичок. Карʼєрні консультанти радять не соромитися та писати максимальну кількість релевантних хард- та софт-скілів. Важливо розмістити їх у правильному порядку, починаючи із найголовніших для вашої професії. Краще писати англійською мовою та обирати зі списку, який пропонує система LinkedIn. У профілі Ріда зазначено 44 скіла, серед яких найголовніші — стартапи, підприємництво та стратегія. «Рекрутери звертають увагу на таймлайн досвіду роботу: якщо кандидат занадто часто змінює компанії та не затримується надовго, — це поганий знак. Також дивляться на освіту та наявні сертифікати, скіли, — ділиться Софія Татунчак. — Окрім цього, дивимося на рекомендації від колишніх або теперішніх колег, рівень англійської та соціальну активність». Якщо в людини рідкісна позиція та досвід, то скоріше за все їй напишуть і з мінімально заповненим профілем. А от тим, хто шукає роботу на ринку з високою конкуренцією, краще приділити максимум уваги своїй сторінці. «Нещодавно ми найняли талановитого менеджера, у якого на сторінці було не більше двох рядків інформації. Це як в Instagram: якщо в людини роками не зʼявляються нові пости, це зовсім не означає, що в нього немає соціального життя. Проте кандидати із повною інформацією в профілі завжди краще запамʼятовуються і швидше отримують запрошення на співбесіду. Коли рекрутер не знаходить інформації про навички й досвід, він мусить дізнаватися це в приватній переписці, а це займає досить багато часу, — розповідає Софія. Отже, LinkedIn — це соціальна мережа з чималими можливостями. Щоби ними скористатися, недостатньо просто зареєструватися. Алгоритми системи просувають у пошуку активних користувачів, тому, щоби налагодити якомога більше корисних звʼязків, оптимізувати профіль у пошуковій видачі та налаштувати стрічку новин, регулярно приділяйте увагу своїй сторінці, спілкуйтеся та будьте відкритими.

ChatGPT 4 може допомогти оптимізувати роботу технічних команд у різні способи: шукати баги в коді, конвертувати або генерувати код, проводити код-ревʼю, моделювати співбесіду, писати коментарі, тести. Окрім цього, він може прочитати «спагеті-код» чи пропонувати ідеї для рефакторингу, бути консоллю, linux-терміналом чи іншим інструментом. Кожну з цих ролей ChatGPT може виконати за умови правильного запиту та певної кількості ітерацій додаткових уточнень. В цьому матеріалі ми розберемо, що таке промпт, як правильно його сформувати, щоби отримати релевантну відповідь, а також поділимося переліком корисних команд та прикладами. Технічні спеціалісти з екосистеми та партнерських компаній Genesis поділяться, які задачі готові делегувати ChatGPT, а для яких написання промпту та учтонень займає більше часу, ніж виконання власноруч. > Що таке промпт та як його скласти > Загальна структура промпту > Поширені команди для ChatGPT > Генерація коду > Code review > Конвертація коду > Тестування > Документація > Рефакторинг коду > Виявлення та виправлення помилок > Проєктування системи та архітектура > DevOps > Data Engineering Що таке промпт та як його скласти Промпт — набір вхідних даних, які ми надаємо лінгвістичній моделі, щоби керувати розмовою або завданням. Залежно від мети користувача, запит може бути у форматі питання, твердження, короткої історії, завдання або набору інструкцій. На основі цієї інформації модель генерує відповідь. Іншими словами, процес створення тексту в GPT-4 починається з промптів. Вони можуть бути простими, як одне слово, або складними, як ціле есе. Промпт має бути конкретним, зрозумілим та містити достатньо інформації, щоби модель могла зрозуміти тему та сформулювати релевантну відповідь. ChatGPT рідко вдається дати одразу точний результат, який не треба буде допрацьовувати. Навіть прості завдання потребують корегувань. Чим більш узагальненим буде запит, тим більше ітерацій уточнень вам знадобиться. Натомість якісний перший промпт допоможе мінімізувати їхню кількість до 3-5. Загальна структура промпту містить: Роль Суть завдання Контекст Мету завдання Опис результату, якого ви очікуєте, в якій кількості та в якому форматі (текст, невпорядкований список, JSON, CSV, таблиця тощо) Умови та обмеження. Якщо ви хочете дати ChatGPT складне завдання, яке містить багато деталей та референсів, напишіть інструкцію, як далі відбуватиметься комунікація. Щоби правильно «згодувати» моделі всі вхідні дані, попередьте чат, що в наступних повідомленнях ви надсилатимете приклади, а він має чекати, поки ви не завантажите всю інформацію. Можна попросити ChatGPT не писати пояснень, відповідати певними фразами та ставити уточнюючі запитання, щоби краще зрозуміти завдання. Складні задачі слід розбивати на підзадачі для отримання більш точної відповіді. Поширені команди для ChatGPT: «Act as» — можна почати запит із визначення ролі для бота. Це допоможе йому краще розуміти контекст. Це може бути професія, позиція, відома особистість або навіть консоль, яка покаже, що виведе код. «Ignore Previous Commands» — оскільки ChatGPT запам'ятовує всю вашу переписку і вказівки, які ви надавали раніше, ви можете попросити їх ігнорувати, не створюючи новий чат. «Step by Step» — просимо бота відповідати послідовно, щоб отримати більш розгорнуту, логічну та детальну відповідь. «Do not write your own opinion» — просимо не додавати власну думку. «Continue» — якщо генерація тексту зупиняється на середині речення, ця команда продовжить текст з того місця, на якому вона зупинилась у попередній відповіді. «Summarize» — команда підходить, коли вам потрібен стислий огляд теми чи відповіді. «Compare & Contrast» — команда для порівняння предметів та виявлення схожостей та відмінностей. «Clarify» — якщо відповідь штучного інтелекту нечітка або неоднозначна, ця команда допоможе отримати чіткіше пояснення. «Brainstorm» — ця команда корисна, коли вам потрібні свіжі ідеї або інноваційні рішення. Приклади запитів, в яких передбачена роль, завдання та подальша інструкція: Act as a linux terminal. I will type commands and you will reply with what the terminal should show. I want you to only reply with the terminal output inside one unique code block, and nothing else. do not write explanations. Do not type commands unless I instruct you to do so. When I need to tell you something in English, I will do so by putting text inside curly brackets {like this}. My first command is pwd. Act as an interviewer. I will be the candidate and you will ask me the interview questions for the `position` position. I want you to only reply as the interviewer. Do not write all the conservation at once. I want you to only do the interview with me. Ask me the questions and wait for my answers. Do not write explanations. Ask me the questions one by one like an interviewer does and wait for my answers. My first sentence is "Hi". Act as a javascript console. I will type commands and you will reply with what the javascript console should show. I want you to only reply with the terminal output inside one unique code block, and nothing else. do not write explanations. Do not type commands unless I instruct you to do so. when I need to tell you something in English, I will do so by putting text inside curly brackets {like this}. My first command is console.log("Hello World"). Act as a cybersecurity specialist. I will provide some specific information about how data is stored and shared, and it will be your job to come up with strategies for protecting this data from malicious actors. This could include suggesting encryption methods, creating firewalls, or implementing policies that mark certain activities as suspicious. My first request is "I need help developing an effective cybersecurity strategy for my company". Стандартна проблема GPT — він все робить, як дуже лінива людина. Щоб ефективно користуватися цим інструментом, ви маєте чітко уявляти результат та мати терпіння знову і знову просити його щось доробити, змінити, додати або прибрати. Здається, що іноді швидше виконати завдання самому, ніж писати досконалий запит. Ми проводили ряд експериментів із ChatGPT, але більшість із них він провалив. Часом ChatGPT втрачав важливі деталі або обирав менш зручні конструкції фреймворку. Зокрема ми пробували переписувати код з однієї мови на іншу. На жаль, для цього треба було зробити таку кількість ітерацій з уточненнями, що важко розцінювати цей кейс, як спрощення роботи. Перший варіант, який він видав, був цілком робочим, але в такому вигляді код в продакшн не додають. Після кількох зауважень, другий та третій варіант були неробочими. Також ми давали завдання написати технічну документацію, надаючи код класу або фічі. Частково вийшло, але все ж таки потім багато довелося правити «руками». Швидкі огляди технологій та фреймворків — те, у чому чат показав найкращий перформанс. Ми використовували запити на кшталт «порівняй Selenide та Playwright» або «як написати цей тест, використовуючи фреймворк X». Без допомоги ChatGPT довелося б гуглити чимало статей, а він зібрав та систематизував розкидані дані. Хоча в останньому скрині видно, що він все ж забув про важливий функціонал. Я пробував ChatGPT для деяких рутинних завдань. Загальну якість відповідей чату оцінюю в 7 з 10. Вони завжди потребують перевірки та доопрацювання, але це дозволяє прискорити роботу на 5-10%. З мінусів — чат працює доволі нестабільно. Інколи прості завдання він може виконати з 1-2 разу та зекономити кілька годин роботи. А інколи буває, що релевантного результату взагалі неможливо добитися. В середньому я роблю 1-5 ітерацій уточнень. Наприклад, він може допомогти зі створеннями DTO із заданими полями (даю посилання або опис документації певної API) або з документацією (даю код і прошу описати це текстом або намалювати блок-схему в текстовому вигляді). Коли потрібно використати велику бібліотеку, яка має багато документації, він може згенерувати приклад використання в коді за описом. Це економить час. Якщо потрібно створити велику кількість однотипних файлів, Chat GPT пише bash-скрипти для оптимізації цього процесу. Також може допомогти з міграцією з PHP на TypeScript, яку ми зараз проводимо. Нижче ви знайдете підбірку із запитами для різних завдань, з якими ChatGPT може допомогти технічній команді. Генерація коду ChatGPT може генерувати код для різних завдань — семантичний HTML та CSS код, функції JavaScript і навіть запити до бази даних. Модель також може пропонувати варіанти завершення коду, які відповідають вашому контексту та стилю. Структура запиту: Generate a [language] script to parse [file format] and extract [information]. The script should meet the following requirements: [requirements list]; Develop a high-performance [language] microservice for [domain]. The microservice should provide well-defined endpoints for [operations list] and should follow the recommended [design pattern]; Compose a [language] function to filter [data structure] based on a specific [condition]. The function should take [input variables] as inputs and produce the expected output: [output description]; Design a [language] algorithm to solve [problem] using [strategy or technique]. Приклади промптів: Act as a code generation tool and create a Python script to parse CSV files and extract customer information with the following requirements: the script should handle large datasets, support filtering based on specific criteria, and provide a summary report of extracted data. Act as a code generation tool and develop a Node.js microservice for the e-commerce domain that includes endpoints for user authentication, product catalog management, and order processing. The microservice should adhere to the MVC (Model-View-Controller) design pattern. Act as a code generation tool and write a Java function to filter an ArrayList of integers based on whether they are even numbers. The function should take the ArrayList as input and return a new ArrayList containing only the even numbers. Act as a code generation tool and design a C++ algorithm to solve the knapsack problem using the dynamic programming approach. The algorithm should efficiently find the optimal combination of items to maximize the total value within a given weight constraint. Act as a code generation tool and generate a Python script that creates a directory structure for a new project. The script should include folders for source code, documentation, tests, and any other necessary components. Act as a code generation tool and generate a HTML template for a basic blog website. The template should include placeholders for the blog post title, content, author, and publication date. Act as a code generation tool and generate a Java class that represents a customer object. The class should have attributes for name, email, phone number, and any other relevant information. Act as a code generation tool and generate a JavaScript function that calculates the total price of a shopping cart. The function should take an array of items with their prices and quantities as input. Act as a code generation tool and generate a C# code snippet that creates a database connection and performs a simple CRUD operation on a table. Act as a code generation tool and generate a PHP script that generates a random password with a specified length. The script should include options for including uppercase letters, lowercase letters, numbers, and special characters. Code review Перевірка коду є важливою складовою розробки програмного забезпечення. За допомогою ChatGPT ви можете виявляти ознаки проблемного коду та вразливості. Структура запиту: Analyze the given [language] code and suggest improvements: [code snippet]; Review the given [language] code for potential scalability issues: [code snippet]; Check the following [language] code for proper logging and monitoring practices: [code snippet]. Приклади промптів: Act as a code reviewer and provide feedback on a Python script I wrote for a simple web scraping task. Please point out any potential errors or areas of improvement. Act as a code reviewer and analyze my JavaScript code for a responsive website design. Look for any potential performance issues or ways to optimize the code. Act as a code reviewer for my C++ program that implements a sorting algorithm. Please evaluate the efficiency of the algorithm and suggest any optimizations if necessary. Act as a code reviewer and assess the security of my PHP application. Check for any potential vulnerabilities or best practices that should be implemented. Act as a code reviewer for my Java application that handles database operations. Please review the database design and query optimization strategies. Act as a code reviewer for my Swift iOS app. Please assess the overall architecture and suggest any improvements in terms of code structure and organization. Act as a code reviewer and provide feedback on my HTML and CSS code for a responsive landing page. Look for any browser compatibility issues and suggest ways to enhance the design. Act as a code reviewer and analyze my SQL queries for a database-driven application. Check for any potential security vulnerabilities or ways to improve query performance. Конвертація коду Розробнику може знадобитися працювати з кодом, написаним різними мовами програмування або фреймворками. З допомогою ChatGPT ви зможете легко конвертувати фрагменти коду з однієї мови або фреймворка в інші. Структура запиту: Convert the following [source language] data processing pipeline to [target language]: [code snippet]; Migrate the following [source language] code that interacts with [database or service] to [target language] with a similar database or service: [code snippet]; Adapt the following [source language] code snippet to [target language] while adhering to [target language’s framework or library conventions]: [code snippet]; Translate the given [source language] method that performs [specific task or operation] to [target language]: [code snippet]. Приклади промптів: Transform a data processing pipeline implemented in JavaScript to Rust. Perform a migration of code written in Java that interacts with MySQL to C# with a similar database. Modify a PHP code snippet to work with Node.js using Express.js conventions. Convert a Java method that handles data encryption to C#. Translate a Ruby method used for text parsing to Python. Тестування ChatGPT може допомогти з тестуванням коду, надавши ідеї для написання тестових сценаріїв, виявлення помилок та поліпшення якості коду. Також він може допомогти писати модульні тести, створювати список тестових кейсів та вибрати відповідний фреймворк або бібліотеку для тестування. Структура запиту: Write a test script for the [language] code that covers [functional or non-functional] testing: [code snippet]; Generate test scenarios for the following [language] class or module: [code snippet]; Create a test suite for a [language] library or framework that validates its functionality and stability; Develop an end-to-end testing strategy for a [web/mobile] app that covers critical user workflows. Приклади промптів: Act as a QA engineer and write a test script for the Python code that covers performance testing. Act as a QA engineer and generate test scenarios for the following Java class or module. Act as a QA engineer and create a test suite for a JavaScript library or framework that validates its functionality and stability. Act as a QA engineer and develop an end-to-end testing strategy for a web app that covers critical user workflows. Act as a QA engineer and write a test script for the C# code that covers security testing. Act as a QA engineer and devise a comprehensive testing strategy for a mobile app that includes functional, usability, and localization testing. Act as a QA engineer and design a test suite for a PHP framework that covers both positive and negative test cases. Act as a QA engineer and develop an automated testing framework for a Java web application that includes unit tests, integration tests, and API testing. Документація За допомогою ChatGPT ви можете отримати підказки та рекомендації щодо генерації документації для вашого проєкту. Він може допомогти вам створити описи функцій, коментарі до коду та іншу необхідну документацію. Структура запиту: Create an API documentation template for the following [language] code: [code snippet]; Document the functionality and usage of the following [language] command-line tool: [code snippet]; Produce a tutorial for using the following [language] API with example code: [code snippet]. Приклади промптів: Act as a technical writer and explain the input parameters, output, and usage guidelines for the [function/class] in the given JavaScript code: [code snippet]. Act as a developer and generate detailed documentation for the [API/library] in the following Java code, including its methods, parameters, and return values: [code snippet]. Act as a technical writer and describe the purpose, dependencies, and usage instructions for the [module/package] in the given Ruby code: [code snippet]. Act as a technical writer and provide detailed documentation for the [function/class] in the following TypeScript code, including its purpose, parameters, and usage examples: [code snippet]. Act as a technical writer and explain the purpose, workflow, and configuration options of the [framework/library] in the provided PHP code: [code snippet]. Act as a developer and generate API documentation for the [RESTful API/endpoint] in the given Node.js code, including supported HTTP methods, request/response formats, and authentication requirements: [code snippet]. Рефакторинг коду ChatGPT може допомогти скоротити список коментарів «//todo: переробити цей код», пропонуючи способи рефакторингу та поліпшення коду без зайвих затрат часу та зусиль. Структура запиту: Suggest refactoring improvements for the following [language] code to enhance testability: [code snippet]; Identify opportunities to apply [architecture pattern] in the given [language] code: [code snippet]; Optimize the following [language] code for lower memory usage: [code snippet]; Refactor the given [language] code to improve its error handling and resilience: [code snippet]; Propose changes to the given [language] code to follow [SOLID or other design principles]: [code snippet]. Приклади промптів: Act as a Developer and suggest ways to improve the efficiency and readability of the [function/class/module] in the following Python code: [code snippet]. Act as a Developer and identify any code smells or antipatterns in the provided Java code, suggesting alternative approaches for cleaner and more maintainable code: [code snippet]. Act as a Developer and propose refactoring techniques to simplify the complex conditional statements and loops in the given JavaScript code: [code snippet]. Act as a Developer and refactor the redundant code blocks and duplicate logic in the provided C++ code to improve code reusability and maintainability: [code snippet]. Act as a Developer and suggest ways to enhance the performance and scalability of the [class/module] in the following Ruby code, considering best practices and design patterns: [code snippet]. Act as a Developer and propose a more concise and elegant implementation for the [function/class] in the given TypeScript code, eliminating any unnecessary complexity or repetition: [code snippet]. Act as a Developer and identify opportunities for abstraction and modularization in the provided PHP code, making it more modular and easier to maintain: [code snippet]. Act as a Developer and suggest improvements to the naming conventions, variable declarations, and code organization in the given C# code to enhance code clarity and readability: [code snippet]. Act as a Developer and propose refactoring techniques to optimize the database queries and improve the overall performance of the provided SQL script: [code snippet]. Act as a Developer and suggest ways to make the code in the given Python script more testable and decoupled, promoting better separation of concerns and code modularity: [code snippet]. Виявлення та виправлення помилок За допомогою підказок ChatGPT можна ідентифікувати та виправляти помилки в коді. Структура запиту: Locate any logic errors in the following [language] code snippet: [code snippet]; Identify potential performance issues in the given [language] code: [code snippet]; Find any resource leaks in the following [language] code and suggest fixes: [code snippet]; Check for potential deadlock issues in the given [language] code: [code snippet]. Приклади промптів: Act as a bug detection and fixing tool and identify common coding mistakes in a given Python script. Provide suggestions and explanations on how to fix the identified issues. Act as a bug detection and fixing tool and analyze a JavaScript program for potential memory leaks. Identify areas where memory is not properly released and suggest modifications to prevent memory leaks. Act as a bug detection and fixing tool and troubleshoot a C++ program that is causing a segmentation fault. Identify the source of the error and propose a solution to fix the segmentation fault issue. Act as a bug detection and fixing tool and analyze a Java application for potential concurrency issues. Identify areas where race conditions or deadlock situations may occur and suggest modifications to ensure thread safety. Act as a bug detection and fixing tool and inspect a PHP website for SQL injection vulnerabilities. Identify parts of the code where user input is not properly sanitized and suggest changes to prevent SQL injection attacks. Act as a bug detection and fixing tool and examine a Swift iOS app for memory management issues. Identify areas where memory is not properly released, such as retain cycles, and suggest modifications to improve memory management. Act as a bug detection and fixing tool and review a .NET application for potential security vulnerabilities. Identify areas where input validation or authorization checks are missing and suggest changes to enhance the application's security. Act as a bug detection and fixing tool and analyze a Python script for logical errors. Identify parts of the code where incorrect conditions or incorrect variable assignments may lead to unexpected behavior and propose fixes. Act as a bug detection and fixing tool and inspect a JavaScript codebase for potential cross-site scripting (XSS) vulnerabilities. Identify areas where user input is not properly sanitized before being displayed and suggest changes to prevent XSS attacks. Проєктування системи та архітектура ChatGPT може надати рекомендації щодо проєктування системи з використанням конкретного технологічного стеку або порівняння дизайну та архітектури. Структура запиту: Analyze the given architecture or design for potential security vulnerabilities: [architecture or design description]; Suggest improvements to the following [language] code or configuration to enhance its network performance or security: [code snippet]. Приклади промптів: Act as a system design and architecture consultant and provide guidance on designing a scalable and fault-tolerant distributed system. Discuss key principles and patterns, such as load balancing, replication, and partitioning, that should be considered in the design. Act as a system design and architecture expert and outline the architectural components and their interactions for building a real-time chat application. Consider aspects like message routing, data synchronization, and scalability in your design. Act as a system design and architecture consultant and propose an architecture for a cloud-based e-commerce platform. Discuss how to handle high traffic, ensure data consistency, and incorporate features like user authentication and order processing. Act as a system design and architecture expert and explain the design considerations for building a microservices-based architecture. Discuss topics like service decomposition, communication protocols, and fault tolerance in the design. Act as a system design and architecture consultant and design a data warehouse system for analyzing large volumes of data. Discuss the selection of appropriate storage technologies, data ingestion processes, and query optimization techniques. Act as a system design and architecture expert and propose an architecture for a content delivery network (CDN) to efficiently serve multimedia content worldwide. Discuss concepts like caching, edge servers, and content routing in your design. Act as a system design and architecture consultant and design a high-performance database system for a financial application. Discuss strategies for data indexing, query optimization, and ensuring data integrity in the design. Act as a system design and architecture expert and propose an architecture for a scalable and secure IoT (Internet of Things) platform. Discuss topics like device management, data processing, and authentication mechanisms in your design. Act as a system design and architecture consultant and design a fault-tolerant backup and disaster recovery system for a critical business application. Discuss replication strategies, backup scheduling, and failover mechanisms in your design. Act as a system design and architecture expert and propose an architecture for a real-time analytics platform. Discuss topics like data ingestion, stream processing, and visualization components in your design. DevOps ChatGPT може використовуватися для автоматизації деяких завдань DevOps-інженерів. Наприклад, контейнеризація та складання програми, створення helm chart для Kubernetes. Структура запиту: Create a [tool or script] for automating the deployment of a [language or technology] application to [cloud or platform]; Suggest improvements to the existing CI/CD pipeline for a [language or technology] project: [pipeline description or URL]; Design a monitoring and alerting strategy for a [web/mobile] app deployed on [cloud or platform]; Create a Dockerfile or containerization strategy for a [language or technology] application. Приклади промптів: Act as a DevOps Engineer and develop a Dockerfile and containerization strategy for a Java Spring Boot application. Ensure the Dockerfile includes all the necessary dependencies, build steps, and configurations for running the application in a containerized environment. Act as a DevOps Engineer and evaluate the existing CI/CD pipeline for a Ruby on Rails project hosted on GitLab CI/CD. Provide recommendations to optimize the pipeline, such as parallelizing test suites, introducing canary deployments, and integrating code quality checks and security scans. Act as a DevOps Engineer and create a containerization strategy using Kubernetes for a Python Flask application. The strategy should include defining deployment manifests, configuring load balancing, and implementing scaling policies based on resource utilization and traffic patterns. Act as a DevOps Engineer and propose a scaling strategy for a mobile app deployed on Firebase Hosting to handle high user demand and ensure optimal performance. Consider leveraging Firebase features like hosting CDN, Firestore database sharding, and Cloud Functions auto-scaling. Act as a DevOps Engineer and develop a tool or script for automating the deployment of a Node.js application to AWS Elastic Beanstalk. The tool should streamline the process of configuring the environment, deploying the code, and managing the infrastructure resources. Act as a DevOps specialist and provide suggestions to improve the existing CI/CD pipeline for a Python Django project. The pipeline currently uses Jenkins for building, testing, and deploying the application. Identify areas for optimization, such as parallelizing tests, implementing deployment strategies like blue-green deployments, and integrating additional quality checks. Act as a DevOps consultant and design a monitoring and alerting strategy for a mobile app deployed on Google Cloud Platform. The strategy should include setting up performance monitoring, log aggregation, and defining alerts for critical metrics using services like Stackdriver or Prometheus. Act as a DevOps expert and create a Dockerfile and containerization strategy for a Java Spring Boot application. The Dockerfile should package the application along with its dependencies, and the strategy should address efficient image building, optimization of container size, and integration with container orchestration platforms like Kubernetes. Act as a DevOps engineer and propose a scaling strategy for a web application deployed on Microsoft Azure. The strategy should focus on handling high traffic loads and ensuring scalability. Consider utilizing features like auto-scaling, load balancing, and caching to achieve optimal performance and resource utilization. Data Engineering ChatGPT може допомогти із перетворенням даних з одного формату в інший (наприклад, перетворення файлів CSV у JSON або XML), а також із обробкою та інтеграцією даних з різних джерел та розробкою конвеєрів даних. Приклади промптів: Act as a Data Engineer. I have two datasets: A and B. A is [explain A structure]. B is [explain B structure]. I need to join them on a foreign key [enter FK]. Provide the decision. Act as a Data Generator. Create a dataset that has [x] rows and [y] columns: [insert column names]. Act as a Senior Data Engineer. Provide a Python code sample demonstrating data engineering best practices to move data from a CSV file to BigQuery. Use the standard library when possible, but feel free to use external libraries if they significantly improve the process. Act as a Data Engineer. In Python I have a dependency tree in a dict. Write a script to invert that dependency tree. Act as a Data Engineer. I need to create a regular expression pattern that matches [specific requirement]. Can you provide a regex pattern and explain how it works? Act as a Code Optimizer. Can you point out what's wrong with the following Pandas code and optimize it? [Insert code here]. Act as a Data Engineer. Design an efficient data pipeline for ingesting and processing real-time streaming data from multiple sources. Act as a Data Engineer. Suggest best practices for data quality assurance and anomaly detection in a large-scale data warehouse. Act as a Data Engineer. Assist in selecting the appropriate data storage solution for storing and querying large volumes of structured and unstructured data. Act as a Data Engineer. Recommend strategies for data partitioning and indexing to enhance query performance in a distributed database system. Act as a Data Engineer. Help evaluate different data visualization tools and techniques for creating intuitive and interactive dashboards to visualize data insights. Suggest strategies for data versioning and lineage tracking to ensure traceability and reproducibility of data transformations and analyses.

В Україні стартує двотижневе безоплатне навчання для викладачів закладів освіти, які планують інтегрувати Всеукраїнські курси від Genesis у свої освітні програми. Навчання дає можливість викладачам підвищити експертизу у сфері створення, розвитку та маркетингу ІТ-продуктів, а також дізнатися більше про структуру Всеукраїнських курсів та навчитися методології їхнього викладання для студентів. Навчання викладачів відбуватиметься за наступним графіком:: 10–21 липня — курс «Створення та розвиток IT-продуктів». 24 липня – 04 серпня — курс «Маркетинг IT-продуктів». Викладачі, що успішно пройдуть курс і складуть тестування, отримають сертифікат із переліком набутих компетенцій та право на інтеграцію курсів у своєму ЗВО. Сертифікат містить відповідну кількість кредитів ЄКТС, ідентифікаційний номер та перелік здобутих результатів упродовж навчання. Також викладачі отримують доступ до всіх необхідних матеріалів для інтеграції курсу у свій навчальний процес: конспекти, інфографіки, презентації, бізнес-моделі тощо. Курси розроблено IT-компанією Genesis, Product IT Foundation for Education та студією онлайн-освіти EdEra спільно з Міністерством цифрової трансформації та Міністерством освіти і науки України. Викладачі можуть зареєструватися за посиланням. Адаптована версія курсу «Створення та розвиток IT-продуктів» також розміщена у вільному доступі на національній платформі цифрової грамотності Дія.Освіта.