Не обижайте ДМов 🤣
мем украл из канала 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) на стрим.
Софториум делают хард разработку для аптечных сетей и производства.
Будем говорить о моем любимом Канбане, приходите будет интересно!

Стрим с Александром Торгашовым

В марте планируем провести стрим с Александром Торгашовым, деливери-менеджером «Т-Банк». Подписывайтесь на его канал

Тема стрима — Kanban, и как наконец его внедрить!

Поговорим, о том, кто выиграет от внедрения практик канбан. Каким командам он точно необходим и с чего начинать.

Предлагайте свои вопросы.

🚀 Всем успешной доставки!
Этап Delivery — это ключевая часть e2e процесса, где идея превращается в реальный результат. Но как сделать так, чтобы этот этап прошел гладко, а клиент получил именно то, что ему нужно? Давайте разберемся.

Что такое этап Delivery?
Delivery — это этап, на котором команда реализует продукт или фичу, основываясь на требованиях, определенных на этапе Discovery. Это не просто разработка, а целый комплекс процессов, включающий планирование, выполнение, тестирование и выпуск продукта.

Цель этапа Delivery — доставить ценность клиенту в рамках установленных ограничений: бюджета, сроков, ресурсов и качества.

Основные подэтапы Delivery
1.Планирование
На этом этапе команда определяет, как будет реализован продукт. Это включает:
Разработку дорожной карты.
Оценку ресурсов и сроков.
Распределение задач между участниками команды.

2.Разработка
Здесь команда приступает к созданию продукта. Важно, чтобы каждый участник понимал свои задачи и сроки их выполнения.
Разработчики пишут код.
Дизайнеры создают интерфейсы.
Тестировщики готовят тестовые сценарии.

3.Тестирование
Тестирование — это не просто проверка на баги, а гарантия того, что продукт соответствует требованиям клиента.
Функциональное тестирование: проверка, что все функции работают как задумано.
Регрессионное тестирование: проверка, что новые изменения не сломали старый функционал.
Юзабилити-тестирование: проверка удобства использования.
Совет: Автоматизируйте тестирование, чтобы сократить время на рутинные проверки.

4.Релиз
Релиз — это момент, когда продукт становится доступным для клиентов. Это может быть:
Полное развертывание (когда продукт выпускается для всех пользователей).
Поэтапное развертывание (когда продукт сначала выпускается для ограниченной группы пользователей).
Совет: Используйте feature toggles (флаги функций), чтобы включать или отключать функционал без необходимости повторного релиза.

5.Сбор обратной связи
После релиза важно собрать обратную связь от пользователей. Это поможет понять, насколько продукт соответствует их ожиданиям, и выявить возможные улучшения.
Опросы пользователей.
Аналитика продукта (например, метрики вовлеченности).
Интервью с клиентами.
Совет: Внедрите систему обратной связи прямо в продукт (например, кнопку «Сообщить о проблеме»).

Метрики для контроля этапа Delivery
Чтобы понять, насколько эффективно проходит этап Delivery, используйте следующие метрики:

1.Lead Time
Время от момента поступления задачи до ее завершения. Помогает оценить скорость выполнения задач.
2.Throughput
Количество задач, завершенных за единицу времени. Показывает, насколько продуктивна команда.
3.WIP (Work In Progress)
Количество задач, находящихся в работе одновременно. Высокий WIP может указывать на перегрузку команды.

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

А как вы организуете этап Delivery в своей команде? Делитесь опытом в комментариях! 😊
#delivery #метрики #e2e

🚀 Всем успешной доставки!
В апреле, а точнее 25 апреля я буду в Екатеринбурге выступать на конференции DUMP
Буду рассказывать про практики и метрики (про что мне еще рассказывать😁), которые помогают команда улучшать свои процессы, причем практики и метрики зависят от уровня зрелости команд. Приходите обязательно, конференция суперинтересная!
При покупке билета вводите промокод "Torgashov" для 10% скидки .

А еще я стал ментором на getmentor и уже помог двум менти 🤟 если вам требуются мои консультации, то я готов помочь!
#dump

🚀 Всем успешной доставки!
Сегодня хочется поговорить про SDLC (Software Development Life Cycle) — это основа разработки любого программного продукта. Это не просто процесс написания кода, а целый цикл, который включает планирование, создание, тестирование и поддержку продукта.

Что такое SDLC?
SDLC — это структурированный подход к созданию программного обеспечения, который включает несколько этапов. Каждый этап имеет свои цели, задачи и результаты.
Основная цель SDLC — минимизировать риски, обеспечить качество и доставить продукт в срок (прям как delivery manager😏).

Основные этапы SDLC
Планирование и анализ требований
На этом этапе команда определяет, что нужно сделать. Это включает:
-Сбор и анализ требований от заказчика.
-Определение целей и задач проекта.
-Оценку ресурсов, сроков и бюджета.

