🔥 QA в Agile Командах у 2026: вас замінить AI чи ви навчитеся ним керувати?Минулого тижня ми з Alexandra Kovalova провели вебінар «Agile навички тестувальника: сертифікація 2026 vs наболіла реальність».Якщо дуже коротко: QA вже не зможе ховатися за фразою “я просто тестую таски”. Бо задачі тепер можуть писати AI-агенти. Базові автотести - теж. Чеклісти, тест-кейси, аналіз вимог - все це вже частково автоматизується.А от розібратися, що насправді хоче користувач, де бізнес-ризик, чому команда знову назвала хаос “Agile”, і як не випустити в прод те, що технічно працює, але продуктово безглузде - тут магія в руках Людини. Тут потрібен нормальний QA із головою.На вебінарі ми розбирали:• чому хардові навички більше не гарантують безпеку на ринку;• як змінюється роль QA в кросфункціональних командах;• чому продуктовому мисленню вже не “було б добре навчитися”, а треба;• що нового з’явилось в ISTQB Agile Tester 2.0;• що з нових термінів типу mob testing, pair testing, test smells, exploratory testing, vibe testing реально корисне, а що більше схоже на маркетингову ковбасу в красивій обгортці.Моя улюблена частина - ISTQB нарешті почав наздоганяти реальність.Бо Agile Testing - це вже не про “тестувальник сидить в кінці спринта і героїчно розгрібає все, що команда накидала та читає мантри про неможливість shift-left...”.Це про участь у формуванні user stories, роботу з ризиками, швидкий фідбек, командну відповідальність за якість і вміння бачити систему, а не тільки багу в Jira.Судячи з відгуків - тема багато кого зачепила і саме тому ми запускаємо курс ISTQB Agile Testing.📅 Старт вже 17 червня! Разом з Олександрою будемо не просто готувати до сертифікації, а до реальної роботи в Agile-командах.Формула курсу проста:30% — ISTQB база, щоб скласти іспит70% — Agile-реальність, кейси, приклади, біль, дискусії і “а як це вижити на справжньому проєкті?”Це курс для QA, QA Lead’ів, автоматизаторів і всіх, хто хоче нарешті відрізняти Agile від анархії з дейліками й зрозуміти, чому в Scrum Guide є лише 3 відповідальності: Product Owner, Scrum Master, Developers 😉 🎥 Запис вебінару тут <<🚀 >>> Реєстрація на курс тут <<<Ви не тестувальник і не QA?Поділіться із тими - кому може бути корисно й цікаво 🤪 судячи з відгуків з 1ї групи - вони будуть вам вдячні 😉
Головна навичка для Бізнесу сьогодні — це вже не “планувати краще”, а вміти мислити, приймати рішення й рухатись тоді, коли стабільності як опори просто немає.12 червня 2026 (ця пʼятниця) у Києві буде BUSINESS THINKERS FORUM’2026 — і я планую бути там, щоб послухати дуже сильних спікерів і спікерок. Формат: offline + online, очікують 300+ учасників. Тема форуму — “Гра на випередження”: як створювати довгострокову цінність і конкурентну перевагу, коли майбутнє неможливо нормально спрогнозувати. Чому мені це цікаво?Бо більшість компаній досі намагаються керувати невизначеністю так, ніби це тимчасовий баг. А схоже, що це вже операційна система.На форумі будуть говорити про речі:— як ухвалювати рішення без повної інформації;— як тримати стратегічний горизонт під час постійних криз;— як будувати адаптивний бізнес в умовах геополітичної й безпекової невизначеності;— що буде з роллю CEO, коли аналіз, прогнозування й оптимізацію дедалі більше бере на себе ШІ;— як зберігати людяність, довіру й культуру в організаціях, які живуть під постійним тиском. Окремо для мене цінно, що там буде не чергова “бізнесова мотивація зі сцени”, а топові люди з дуже різних контекстів: Євген Глібовицький, Ольга Устинова, Дмитро Поліщук, Артур Міхно, Андрій Длігач, Катерина Загорій, Сергій Ноздрачов, Наталія Кривда, Петро Чорноморець, Олександр Філоненко та інші. Я йду туди не за “готовими відповідями”. Їх, чесно кажучи, давно ні в кого немає.Йду за якісними питаннями, живим обміном досвідом і можливістю провести день серед людей, які теж намагаються думати на кілька кроків вперед.І дуже рекомендую долучитись — особливо, якщо ви CEO, топменеджер/-ка, працюєте з трансформаціями, стратегією, людьми або просто відчуваєте, що старі управлінські моделі вже не тягнуть.🫰Для моєї спільноти є промокод на знижку на квитки:Bykovets -10%
Деталі та реєстрація тут:https://kagroup.ua/btf/Побачимось на форумі. Буде хороший день, щоб подумати не тільки “що робити завтра”, а й “якою має бути наша організація, щоб у неї взагалі було післязавтра”.
Повернувся з DOU Day 2026 — і поки емоції ще не вляглись, хочу поділитись враженнями.1. Перш за все — величезна подяка організаторам. Dou Day схоже стає наймасштабнішою й топовою Tech-подією не тільки України, а й всього регіону.Топові спікери, сильні дискусії, купа випадкових і невипадкових зустрічей, нові знайомства, обмін ідеями, думками, контактами — і той самий вайб, після якого хочеться робити більше й краще.2. Цього року дуже відчувся ще один момент: AI-тема остаточно перестала бути “чимось абстрактним, що насувається”.Менше футурології й хайпу — більше конкретики, прагматизму й реальних кейсів. І це, чесно, дуже хороший знак для індустрії.3. Окремий кайф — виступ (чи все ж таки інтерв’ю?) Віталія Портникова.Десь на межі між ввічливістю та прямотою. Подекуди — емоційно переступаючи цю межу. Але саме через це — живо, чесно й дуже сильно. (рекомендую глянути запис, як опублікують)4. На жаль, цього разу багато побачити не встиг. У мене вже майже традиція: DOU Day знову припав на день народження Сина 😅 Тому встиг переважно привітатись, пофоткатись з тими, кого давно не бачив, поспілкуватись із людьми, які підходили подякувати чи познайомитись — і помчав далі.5. І окремо — про мій воркшоп:“Леви, Жирафи і Техлід. Як не згоріти в різних очікуваннях”.Це був, мабуть, один із найбільш ризикованих форматів, які я виносив на Tech-аудиторію. Тема про Competing Values Framework, метафори, поведінкові моделі, різні типи управлінських очікувань — звучить доволі абстрактно для технічної конференції. До того ж воркшоп додали в програму вже на фінальних етапах підготовки.Зала була найменшою зі сцен.Але людей прийшло стільки, що:— хтось сидів на підлозі;— хтось дивився збоку на екрані;— а частина людей стояли в кінці зали в три ряди.І це все — після повітряної тривоги буквально за кілька хвилин до старту.Вийшов справжній фурор.І я дуже вдячний вам за довіру, включеність, жарти, дискусії й той фідбек, який летить уже третій день поспіль ❤️Як і обіцяв — докрутив метафору з “Льодовикового періоду” й додаю її до посту 🙂P.S. Якщо були на конференції — пишіть в коментарях свої враження.І окремо цікаво: про що хочеться почитати в наступних постах?
Останні тижні виглядають так, ніби я відкрив “Список виступів 2026” і вирішив не зупинятись 😄Короткий апдейт, що вже вийшло (і що ви могли пропустити):• Записав відео про OKR. Якщо ви досі думаєте, що OKR = “більш амбітні KPI” — варто глянути.• Поговорили про “темну сторону ІТ” разом з Ray Astafichev, Andrii Mandrika та Susanna Salata в “Шляху Самурая”. Там про реальність, про яку не говорять на конференціях.• Сходив до Павла Сафонова в подкаст з темою, яка всіх трохи нервує: “чи живий Agile в епоху AI?” (спойлер: питання не в тому, живий чи ні)• Вийшов наш подкаст на Radio KMBS з Сергієм Комберяновим: “Lean vs Agile” — не як фреймворки, а як спосіб мислення;• і скоро ще дещо вийде на каналі у Лєри Лістратової.А тепер — куди можна прийти і поспілкуватись «вживу» (плануйте дати!) 👇📍 DOU Day (15–17 травня, Київ)15-го — ходжу, слухаю, знайомлюсь16-го (11:00–12:30, потік GROWTH) — веду воркшоп:“Леви, Жирафи і Техлід. Як не згоріти в різних очікуваннях”🎟 промокод: BYKOVETS10📍 19’ People Management Conference (20 травня, Київ)Тема: “Рентабельність сміху: як гумор захищає команди від вигорання та підвищує ефективність”(так, це серйозна тема 😏)📍 Форум Бізнес-Фасилітації (9 червня, Київ)Воркшоп: “50 відтінків стилів фасилітаторів”(спойлер: універсального стилю не існує)📍 Бізнес Форум: Стратегічний HR (12 червня, online)Тема: “Організаційний дизайн та Agile-практики на етапі стратегічних змін”📍 Product fwdays’26 (20 червня, Київ)Тема ще в роботі — і тут цікаво:напишіть, що вам реально болить у продукті / командах / масштабуваннізроблю виступ не “як треба”, а “як потрібно вам”Якщо коротко:менше теорії → більше реальних кейсів, помилок і того, що працює (або не працює 🤪)Побачимось офлайн або в записах 👌
Давно нічого не релізив на своєму YouTube каналі та ось цей час настав 🙂 Все частіше мене питали: «чи є щось коротко й лаконічно про OKR щоб показати ТОП-ам / Командам?» і я не мав під рукою відповіді в якій впевнений достатньо 🤪Отож (не Otoy, а саме Отож (с))! В цьому короткому та лаконічному відео за 20 хвилин розповідаю ключову суть #OKR фреймворку - Ojective & Key Results або ж Цілі та Ключові Результати. Розкажу про:• суть та призначення OKR• output vs outcome• звʼязок між Стратегією, OKR та KPI• відмінність між KPI та OKR (й чому один підхід не є заміною іншому)• які переваги може привнести використання OKR• коротко принципи створення та опису Цілей (Ojectives) та Ключових Результатів (Key Results)• різниця між Key Activities та Key Results• Стратегічний та Тактичний рівень при застосування у великих організаціях• ітеративний процес й квартальні цикли з конкретними подіями по створенню й перегляду OKR• приклади використання фреймворку з побутового життя та різних типів бізнесів Лишайте коментарі, поширюйте, діліться вашим досвідом 😉
👋 Памʼятаю, що вам добре заходила тема #PolarityThinking і сьогодні поділюсь із вами чудовим постом від Яріка Бондарчука (мого екс-колегу по #Simplesense та mono).Автономія без інтеграції - це не свобода.Це дорога форма хаосу.–––Приніс вам цікавий історичний кейс, який вважається одним із класичних прикладів "стратегічного самогубства”, на який пропоную поглянути під призмою Polarity Management.Одна з неочевидних причин поразки Японії у Другій світовій війні полягає у внутрішній архітектурі управління: глибокий конфлікт між армією та флотом, які діяли майже як дві окремі держави. Армія будувала власні підводні човни.Флот мав власні наземні війська.Різні типи озброєння, різні стандарти, різні пріоритети.У критичні моменти - мінімум координації, максимум боротьби за ресурси.Більше того - різне визначення ворога і, відповідно, цілей: армія "дивилася на північ", вважаючи головним ворогом СССР; флот "дивився на південь", вбачаючи загрозу в США та Британії.Polarity Thinking нагадує просту, але незручну річ:є питання, які не можна “закрити” одним правильним рішенням.Їх можна лише тримати в робочій напрузі, не скочуючись у крайнощі.Відповідно це не “або-або”. Це “і-і”, яким треба свідомо керувати. У випадку з японцями це славнозвісна парочка полярностей “централізація <-> автономія” Автономія дає:— швидкість— адаптивність— ініціативу ближче до реальностіЦентралізація дає:— узгодженість— спільний пріоритет— дисципліну у використанні ресурсівПроблеми починаються тоді, коли система робить ставку лише на один із полюсів.Коли автономії занадто багато, з’являються:— дублювання функцій— локальна оптимізація— coopetition замість cooperation— “мій бюджет / мої люди / мої пріоритети”Коли все занадто “централізоване”, з’являються:— повільність— бюрократія— втрата відповідальності на місцях— управлінський центр як bottleneckГадаю, кожен з нас хоча б раз стикався зі схожим патерном в організаціях:команди, департаменти чи функції настільки захищають свою автономію, що починають будувати власні “флоти”:свої процеси,свої інструменти,свої правила,свої рішення,і найчастіше свої версії реальності.На короткій дистанції це може виглядати ефективно.На довгій - система платить за це фрагментацією, конфліктами пріоритетів, підвищеною психодинамікою і виснаженням ресурсів.Тому питання для організацій не в тому, що обрати: централізацію чи автономію.Питання в іншому: які рішення мають бути централізовані, а де автономія справді створює цінність?І ще важливіше:які механізми допомагають не воювати за ресурси, а працювати в спільному контексті?Сильна організація - це не та, де всі однаково мислять. І не та, де кожен тягне у свій бік “на силі особистості”.Сильна організація вміє тримати напругу між різними полюсами, не руйнуючи себе зсередини.
FOMO vs. FOWT: Чи варто бігти за кожним АІ-потягом? 🧠🚂Спостерігаю зараз цікавий феномен, який дуже нагадує класичну пастку трансформацій, тільки тепер у площині Штучного Інтелекту. Назвемо це битвою: FOMO (Fear Of Missing Out) проти FOWT* (Fear Of Wasting Time) (*цікаво чи існує такий термін, бо я певен, що сам його щойно вигадав 🤪 …).🤯 Раунд 1: Хайп і FOMOЗараз усі стрічки забиті: "AI-агенти за 5 хвилин", "Як впровадити Claude Cowork у вашу рутину», "Мануал по Claws для початківців". Здається, якщо ти сьогодні не проходиш новий курс по ШІ - завтра ти вже динозавр.Це класичне FOMO. Страх пропустити "ту саму срібну кулю", яка вирішить усі проблеми.🔄 Але давайте згадаємо...Приблизно рік тому всі божеволіли від "Курсів по правильному написанню промптів" та «автоматизації на n8n». Де ці знання зараз? Вони або стали базовою гігієною, або застаріли, бо самі інструменти еволюціонували і стали розумнішими.Швидкість змін шалена. Те, що вчора було проривом, сьогодні - legacy.⏱️ Раунд 2: Прагматизм і FOWT*І тут вмикається FOWT - страх даремно витраченого часу.Як Лідер трансформацій, я дивлюсь на це системно. Проблема не в тому, щоб вивчити новий інструмент. Проблема в тому, навіщо ми його вчимо і що це змінить у нашому потоці цінності (value stream).Витратити місяці на глибоке вивчення конкретного AI-інструмента, який через півроку замінять вбудованим функціоналом, - це класичне Муда (втрати) у Lean.💡 висновок і порада лідерам:Ми ж з вами не про інструменти, як основу, а про структури, системи й мислення. ШІ - це надпотужний акселератор, але він не замінить здоровий глузд і правильний оргдизайн. Як там було? 🤔 «Agile AI has no Brain. Please! Use your own…»Не піддавайтеся FOMO. Балансуйте з FOWT.1. Не вчіть "інструмент ради інструменту". Вивчайте принципи роботи ШІ та його можливості для автоматизації рутини.2. Тестуйте швидко, впроваджуйте обережно. (Inspect and Adapt(с)). Створіть пілот, подивіться, чи зросла швидкість, ефективність і тільки тоді масштабуйтесь й вкладайте більше часу.3. Головна навичка - адаптивність, а не знання claude-blabla. Вчіться й будьте готові постійно вчитись!Інструменти змінюються щомісяця. Принципи ефективної роботи та Лідерства залишаються.А як у вас? Більше FOMO чи FOWT, коли бачите черговий "революційний" AI-тул? Пишіть у коментарях 👇#Agile #Leadership #Transformation #AI #Mindset #FOMO #FOWT
🚀 Якщо вам здається, що для "прискорення" потрібно просто найняти ще людей — у мене для вас погані новини 🙂Давайте відверто. Якщо у вас на одну фічу потрібно 5++ команд, 3 сінка в тиждень і окремий чат “координація координації” - у вас не проблема з кількістю розробників чи їх швидкістю. У вас проблема з системою.📉 Що відбувається на практиці?Бізнес росте → наймаємо людей → створюємо нові команди → додаємо “ще трохи Agile для швидкості”І отримуємо: більше залежностей + більше синхронізацій + більше конфліктів пріоритетів...❌ менше швидкостіБо "спойлер": більше людей ≠ більше delivery🤦♂️ Типова реакція:“Може ще SAFe зверху накотимо?”“А давайте Spotify-модель ...”🧠 Що насправді ламається?Проблема не у Scrum / SAFe / Spotify... Проблема в тому, що:- неправильно визначені межі продукту;- команди розрізані по компонентах, а не по value;- відповідальність за результат розмита;І це все намагаються… масштабувати...💥 Найболючіша помилка:Масштабувати людей і команди раніше, ніж оновити Організаційний Дизайн! Бо тоді ви масштабуєте не value delivery, а власні дисфункції.🚀 Висновок: Scale Value Delivery and De-scale Complexity!А саме:👉 Менше ролей!👉 Менше "продуктів / беклогів"!👉 Менше “координації координації”!👉 Більше цілісності.Масштабування — це не про те, щоб найняти ще 20-120 людей. Це про те, як витримає система цей ріст...p.s.: цей пост «залетів» і викликав багато коментарів у мене в Linkedin, то я вирішив і тут із вами поділитись 😉#Agile #Scaling #Product #Fintech
Не все, що неприємно чути, є токсичністюЗараз у командах з’явилася зручна гра: усе, що не гладить по голові, оголошувати токсичністю.Сказали прямо, що результат слабкий — токсичність.Нагадали про відповідальність — токсичність.Не проковтнули зрив дедлайну — токсичність.Поставили жорстку рамку — токсичність.Не стали танцювати навколо чужого его — токсичність.Це вже не про турботу до людей. Це про втечу від дорослої професійної реальності.Бо правда в тому, що багато команд сьогодні страждають не від жорстких керівників. Вони страждають від розмитих правил, боягузливої комунікації і м’якої нечесності, яку подають як емпатію.Поведінкова наука давно це описала - людина природно уникає соціального дискомфорту. Саме тому керівники так часто відкладають складні розмови, пом’якшують очевидне, не фіксують порушення, закривають очі на слабкий внесок і роками шукають підхід там, де давно треба було домовитися про норму. У короткій перспективі це дає полегшення. У довгій — руйнує довіру, стандарти і саму систему відповідальності.Нейронаука додає важливу деталь: нервова система виснажується не лише від тиску. Вона дуже погано переносить невизначеність. Коли в команді незрозуміло, що є нормою, що є порушенням, за що є наслідки, а за що їх немає, мозок переходить у режим постійного сканування. Люди працюють не на результат. Люди працюють на виживання в непередбачуваному середовищі.І ось тут ключове:жорсткість не дорівнює токсичність.Чіткість — це не агресія.Вимогливість — це не насильство.Пряма зворотна реакція — це не приниження.Стандарти — це не жорстокість.Більше того, у багатьох командах саме цього зараз критично бракує: ясності, послідовності й чесності, яка не маскується під делікатність.Токсичність має цілком конкретні ознаки. Це приниження. Це маніпуляція. Це подвійні стандарти. Це публічне знецінення. Це страх як інструмент управління. Це системне руйнування гідності людини.Але коли керівник каже:ось стандарт;ось порушення;ось відповідальність;ось наслідки;ось що треба виправити, —це не токсичність. Це елементарна управлінська дорослість.Ми занадто далеко зайшли в культі індивідуального підходу. Так, люди різні. Так, у всіх різний темперамент, різна швидкість адаптації, різний спосіб сприймати зворотний зв’язок. Але команда не може існувати як сервіс безкінечного персонального налаштування під кожного. Тому що в якийсь момент управління закінчується і починається хаос, де найгучніший, найобразливіший або найемоційніший фактично диктує правила всім іншим.Зріла команда тримається не на нескінченному пошуку підходів. Вона тримається на домовленостях і правилах.Що для нас є нормою? Як ми даємо зворотний зв’язок?Яку якість роботи вважаємо прийнятною? Що відбувається, якщо домовленість зірвана? І головне — чи правила справді однакові для всіх? Бо коли правил немає, з’являється улюблена корпоративна брехня: у нас людиноцентрична культура. Насправді ж там зазвичай інше: уникання складних рішень, толерування слабкості, вибіркові винятки і страх назвати проблему проблемою.Найнебезпечніше, що під ярликом нетоксичності зараз часто продають управлінську безхребетність.Керівник боїться бути незручним.Команда боїться чітких розмов.Посередність отримує захист.Вимогливість викликає підозру.А потім усі щиро дивуються, чому сильні люди втомлюються і йдуть.Сильні люди рідко йдуть від ясності. Вони йдуть від подвійних стандартів, туману і середовища, де порушення треба терпляче контейнерити, а не припиняти.Тому, можливо, час уже перестати називати токсичністю все, що має хребет.Не кожна жорстка розмова ранить.Не кожна вимога пригнічує.Не кожне пряме слово руйнує.Дуже часто воно просто повертає команду в реальність, де домовленості щось означають, відповідальність не є декоративною, а чесність звучить не завжди приємно, зате зрозуміло.Авторка Natalya Kadja
🔥 Новинка від Dave West з Scrum.org: Опубліковано принципи Agile Product Operating Model (APOM)!Що кажуть в пості на сайті та що видно з швидкого огляду гайдлайну:Світ змінюється занадто швидко для традиційних операційних моделей. Саме тому Scrumorg представили Agile Product Operating Model (APOM) - підхід, заснований на принципах і доказах (evidence-based), який допомагає організаціям узгодити бізнес-стратегію з операційним виконанням.Що це і для чого?APOM - це не жорсткий шаблон, а цілісний підхід для навігації в комплексному середовищі. Його головна мета - допомогти компаніям безперервно постачати цінність, швидше адаптуватися та процвітати в умовах високої невизначеності. Він виступає «містком» між сучасним продакт-менеджментом та гнучкими agile-підходами.Як розвивався APOM?Робота над моделлю тривала останні два роки. Команда Scrumorg спілкувалася з представниками різних галузей - від автомобілебудування та біотехнологій до банківської справи та ритейлу. Дослідження показали, що кожна організація унікальна, тому APOM еволюціонував із чіткого фреймворку в набір настановчих принципів. Це дозволяє компаніям оцінювати будь-яку існуючу модель роботи (наприклад, SAFe або «Spotify») через призму цих принципів.Варіанти застосування та ключові зони:APOM охоплює чотири основні сфери, де принципи допомагають приймати рішення:- Стратегія: Інтеграція цілей бізнесу та технологій через довгострокові дорожні карти та метрики результатів (outcomes), а не просто фіксовані графіки поставок.- Люди: Фокус на крос-функціональних командах, які мають повноваження та підтримку Лідерів.- Структура: Заміна бюрократичних бар'єрів гнучкими процесами, закупівлями та управлінням, що базується на результатах.- Цикл створення цінності (Value Cycle): Об'єднання Discovery (валідація ідей), Delivery (поставка) та Support (підтримка) в єдину безперервну петлю зворотного зв'язку.Чому це важливо?У сучасну цифрову епоху та з розвитком ШІ (AI) організаціям потрібно бути «швидшими, меншими та пласкішими». APOM надає інструменти для вимірювання реального прогресу за допомогою об'єктивних даних (Evidence-Based Management), а не суб'єктивних припущень.👇 Ознайомитися з повною версією гайду можна за посиланням.#Agile #Scrum #APOM #BusinessAgility
TGLIST.COM.UA
