Всем успешной доставки!
Как я уже писал ранее Delivery Manager - это менеджер изменений, который приносит в компанию/команду новые изменения и внедряет их.

Сегодня обсудим, как осуществлять эти изменения
Когда вы пытаетесь внедрить какие либо изменения, то скорее всего вы сталкиваетесь с большим сопротивлением со стороны участников этих изменений.
Чтобы минимизировать это сопротивление, можно использовать популярную модель управления изменениями ADKAR, разработанную компанией Prosci.

ADKAR включает пять ключевых элементов для успешного внедрения изменений.
Каждая буква в акрониме обозначает одну из стадий:
A - Awareness (Осведомлённость): Понимание необходимости изменений и осознание причин, по которым они необходимы. Какую проблему решаем и какой профит получит команда/компания.
D - Desire (Желание): Стремление поддерживать изменения и участвовать в процессе.
K - Knowledge (Знание): Осознание того, как именно будут реализованы изменения и какие навыки нужны для этого.
A - Ability (Способность): Практическое применение знаний и навыков для реализации изменений.
R - Reinforcement (Подкрепление): Устойчивое внедрение изменений в организационную культуру и признание успехов.

Для внедрения изменений необходимо пройти три фазы:
1.Подготовка изменений: включает осведомлённость и желание.
2.Управление изменениями: включает знание и способность.
3.Закрепление изменений: включает окончательную стадию — подкрепление.

Чтобы начать процесс внедрения по модели ADKAR или другой, важно понять, какую проблему вы решаете, и вовлечь команду.
Этот путь проходит через: стресс (метрика, показывающая проблемы в команде) -> рефлексия (встреча для обсуждения решения проблемы) -> лидерство (инициатива действий).

Ну и самое главное, что нужно сделать перед внедрением любого изменения - определить спонсора изменения, если у вас нет спонсора , то у вас 30% на успех внедрения изменения.

Рассказывайте в комментариях по какой модели вы внедряете изменения?)
#adkar #изменения #deliverymanager

Всем успешной доставки! Для эксперимента я решил сделать дайджест постов за октябрь.

В этом месяце вышло 5 постов:
1.Как мне кажется, самый холиварный и самый просматриваемый пост (200 просмотров) - Оценка задач в story pointах/часах/попугаях не нужна.
2.Интересная тема - ADKAR, как внедрять изменения.
3.Трудная для восприятия тема - ЗВК (запрос в команду) с которым я выступал на конференции в Ижевске.
4.Самая базовая информация - STATIK в Канбан методе.
5.Небольшой итог по каналу за 2 месяц, на момент написания поста было 95 подписчиков, а сегодня уже 116 🚀

Если вы еще не видели эти посты, то стоит обратить внимание 😎
Новые посты уже на подходе в ноябре, темы будут интересны!

Всем успешной доставки! Давайте снова обсудим визуализацию end-to-end процесса.
Ранее уже писал пост про discovery и delivery , ЗВК и продуктовые эпики . Важно не только визуализировать процесс доставки ценности клиенту, но и грамотно с ним работать.
Сегодня хочу вам рассказать про "продуктовый эпик (ПЭ)", у вас в компании он может называться по другому.
ПЭ - это сущность, с которой работает продакт на всем end-to-end процессе, от discovery и до delivery, представляющая собой ценность (фичу), которую нужно доставить клиенту.

На этапе discovery ПЭ проходит этапы определение проблемы, валидация гипотез решения и защита 1 pagerа

ПЭ необходим для:
1. Фокусировки на потребностях клиента.
2. Отслеживания эффективности продукта:
* Мы доставляем то, что нужно клиенту.
* Скорость доставки ценности.
* Улучшение процессов доставки ценности.
3. Правильного распределения нагрузки среди команд разработки. Если у вас три команды, работающие над одним ПЭ, достаточно его декомпозировать на три подзадач

Основное правило ПЭ, он всегда должен быть один.
Нельзя делить ПЭ на платформы (например IOS и Android) или на части функционала, так как ценность надо доставить для всех клиентов, не зависимо от платформы.
У ПЭ могут быть разные типы работ, если вы как продукт делаете не только фичи, но и какую-то другую работу (например проводить качественные или количественные исследования), то можете отразить это в поле ПЭ и выбрать нужный тип работ.

Как внедрить:
1.Визуализировать весь end-to-end процесс
2.Определить флоу для этапов discovery и delivery
3.Определить типы работ для ПЭ, если такие имеются
4.Внедрить метрики на ПЭ, такие как ТТМ, пропускная способность.