Проектирование
На этапе проектирования команда создает архитектуру продукта. Это включает:
-Разработку технической документации.
-Создание прототипов и макетов.
-Выбор технологий и инструментов.

Разработка
Это этап, где идеи превращаются в код. Команда:
-Пишет код в соответствии с требованиями.
-Интегрирует модули и компоненты.
-Проводит код-ревью для обеспечения качества.

Тестирование
Тестирование — это не просто поиск багов, а гарантия того, что продукт соответствует требованиям. Это включает:
-Функциональное тестирование.
-Регрессионное тестирование.
-Юзабилити-тестирование.

Внедрение (Deployment)
На этом этапе продукт становится доступным для пользователей. Это может быть:
-Полное развертывание (когда продукт выпускается для всех пользователей).
-Поэтапное развертывание (когда продукт сначала выпускается для ограниченной группы пользователей).

Поддержка и обслуживание
После релиза команда продолжает работать над продуктом:
-Исправляет баги.
-Вносит улучшения.
-Обеспечивает техническую поддержку.

Итог
SDLC — это не просто процесс разработки, а основа успешного создания программного продукта. Чтобы он был эффективным, важно:
-Планировать каждый этап.
-Использовать подходящие методологии.
-Контролировать качество на всех этапах.
-Собирать и учитывать обратную связь.
А как вы организуете SDLC в своей команде? Делитесь опытом в комментариях! 😊
#sdlc

🚀 Всем успешной доставки!
Сегодня хочется поговорить про очень сложную тему - эффективность IT-команд.
По моему мнению эффективность команды — это когда вы делаете больше, тратя меньше (времени, денег и нервов). В IT это означает:
-Быстро, но без косяков: задачи выполняются в срок, а баги не плодятся как кролики.
-Минимум переделок: чтобы не приходилось переписывать код, как школьное сочинение.
-Довольные клиенты: чтобы они не писали гневные письма, а ставили лайки.

Можно попробовать сформировать показатели эффективности
-Скорость выполнения задач (Throughput)
Сколько задач команда закрывает за неделю? Если это число растет, вы на правильном пути. Если нет, возможно, пора пересмотреть приоритеты (или купить больше кофе).
-Время выполнения задач (Lead Time)
Сколько времени проходит от поступления задачи до ее завершения? Если Lead Time растет, это повод задуматься.
-Качество продукта
Сколько багов вы находите после релиза? Если их больше, чем звезд на небе 😏, пора усилить тестирование .
-Удовлетворенность клиентов
Что говорят клиенты? Если они счастливы, вы молодец. Если нет, пора включать режим "спасатель".

Получается, эффективность IT-команд — это не про скорость, а про умение работать с умом.
Чтобы достичь максимума, важно:
-Использовать метрики для анализа и улучшения процессов.
-Внедрять инструменты и практики, которые повышают продуктивность.
-Учитывать обратную связь от клиентов и команды.
-Инвестировать в обучение и развитие сотрудников.
А как вы повышаете эффективность своей команды? Делитесь опытом в комментариях!
А еще можно послушать про эффективность в подкасте "Письма Лиды Таймовны", как раз вышел новый сезон 👍

🚀 Всем успешной доставки! А в вашем продукте есть платформенные команды? Если нет, то это фатальная ошибка 😁
Давайте попробую раскрыть зачем нужны такие команды.

Платформа — это набор инструментов, сервисов и решений, которые упрощают разработку и эксплуатацию продуктов. Это может быть:
-Техническая платформа: инфраструктура, API, библиотеки, фреймворки.
-Бизнес-платформа: экосистема, которая объединяет продукты, сервисы и пользователей.
Платформа позволяет продуктовым командам сосредоточиться на создании ценности для клиентов, а не на решении рутинных задач.

Зачем нужны платформенные команды?
Платформенные команды — это специализированные группы, которые разрабатывают и поддерживают платформу. Их основные задачи:
Создание инфраструктуры - разрабатывают инструменты и сервисы, которые используют другие команды. Например, CI/CD-пайплайны, системы мониторинга, шаблоны микросервисов.
Упрощение разработки - создают готовые решения, которые ускоряют разработку. Например, библиотеки компонентов, API для интеграции, шаблоны проектов.
Обеспечение стабильности - следят за тем, чтобы платформа работала стабильно и безопасно. Это включает мониторинг, устранение инцидентов и обновление инфраструктуры.

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

Итог
Платформы и платформенные команды — это мощный инструмент для ускорения разработки и повышения качества продуктов. Чтобы создать успешную платформу, важно:
-Определить цели и задачи.
-Разработать архитектуру, которая поддерживает текущие и будущие потребности.
-Сформировать сильную платформенную команду.
-Собирать и учитывать обратную связь от пользователей.
А как вы используете платформы в своей компании? Делитесь опытом в комментариях! 😊
P.S. Полезная книга Team Topologies
#платформа #платформенныекоманды