Курдюмов Дмитрий - мастер по внедрению гибких процессов

Как быстро и эффективно разложить любую цель и определить границы проекта и сформировать беклог? 💡с помощью Impact mapping. Есть несколько шагов: 1. Определите цель которую будете раскладывать 2. Выпишите действующих лиц влияющих на цель (могут как положительно так и отрицательно) 3. Определите через какие влияния они смогут влиять на цель. Здесь могут быть потенциальные гипотезы. 4. Определить задачи чтобы реализовать влияния.

Теперь я сертифицированный PADI Open Water Diver, могу погружаться на глубину до 18 метров. Считаю что в жизни не нужно стоять на месте, а нужно всегда пробовать новое, не бояться, только так можно познать мир. Следующий шаг - advanced левел, до 40 метров. Выбираю интересные дайв сайты. Если вдруг кто то тоже дайвит, буду рад рекомендациям и красивым местам. Например знаю точно что крутой дайвинг в Комодо, Индонезия.

RAT и MVP: Проверка идеи перед созданием продукта В современном мире продуктовой разработки уже давно используется подход к реализации новых продуктов и фич через MVP. Однако создание MVP также может быть не дешевым удовольствием для компании и поэтому прежде чем делать MVP, для начала стоит проверить саму идею. Для этих целей есть подход RAT — Riskiest Assumption Test — проверка рискованного предположения об успешности нашей идеи. В ходе тестирования по RAT мы можем продавать несуществующий продукт или тестировать несуществующую фичу, сделав макет или fake feature на определенном сегменте трафика. Примеры RAT: 🔴Пост в соцсетях с целевым действием (например, написать с просьбой оставить контакт). 🔴Раздача листовок на улице с номером телефона, чтобы заинтересованные пользователи могли позвонить. 🔴Создание лендинга и привлечение трафика с предложением купить продукт. 🔴Fake feature — создание фронтенда без сложной бэкенд логики для отслеживания интереса к новой фиче. 🔴No-code/low-code прототипы. 🔴Ухудшающий эксперимент. 🔴Коридорный тест. 🔴Перепродажа с презентацией. Как сформировать эксперимент по RAT? 1. Описать гипотезу: Например, «Люди готовы платить за поиск свободной парковки в центре города, так как сталкиваются с проблемами отсутствия мест». 2. Описать эксперимент: Например, Сделать листовки с информацией о сервисе и номером телефона для поиска парковки и раздать автомобилистам в центре города 3. Описать критерии успеха: Из 10 000 разданных листовок нам позвонит 2% потенциальных клиентов, т.е. 200 человек. 4. Запуск и выводы: После проведения эксперимента оценить количество звонков и сделать выводы о жизнеспособности идеи. Описанный эксперимент по сервису поиска парковок — реальный пример использования RAT - стартапу начало поступать большое количество звонков с листовок с готовностью заплатить за парковку. И только после этого они начали делать MVP. А правильно делать MVP без разработки или с минимальным количеством поделюсь в следующих постах🚀

Хочу поделиться новостью о старте курса про Проработке бизнес задач и гибким процессам управления требованиями для одной компании для senior инженеров. И сегодня стартовали урок про процесс создания продукта и работу с гипотезами. Разобрали 2 формата проведения экспериментов: с помощью RAT и MVP 1 - позволяет быстро и дешево проверить самое рискованное предположение и идею 2- минимальными усилиями после проверки собрать то самое решение. Ставь 👍 если интересно узнать подробнее про эти подходы, чтобы раскрыть в следующих постах.

Следующую неделю очень много планов🤪

С Днём России🇷🇺 Тк выходной выпал на середину недели, а дел накопилось очень много, то сегодня я решил его использовать для подготовки к Тренингу по LeSS (Large Scale Scrum) для руководителей еще одной прекрасной компании Сибур Будем разбирать как организовать команды и процессы разработки в продукте 100+ человек. Предстоит много практики и интересной теории Всех с праздником🎉