Всем успешной доставки!
Сегодня хочу рассказать вам про одну полезную практику, которую вы можете внедрить в свои команды, если, конечно, еще не внедрили.
Практика называется "3 Амиго" 😂, представляют собой подход к разработке, который фокусируется на тесном сотрудничестве между тремя ключевыми ролями:
-бизнес-аналитиком(у вас он может называться по другому, тот кто придумал фичу и написал тз),
-разработчиком
-тестировщиком

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

Как это работает:
Совместные обсуждения требований: Все три роли собираются на встречи, чтобы обсудить требования, что способствует лучшему пониманию и выявлению неполных или противоречивых требований еще на начальном этапе.
Создание спецификаций: Вместе они могут разрабатывать Acceptance Criteria (критерии приемки), которые служат основой для тестирования и проверки готовности продукта.
Проверка понимания: Каждая роль может задавать вопросы и вносить предложения, что увеличивает шансы на окончательное согласование требований.
Обратная связь: Регулярные встречи позволяют участникам делиться обратной связью о процессе и достигнутых результатах, что способствует постоянному улучшению

Зачем нужно?
Нужно это для того, чтобы сократить количество недоразумений после взятия фичи в работу и повысить качество продукта, так как все участники процесса работают как единая команда, направленная на достижение общих целей.
#3amigo #3амиго

Всем успешной доставки! До нового года осталось 25 дней, и многие, вероятно, начинают подводить итоги, для этого как раз есть одна полезная практика - ретроспектива 😎

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

Виды ретроспектив:
Ретроспектива по завершении проекта: Проводится после завершения проекта для оценки его результатов и выявления успешных и проблемных аспектов
Итерационная ретроспектива: Используется для анализа завершенной итерации с целью улучшения будущих итераций.
OKR ретроспектива: Проводится для анализа и оценки результатов работы команды или организации в рамках метода OKR за определенный период, например за квартал.
Тематическая или фокусная ретроспектива: Сосредотачивается на конкретной теме, проблеме или аспекте работы команды, например разбор долгой фичи, которую вы делали больше чем планировали.

Зачем проводить ретроспективу:
Повышение эффективности: Выявление проблем и областей для улучшения позволяет сделать процессы более эффективными.
Обучение и развитие: Позволяет команде учиться на собственных ошибках и достигнутых успехах.
Оптимизация процессов: Помогает выявить неэффективные практики и заменить их более продуктивными.

Многие команды проводят ретроспективы онлайн, и большинство онлайн-досок предлагает шаблоны для этого, например, такой в Unidraw
#retro #unidraw #команда

Не обижайте ДМов 🤣
мем украл из канала https://news.1rj.ru/str/OgileKambanScram

Всем успешной доставки!
После подведения итогов разумно подумать о планах на следующий год, для чего поможет методология OKR (Objectives and Key Results).

OKR — это методология управления целями, которая помогает организациям и командам устанавливать и отслеживать амбициозные цели (Objectives) и ключевые результаты (Key Results), используемые для оценки прогресса и достижения этих целей. Этот подход обеспечивает фокус, прозрачность и согласованность в работе, мотивируя команды достигать значимых результатов.

Objectives (Цели): Это амбициозные, четко сформулированные цели, которые определяют, чего именно вы хотите достичь. Они должны быть вдохновляющими и понятными всей команде.
Например: Увеличить удовлетворенность клиентов в нашем онлайн-магазине.

Key Results (Ключевые результаты): Это конкретные и измеримые результаты, которые показывают, как будет оцениваться достижение каждой цели. Они должны быть количественными и четко определять, каков успех.
Например:
-Увеличить общий рейтинг клиентских отзывов с 4.2 до 4.7.
-Сократить среднее время ответа службы поддержки на обращения клиентов до 1 часа.
-Повысить уровень повторных покупок с 25% до 35% в течение квартала.
-Провести 3 опроса удовлетворенности клиентов и получить минимум 500 ответов на каждый.

Теперь совместим OKR и KR и получим:
Амбициозная цель: Увеличить удовлетворенность клиентов в нашем онлайн-магазине
Как мы эту цель будем достигать:
-Увеличить общий рейтинг клиентских отзывов с 4.2 до 4.7.
-Сократить среднее время ответа службы поддержки на обращения клиентов до 1 часа.
-Повысить уровень повторных покупок с 25% до 35% в течение квартала.
-Провести 3 опроса удовлетворенности клиентов и получить минимум 500 ответов на каждый.

