🚀Применяем OKR-подход к целеполаганию

OKR - Objectives and Key Results
(Цели и Ключевые Результаты).

У этого подхода есть два направления.

1️⃣ OKR Institute - оригинальное направление от создателей первоначального подхода.
В данном случае формулируются, как правило на квартал, достаточно амбициозные цели (3-5 наиболее приоритетных), которые могут быть не достигнуты на 100%, и считается, что выполнение цели на уровне 70% - это вполне нормально.
Цель должна отвечать на вопрос: "В каком направлении нам нужно двигаться?".

Например, цель: "Успешно запустить в эксплуатацию автоматизированную скоринговую модель".

Далее формулируются 3-5 ключевых результатов по этой цели, которые используются для проверки прогресса относительно цели и отвечают на вопрос: "Как мы поймем, что мы двигаемся в правильном направлении?".
И как следствие, здесь возникают метрики, которые мы можем отслеживать, измерять в момент выполнения тех или иных действий с нашей стороны. Например: с использованием новой системы было проскорено 10 000 заявлений, индекс удовлетворенности операторов составляет более 8 баллов и скоринговая модель привела к снижению расходов нашей компании на Х%.

2️⃣ OKR Academy - отличие здесь в том, что может не быть четких метрик, а вместо них некие бинарные действия.
Например, цель: "Успешно запустить в эксплуатацию новую систему регулирования в страховании".
И здесь, например, могут быть такие ключевые результаты:
- успешно пройти процесс проверки на качество кода
- заинтегрироваться с безопасниками
- иметь систему электронной защиты и сохранности данных и т.п.
То есть это упрощенный вариант, исключающий метрики.

👉В больших зрелых организаций сейчас акцент идет на использование классического OKR подхода, как доказавшего свою эффективность на практике.
👉Важно также отметить, что OKR могут каскадироваться на разные уровни организации от OKR компании до OKR команд.

Позже рассмотрим более подробно некоторые примеры OKR.
Желаем всем амбициозных целей и крутых результатов в этом году!🚀

OnAgile Learning Hub

👥Создание пользовательских историй - требований к продукту в формате Agile.

Завершающими этапами создания бэклога продукта будут описание требований к нашему продукту в виде пользовательских историй, с дальнейшей их декомпозицией и приоритизацией.

👉 Для описания продуктовых идей в формате Пользовательских историй (User Stories), можно использовать стандартный шаблон, придуманный Майком Коном:
Как [роль/персона], я хочу [возможность продукта], чтобы [цель]

Например:
1️⃣ Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования.
2️⃣ Как управляющий кафе, я хочу видеть статистику бронирований, чтобы планировать загрузку заведения.

Как видно из примеров, описание цели в дополнение к возможности продукта позволяет команде лучше понимать контекст использования и, следовательно, придумать более качественную реализацию функциональности.

Далее мы прописываем Приемочные критерии о которых поговорим в следующем посте.

OnAgile Learning Hub

📌Описание приемочных критериев для пользовательской истории.

👆В посте выше поговорили про Создание пользовательских историй - требований к продукту в формате Agile.

Но достаточно ли нам такого описания требования, чтобы начать его разработку? Конечно нет.
Поэтому обычно в дополнение к истории мы прописываем Приемочные критерии – набор утверждений, который помогает нам лучше понять, что и как нужно сделать.

👉Например, для первой истории из поста выше:
"Как посетитель кафе, я хочу видеть список доступных локаций, чтобы выбрать наиболее удобное место для бронирования."
Приемочные критерии могут быть следующие:
• Отображать кафе в пределах 10км
• Сделать фильтр по времени работы «Открыто сейчас»
• Для каждого кафе отображается его рейтинг

Теперь описание выглядит достаточно проработанным, разработчики задали все свои вопросы и в целом готовы приступать к реализации.🚀

Далее истории необходимо декомпозировать и приоритизировать. Об этом поговорим в следующих публикациях.

OnAgile Learning Hub

Дисбаланс в работе команды🗓

👥Обычно в команде есть несколько разных компетенций, которые должны сотрудничать друг с другом для создания ценности. Например, в IT это бэк-, фронт-разработчики, аналитики, тестировщики.

⏱Если у нас ограниченный временной отрезок для поставки ценности, например, спринт 2-3 недели, то команда, как правило, декомпозирует задачи. При этом могут возникать разрывы в поставке.

👉Например, у команды есть истории А, B и C, которые они взяли в спринт. А и B команда смогла целиком поставить, а история С полностью не влезла. Команда все равно берет ее в работу для оптимизации процесса, так как до конца спринта остается запас velocity — и частично делает. Оставшаяся часть работы по истории С перейдет в следующий спринт.

И здесь зачастую возникает дисбаланс нагрузки. Если в прошлом спринте по истории С свою работу сделал бэк, далее происходит отладка: возможно, нашли дефекты, и, соответственно, работу берет на себя тестировщик. И если оказывается, что дефектов больше, чем рассчитывали — возникает локальный избыток задач на отдельном специалисте, и на другие задачи ему может не хватить времени.
Или наоборот, все в порядке, и мы опять заканчиваем раньше. И снова возникает ситуация, при которой у нас есть возможность воспользоваться небольшим временным отрезком, чтобы взять в работу следующую задачу. Но полноценную поставку за эти один-два дня сделать, скорее всего, не получится.