Метод приоритизации WSJF📄 Хочу поделиться отличным инструментом приоритизации беклога продукта с помощью Weighted Shortest Job First (WSJF). WSJF помогает определить приоритет задач для максимальной экономической выгоды. Он основывается на соотношении стоимости задержки (Cost of Delay) к трудоемкость задачи. Формула WSJF: WSJF = (User-Business Value + Time Criticality + Risk Reduction или Opportunity Enablement) / Effort ​ User-Business Value (Пользовательская и бизнес-ценность): Насколько это важно для пользователей и бизнеса. Time Criticality (Срочность): Насколько важно сделать это сейчас. Risk Reduction / Opportunity Enablement (Снижение рисков / Открытие возможностей): Насколько это уменьшает риски или открывает новые возможности. Каждый параметр оценивается по 10 бальной шкале. Оценки относительные друг от друга. Будет плюсом если вы под каждый параметр придумаете измеримые результаты, опишите что есть 1 и что есть 10, например измеряя User-Business Value насколько повлияет доработка на то сколько продукт заработает. Effort - оценка трудоемкость. Здесь подойдет оценка в Story points из последовательности Фибоначчи (1 2 3 5 8 13 21) Больше о WSJF можете узнать тут

SAFe DevOps Health Radar: Оценка Зрелости DevOps Друзья, привет! Сегодня расскажу вам об инструменте для оценки зрелости DevOps в вашей компании — SAFe DevOps Health Radar. Этот радар помогает оценить текущий уровень зрелости DevOps практик в вашей организации. Он включает четыре ключевых области: 🔄 Continuous Exploration (Непрерывное исследование): Начинается с гипотез и заканчивается выработкой архитектурных решений ⚙️ Continuous Integration (Непрерывная интеграция): От разработки до тестирования и сборки. 🚀 Continuous Deployment (Непрерывное развертывание): Включает верификацию, развертывание и мониторинг. 📅 Release on Demand (Релиз по требованию): От стабилизации и измерения до релиза и реагирования на изменения. Радар позволяет командам самооценить свои процессы по пятибалльной шкале, что помогает выявить слабые места и наметить пути для улучшения. Используйте его при диагностике процессов, чтобы усилить DevOps практики и достичь более высокой эффективности!

Регулярные ретроспективы Очень часто бывает что ретроспективы проводят в конце каких то значимых этапов или проектов. Это действительно хороший повод взглянуть назад и сделать работу над ошибками. Но в таком подходе есть большой минус. Делая ретроспективу в конце пути у вас нет возможности улучшаться по ходу этого пути. Когда ретроспектива становиться частью регулярного процесса, раз в неделю или две, то вы тратите меньше на нее времени и получаете больше пользы, в моменте можете решать конфликты, устранять препятствия и договариваться. Поэтому старайтесь уходить от понятия Релизных ретроспектив или Проектных, а приходите к более частым спринтовым. Если вы работаете в Scrum, ретроспектива должна быть в конце каждого спринта. Делите работу на маленькие итерации и каждую итерацию проводите улучшения.

Многие просили поделиться паттернами которые можно использовать при построении Agile команд вне IT💡 Правильный Agile идет всегда через трансформацию структуры и организации людей. Это помогает им фокусироваться на одной цели и ломать барьеры коммуникации. Поэтому не важно в какой сфере вы работаете, важно над каким продуктом вы работаете. Команды организуют в кроссфункциональные. Внутрь же команды должны быть все необходимые функции для достижения целей команды. Многие компании берут за основу воронку продаж AAARR и создают команды по воронке, где каждая команда отвечает за конкретный шаг. А внутри уже создают кроссфункциональные команды. За весь продукт отвечает Product owner, за конкретное направление Area Product Owner. Воронка: - Awareness (осведомленность) - Acquisition (привлечение) - Activation (активация) - Retention (удержание) - Revenue (доход) - Referral (рекомендации) Так например в направлении Привлечения и Активации у нас были примеры следующие примеры команд: 🔴Команда Роста (отвечают за постоянный тест гипотез привлечения через разные каналы) Туда могут входить как маркетинг, так дизайн так и разработчики. 🔴Команда продаж и активации клиента (туда могут входить и продажи, маркетинг, дизайнер, юристы, бухгалтер) - они отвечают за конвертацию лида в продажи. Здесь важно объединить роли и функции для упрощения коммуникации и доведения лида до клиента. 🔴Были также и чисто инженерные команды с разработкой, дизайнерами и исследователями которые улучшали опыт продукта на этапе Активации. 💡 всегда нужно идти от целей продукта и воронки или его CJM по которой идет клиент и далее уже определяя цели на каждом этапе формировать необходимый состав под цели. Более подробно о такой структуре можете почитать в моей статье И да, для компаний которые хотят построить гибкие Agile процессы мы предлагаем Консалтинг по Agile трансформации вашей компании Пишите @Agileguru, поможем сформулировать ваш запрос и предложить наилучшие варианты и полезную консультацию🚀