OKR обычно планируется на определенные временные периоды, наиболее распространённые из которых:
1. Квартал: Это самый популярный срок для OKR. Четыре раза в год команда устанавливает новые цели и ключевые результаты, что позволяет оставаться гибкими и адаптироваться к изменениям.
2. Год: Некоторые компании устанавливают годовые OKR, особенно для стратегических целей, которые требуют более длительного времени для достижения.
3. Месяц: В некоторых случаях OKR могут быть установлены на месячный срок, особенно в динамичных или стартап-средах, где изменения происходят очень быстро.

В OKR существуют несколько регулярных каденций, которые помогают эффективно управлять процессом установки и отслеживания целей. Основные из них:
Квартальная каденция: Наиболее распространенный вариант, при котором команды устанавливают OKR на квартал. В конце квартала они оценивают достижения OKR и при необходимости корректируют цели на следующий квартал.
Месячная проверка (OKR Chek-in): Часто в рамках квартальных OKR команды проводят ежемесячные проверки для оценки текущего прогресса по KR и при необходимости корректировки действий.
Итоговая оценка: В конце цикла (квартал или год) команды подводят итоги, анализируют достижения и определяют что можно улучшить в будущих OKR.
Если хочется более детально погрузиться в OKR, то можно заказать книгу "Цели и ключевые результаты. Полное руководство"
Пройти курс обучения у таких ребят как ScrumTrek, Neogenda(советую, так как сам там проходил), Нетология и другие компании.
#OKR #KR #цель

Всем успешной доставки!
Сегодня расскажу, как мы используем Канбан в командах. Я работаю с 12 продуктовыми командами, и в каждой из них применяются различные практики Канбан, от "визуализации" до "улучшайте совместно, развивайтесь экспериментально".

Для визуализации этапа delivery мы используем ЗВК (запрос в команду), а для discovery — продуктовые эпики. Эти сущности часто расположены в разных проектам Jira: по продуктовым эпикам измеряем TTM, а по ЗВК — Lead Time и другие метрики команды.

У нас описаны DOR/DOD/AC на каждом этапе, проводятся регулярные встречи по обзору процессных метрик и ретро команды. Мы находимся в постоянном состоянии улучшения наших процессов.

Для всех этих практик у нас есть полезный инструмент — practice map, представляющий набор лучших практик и инструментов для команд, которые позволяют повысить скорость и качество.
Каждая практика решает конкретную проблему, например, если у вас много задач и низкая пропускная способность, внедрите WIP лимиты.
Новые практики периодически появляются после внедрения их в команды и получения результатов.

Единственное, что постоянное - это изменение 😎 Не сдавайтесь и продолжайте внедрять изменения 🚀
#practicemap #dor #dod #ac

Всем успешной доставки!
Салаты закончились, и я решил рассказать вам о Kanban Maturity Model (KMM).
Даже будет правильней написать так Kanban Maturity Model - это прагматичное и прикладное руководство, основанное на данных, для определения зрелости организаций.
Канбан сообществом было проанализировано порядка 300 организаций, что позволило выявить общие шаги на разных этапах развития организации.
Всего таких шагов 7, от 0 до 6, сегодня поговорим про первые три шага (если вы считаете, что сейчас находитесь на шаге ML3, то я бы с вами поспорил 😎):

ML0 - Рассеянный - Боязнь правил и регламентов, стремление справиться с личной нагрузкой.
ML1 - Командно-ориентированный - Фокус на командном результате, зарождение командной культуры, все делается командами вокруг команд.
ML2 - Клиенто-ориентированный - Поставляем задачи клиенту вовремя, но не всегда, то что нужно клиенту, появление end-to-end процесса.

На каждом шаге применяются определенные практики (см. картинку к посту), но главное тут, что наличие всех практик на уровне, не гарантирует переход на следующий уровень, нужно осознвоать зачем вам этот переход и какие выгоды он принесет команде или компании.
Переход на следующий уровень, это получение outcomes этого уровня.

Если вам известны примеры компаний в России на уровне 4 и выше, напишите в комментариях — будет интересно!
#kmm #kanban #уровеньзрелости

Всем успешной и быстрой доставки!
Я написал много постов о метриках, и описал практики работы с этими метриками. Однако я упустил важный аспект — Jira гигиену.
Jira гигиена - это определенные действия, которые помогают вам поддерживать порядок на вашей доске в таск трекере Jira 😂.Она включает в себя набор действий и рекомендаций, направленных на поддержание актуальности информации. Соответственно если у вас любой другой таск-трекер, называться будет по другому, но работает в любом.

Ключевой аспект Jira гигиены — регулярное обновление статусов задач, что обеспечивает прозрачность процесса и позволяет собирать точные метрики (метрики собираются по времени нахождения задачи в каждом статусе). Если статусы не обновлять, метрики будут искажены, что может привести к неверным выводам. Часто команды забывают или не хотят обновлять статусы. Для решения этой проблемы можно:

