Хей! Сьогодні починаємо серію публікацій про провали у наших (скрам мастерських і не тільки) кар’єрах 😵
Kateryna Motko
Діло було у моїй першій-першій команді на позиції скрам мастера. Команда була теж юна: усе джуни + 2 тех ліди, жодних мідлів та сініорів.
На першому пленінгу ми стикнулись з проблемою, що більшість тіммейтів ніколи не естімейтали та про сторі поінти, як у приказці: чули дзвін - та не знають, де він. Я взялась розказувати про відносні та абсолютні, про числа Фібоначі, про те, що сторі поінти не конвертуємо в дні-години-хвилини 👀, одним словом все, що знала сама у теорії.
Але чи то лижі не їдуть, чи то я, та команда, бачу, намагається скласти пазл, але не виходить. І я, щоб полегшити їм муки, якогось милого кажу: “ну 1 сторі поінт - то менше дня робити, 8 сторі поінтів - то на весь спринт роботи, 5 - десь на половину, 2 і 3 - десь посередині.” В очах колег бачу осяяння, мовляв, а чому зразу так не сказали 😇, і далі перший пленінг пройшов доволі незле.
Всі наступні естімації були приблизно такими: “ну це десь на 2 дні, тому 2 сторі поінти” і т.д. І скільки мені зусиль би не пішло, команда затямила собі таку рівність, і навіть якщо потім вони цього не озвучували, та все одно продовжували так робити через те, що на старті я їм це вклала в голови.
❗️Скрам мастери, поділіться в коментарях своїми фейлами?
Kateryna Motko
Діло було у моїй першій-першій команді на позиції скрам мастера. Команда була теж юна: усе джуни + 2 тех ліди, жодних мідлів та сініорів.
На першому пленінгу ми стикнулись з проблемою, що більшість тіммейтів ніколи не естімейтали та про сторі поінти, як у приказці: чули дзвін - та не знають, де він. Я взялась розказувати про відносні та абсолютні, про числа Фібоначі, про те, що сторі поінти не конвертуємо в дні-години-хвилини 👀, одним словом все, що знала сама у теорії.
Але чи то лижі не їдуть, чи то я, та команда, бачу, намагається скласти пазл, але не виходить. І я, щоб полегшити їм муки, якогось милого кажу: “ну 1 сторі поінт - то менше дня робити, 8 сторі поінтів - то на весь спринт роботи, 5 - десь на половину, 2 і 3 - десь посередині.” В очах колег бачу осяяння, мовляв, а чому зразу так не сказали 😇, і далі перший пленінг пройшов доволі незле.
Всі наступні естімації були приблизно такими: “ну це десь на 2 дні, тому 2 сторі поінти” і т.д. І скільки мені зусиль би не пішло, команда затямила собі таку рівність, і навіть якщо потім вони цього не озвучували, та все одно продовжували так робити через те, що на старті я їм це вклала в голови.
❗️Скрам мастери, поділіться в коментарях своїми фейлами?
💥Секрети фасилітації за Майклом Вілкінсоном
Ділиться з нами Dmytro Skliar
SMART-фасилітація заснована на 11 принципах, які забезпечують фасилітаторам чітке бачення ідеального процесу. Структура і схема SMART-фасилітації наведена нижче.
#1
Головний секрет фасилітації
Ви можете досягти більш ефективних результатів, якщо рішення створюються, розуміються і приймаються людьми, на яких вони впливатимуть.
#2
Секрет доцільності фасилітації
Фасилітація необхідна, якщо до процесу ухвалення рішення залучено кілька осіб і потрібні їхнє розуміння і прийняття.
#3
Секрет початкового запитання
Вдалі початкові запитання породжують яскраві образи відповідей.
#4
Секрет спрямування групи
Спрямовуйте групу за допомогою запитань, а не тверджень.
#5
Секрет передачі ідеї учасникам фасилітаційної сесії
Коли ви намагаєтеся запропонувати учасникам ідею, попросіть їх назвати її переваги й те, як її можна сформулювати.
#6
Секрет підготовки
Під час підготовки визначте свої *5P (purpose, product, participants, probable issues, process) - мета, продукт, учасники, можливі проблеми, процес.
#7
Секретна сила мети
Чітка мета забезпечує надійну основу для ухвалення рішень.
#8
Секрет визначення продукту сесії: 3H(hands, heads, hearts)
Щоби визначити бажані продукти фасилітаційної сесії, поставте таке запитання: Які речі, що їх до початку сесії не було, ви хочете мати в руках (результати), головах (знання) та серцях (переконання) учасників?
Решта секретів фасилітації очікуйте в наступному дописі ⏩
Ділиться з нами Dmytro Skliar
SMART-фасилітація заснована на 11 принципах, які забезпечують фасилітаторам чітке бачення ідеального процесу. Структура і схема SMART-фасилітації наведена нижче.
#1
Головний секрет фасилітації
Ви можете досягти більш ефективних результатів, якщо рішення створюються, розуміються і приймаються людьми, на яких вони впливатимуть.
#2
Секрет доцільності фасилітації
Фасилітація необхідна, якщо до процесу ухвалення рішення залучено кілька осіб і потрібні їхнє розуміння і прийняття.
#3
Секрет початкового запитання
Вдалі початкові запитання породжують яскраві образи відповідей.
#4
Секрет спрямування групи
Спрямовуйте групу за допомогою запитань, а не тверджень.
#5
Секрет передачі ідеї учасникам фасилітаційної сесії
Коли ви намагаєтеся запропонувати учасникам ідею, попросіть їх назвати її переваги й те, як її можна сформулювати.
#6
Секрет підготовки
Під час підготовки визначте свої *5P (purpose, product, participants, probable issues, process) - мета, продукт, учасники, можливі проблеми, процес.
#7
Секретна сила мети
Чітка мета забезпечує надійну основу для ухвалення рішень.
#8
Секрет визначення продукту сесії: 3H(hands, heads, hearts)
Щоби визначити бажані продукти фасилітаційної сесії, поставте таке запитання: Які речі, що їх до початку сесії не було, ви хочете мати в руках (результати), головах (знання) та серцях (переконання) учасників?
Решта секретів фасилітації очікуйте в наступному дописі ⏩
Друзі нагадуємо, що 15 червня відбудеться Agile Dojo: Hell's Kitchen of Facilitation!
Будемо говорити про справжні кулінарні шедеври 🥗, які допоможуть покращити ваші мітинги та підвищити навички фасилітації 🔥
❗️Подія безкоштовна за умови попередньої реєстрації.
Будемо раді усім, хто бажає отримати нові знання чи поділитись власним досвідом 😉
Будемо говорити про справжні кулінарні шедеври 🥗, які допоможуть покращити ваші мітинги та підвищити навички фасилітації 🔥
❗️Подія безкоштовна за умови попередньої реєстрації.
Будемо раді усім, хто бажає отримати нові знання чи поділитись власним досвідом 😉
Привіт усім!
Ми вже неодноразово згадували про важливість системного мислення для агентів змін. Пропоную сьогодні заглибитись в одну показову техніку для більш системного погляду на розв'язання проблем - causal-effect diagram, а конкретніше її інтерпретація від Henrik Kniberg. (Kateryna Motko)
Коли на проєкті ви стикаєтеся з проблемою, є велика ймовірність, що це не справжня проблема, а симптом. Відтак, працювати суто з ним немає сенсу, бо пофіксивши симптом, проблему не виправите, а отож вона буде проявлятись в тих чи інших варіаціях.
📍Наприклад, ви пливете у човні і він наповнюється водою. Це не проблема, а симптом.
1️⃣ Несистемне рішення: вичерпувати воду посеред озера, бо це боротьба зі симптомом.
2️⃣ Більш системне рішення: закрити діру у човні та тоді вичерпувати воду з нього. Це тимчасове рішення за таких умов та середовища, але якщо по виходу на берег нічого більше з дірою у човні не зробити, то є великий шанс, що наступний заплив вас знову неприємно здивує.
3️⃣ Системніше рішення: закрити діру у човні, тоді вичерпувати воду з нього, а по прибутті на берег зробити необхідні дії, щоб залатати діру.
Як же це діє на проєктному прикладі?
Проблема “Запізнілі релізи” сама по собі не є проблемою. Давайте відмотаємо до реальної проблеми. Для цього ставимо собі питання “той що?”.
Запізнілі релізи -той що?-> довгий релізний цикл -той що?-> відтермінована поставка рішення -той що?-> втрачені клієнти.
Отож справжньою проблемою є втрата клієнтів. Все що цьому передує — лише симптоми.
Тепер відмотуємо на орієнтир наслідків за допомогою питання “чому?”.
Запізнілі релізи <-чому?- Скоуп постійно збільшується <-чому?- нові фічі постійно додаються до релізу, а низько-пріоритетні не забираються.
І тут вже бачимо справжню причину цього симптому, з якою і треба працювати.
Звісно, ці приклади дещо абстрактні, але якщо ви спробуєте цю техніку у своєму проєкті з розумінням своїх реалій, то будете здивовані наскільки більш комплексно та системно ви їх побачите.
Сподобалась техніка, хочете більше про неї дізнатись? Повну статтю в оригіналі можете почитати тут 👈
Ми вже неодноразово згадували про важливість системного мислення для агентів змін. Пропоную сьогодні заглибитись в одну показову техніку для більш системного погляду на розв'язання проблем - causal-effect diagram, а конкретніше її інтерпретація від Henrik Kniberg. (Kateryna Motko)
Коли на проєкті ви стикаєтеся з проблемою, є велика ймовірність, що це не справжня проблема, а симптом. Відтак, працювати суто з ним немає сенсу, бо пофіксивши симптом, проблему не виправите, а отож вона буде проявлятись в тих чи інших варіаціях.
📍Наприклад, ви пливете у човні і він наповнюється водою. Це не проблема, а симптом.
1️⃣ Несистемне рішення: вичерпувати воду посеред озера, бо це боротьба зі симптомом.
2️⃣ Більш системне рішення: закрити діру у човні та тоді вичерпувати воду з нього. Це тимчасове рішення за таких умов та середовища, але якщо по виходу на берег нічого більше з дірою у човні не зробити, то є великий шанс, що наступний заплив вас знову неприємно здивує.
3️⃣ Системніше рішення: закрити діру у човні, тоді вичерпувати воду з нього, а по прибутті на берег зробити необхідні дії, щоб залатати діру.
Як же це діє на проєктному прикладі?
Проблема “Запізнілі релізи” сама по собі не є проблемою. Давайте відмотаємо до реальної проблеми. Для цього ставимо собі питання “той що?”.
Запізнілі релізи -той що?-> довгий релізний цикл -той що?-> відтермінована поставка рішення -той що?-> втрачені клієнти.
Отож справжньою проблемою є втрата клієнтів. Все що цьому передує — лише симптоми.
Тепер відмотуємо на орієнтир наслідків за допомогою питання “чому?”.
Запізнілі релізи <-чому?- Скоуп постійно збільшується <-чому?- нові фічі постійно додаються до релізу, а низько-пріоритетні не забираються.
І тут вже бачимо справжню причину цього симптому, з якою і треба працювати.
Звісно, ці приклади дещо абстрактні, але якщо ви спробуєте цю техніку у своєму проєкті з розумінням своїх реалій, то будете здивовані наскільки більш комплексно та системно ви їх побачите.
Сподобалась техніка, хочете більше про неї дізнатись? Повну статтю в оригіналі можете почитати тут 👈
Привіт! Нагадуємо, що ми починаємо через 30хв ☝️
❗️Zoom Link: https://symphony-solutions-eu.zoom.us/j/8866529540
Усім кому цікаво, долучайтесь, будемо покращувати навички проведення мітингів 😉
❗️Zoom Link: https://symphony-solutions-eu.zoom.us/j/8866529540
Усім кому цікаво, долучайтесь, будемо покращувати навички проведення мітингів 😉
Друзі, хочемо поділитись із вами цікавим безкоштовним івентом "SHE. Talks event Women in the Future of Work: Embracing AI for Growth and Adaptation", тож якщо вам цікаво:
☝️How is AI transforming the way we work?
☝️What are the challenges of AI integration in the workplace?
☝️How can you secure your competitiveness in the workforce with AI-centered skills and competencies?
When: June 22, 6 PM CET
Where: Online, Zoom
Duration: 1 h
Language: English
Долучайтесь 😉
☝️How is AI transforming the way we work?
☝️What are the challenges of AI integration in the workplace?
☝️How can you secure your competitiveness in the workforce with AI-centered skills and competencies?
When: June 22, 6 PM CET
Where: Online, Zoom
Duration: 1 h
Language: English
Долучайтесь 😉
We can rebrand MoSCoW technique to KYIV prioritisation technique now.
KYIV prioritisation:
(K)eep it in
(Y)ou ought to
(I)f you can
(V)anish
@PMI Ukraine Chapter
KYIV prioritisation:
(K)eep it in
(Y)ou ought to
(I)f you can
(V)anish
@PMI Ukraine Chapter
Друзі, запрошуємо Вас та Ваших колег на Scrum Basics Training, який відбудеться 6 липня!
👉 Тренінг буде корисним як для новачків, так для тих, хто вже практикує Agile та Scrum. Учасники навчаться ефективно та правильно використовувати інструменти Scrum та зрозуміють як будувати Agile середовище на проєкті, в команді чи в цілій організації.
👉 Програма складається з інтерактивних дискусій, воркшопів, практичних вправ та чітко структурованої теорії, яка підсилюється великою кількістю реальних прикладів.
Бажаєте освіжити свої знання про Scrum?
Долучайся👇
👉 Тренінг буде корисним як для новачків, так для тих, хто вже практикує Agile та Scrum. Учасники навчаться ефективно та правильно використовувати інструменти Scrum та зрозуміють як будувати Agile середовище на проєкті, в команді чи в цілій організації.
👉 Програма складається з інтерактивних дискусій, воркшопів, практичних вправ та чітко структурованої теорії, яка підсилюється великою кількістю реальних прикладів.
Бажаєте освіжити свої знання про Scrum?
Долучайся👇
Хей! Сьогодні продовжуємо серію публікацій про провали у наших (скрам мастерських і не тільки) кар’єрах 😵
Olesia Prots
Десь я чула думку, що помиляються лишень новачки. Хочу розвіяти такий міф. З часом, практикою та досвідом певні провали зменшується, бо вони просто змінюються на інші.
Тож, хочу поділитись своїм невдалим досвідом — а саме провал з рейфанментом.
POV: я СМ, середина проєкту, проте відбулася зміна РО і бізнес пріорітетів. На знайомстві з командою РО розповів, що він супер досвідчений, проте в менеджменті, а не скрамі і цю роль виконуватиме тимчасово. Це мало б бути сигналом тривоги. Проте, для мене — не стало. Адже ми працювали вже деякий час з клієнтами, в нас вже були плюс-мінус налагоджені процеси і тд.
Отже, день першого рефайнмету з новим РО. Я розпочинаю зустріч, команда присутня, всі готові працювати. Я відкриваю джиру – а там … порожньо😳. Як так? Адже раніше попередній РО завжди створював сторьки, пріорітезував! На питання що будемо обговорювати — я отримала відповідь, що він очікував від мене нагадування та організацію беклогу, він би дав свій бізнес імпут на зустрічі і що я не виконала своїх обов'язків, та більше того згаяла час команди та його.
Висновок: зі зміною людини в ролі може змінитися і налагоджений вже процес та підхід. Навіть якщо пріоритизацію беклогу не є задачею СМа — варто нагадати, перепитати, допомогти РО, особливо якщо це нова людина у команді. Також, не думайте що хтось буде відповідати вашим очікуванням і "вгадає" які були правила та домовленості 😉
А що цікаво траплялось у вас?
Olesia Prots
Десь я чула думку, що помиляються лишень новачки. Хочу розвіяти такий міф. З часом, практикою та досвідом певні провали зменшується, бо вони просто змінюються на інші.
Тож, хочу поділитись своїм невдалим досвідом — а саме провал з рейфанментом.
POV: я СМ, середина проєкту, проте відбулася зміна РО і бізнес пріорітетів. На знайомстві з командою РО розповів, що він супер досвідчений, проте в менеджменті, а не скрамі і цю роль виконуватиме тимчасово. Це мало б бути сигналом тривоги. Проте, для мене — не стало. Адже ми працювали вже деякий час з клієнтами, в нас вже були плюс-мінус налагоджені процеси і тд.
Отже, день першого рефайнмету з новим РО. Я розпочинаю зустріч, команда присутня, всі готові працювати. Я відкриваю джиру – а там … порожньо😳. Як так? Адже раніше попередній РО завжди створював сторьки, пріорітезував! На питання що будемо обговорювати — я отримала відповідь, що він очікував від мене нагадування та організацію беклогу, він би дав свій бізнес імпут на зустрічі і що я не виконала своїх обов'язків, та більше того згаяла час команди та його.
Висновок: зі зміною людини в ролі може змінитися і налагоджений вже процес та підхід. Навіть якщо пріоритизацію беклогу не є задачею СМа — варто нагадати, перепитати, допомогти РО, особливо якщо це нова людина у команді. Також, не думайте що хтось буде відповідати вашим очікуванням і "вгадає" які були правила та домовленості 😉
А що цікаво траплялось у вас?
На тренінгу про фасилітацію наша колега поділилась технікою 6 thinking hats 🤠
👉 тримайте і ви шаблон для неї, приміряйте різні капелюхи і вдалих вам експериментів з вашими командами 😉
👉 тримайте і ви шаблон для неї, приміряйте різні капелюхи і вдалих вам експериментів з вашими командами 😉
Друзі, продовжуємо нашу рубрику Секрети фасилітації 💥 за Майклом Вілкінсоном
Dmytro Skliar
#9
Секрет управління присутністю організатора
Домовтеся з організатором про те, що під час розгляду питань він не буде відповідати ані першим, ані другим, ані третім.
#10
Секрет потужного відкриття
Інформуйте, зацікавте, наділіть повноваженнями та залучіть учасників протягом перших 15 хвилин.
#11
Секрет зацікавлення під час відкриття сесії
Під час відкриття сесії на етапі зацікавлення використовуйте слова “ви”, “ваш”, тощо щонайменше 4 рази, щоби впевнитися, що ви пояснили, у чому криються переваги для учасників.
#12
Секрет забезпечення підтримки програми сесії
Щоби досягти підтримки програми сесії, пов’яжіть особисті цілі учасників із програмою зібрання.
#13
Секрет використання основних правил
Ви розпочинаєте список основних правил, учасники групи його завершують.
#14
Секрет паркувальних дошок
Організуйте місце, де ви можете “припаркувати” рішення, дії та побічні коментарі, які виникли раніше запланованого для них часу.
#15
Секрет ефективного знайомства
Дайте учасникам змогу завчасно записати свої слова і встановіть ліміт часу для самопрезентації.
#16
Секрет вчасного відкриття сесії
Вкажіть час прибуття групи першим пунктом у програмі сесії; переконайтеся, що перший доповідач готовий до виступу; попередьте учасників про початок зібрання за дві хвилини до цієї події.
👉 Першу частину можна переглянути тут
Dmytro Skliar
#9
Секрет управління присутністю організатора
Домовтеся з організатором про те, що під час розгляду питань він не буде відповідати ані першим, ані другим, ані третім.
#10
Секрет потужного відкриття
Інформуйте, зацікавте, наділіть повноваженнями та залучіть учасників протягом перших 15 хвилин.
#11
Секрет зацікавлення під час відкриття сесії
Під час відкриття сесії на етапі зацікавлення використовуйте слова “ви”, “ваш”, тощо щонайменше 4 рази, щоби впевнитися, що ви пояснили, у чому криються переваги для учасників.
#12
Секрет забезпечення підтримки програми сесії
Щоби досягти підтримки програми сесії, пов’яжіть особисті цілі учасників із програмою зібрання.
#13
Секрет використання основних правил
Ви розпочинаєте список основних правил, учасники групи його завершують.
#14
Секрет паркувальних дошок
Організуйте місце, де ви можете “припаркувати” рішення, дії та побічні коментарі, які виникли раніше запланованого для них часу.
#15
Секрет ефективного знайомства
Дайте учасникам змогу завчасно записати свої слова і встановіть ліміт часу для самопрезентації.
#16
Секрет вчасного відкриття сесії
Вкажіть час прибуття групи першим пунктом у програмі сесії; переконайтеся, що перший доповідач готовий до виступу; попередьте учасників про початок зібрання за дві хвилини до цієї події.
👉 Першу частину можна переглянути тут
Друзі, отримали багато приємних відгуків, щодо нашої рубрики SM fails, тож продовжуємо...
Oksana Tkach, PO на Healthcare проєкті з кількома скрам командами.
Хочу вам признатися, що довгий період часу на проєкті я монополізовувала проведення демо для замовників, не залучаючи інших учасників наших команд. Чому я вважала, що моя презентація буде доцільнішою:
👉 знаю і розумію потреби замовника набагато краще ніж розробники чи тестувальники, адже це є основним завданням моєї роботи як PO;
👉 розмовляю термінологією замовників;
👉 розумію, які очікування замовники мають стосовно функціоналу і можу зробити правильні акценти під час проведення демо;
👉 маю bigger picture, в той час, коли команда працює на рівні коду, технічної реалізації, скрінів, user stories, user journeys і тд;
👉 розумію запитання стейкхолдерів краще і можу надати влучніші відповіді під час презентації;
👉 не всі учасники команди люблять проводити презентації.
Що я втрачала:
☝️ можливість зближення і порозуміння між стейкхолдерами проєкту та командами;
☝️ face to face комунікацію стейкхолдерів проєкту з розробниками, тестувальниками, девопсами, автоматизаторами;
☝️ розвиток команд;
☝️ кращий комітмент і відповідальність всієї команди перед замовником;
☝️ можливість для команд отримати прямий і вчасний фідбек від стейкхолдерів;
☝️ краще розуміння командами продукту та бізнесу;
розуміння замовниками технічних нюансів;
☝️можливість розділити мою відповідальність разом зі всією командою.
То ж під керівництвом легкої та досвідченої руки нашого скрам мастера ми впровадили цю зміну — почали залучати по черзі всіх учасників наших команд до проведення демо для стейкхолдерів на спринт рев‘ю мітингу. Спершу було складно, бентежно і часозатратно підготуватися команді до демо, бо треба ж розібратися над чим вся команда працювала цілий спринт та зрозуміти всі юзер джорні, але ж ці кроки вже самі по собі стають додатковим бенефітом.
Не можу сказати, що всі в команді полюбили чи з нетерпінням почали чекати демо, але позитивні результати змін були відчутні відразу. Для довготермінової перспективи це точно правильне рішення. Вже сплило багато спринтів з того часу, наші презентації стали кращими, різноманітними і цікавими, кожен вносить в спринт ревю щось своє та унікальне. А я в той час уважно слухаю, п’ю каву, пишаюся нашими скрам командами і завжди готова підтримати.
А як проходять демо у вас на проєктах?
Oksana Tkach, PO на Healthcare проєкті з кількома скрам командами.
Хочу вам признатися, що довгий період часу на проєкті я монополізовувала проведення демо для замовників, не залучаючи інших учасників наших команд. Чому я вважала, що моя презентація буде доцільнішою:
👉 знаю і розумію потреби замовника набагато краще ніж розробники чи тестувальники, адже це є основним завданням моєї роботи як PO;
👉 розмовляю термінологією замовників;
👉 розумію, які очікування замовники мають стосовно функціоналу і можу зробити правильні акценти під час проведення демо;
👉 маю bigger picture, в той час, коли команда працює на рівні коду, технічної реалізації, скрінів, user stories, user journeys і тд;
👉 розумію запитання стейкхолдерів краще і можу надати влучніші відповіді під час презентації;
👉 не всі учасники команди люблять проводити презентації.
Що я втрачала:
☝️ можливість зближення і порозуміння між стейкхолдерами проєкту та командами;
☝️ face to face комунікацію стейкхолдерів проєкту з розробниками, тестувальниками, девопсами, автоматизаторами;
☝️ розвиток команд;
☝️ кращий комітмент і відповідальність всієї команди перед замовником;
☝️ можливість для команд отримати прямий і вчасний фідбек від стейкхолдерів;
☝️ краще розуміння командами продукту та бізнесу;
розуміння замовниками технічних нюансів;
☝️можливість розділити мою відповідальність разом зі всією командою.
То ж під керівництвом легкої та досвідченої руки нашого скрам мастера ми впровадили цю зміну — почали залучати по черзі всіх учасників наших команд до проведення демо для стейкхолдерів на спринт рев‘ю мітингу. Спершу було складно, бентежно і часозатратно підготуватися команді до демо, бо треба ж розібратися над чим вся команда працювала цілий спринт та зрозуміти всі юзер джорні, але ж ці кроки вже самі по собі стають додатковим бенефітом.
Не можу сказати, що всі в команді полюбили чи з нетерпінням почали чекати демо, але позитивні результати змін були відчутні відразу. Для довготермінової перспективи це точно правильне рішення. Вже сплило багато спринтів з того часу, наші презентації стали кращими, різноманітними і цікавими, кожен вносить в спринт ревю щось своє та унікальне. А я в той час уважно слухаю, п’ю каву, пишаюся нашими скрам командами і завжди готова підтримати.
А як проходять демо у вас на проєктах?
Привіт👋
З Product Owner ми трішки розібралися, а зараз давайте поговоримо про Business Analyst та дамо відповідь на питання:
🔸Чим займається бізнес аналітик?
🔸Яка його основна мета?
🔸Відмінність між PO та BA?
Перш за все зазначимо, що згідно з BABOK, бізнес-аналітик — це є роль, яку може виконувати будь-хто в команді, незалежно від його основної ролі або посади. Мапінг ролей у команді може бути різним і залежить від конкретної організації та її потреб. Хочемо звернути увагу, що це ніяким чином не суперечить Scrum Guide.
Scrum Guide не визначає конкретну роль "бізнес-аналітика". У цьому фреймворку зазвичай використовується роль Product Owner для представлення і керування вимогами бізнесу. Однак, у практиці Scrum-команд може бути хтось, який виконує функції бізнес-аналітика, якщо це відповідає потребам проєкту і організації.
Бізнес-аналітик є фахівцем, який вивчає бізнес-процеси компанії та збирає вимоги від зацікавлених сторін. Він аналізує дані та робить прогнози, спираючись на них, формує вимоги до програмного забезпечення та розробляє стратегію розвитку продукту або послуги.
Основною метою бізнес-аналітика є допомога компанії (клієнту) в тому, щоб зрозуміти свої потреби та визначити оптимальну стратегію розвитку. Він допомагає знайти способи підвищення продуктивності та вдосконалення бізнес-процесів, що в свою чергу призводить до покращення показників компанії.
☝️ В чому ж відмінність Product Owner (PO) та бізнес-аналітик (BA)? Вони мають схожі, але різні ролі в розробці продукту.
PO, як ми вже знаємо, відповідає за стратегічне керівництво розробкою продукту, тобто він приймає рішення про те, що потрібно розробляти та в якому порядку. BA ж займається конкретним дослідженням бізнес-процесів та вимог користувачів, інтерв'юючи зацікавлених сторін та аналізуючи дані. Ці дві ролі доповнюють одна одну, тому їх взаємодія є ключовою для успішного розвитку продукту.
Загалом, PO несе відповідальність за визначення того, що і навіщо продукту, тоді як BA відповідає за визначення того, як. Працюючи разом, вони можуть переконатися, що команда розробників надає правильний продукт, який відповідає потребам бізнесу та клієнта.
Друзі, як ви вважаєте, роль PO та BA має виконувати одна людина? Чи це мають бути окремі ролі?
З Product Owner ми трішки розібралися, а зараз давайте поговоримо про Business Analyst та дамо відповідь на питання:
🔸Чим займається бізнес аналітик?
🔸Яка його основна мета?
🔸Відмінність між PO та BA?
Перш за все зазначимо, що згідно з BABOK, бізнес-аналітик — це є роль, яку може виконувати будь-хто в команді, незалежно від його основної ролі або посади. Мапінг ролей у команді може бути різним і залежить від конкретної організації та її потреб. Хочемо звернути увагу, що це ніяким чином не суперечить Scrum Guide.
Scrum Guide не визначає конкретну роль "бізнес-аналітика". У цьому фреймворку зазвичай використовується роль Product Owner для представлення і керування вимогами бізнесу. Однак, у практиці Scrum-команд може бути хтось, який виконує функції бізнес-аналітика, якщо це відповідає потребам проєкту і організації.
Бізнес-аналітик є фахівцем, який вивчає бізнес-процеси компанії та збирає вимоги від зацікавлених сторін. Він аналізує дані та робить прогнози, спираючись на них, формує вимоги до програмного забезпечення та розробляє стратегію розвитку продукту або послуги.
Основною метою бізнес-аналітика є допомога компанії (клієнту) в тому, щоб зрозуміти свої потреби та визначити оптимальну стратегію розвитку. Він допомагає знайти способи підвищення продуктивності та вдосконалення бізнес-процесів, що в свою чергу призводить до покращення показників компанії.
☝️ В чому ж відмінність Product Owner (PO) та бізнес-аналітик (BA)? Вони мають схожі, але різні ролі в розробці продукту.
PO, як ми вже знаємо, відповідає за стратегічне керівництво розробкою продукту, тобто він приймає рішення про те, що потрібно розробляти та в якому порядку. BA ж займається конкретним дослідженням бізнес-процесів та вимог користувачів, інтерв'юючи зацікавлених сторін та аналізуючи дані. Ці дві ролі доповнюють одна одну, тому їх взаємодія є ключовою для успішного розвитку продукту.
Загалом, PO несе відповідальність за визначення того, що і навіщо продукту, тоді як BA відповідає за визначення того, як. Працюючи разом, вони можуть переконатися, що команда розробників надає правильний продукт, який відповідає потребам бізнесу та клієнта.
Друзі, як ви вважаєте, роль PO та BA має виконувати одна людина? Чи це мають бути окремі ролі?
Привіт усім 🫡
Давно у нас не було оглядів книг. А це на днях наш колега у своєму каналі MakeYourTeamBetter заспойлерив про різні ролі у командах з “Короткого гіду про команди” Дена Колінза, от і ми вирішили прочитати тих 40+ сторінок про команди. І не пожаліли 😊.
Гід насправді дуже лаконічний. Головна ідея, яка кілька разів у різних варіаціях простежується, в тому, що якщо об’єднати найпродуктивніших окремих індивідів в одну справжню команду, то вийде не сума їхніх продуктивностей, а добуток (математика молодша школа — довелось гуглити як буде результат дії множення🤦). Все через те, що люди — соціальні істоти, якими б інтровертивними вони не були, всім цінна підтримка інших, визнання, процес спільного пошуку ідей.
Однак при цьому важлива командність, а не індивідуалізм. Це знаєте, як з деякими голлівудськими фільмами, коли закастили купу оскароносців, а фільм провалився в усіх прокатах та відгуках. Тому що “примадонни” рідко можуть включити режим командного гравця.
Мікс талантів тоді дає виграшну комбінацію, коли усі знають слабкості, суперсили та побажання одне одних. Ден виділяє 4 обов’язкові складники для чудесних команд: Gluers (творці стосунків у тімі), Creators (творці ідей та рішень (солюшинів)), Doers (творці результату), Leaders (творці напрямків та рішень (десижинів)).
Крім таких “ролей”, чудесні команди “сповідують” такі цінності (десь ми таке вже бачили 🤔):
👉 maturity (це про внутрішнє бажання команди до постійних покращень та розвитку, а не розслабитись, коли все менш-більш нормалізувалось)
👉 engagement (це про спільне бачення що і як робити різницю)
openness (в тому числі і відкритість до конфліктів, бо де є пристрасть до того, що ви робите, там і конфліктуючі погляди)
👉 focus (командам постійно треба нагадувати про спільні домовленості, цінності, бачення)
👉 trust (якість команди прямопропорційна рівню довіри, і 1 недовірливий гравець робить усю команду слабшою)
👉 humility (команда складається з людей, люди маю Его, Его руйнує команди, особливо, якщо у команді багато “досягаторів”)
👉 measurement (робіть короткотермінові можливі для реалізації цілі, так щоб святкувати успіх та результат регулярно. Так твориться культура досягнень)
Хочете прочитати весь гід? Ось, будь ласка, не забудьте поділитись своїми інсайтами в коментарях 😊
Давно у нас не було оглядів книг. А це на днях наш колега у своєму каналі MakeYourTeamBetter заспойлерив про різні ролі у командах з “Короткого гіду про команди” Дена Колінза, от і ми вирішили прочитати тих 40+ сторінок про команди. І не пожаліли 😊.
Гід насправді дуже лаконічний. Головна ідея, яка кілька разів у різних варіаціях простежується, в тому, що якщо об’єднати найпродуктивніших окремих індивідів в одну справжню команду, то вийде не сума їхніх продуктивностей, а добуток (математика молодша школа — довелось гуглити як буде результат дії множення🤦). Все через те, що люди — соціальні істоти, якими б інтровертивними вони не були, всім цінна підтримка інших, визнання, процес спільного пошуку ідей.
Однак при цьому важлива командність, а не індивідуалізм. Це знаєте, як з деякими голлівудськими фільмами, коли закастили купу оскароносців, а фільм провалився в усіх прокатах та відгуках. Тому що “примадонни” рідко можуть включити режим командного гравця.
Мікс талантів тоді дає виграшну комбінацію, коли усі знають слабкості, суперсили та побажання одне одних. Ден виділяє 4 обов’язкові складники для чудесних команд: Gluers (творці стосунків у тімі), Creators (творці ідей та рішень (солюшинів)), Doers (творці результату), Leaders (творці напрямків та рішень (десижинів)).
Крім таких “ролей”, чудесні команди “сповідують” такі цінності (десь ми таке вже бачили 🤔):
👉 maturity (це про внутрішнє бажання команди до постійних покращень та розвитку, а не розслабитись, коли все менш-більш нормалізувалось)
👉 engagement (це про спільне бачення що і як робити різницю)
openness (в тому числі і відкритість до конфліктів, бо де є пристрасть до того, що ви робите, там і конфліктуючі погляди)
👉 focus (командам постійно треба нагадувати про спільні домовленості, цінності, бачення)
👉 trust (якість команди прямопропорційна рівню довіри, і 1 недовірливий гравець робить усю команду слабшою)
👉 humility (команда складається з людей, люди маю Его, Его руйнує команди, особливо, якщо у команді багато “досягаторів”)
👉 measurement (робіть короткотермінові можливі для реалізації цілі, так щоб святкувати успіх та результат регулярно. Так твориться культура досягнень)
Хочете прочитати весь гід? Ось, будь ласка, не забудьте поділитись своїми інсайтами в коментарях 😊
BA fails 😮
Tamara Oliinyk, Business Analyst at Symphony Solutions.
Озираючись назад, я маю визнати, що однією з моїх серйозних помилок у минулому була недостатня залученість кінцевих користувачів і клієнтів - Lack of User Involvement.
Це був один із моїх перших проєктів, в нас були досить тісні терміни проєкту, і щоб вкластися, я подумала — що цей пункт взагалі можна не брати до уваги, що він не несе в собі користі. Ох, як же я помилялась!)))
Що саме я пропустила?
Я не отримала та не пропрацювала з усіх боків конкретні потреби та очікування користувачів, які будуть основними споживачами продукту.
До чого це призвело?
В результаті, розроблені нами рішення не повністю відповідали тому, що справді потрібно кінцевим користувачам, що призвело до часткового невдоволення та проблем із використанням після релізу продукту.
І на що ж це вплинуло?
В результаті це призвело до ініціації нової ітерації доробки продукту, як результат — збільшення витрат, що можна було уникнути, якби з самого початку отримувати та пропрацьовувати фідбеки, а також залучати користувачів на початкових етапах.
Але досвід без набивання болючих синяків — це не повноцінний досвід 😊 Тому, зробивши висновки, зараз я намагаюся одразу залучати користувачів (при можливості, і звісно, виходячи з потреб проєкту).
Як саме можна проводити сесії з юзерами?
👉 інтерв'ю і семінари для зібрання вимог;
👉 сесії тестування на різних стадіях проєкту для збору цінних відгуків та забезпечення того, що їх потреби є в центрі процесу прийняття рішень.
Роль ВА — це про постійну комунікацію. Тому дуже важливо створити середовище, яке сприяє відкритій комунікації з зацікавленими сторонами. А як результат — отримати саме той результат, який дійсно буде відповідати потребам та очікуванням усіх end-point users.
Робити помилки — не соромно. Соромно не зробити після цього висновки!
Tamara Oliinyk, Business Analyst at Symphony Solutions.
Озираючись назад, я маю визнати, що однією з моїх серйозних помилок у минулому була недостатня залученість кінцевих користувачів і клієнтів - Lack of User Involvement.
Це був один із моїх перших проєктів, в нас були досить тісні терміни проєкту, і щоб вкластися, я подумала — що цей пункт взагалі можна не брати до уваги, що він не несе в собі користі. Ох, як же я помилялась!)))
Що саме я пропустила?
Я не отримала та не пропрацювала з усіх боків конкретні потреби та очікування користувачів, які будуть основними споживачами продукту.
До чого це призвело?
В результаті, розроблені нами рішення не повністю відповідали тому, що справді потрібно кінцевим користувачам, що призвело до часткового невдоволення та проблем із використанням після релізу продукту.
І на що ж це вплинуло?
В результаті це призвело до ініціації нової ітерації доробки продукту, як результат — збільшення витрат, що можна було уникнути, якби з самого початку отримувати та пропрацьовувати фідбеки, а також залучати користувачів на початкових етапах.
Але досвід без набивання болючих синяків — це не повноцінний досвід 😊 Тому, зробивши висновки, зараз я намагаюся одразу залучати користувачів (при можливості, і звісно, виходячи з потреб проєкту).
Як саме можна проводити сесії з юзерами?
👉 інтерв'ю і семінари для зібрання вимог;
👉 сесії тестування на різних стадіях проєкту для збору цінних відгуків та забезпечення того, що їх потреби є в центрі процесу прийняття рішень.
Роль ВА — це про постійну комунікацію. Тому дуже важливо створити середовище, яке сприяє відкритій комунікації з зацікавленими сторонами. А як результат — отримати саме той результат, який дійсно буде відповідати потребам та очікуванням усіх end-point users.
Робити помилки — не соромно. Соромно не зробити після цього висновки!