📌Что делать в этой ситуации?

1 вариант.
При декомпозиции сфокусироваться на том, чтобы в бэклоге оказались задачи разного размера. Например, не только 3, 5 или 8 сторипоинтов, но и небольшие задачи в 1, 2 сторипоинта — чтобы можно было заполнить ими любой разрыв.

2 вариант.
Определить наиболее приоритетные задачи и сфокусироваться на них с рассчетом потратить, например, 70% своего velocity. А 30% остается как буфер, который может использоваться по-разному, и в том числе команда может договориться и согласиться с тем, что перенос части задачи из спринта в спринт - это нормально.

В контексте построения agile процесса более предпочтительным является первый вариант. Однако команда может экспериментировать и выбрать наиболее удобный для нее способ работы в данный момент.

Желаем всем сбалансированной работы!

OnAgile Learning Hub

Отличный вопрос задали под постом про дисбаланс в работе команды:

«А что делать, если есть дисбаланс по количеству работы у участников команды? К примеру, у бэка и тестировщика задач много, а у аналитика и фронта очень мало. И в силу особенности продукта работы для аналитика и фронта неоткуда взяться».

Об этом будет следующая статья👌

Фрагменты вебинара "5 ошибок при внедрении Agile"

Недавно мы проводили вебинар, на котором разбирали ошибки внедрения Agile и работы с командой.
Для удобства просмотра разбили вебинар на фрагменты.

В частности, теперь есть отдельные видео по следующим ошибкам:
- Оптимизировать работу команды, а не работу системы
- Бросать менеджеров в костер проблем
- Игнорирование улучшений и ОС, идущей из команд
- Непонимание концепта лидерства и культуры
- Убежденность, что процесс трансформации в организации — идеальный проект

Приятного просмотра!
А уже совсем скоро анонсируем новый вебинар для вас;)

OnAgile Learning Hub

⚡️Вебинар "Внедрение OKR в организациях среднего размера"

Привет!
Ранее мы уже затрагивали тему OKR, и так как это направление очень актуально, а совсем скоро пора будет задумываться над целями 2 квартала — мы решили провести для вас полезный вебинар на тему внедрения OKR в организациях среднего размера.

На вебинаре расскажем про OKR: что из себя представляет этот подход, откуда появился, где и как применяется. И сделаем разбор реального кейса внедрения, а также рассмотрим популярные ошибки, которые встречаются при использовании подхода. На вебинаре вы сможете задать свои вопросы, и мы с удовольствием на них ответим.

🎙Спикер: Артём Гринякин, тренер и консультант OnAgile Consulting
🗓Дата и время: 1 февраля в 19:00 (мск)
⏱Длительность вебинара: 1 час
⚡️Участие бесплатное

Зарегистрироваться

Декомпозиция и приоритизация бэклога

👉После того как пользовательские истории в общем виде сформированы, их необходимо декомпозировать, то есть разбить на более мелкие истории, каждую из которых можно будет брать в работу (например, она влезет в спринт).

Декомпозировать можно разными способами в зависимости от ситуации: по функциональности, по шагам бизнес-процесса, по логике взаимодействия с пользователем и т.д.

🔹Один из самых эффективных методов декомпозиции мы рассмотрели с вами в разделе про User Story Mapping.
🔹Второй частый метод декомпозиции – по приемочным критериям: как в примере выше, отдельный критерий может являться самостоятельной небольшой пользовательской историей.

📍Приоритизация пользовательских историй

После декомпозиции истории в бэклоге продукта необходимо приоритизировать в соответствии с их ценностью и возможностью быстрой реализации.

Стандартный способ приоритизации такой:
Приоритет = Ценность истории / Трудоемкость

🔹Из популярных количественных методов приоритизации можно порекомендовать RICE и WSJF.

🔹Из очень простого — метод приоритизации MoSCoW:
• Must-Have (Обязательно): Функционал, который обязательно должен быть включен в конечную версию продукта.
• Should-Have (Желательно): Важный функционал, но его отсутствие не является критичным.
• Could-Have (Возможно): Дополнительные функции, которые могут быть включены, если у нас есть время и ресурсы.
• Won't-Have (Не будем делать): Скорее всего не будем делать в ближайшее время.

⚡️Подробнее, с практическими кейсами и заданиями мы рассматриваем работу с бэклогом на наших тренингах.
База дается на тренинге Certified Agile Professional, а
дальнейшее погружение на тренинге Advanced Product Ownership.

Подключайтесь к ближайшей группе, будем рады увидеться и разобрать ваши кейсы вместе!

OnAgile Learning Hub

❓Дисбаланс в объеме работы участников команды

Недавно под одной из публикаций про дисбаланс в работе команды задали хороший вопрос:
👉«А что делать, если есть дисбаланс по количеству работы у участников команды? К примеру, у бэка и тестировщика задач много, а у аналитика и фронта очень мало. И в силу особенности продукта работы для аналитика и фронта неоткуда взяться».

🎙Прикрепляем комментарий от нашего консультанта на этот счет. Подобные вопросы мы, кстати, разбираем на тренингах, в частности на программе Certified Agile Professional.