1.На дейли начинать с проверки актуальности статусов, предварительно объяснив команде важность этого процесса.
2.Создать бота, который будет подсвечивать задачи, долго находящиеся в одном статусе.
3.Настроить автоматизацию которая будет переводить задачу из одного статуса в другой по определенному событию.
4.Периодически проверять наличие забытых задач, которые давно выполнены, но не закрыты в трекере.

Если это не помогает, то можно вызвать стресс у команды: тимлид сообщает о жалобах бизнеса на "долгую разработку", команда утверждает, что работает быстро. Показываем метрики (например, Lead Time) по "забытой задаче", команда, скорее всего, признает, что просто забыла обновить статус. На этом примере подсвечиваем еще раз зачем держать задачи в актуальных статусах.

Поддержание Jira гигиены способствует повышению эффективности работы команды, улучшению коммуникации и снижению вероятности ошибок в подсчете метрик.
Перед тем как внедрять различные метрики и практики, надо добиться регулярного обновления статусов у задач.🤟
#jiraгигиена #jira #taskmanager

Всем успешной и быстрой доставки!
Давайте поговорим о том, что такое end-to-end процесс, зачем он нужен и как delivery manager может помочь его настроить.

End-to-end процесс (E2E процесс) — это подход, при котором рассматривается весь цикл выполнения определенной задачи или услуги от начала до конца. Включает все стадии, начиная от первичного запроса клиента и заканчивая доставкой конечного продукта или услуги до клиента.
Если мы рассматриваем сферу ИТ, то это весь процесс от идеи до доставки приложения/ПО клиенту.

Зачем нужен E2E? Он позволяет увидеть всю цепочку создания ценности, что дает возможность выявить узкие места, дублирующиеся шаги и улучшить общую эффективность создания ценности.

Discovery (исследование) и Delivery (доставка) — это два ключевых этапа в рамках end-to-end процесса, которые взаимосвязаны.

Цель этапа discovery - определение потребностей о ожиданий клиента, происходит исследования рынка и выявляются будущие возможности. Никому не хочется выпускать продукт, который не будет востребован, что приведет к напрасным затратам.
Подробно про discovery писал тут

Цель этапа delivery - реализовать и предоставить конечный продукт или услугу клиенту, а так же поддерживать этот продукт или услугу (иногда про это забывают).
На этапе delivery происходит: разработка, тестирование, развертывание, предоставление решения, поддержка.

Как раз для улучшения процессов на discovery&delivery нужен delivery manager.
Что делает delivery manager:
1.Оценивает текущие процессы и предлагает улучшения для большей эффективности.
2.Использует проверенные методологии и подходы для повышения качества работы команды и улучшения процессных метрик.
3.Масштабирует изменения на команды.

Внедрение E2E процессов помогает создать более эффективные, адаптивные и качественные системы как в бизнесе, так и в других областях.
Если вы все еще не визуализировали E2E в вашем продукте или услуге, то буду надеяться, этот пост поможет вам сделать первый шаг 😏. За деталями можете приходить в личку.
#e2e #discovery #delivery

Всем успешной и быстрой доставки!
Так как я нахожусь в Перми, у нас с ребятами из сообщества project-менеджеров Perm PM появилась замечательная традиция, 31 декабря мы ходим в баню — раз в месяц мы собираемся на "Kanban кальяна" 😄. Курим кальян и обсуждаем вопросы и проблемы, с которыми сталкиваются команды, а также думаем, как принципы и практики Kanban могут помочь в их решении.
Однако не все могут присоединиться к этим встречам лично, поэтому я задумался о новом формате — онлайн-встречах в Google Meet.
На таких встречах я смогу проанализировать метрики вашей команды и дать рекомендации по улучшению процессов.
Что для этого нужно:
1.Накопленные задачи (желательно завершенные), по которым можно собрать статистику.
2.Task-менеджер с возможностью построения отчетов. В идеале это Jira или Kaiten, но я готов рассмотреть и другие инструменты.
3.Ваше желание и возможность поделиться метриками вашей команды.
4.Проблема, которую вы хотите решить.

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

P.S. Если вы из Перми и хотите сходить на "Kanban Кальян" в офлайне, то пишите в комментарии, я вас позову на следующую встречу 🙃

Всем привет, иду к крутым ребятам (https://news.1rj.ru/str/softoriumpro) на стрим.
Софториум делают хард разработку для аптечных сетей и производства.
Будем говорить о моем любимом Канбане, приходите будет интересно!