🌟Но не время грустить! 🌞
В командах идёт трансформация полным ходом. Сейчас помогу Владельцу продукта одной из команд и обо всём расскажу по-порядку.
В командах идёт трансформация полным ходом. Сейчас помогу Владельцу продукта одной из команд и обо всём расскажу по-порядку.
🔥3👍2
Друзья, всем привет! Я вас совсем покинула. Но это не значит что забыла ❤️
Всем кто ещё не видел или забыл, советую посмотреть замечательный ролик Henrik Kniberg, раскрывающий тему утилизации ресурсов.
Всем кто ещё не видел или забыл, советую посмотреть замечательный ролик Henrik Kniberg, раскрывающий тему утилизации ресурсов.
YouTube
The resource utilization trap
Henrik Kniberg explains the resource utilization trap, how it impacts our ability to deliver and what we can do about it.
Visit http://www.crisp.se to find courses, books, products and interesting blogs.
Henriks's blog: http://blog.crisp.se/author/henrikkniberg…
Visit http://www.crisp.se to find courses, books, products and interesting blogs.
Henriks's blog: http://blog.crisp.se/author/henrikkniberg…
This media is not supported in your browser
VIEW IN TELEGRAM
Хочу ввести рубрику пятничных мемов
Как мы катим релиз на прод без настроенного процесса CI/CD
Как мы катим релиз на прод без настроенного процесса CI/CD
👍1
Привет, дорогие подписчики!
Продолжаю делиться пользой и расскажу здесь, почему я в цейтноте и что сейчас происходит.
«Начинающий скрам мастер может справиться с 3-мя командами. Опытный скрам мастер не может справиться и с одной».
Когда-то я гордилась, что умею жонглировать целым внутренним подразделением команд занимающимися процессами в Восточной Европе и двумя Scrum командами. 🥲
Сейчас у меня 2 команды с очень низким уровнем зрелости, которые мы трансформируем и прививаем ценности Agile, и я готова «вскрыться».
Я не успеваю рассказывать обо всем, что мне приходиться делать с командами. Поэтому мои сторис похожи больше на бравирование и показ того, что можно успевать трансформировать команды и работать полноценным скрам мастрером.
Но нет, моё мнение, что полноценно скрам мастерить в 2х командах можно только в случае, если эти команды:
1. зрелые
2. у этих команд рассинхронизированы спринты.
Расскажу что происходит сейчас.
Сейчас мы проводим Agile трансформацию у Заказчика (раскрывать не могу, NDA). Это целый блок кластеров, которые реализуют различные IT продукты.
Мы настраиваем гибрид на базе SAFe.
Это накладывает определённые условия.
Например:
🔹 старт спринтов в один день
🔹 все команды обучаются инженерным практикам и практикам Agile.
🔹 внедряются обязательные мероприятия как для команд (обязательные события скрам), так и для кластера целиком (discovery ю, работа с бэклог продукта на уровне инициатив и прочее)
Я ответственна за свой кластер, в котором есть 2 команды. Каждая команда реализует по 3 продукта (они связаны между собой внутри кластера и есть интеграции с другими продуктами кластера).
По факту я выполняю и роль скрам мастера в этих командах, и роль Agile коуча внутри кластера и организации.
И вот сейчас я очень хочу раскрыть функцию скрам мастера, для тех, кто не совсем понимает, что мы делаем и вообще зачем нужны 🤞🏻
Кроме проведения и разъяснения обязательных событий скрама и прививания ценностей:
1. нужно познакомиться с командой, представиться самому и рассказать о себе
2. узнать у команды чем ты можешь быть полезен
3. узнать у Руководителя Кластера, его ожидания чем ты можешь быть полезен и рассказать о своих ожиданиях вашей совместной работы
4. провести аудит процессов. Как они проводят встречи, как настроены инженерные процессы, как работают с бэклогом продукта, собирают метрики, как часто релизят на прод, что там с багами и вот это всё.
5. посмотреть, как настроена коммуникация. (Например, мои команды используют 100500 чатов в телеге).
6. договориться с командами о предстоящих изменениях
7. настроить каналы коммуникации, определить уровни эскалации
8. запланировать все необходимые мероприятия в календарь. Тут не только запланировать, а договориться со всеми, чтобы всем было удобно. Для этого нужно провести серию опросов с анонимным голосованием
9. настроить Jira доски, сбор метрик и научить команду всем этим пользоваться
10. заполнить странички в вики с полезной информацией, рассказать команде где можно это найти и как они могут этим пользоваться
11. научить команду разбирать бэклог, проводить планирование, оценивать истории, писать истории, научить договариваться как они будут это тестировать и многое другое.
➕ есть менеджер кластера, который раньше занимался микроменеджментом. С ним нужно работать 1:1 и выяснять его истинные потребности.
➕ владельцы продукта, с которыми надо работать отдельно, чтобы научить работать с историями и отойти от назначения разработчикам задач.
И вот представьте, что у вас 2 команды с полнейшим хаосом в процессах, с пониманием, что «скрам - это что-то про тайм менеджмент», которых постоянно дёргает менеджмент, считая, что тестировщики - это лишнее звено, а у Владельцев продукта перманентно 🍑в🔥.
Плюс нужно проводить тренинги, вести лекции и круглые столы в нашем внутреннем Agile комьюнити и заниматься онбордингом новых участников команды.
И после этого кто-то удивляется, почему у меня цейтнот.
Это абсолютно нормально в такой ситуации.
Продолжаю делиться пользой и расскажу здесь, почему я в цейтноте и что сейчас происходит.
«Начинающий скрам мастер может справиться с 3-мя командами. Опытный скрам мастер не может справиться и с одной».
Когда-то я гордилась, что умею жонглировать целым внутренним подразделением команд занимающимися процессами в Восточной Европе и двумя Scrum командами. 🥲
Сейчас у меня 2 команды с очень низким уровнем зрелости, которые мы трансформируем и прививаем ценности Agile, и я готова «вскрыться».
Я не успеваю рассказывать обо всем, что мне приходиться делать с командами. Поэтому мои сторис похожи больше на бравирование и показ того, что можно успевать трансформировать команды и работать полноценным скрам мастрером.
Но нет, моё мнение, что полноценно скрам мастерить в 2х командах можно только в случае, если эти команды:
1. зрелые
2. у этих команд рассинхронизированы спринты.
Расскажу что происходит сейчас.
Сейчас мы проводим Agile трансформацию у Заказчика (раскрывать не могу, NDA). Это целый блок кластеров, которые реализуют различные IT продукты.
Мы настраиваем гибрид на базе SAFe.
Это накладывает определённые условия.
Например:
🔹 старт спринтов в один день
🔹 все команды обучаются инженерным практикам и практикам Agile.
🔹 внедряются обязательные мероприятия как для команд (обязательные события скрам), так и для кластера целиком (discovery ю, работа с бэклог продукта на уровне инициатив и прочее)
Я ответственна за свой кластер, в котором есть 2 команды. Каждая команда реализует по 3 продукта (они связаны между собой внутри кластера и есть интеграции с другими продуктами кластера).
По факту я выполняю и роль скрам мастера в этих командах, и роль Agile коуча внутри кластера и организации.
И вот сейчас я очень хочу раскрыть функцию скрам мастера, для тех, кто не совсем понимает, что мы делаем и вообще зачем нужны 🤞🏻
Кроме проведения и разъяснения обязательных событий скрама и прививания ценностей:
1. нужно познакомиться с командой, представиться самому и рассказать о себе
2. узнать у команды чем ты можешь быть полезен
3. узнать у Руководителя Кластера, его ожидания чем ты можешь быть полезен и рассказать о своих ожиданиях вашей совместной работы
4. провести аудит процессов. Как они проводят встречи, как настроены инженерные процессы, как работают с бэклогом продукта, собирают метрики, как часто релизят на прод, что там с багами и вот это всё.
5. посмотреть, как настроена коммуникация. (Например, мои команды используют 100500 чатов в телеге).
6. договориться с командами о предстоящих изменениях
7. настроить каналы коммуникации, определить уровни эскалации
8. запланировать все необходимые мероприятия в календарь. Тут не только запланировать, а договориться со всеми, чтобы всем было удобно. Для этого нужно провести серию опросов с анонимным голосованием
9. настроить Jira доски, сбор метрик и научить команду всем этим пользоваться
10. заполнить странички в вики с полезной информацией, рассказать команде где можно это найти и как они могут этим пользоваться
11. научить команду разбирать бэклог, проводить планирование, оценивать истории, писать истории, научить договариваться как они будут это тестировать и многое другое.
➕ есть менеджер кластера, который раньше занимался микроменеджментом. С ним нужно работать 1:1 и выяснять его истинные потребности.
➕ владельцы продукта, с которыми надо работать отдельно, чтобы научить работать с историями и отойти от назначения разработчикам задач.
И вот представьте, что у вас 2 команды с полнейшим хаосом в процессах, с пониманием, что «скрам - это что-то про тайм менеджмент», которых постоянно дёргает менеджмент, считая, что тестировщики - это лишнее звено, а у Владельцев продукта перманентно 🍑в🔥.
Плюс нужно проводить тренинги, вести лекции и круглые столы в нашем внутреннем Agile комьюнити и заниматься онбордингом новых участников команды.
И после этого кто-то удивляется, почему у меня цейтнот.
Это абсолютно нормально в такой ситуации.
👍2
Немного о том, как работают в Agile трансформациях коучи:
У меня был запланирован отпуск на июль. Но я его отменила к херам, чтобы запускать новую команду 🙌🏻
Ну ладно, не к херам. На 1 недельку я схожу, но буду готовить 2 выступления на конференцию и выступать на митапе сообщества фасилитаторов. Буду рассказывать как проводить PBR в незрелых командах
У меня был запланирован отпуск на июль. Но я его отменила к херам, чтобы запускать новую команду 🙌🏻
Ну ладно, не к херам. На 1 недельку я схожу, но буду готовить 2 выступления на конференцию и выступать на митапе сообщества фасилитаторов. Буду рассказывать как проводить PBR в незрелых командах
🔥4👍1
Дорогие подписчики!
Я в отпуске, но не забываю делиться с вами пользой.
Сегодня на встрече закрытого клуба Co-Actors Facilitators Club, где я расскажу о своём формате проведения PBR в незрелой команде.
А ещё хочу сказать пару слов о закрытом клубе. Это клуб участников тренинга ICP-ATF (https://co-actors.com/#rec422402352), который ведут тренеры Co-Actors.
Я в отпуске, но не забываю делиться с вами пользой.
Сегодня на встрече закрытого клуба Co-Actors Facilitators Club, где я расскажу о своём формате проведения PBR в незрелой команде.
А ещё хочу сказать пару слов о закрытом клубе. Это клуб участников тренинга ICP-ATF (https://co-actors.com/#rec422402352), который ведут тренеры Co-Actors.
Co-Actors
Помогаем компаниям работать с людьми
Фасилитируем классные стратегические сессии, командные оффсайты и гезеринги, обучаем фасилитации и успешному взаимодействию с креативными командами.
Поняла, что совсем не умею пользоваться тачпадом на маке. 😂 Отправила текст без редактуры нажав не ту кнопочку🙈
Ну да ладно.
Про тренинг я хотела сказать, что очень советую тем, кто хочет погрузиться в мир Фасилитации и узнать как проводить встречи так, чтобы на выходе был результат, чтобы удерживать внимание участников и находиться в тайминге.
И то не маловажно, вы получите международный сертификат о том, что прошли тренинг по фасилитации. Так что сильно рекомендую. Я сама проходила и многому научилась.
Ну да ладно.
Про тренинг я хотела сказать, что очень советую тем, кто хочет погрузиться в мир Фасилитации и узнать как проводить встречи так, чтобы на выходе был результат, чтобы удерживать внимание участников и находиться в тайминге.
И то не маловажно, вы получите международный сертификат о том, что прошли тренинг по фасилитации. Так что сильно рекомендую. Я сама проходила и многому научилась.
🔥4
А для тех, кто не придёт на митап, я расскажу о формате проведения PBR, который использую в своих командах:
Во-первых, что такое, это магическое слово PBR?
Всё очень просто!
Это Product Backlog Refinement или Разбор бэклога продукта, по-русски. Этот тот самый пресловутый грумминг.
Бэклог продукта состоит из элементов, которые необходимы для того, чтобы создавать и улучшать этот самый продукт.
Владелец продукта задаёт направление, как стоит развивать продукт, что стоит взять в работу сейчас, чтобы ваш продукт стал лидером рынка.
Владельцу продукта могут помогать разные эксперты (маркетологи, аналитики, дизайнеры, архитекторы и спонсоры). Но именно человек в роли ВП ответственный за ценность продукта. И именно он задаёт вектор его развития.
Цель встречи PBR – проработать высокоприоритетные элементы бэклога продукта для того, чтобы подготовить их к планированию спринта.
Подготовка
1️⃣ Владелец продукта подготавливает пользовательские истории согласно шаблону.
2️⃣ Владелец продукта проставляет приоритет у каждого элемента бэклога.
3️⃣ Разработчики могут заранее ознакомиться с историями, задать вопросы.
4️⃣ На встречу приглашены все необходимые участники. В теле приглашения указаны цели и план встречи с таймингом.
Что должно быть готово к PBR:
✔️История сформулирована в соответствии с принятым шаблоном[«Как (пользователь), я хочу (намерение), чтобы (цель)] в терминах ценности для пользователя
✔️ Сформулированы критерии приёмки (Acceptance Criteria)
✔️ Полный графический дизайн разработан: UI (на пользовательскую историю)
Открытие
📣 Владелец продукта озвучивает истории, готовые к PBR и порядок, в котором будут разбираться истории.
Разбор элементов бэклога
1️⃣ Фасилитатор показывает элемент бэклога на экране (в нашем случае мы используем Jira).
Владелец продукта объясняет бизнес требования, показывает UI дизайн (мы используем figma), отвечает на вопросы команды.
2️⃣ Разработчики обсуждают элемент бэклога и договариваются о возможной реализации (backend-frontend/mobile-test).
3️⃣ Команда обсуждает все возможные риски и зависимости от другого функционала.
❓Что необходимо сделать, чтобы предусмотреть риски и сложности?
❓Какие команды или специалисты смогут помочь?
4️⃣ Команда приходит к заключению, что история готова к реализации, или переводит её обратно в статус 'In Analysis' для дальнейшей проработки.
5️⃣ Если история готова к разработке, разработчики оценивают её в story points по шкале чисел Фибоначчи (1, 2, 3, 5, 8, 13) и переводят в статус 'Ready for Dev'.
6️⃣ Далее переходим к следующему элементу бэклога.
Что должно быть готово ПОСЛЕ PBR с командой:
✔️ История прошла refinement, и у неё есть оценка в story points
✔️ Определены практики работы с feature toggles (опционально)
✔️ Изменения в API зафиксированы на wiki и согласованы с другими командами
✔️ Разработан технический дизайн (минимально необходимый; может отсутствовать)
✔️ У команды нет открытых вопросов по истории
✔️Acceptance criteria детализирована командой
⚙️ Техническая реализация обсуждается разработчиками во время PBR или на отдельной встрече, если необходимо.
🔍 На встречу можно пригласить архитектора или участников, который смогут помочь в максимальном понимании возможной реализации историй.
Закрытие
1️⃣ Команда договариваются о дальнейшей проработке бэклога.
2️⃣ Разработчики договариваются между собой о необходимых встречах для технических обсуждениях историй.
3️⃣ Фасилитатор должен убедиться, что обратная связь по встрече получена.
Напишите, пожалуйста, был ли вам полезен материал. ☺️🙏🏻
Во-первых, что такое, это магическое слово PBR?
Всё очень просто!
Это Product Backlog Refinement или Разбор бэклога продукта, по-русски. Этот тот самый пресловутый грумминг.
Бэклог продукта состоит из элементов, которые необходимы для того, чтобы создавать и улучшать этот самый продукт.
Владелец продукта задаёт направление, как стоит развивать продукт, что стоит взять в работу сейчас, чтобы ваш продукт стал лидером рынка.
Владельцу продукта могут помогать разные эксперты (маркетологи, аналитики, дизайнеры, архитекторы и спонсоры). Но именно человек в роли ВП ответственный за ценность продукта. И именно он задаёт вектор его развития.
Цель встречи PBR – проработать высокоприоритетные элементы бэклога продукта для того, чтобы подготовить их к планированию спринта.
Подготовка
1️⃣ Владелец продукта подготавливает пользовательские истории согласно шаблону.
2️⃣ Владелец продукта проставляет приоритет у каждого элемента бэклога.
3️⃣ Разработчики могут заранее ознакомиться с историями, задать вопросы.
4️⃣ На встречу приглашены все необходимые участники. В теле приглашения указаны цели и план встречи с таймингом.
Что должно быть готово к PBR:
✔️История сформулирована в соответствии с принятым шаблоном[«Как (пользователь), я хочу (намерение), чтобы (цель)] в терминах ценности для пользователя
✔️ Сформулированы критерии приёмки (Acceptance Criteria)
✔️ Полный графический дизайн разработан: UI (на пользовательскую историю)
Открытие
📣 Владелец продукта озвучивает истории, готовые к PBR и порядок, в котором будут разбираться истории.
Разбор элементов бэклога
1️⃣ Фасилитатор показывает элемент бэклога на экране (в нашем случае мы используем Jira).
Владелец продукта объясняет бизнес требования, показывает UI дизайн (мы используем figma), отвечает на вопросы команды.
2️⃣ Разработчики обсуждают элемент бэклога и договариваются о возможной реализации (backend-frontend/mobile-test).
3️⃣ Команда обсуждает все возможные риски и зависимости от другого функционала.
❓Что необходимо сделать, чтобы предусмотреть риски и сложности?
❓Какие команды или специалисты смогут помочь?
4️⃣ Команда приходит к заключению, что история готова к реализации, или переводит её обратно в статус 'In Analysis' для дальнейшей проработки.
5️⃣ Если история готова к разработке, разработчики оценивают её в story points по шкале чисел Фибоначчи (1, 2, 3, 5, 8, 13) и переводят в статус 'Ready for Dev'.
6️⃣ Далее переходим к следующему элементу бэклога.
Что должно быть готово ПОСЛЕ PBR с командой:
✔️ История прошла refinement, и у неё есть оценка в story points
✔️ Определены практики работы с feature toggles (опционально)
✔️ Изменения в API зафиксированы на wiki и согласованы с другими командами
✔️ Разработан технический дизайн (минимально необходимый; может отсутствовать)
✔️ У команды нет открытых вопросов по истории
✔️Acceptance criteria детализирована командой
⚙️ Техническая реализация обсуждается разработчиками во время PBR или на отдельной встрече, если необходимо.
🔍 На встречу можно пригласить архитектора или участников, который смогут помочь в максимальном понимании возможной реализации историй.
Закрытие
1️⃣ Команда договариваются о дальнейшей проработке бэклога.
2️⃣ Разработчики договариваются между собой о необходимых встречах для технических обсуждениях историй.
3️⃣ Фасилитатор должен убедиться, что обратная связь по встрече получена.
Напишите, пожалуйста, был ли вам полезен материал. ☺️🙏🏻
🔥3❤1
Всем привет!
Давно я не заходила сюда и не делилась полезностями. И очень соскучилась по вам, дорогие подписчики!
Всё дело в том, что я веду Agile-трансформацию у нового заказчика, крупной ритейл компании.
В этой трансформации у меня роль Agile&Kanban коуча. Я работаю на всех уровнях: топ, средний менеджмент (руководители доменов, проектного офиса) и команды.
У команд разные подходы и процессы, с которыми они работают. В основном это работа с изменениями (Change management) по ITSM, есть команды, работающие по Agile.
Было принято решение ко всем процессам и командам применить канбан-метод, для ускорения процесса поставки ценности и уменьшения времени ожидания в очереди.
По уровню зрелости все команды очень разные и со всеми приходится находить свой подход.
Что общего? С руководителем трансформации со стороны Заказчика мы прописали критерии первой стадии трансформации:
✅ провести STATIK
✅ напустить самые основные каденции
✅ научить пользоваться основными инструментами визуализации (в нашем случае это jira)
✅ прописать правила приоритезации, критерии DOR&DOD и согласовать из с бизнесом
✅ научить основным метрикам и запустить процесс анализа процесса по метрикам для постоянных улучшений.
С января я запустила 3 домена и 9 команд в общей сложности
Кроме этого я:
✅ запустила процесс кросс-доменного планирования (некое подобие PI - planning)
✅ запустила внутреннее Agile-сообщество и регулярно выступаю и пишу статьи для него
✅ задизайнила тренинг по изучению инструмента Structure в jira для обзоров потока и работы с метриками. Провела у 15 команд.
✅ провела анализ компетенций в командах с помощью инструмента Star map. Инструмент так зашёл всем, что я провела обучение по использованию этого инструмента на всю компанию.
✅ провела аудиты в командах и поделилась своими рекомендациями улучшений по взаимодействию с другими доменами и бизнесом / работе с инструментами / развитию продуктов и сервисов
✅ проводила ретроспективы и стратсессии по запросам компании
И много всего ещё…
Постараюсь больше рассказывать.
Давно я не заходила сюда и не делилась полезностями. И очень соскучилась по вам, дорогие подписчики!
Всё дело в том, что я веду Agile-трансформацию у нового заказчика, крупной ритейл компании.
В этой трансформации у меня роль Agile&Kanban коуча. Я работаю на всех уровнях: топ, средний менеджмент (руководители доменов, проектного офиса) и команды.
У команд разные подходы и процессы, с которыми они работают. В основном это работа с изменениями (Change management) по ITSM, есть команды, работающие по Agile.
Было принято решение ко всем процессам и командам применить канбан-метод, для ускорения процесса поставки ценности и уменьшения времени ожидания в очереди.
По уровню зрелости все команды очень разные и со всеми приходится находить свой подход.
Что общего? С руководителем трансформации со стороны Заказчика мы прописали критерии первой стадии трансформации:
✅ провести STATIK
✅ напустить самые основные каденции
✅ научить пользоваться основными инструментами визуализации (в нашем случае это jira)
✅ прописать правила приоритезации, критерии DOR&DOD и согласовать из с бизнесом
✅ научить основным метрикам и запустить процесс анализа процесса по метрикам для постоянных улучшений.
С января я запустила 3 домена и 9 команд в общей сложности
Кроме этого я:
✅ запустила процесс кросс-доменного планирования (некое подобие PI - planning)
✅ запустила внутреннее Agile-сообщество и регулярно выступаю и пишу статьи для него
✅ задизайнила тренинг по изучению инструмента Structure в jira для обзоров потока и работы с метриками. Провела у 15 команд.
✅ провела анализ компетенций в командах с помощью инструмента Star map. Инструмент так зашёл всем, что я провела обучение по использованию этого инструмента на всю компанию.
✅ провела аудиты в командах и поделилась своими рекомендациями улучшений по взаимодействию с другими доменами и бизнесом / работе с инструментами / развитию продуктов и сервисов
✅ проводила ретроспективы и стратсессии по запросам компании
И много всего ещё…
Постараюсь больше рассказывать.
🔥6
Дорогие подписчики, всем привет!
Возвращаюсь из небытия.
Всё же проводить Agile-трансформации и вести соц. сети, соблюдая при этом work-life balance, не просто.
Я стала очень ценить свои вечера. И стараюсь максимально отдыхать от онлайна.
Но, искренний интерес моих подписчиков и коллег о том, что я делаю мотивирует меня продолжать делиться своим опытом.
Очень надеюсь, что мой интерес, наконец, совпадет с моими возможностями, и я буду публиковать здесь информацию чаще!
Ваш отклик поможет моей мотивации🫰
Возвращаюсь из небытия.
Всё же проводить Agile-трансформации и вести соц. сети, соблюдая при этом work-life balance, не просто.
Я стала очень ценить свои вечера. И стараюсь максимально отдыхать от онлайна.
Но, искренний интерес моих подписчиков и коллег о том, что я делаю мотивирует меня продолжать делиться своим опытом.
Очень надеюсь, что мой интерес, наконец, совпадет с моими возможностями, и я буду публиковать здесь информацию чаще!
Ваш отклик поможет моей мотивации
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4⚡1🥰1🎉1
Продуктовый подход - начало трансформации
С начала 2 квартала мы начали двигаться в сторону продуктового подхода.
В компании, которая работала ранее только с проектрами, выявили потребность развивать продукты и перейти на продуктовый подход.
Для начала мы решили рассказать коллегам про продуктовые команды и продуктовый подход. Зачем это нужно и какие проблемы этот подход решает.
А также решили поделиться критериями продуктовой команды, чтобы ребята смогли сами себя оценить и заинтересоваться.
В общем, сделали такой мини-прогрев аудитории. 😉
С начала 2 квартала мы начали двигаться в сторону продуктового подхода.
В компании, которая работала ранее только с проектрами, выявили потребность развивать продукты и перейти на продуктовый подход.
Для начала мы решили рассказать коллегам про продуктовые команды и продуктовый подход. Зачем это нужно и какие проблемы этот подход решает.
А также решили поделиться критериями продуктовой команды, чтобы ребята смогли сами себя оценить и заинтересоваться.
В общем, сделали такой мини-прогрев аудитории. 😉
👍3⚡1🔥1🏆1
Критерии продуктовой команды
Деятельность продуктовой команды, направлена на развитие и рост продукта.
Основная цель – удовлетворение пользовательских задач или потребностей, которые влияют на бизнес результат.
Критерии продуктовой команды:
📌 люди в команде - объединённы единой целью;
📌 люди в команде - мотивированные профессионалы;
📌 кроссфункциональная, то есть все необходимые компетенции должны присутствовать в команде;
📌 люди в команде самоорганизующиеся и независимые;
📌 в команде — фиксированный состав участников;
📌 люди в команде соблюдают правила и договорённости команды;
📌 берут ответственность за общий результат;
📌 в команде происходит открытый обмен рабочей информацией;
📌 усилия объединяются для общей цели;
📌 планы и действия команды согласованны;
📌 люди в команде оказывают необходимую помощь друг другу;
📌 совокупный опыт и таланты людей, работающих в команде, превосходит опыт и пособности любого из тех, кто работает в одиночку.
Обязательное условие продуктовой команды - это наличие менеджера отвечающего за цели и метрики продукта. Это Владелец продукта (PO).
Владелец продукта создает стратегию развития продукта, для этого исследует клиентов, выявляет их потребности/задачи и проверяет гипотезы.
Также важна готовность Бизнеса бюджетироваться по продуктовому подходу.
Проблемы, которые могут быть решены продуктовой командой:
👎 постоянные изменения требований и целей развития продукта;
👎 необходимость постоянного развития существующего продукта или запуск нового;
👎 проблемы с синхронизацией и межкомандной коммуникацией (уменьшается скорость доставки ценности до пользователей);
👎 искажение и потеря информации (требований);
👎 неудовлетворённость пользователя/заказчика. Потребности не удовлетворяются.
Если я упустила, какие-то из критериев продуктовой команды, подалуйста, делитесь в комментариях ✍️ ⤵️
Деятельность продуктовой команды, направлена на развитие и рост продукта.
Основная цель – удовлетворение пользовательских задач или потребностей, которые влияют на бизнес результат.
Критерии продуктовой команды:
📌 люди в команде - объединённы единой целью;
📌 люди в команде - мотивированные профессионалы;
📌 кроссфункциональная, то есть все необходимые компетенции должны присутствовать в команде;
📌 люди в команде самоорганизующиеся и независимые;
📌 в команде — фиксированный состав участников;
📌 люди в команде соблюдают правила и договорённости команды;
📌 берут ответственность за общий результат;
📌 в команде происходит открытый обмен рабочей информацией;
📌 усилия объединяются для общей цели;
📌 планы и действия команды согласованны;
📌 люди в команде оказывают необходимую помощь друг другу;
📌 совокупный опыт и таланты людей, работающих в команде, превосходит опыт и пособности любого из тех, кто работает в одиночку.
Обязательное условие продуктовой команды - это наличие менеджера отвечающего за цели и метрики продукта. Это Владелец продукта (PO).
Владелец продукта создает стратегию развития продукта, для этого исследует клиентов, выявляет их потребности/задачи и проверяет гипотезы.
Также важна готовность Бизнеса бюджетироваться по продуктовому подходу.
Проблемы, которые могут быть решены продуктовой командой:
👎 постоянные изменения требований и целей развития продукта;
👎 необходимость постоянного развития существующего продукта или запуск нового;
👎 проблемы с синхронизацией и межкомандной коммуникацией (уменьшается скорость доставки ценности до пользователей);
👎 искажение и потеря информации (требований);
👎 неудовлетворённость пользователя/заказчика. Потребности не удовлетворяются.
Если я упустила, какие-то из критериев продуктовой команды, подалуйста, делитесь в комментариях ✍️ ⤵️
🔥5
Владелец Продукта
Кроме определения, какой проект мы будем трансформировать в продукт, у нас возникли сложности с поиском кандидатов на Владельца Продукта.
Мы решили пойти тем же путём хитрого прогрева, и рассказать коллегам, что же за роль такая “Владелец Продукта” или Product Owner.
Ниже приведу описание роли Владельца Продукта, которое учитывает внутренние особенности и потребности компании⤵️
Кроме определения, какой проект мы будем трансформировать в продукт, у нас возникли сложности с поиском кандидатов на Владельца Продукта.
Мы решили пойти тем же путём хитрого прогрева, и рассказать коллегам, что же за роль такая “Владелец Продукта” или Product Owner.
Ниже приведу описание роли Владельца Продукта, которое учитывает внутренние особенности и потребности компании⤵️
ВЛАДЕЛЕЦ ПРОДУКТА (PRODUCT OWNER)
Отвечает за максимизацию ценности продукта для клиента в кратчайшие сроки, за счёт постоянной приоритезации и глубокой проработки («refinement») бэклога с командой.
ЗАДАЧИ:
🔹 эффективное управление бэклогом продукта
🔹 достигать понимания командой того, что надо делать и почему
🔹 знание и исследования рынка по своему направлению, работа с клиентами
🔹 создание видения продукта (lean canvas и тд.)
🔹 составление дорожных карт / релизов /эпиков
🔹 создание финансовой модели продукта и её постоянная проверка / уточнение
КЛЮЧЕВЫЕ АРТЕФАКТЫ:
🔺 бэклог продукта
🔺 бизнес-метрики
🔺 дорожная карта
🔺 бюджет продукта / P&L
🔺 Lean canvas продукта (видение продукта)
ЧТО ДЕЛАЕТ:
✔️ обеспечивает прозрачность, видимость и понимание бэклога продукта со сторон Product Management команды и заинтересованных лиц.
✔️ прорабатывает бизнес-гипотезы, пользовательские пути и тд.
✔️ декомпозирует пользовательские истории в соответствии с бизнес-ценностью
✔️ фокусирует команду на цели и задачах, приносящих максимальную ценность
✔️ отвечает на вопросы команды, даёт необходимые разъяснения об ожиданиях заинтересованных лиц
✔️ если требуется, помогает команде в работе с внешними зависимостями
✔️ принимает пользовательские истории в соответствии с критериями приёмки и Definition of Done
✔️ работает вместе с архитектором продукта и tech lead, приоритезируя сокращение тех долга и архитектурные изменения
✔️ создаёт эпики, соответствующие Definition of Ready, включая бизнес-метрики и проверяемые гипотезы
✔️ создаёт клиентские пути (если надо, с помощью своей команды)
✔️ координирует работу команды и работу с другими продуктами и внешними зависимостями
✔️ помогает команде с приоритезацией и детализацией / декомпозицией эпиков на пользовательские истории
✔️ защищает команду от внезапного «вброса» требований сверху без согласования
✔️ после релиза, собирает метрики и подтверждает гипотезы
✔️ проводит анализ рынка (тренды, конкуренты, потенциал, проблемы клиентов)
✔️ определяет ЦА по продукту и стратегию / бюджет маркетинга
✔️ разрабатывает концепцию продукта и дорожную карту и отслеживает её выполнение
✔️ планирует и управляет бюджетом продукта.
ЧТО НЕ ДЕЛАЕТ ⛔️ :
❌ Не переходит на директивное управление командой, указывая, как им работать и сколько брать задач
❌ Не делегирует основные задачи работы с бэклогом продукта
❌ Не поддаётся давлению сверху, меняя цели и принимая новые задачи, нарушая правила готовности задач к взятию в работу, принятые в команде
❌ Не даёт обязательства от лица команды
❌ Не игнорирует технические задачи и необходимость инвестировать в архитектуру продукта
❌ Не ставит задачи команде и назначает исполнителей
❌ Не занимается микро-менеджментом
Если у вас есть вопросы к каким-то пунктам или есть что-то, что бы вы добавили, подалуйста, пишите в комментариях. ✍️⤵️
Отвечает за максимизацию ценности продукта для клиента в кратчайшие сроки, за счёт постоянной приоритезации и глубокой проработки («refinement») бэклога с командой.
ЗАДАЧИ:
🔹 эффективное управление бэклогом продукта
🔹 достигать понимания командой того, что надо делать и почему
🔹 знание и исследования рынка по своему направлению, работа с клиентами
🔹 создание видения продукта (lean canvas и тд.)
🔹 составление дорожных карт / релизов /эпиков
🔹 создание финансовой модели продукта и её постоянная проверка / уточнение
КЛЮЧЕВЫЕ АРТЕФАКТЫ:
🔺 бэклог продукта
🔺 бизнес-метрики
🔺 дорожная карта
🔺 бюджет продукта / P&L
🔺 Lean canvas продукта (видение продукта)
ЧТО ДЕЛАЕТ:
✔️ обеспечивает прозрачность, видимость и понимание бэклога продукта со сторон Product Management команды и заинтересованных лиц.
✔️ прорабатывает бизнес-гипотезы, пользовательские пути и тд.
✔️ декомпозирует пользовательские истории в соответствии с бизнес-ценностью
✔️ фокусирует команду на цели и задачах, приносящих максимальную ценность
✔️ отвечает на вопросы команды, даёт необходимые разъяснения об ожиданиях заинтересованных лиц
✔️ если требуется, помогает команде в работе с внешними зависимостями
✔️ принимает пользовательские истории в соответствии с критериями приёмки и Definition of Done
✔️ работает вместе с архитектором продукта и tech lead, приоритезируя сокращение тех долга и архитектурные изменения
✔️ создаёт эпики, соответствующие Definition of Ready, включая бизнес-метрики и проверяемые гипотезы
✔️ создаёт клиентские пути (если надо, с помощью своей команды)
✔️ координирует работу команды и работу с другими продуктами и внешними зависимостями
✔️ помогает команде с приоритезацией и детализацией / декомпозицией эпиков на пользовательские истории
✔️ защищает команду от внезапного «вброса» требований сверху без согласования
✔️ после релиза, собирает метрики и подтверждает гипотезы
✔️ проводит анализ рынка (тренды, конкуренты, потенциал, проблемы клиентов)
✔️ определяет ЦА по продукту и стратегию / бюджет маркетинга
✔️ разрабатывает концепцию продукта и дорожную карту и отслеживает её выполнение
✔️ планирует и управляет бюджетом продукта.
ЧТО НЕ ДЕЛАЕТ ⛔️ :
❌ Не переходит на директивное управление командой, указывая, как им работать и сколько брать задач
❌ Не делегирует основные задачи работы с бэклогом продукта
❌ Не поддаётся давлению сверху, меняя цели и принимая новые задачи, нарушая правила готовности задач к взятию в работу, принятые в команде
❌ Не даёт обязательства от лица команды
❌ Не игнорирует технические задачи и необходимость инвестировать в архитектуру продукта
❌ Не ставит задачи команде и назначает исполнителей
❌ Не занимается микро-менеджментом
Если у вас есть вопросы к каким-то пунктам или есть что-то, что бы вы добавили, подалуйста, пишите в комментариях. ✍️⤵️
🔥1
Я пытаюсь собрать библиотеку Владельца продукта
Книги для Владельца Продукта:
🔻A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE
🔻"Управление продуктом в Scrum. Agile-методы для вашего бизнеса" Роман Пихлер
🔻Steve Krug “Don’t make me think”
🔻User Story Mapping: Discover the Whole Story, Build the Right Product
🔻Майк Кон «Пользовательские истории»
🔻Эрик Рис «Бизнес с нуля» ('Lean Startup')
🔻Александр Остервальдер «Построение бизнес-моделей»
🔻Стив Бланк, Боб Дорф «Стартап. Настольная книга основателя»
🔻https://www.romanpichler.com/
Собрала несколько книг и материалов в список, но, уверена, у вас есть рекомендации.
Поэтому, есть что-то, что бы вы добавили, пожалуйста, пишите в комментариях. ✍️⤵️
Книги для Владельца Продукта:
🔻A GUIDE TO THE BUSINESS ANALYSIS BODY OF KNOWLEDGE
🔻"Управление продуктом в Scrum. Agile-методы для вашего бизнеса" Роман Пихлер
🔻Steve Krug “Don’t make me think”
🔻User Story Mapping: Discover the Whole Story, Build the Right Product
🔻Майк Кон «Пользовательские истории»
🔻Эрик Рис «Бизнес с нуля» ('Lean Startup')
🔻Александр Остервальдер «Построение бизнес-моделей»
🔻Стив Бланк, Боб Дорф «Стартап. Настольная книга основателя»
🔻https://www.romanpichler.com/
Собрала несколько книг и материалов в список, но, уверена, у вас есть рекомендации.
Поэтому, есть что-то, что бы вы добавили, пожалуйста, пишите в комментариях. ✍️⤵️
Roman Pichler
Expert Coaching and Training in Product Management
Find out how Roman Pichler's product management training courses, books, blog, podcast, and tools can benefit you.
👏3
Всем привет! 👋
Надеюсь, вам удалось отдохнуть в первые майские выходные! 🌞
Сегодня я расскажу, какой план обучения Владельца продукта я подготовила.
Пока что это черновой список тем, которых я хотела бы коснуться во время обучения.
К тому же мы пока что касаемся этой темы по верхам, для того, чтобы уже сейчас делать какие-то шаги вперёд к продуктовому подходу и учиться на практике.
Надеюсь, вам удалось отдохнуть в первые майские выходные! 🌞
Сегодня я расскажу, какой план обучения Владельца продукта я подготовила.
Пока что это черновой список тем, которых я хотела бы коснуться во время обучения.
К тому же мы пока что касаемся этой темы по верхам, для того, чтобы уже сейчас делать какие-то шаги вперёд к продуктовому подходу и учиться на практике.
Please open Telegram to view this post
VIEW IN TELEGRAM
📌Список тем, которые будем изучать с обучающимися на роль Владельца продукта:
1. Роль Владельца Продукта ( заполним Star map для PO)
2. Vision продукта - что такое, как описывать (продукт с которым работаем)
3. Lean Canvas. Что такое, как заполнять, заполним для каждого продукта.
4. Гипотезы. HADI. Процесс Discovery
5. Customer Development
6. Epic. Формирование эпиков. Построение дорожной карты для каждого продукта
7. User story - описание пользовательских историй.
8. Декомпозиция (User story mapping/ карпаччо из слона)
9. Приоритезация бэклога (ICE/RICE)
10. Продуктовые метрики, топ 10 продуктовых метрик (dvtcnt выбрать из множества, примерив на свой продукт. Научить пользоваться)
11. Взаимодействие с командой
12. Обзор результатов с заказчиком + сбор обратной связи от Заказчика.
Пока что это mvp обучения для PO.
Если вы уже проводили подобные обучения и вам есть чем поделиться, пожалуйста, пишите об этом в комментариях!✍️
1. Роль Владельца Продукта ( заполним Star map для PO)
2. Vision продукта - что такое, как описывать (продукт с которым работаем)
3. Lean Canvas. Что такое, как заполнять, заполним для каждого продукта.
4. Гипотезы. HADI. Процесс Discovery
5. Customer Development
6. Epic. Формирование эпиков. Построение дорожной карты для каждого продукта
7. User story - описание пользовательских историй.
8. Декомпозиция (User story mapping/ карпаччо из слона)
9. Приоритезация бэклога (ICE/RICE)
10. Продуктовые метрики, топ 10 продуктовых метрик (dvtcnt выбрать из множества, примерив на свой продукт. Научить пользоваться)
11. Взаимодействие с командой
12. Обзор результатов с заказчиком + сбор обратной связи от Заказчика.
Пока что это mvp обучения для PO.
Если вы уже проводили подобные обучения и вам есть чем поделиться, пожалуйста, пишите об этом в комментариях!✍️
🔥3❤1👍1
Всем привет!👋
Сегодня я выступала на внутреннем митапе для сотрудников компании Заказчика с презентацией про создание требований в Продуктовом подходе.
Хотела бы с вами здесь поделиться 5ю основными принципами, которыми стоит руководствоваться при создании требований.
Читайте далее⤵️
Сегодня я выступала на внутреннем митапе для сотрудников компании Заказчика с презентацией про создание требований в Продуктовом подходе.
Хотела бы с вами здесь поделиться 5ю основными принципами, которыми стоит руководствоваться при создании требований.
Читайте далее⤵️
Please open Telegram to view this post
VIEW IN TELEGRAM
ОСНОВНЫЕ ПРИНЦИПЫ СОЗДАНИЯ ТРЕБОВАНИЙ
🎯Фокус требований в Agile на ценности для конечного пользователя.
1️⃣ Исследовать потребности потребителей
Это необходимо для того, чтобы не создавать ненужную функциональность, которая не принесёт ценности.
Задача Владельца продукта - исследовать потребности потенциальных или существующих потребителей, рынок существующих продуктов и решений, а также понимать, какую ценность этот продукт принесёт.
2️⃣ Выявить истинную потребность потребителя
Не всегда то, что просит нас выполнить заказчик является решением его задачи. Не всегда, мы понимаем истинный смысл того, что хочет Заказчик.
Поэтому задача Владельца продукта - выявить истинную потребность Заказчика, какую проблему он хочет закрыть функциональностью, которую хочет заказать.
3️⃣ Сформировать пользовательские истории
На базе полученной информации от Заказчика и исследований потребностей рынка необходимо описать User Story (описание функциональной возможности ПО простыми словами, составленное с точки зрения конечного пользователя).
4️⃣ Создавать требования совместно с командой, придумывать решения вместе
Во-первых, обсуждение с командой поможет команде лучше понять то, что требуется сделать. Так Владелец продукта упростит жизнь разработчикам и сократитнесколько дней жизни время на доуточнение требований.
Во-вторых, Разработчики помогают доучесть технические возможности и риски, поможет оценить требования с точки зрения сложности и выполнимости.
Про взаимодействие с командой ещё обязательно буду писать отдельно.
5️⃣ Формировать требования маленькими кусочками итеративно, проверяя результат. Не создавать требования наперёд
Чистота бэклога - залог успеха, я считаю. Если создавать требования на год вперёд, есть шан зарыться в этих идеях и начать создавать то, что на самом деле уже не актуально.
Поэтому рекомендуется создавать требования по мере получения результатов и обратной связи от пользователей.
Задача Владельца продукта - проверять гипотезы и собирать обратную связь от пользователей. Таким образом мы сократим издержки на создание заведомо ненужной функциональности.
Надеюсь, эти принципы будут полезны для вас и ваших продуктов.
Если вы готовы добавить какие-то дополнительные принципы создания требований, то пишите в комментариях!✍️
🎯Фокус требований в Agile на ценности для конечного пользователя.
1️⃣ Исследовать потребности потребителей
Это необходимо для того, чтобы не создавать ненужную функциональность, которая не принесёт ценности.
Задача Владельца продукта - исследовать потребности потенциальных или существующих потребителей, рынок существующих продуктов и решений, а также понимать, какую ценность этот продукт принесёт.
2️⃣ Выявить истинную потребность потребителя
Не всегда то, что просит нас выполнить заказчик является решением его задачи. Не всегда, мы понимаем истинный смысл того, что хочет Заказчик.
Поэтому задача Владельца продукта - выявить истинную потребность Заказчика, какую проблему он хочет закрыть функциональностью, которую хочет заказать.
3️⃣ Сформировать пользовательские истории
На базе полученной информации от Заказчика и исследований потребностей рынка необходимо описать User Story (описание функциональной возможности ПО простыми словами, составленное с точки зрения конечного пользователя).
4️⃣ Создавать требования совместно с командой, придумывать решения вместе
Во-первых, обсуждение с командой поможет команде лучше понять то, что требуется сделать. Так Владелец продукта упростит жизнь разработчикам и сократит
Во-вторых, Разработчики помогают доучесть технические возможности и риски, поможет оценить требования с точки зрения сложности и выполнимости.
Про взаимодействие с командой ещё обязательно буду писать отдельно.
5️⃣ Формировать требования маленькими кусочками итеративно, проверяя результат. Не создавать требования наперёд
Чистота бэклога - залог успеха, я считаю. Если создавать требования на год вперёд, есть шан зарыться в этих идеях и начать создавать то, что на самом деле уже не актуально.
Поэтому рекомендуется создавать требования по мере получения результатов и обратной связи от пользователей.
Задача Владельца продукта - проверять гипотезы и собирать обратную связь от пользователей. Таким образом мы сократим издержки на создание заведомо ненужной функциональности.
Надеюсь, эти принципы будут полезны для вас и ваших продуктов.
Если вы готовы добавить какие-то дополнительные принципы создания требований, то пишите в комментариях!✍️
👍1