Існує думка, що менторство полягає виключно у передачі досвіду від сформованого спеціаліста до початківця. Але системна робота у цьому напрямі дає ментору не менше користі, ніж менті. Створення позитивної репутації серед рекрутерів та спільноти, масштабування себе та свого впливу через контент, рев’ю пет-проєктів для розвитку надивленості та збільшення кількості пропозицій від роботодавців — це лише частина плюсів, які може через менторство отримати ІТ-фахівець. Також розповім, як менторство початківців допомогло мені почати співпрацю з поточною компанію. Доповідь буде корисною спеціалістам з досвідом, які хочуть розвивати професійну спільноту, але не розуміють, що це їм дасть.

Про що піде мова? Що відрізняє “тиск” і “хаос” в продуктових командах? Чому ці категорії часто розмиваються між собою, і як привчитись дотримуватись тонкої межі між ними. Що допомагає командам рости над собою? Чому “зрілі” команди втрачають чутливість до стимулів росту, а “молоді” команди не можуть визначитись із підходами до росту? Що “ламає” команди, а що “закаляє“? Як менеджерам визначитись із стратегією управління тиском на команди, а командам правильно сприймати і використовувати той самий тиск?

Що означає бути лідером і які якості потрібно в собі розвивати? І як зрозуміти чи є в тебе взагалі ці скіли? Це не просто питання — це ключ до розуміння того, з чого почати і куди рухатись далі у розкритті свого потенціалу. Розберемось з лідерством і з коучином, як інструментом розкриття лідерського потенціалу. Зрозуміємо, чим коучинг відрізняється від менторства, психотерапії та тренінгів і чому це все не одне і те ж. Особливу увагу приділимо самокоучингу – як навчитися вести внутрішній діалог так, щоб рухатися вперед навіть тоді, коли поруч немає підтримки. Поділюся кількома практичними лайфхаками і реальними прикладами, які допоможуть сформувати план і почати діяти вже завтра.

Щодня менеджери і лідери стикаються з великою кількістю рутинних завдань: створення та оновлення задач у Jira, ведення мітингів, синхронізація команди, ретроспективи, документація. Більшість цих процесів забирає час, який можна витратити на стратегічне управління та розвиток команди. У цій доповіді я покажу, як використовувати AI, щоб оптимізувати командні процеси, автоматизувати рутину та зробити роботу ефективнішою. Ви дізнаєтесь, як AI допомагає зі Scrum-процесами. Також я поділюся своїм досвідом автоматизації в Jira та Slack: як за допомогою простих правил зменшити ручну роботу, налаштувати автоматичні повідомлення про блокери, створювати сторінки в Confluence, оцінювати продуктивність команди та отримувати корисні інсайти.

Розвиток продуктового майндсету – це довготривалий процес, що потребує правильної комунікації, залучення команди та створення культури експериментів. Коли розробники відчувають себе частиною продукту, вони починають не просто кодити, а створювати цінність для користувачів. Розглянемо на реальних кейсах, завдяки яким практичним інструментам можна розібратися з кожним викликом та перетворити команду з виконавців на продуктових ентузіастів. Також надамо поради для розробників, про те, як можна задрайвити продуктову культуру самостійно.

Суміш практичних порад і реальних історій, де два експерти діляться секретами успішного проходження всіх етапів від прескріну до фінальної розмови. Співбесіда – це завжди випробування, незалежно від досвіду. Чи можна уникнути типових помилок та підвищити свої шанси на успіх? Так! Головне – знати, як правильно підготуватися та які факапи обходити стороною.На цій зустрічі два експерти поділяться реальними історіями та практичними порадами щодо проходження всіх етапів від першого прескріну до фінальної розмови. Ми розберемо типові помилки кандидатів, пояснимо, як не зірвати офер в останній момент, та дамо рекомендації, які допоможуть почуватися впевнено під час співбесіди.

Одна з головних проблем у робочому спілкуванні — говорити про те, що не подобається, і надавати фідбек. Понад 50% непорозумінь виникає саме в таких ситуаціях, незалежно від проєкту. А якщо додати емоційне виснаження та нерозуміння культурних відмінностей, наслідки можуть бути серйозними. У своєму виступі Олексій розповість про інструменти зворотного зв’язку, які працюють для IT-фахівців. Він розгляне, чому в багатьох культурах складно давати й приймати конструктивну критику, і як основи аргументації, помножені на прості принципи емпатії, допомагають уникнути понад половину потенційних конфліктів.

Чи бувало у вас таке, що одна команда працює як годинник, а інша – гальмує на рівному місці? Чому один розробник кайфує від свободи, а інший без чітких інструкцій впадає в ступор? А головне – що з цим робити, коли ви вже не просто кодите, а керуєте людьми?Доповідь для тих, хто хоче перестати "гасити пожежі" та почати впливати на людей і результати по-дорослому. Буде практично, місцями боляче, але після цього ви точно інакше подивитеся на свою команду.

У світі IT, де технології розвиваються зі швидкістю світла, важливо розуміти не лише що вивчати, але й коли це робити. На цій доповіді ми розглянемо практичний підхід до професійного розвитку IT-фахівця та з'ясуємо, як ефективно відстежувати новинки галузі без шкоди для основної роботи. Ми поговоримо про те, що насправді впливає на вашу цінність як розробника, коли варто інвестувати час у вивчення нових технологій, та як це співвідноситься з іншими важливими навичками - від знання англійської до розуміння бізнес-цінності проєктів. Доповідь буде корисна як початківцям, які тільки виходять на ринок праці, так і досвідченим розробникам, які прагнуть залишатися конкурентоспроможними.

Кожен справжній перфекціоніст хоч раз у своєму житті чув, що немає нікого і нічого ідеального, тому треба просто зменшити свої вимоги, менше заморочуватися і дозволити собі помилятися. Адже на помилках вчаться і не помиляється тільки той, хто нічого не робить. І хоч це все правда, але ймовірність, що це хоч якось допомогло, приблизно 0,0000000000001%. У своїй доповіді Марія розповість про революційний препарат Перфекціонізин. А саме подивимося на перфекціонізм глибше, розберемося, що приховується за ним, щоб діяти саме на причини. Тобто лікувати хворобу, а не симптоми.