Всем успешной доставки! Сегодня обсудим практики, не касающиеся напрямую доставки ценности, но влияющие на команду: 1:1 встречи и ретроспектива команды.
Раскрою каждую практику отдельно:
1.1:1- индивидуальные встречи между тимлидом (или любым менеджером) и членом команды для обсуждения различных тем, не обязательно связанных с работой.
Зачем нужно тимлиду: позволяет предоставить сотруднику конструктивную обратную связь, наладить доверительные отношения в команде.
Зачем нужно сотруднику: важно понимать как оценивается его работа, как и куда он может расти как профессионал (например составить ИПР), рассказать про свои проблемы, вынести какие-то предложения по своей работе.
Встреча должна быть регулярной и частой, например раз в 1 или 2 недели, обязательной с повесткой и документированием всех договоренностей
2.Ретроспектива - это встреча команды для анализа прошлых результатов: что сделано хорошо, что можно улучшить и какие есть препятствия.
Нужна для того, чтобы собрать обратную связь со всех участников команды, придумать идеи по улучшению работы в команде, вовлечь всех участников команды в работу над внедрением изменений.
Встреча должна быть регулярной, например раз в месяц, для встречи необходима какая-то онлайн доска (писал про доски отдельный пост ссылка на пост) где вы можете стикерами отмечать, что было хорошо и что можно улучшить, фасилитатором встречи может быть любой участник команды.
Обе встречи полезны для раннего выявления проблем в команде или у конкретного человека, что поможет избежать неожиданных увольнений😎
#ретро #1на1 #команда
Раскрою каждую практику отдельно:
1.1:1- индивидуальные встречи между тимлидом (или любым менеджером) и членом команды для обсуждения различных тем, не обязательно связанных с работой.
Зачем нужно тимлиду: позволяет предоставить сотруднику конструктивную обратную связь, наладить доверительные отношения в команде.
Зачем нужно сотруднику: важно понимать как оценивается его работа, как и куда он может расти как профессионал (например составить ИПР), рассказать про свои проблемы, вынести какие-то предложения по своей работе.
Встреча должна быть регулярной и частой, например раз в 1 или 2 недели, обязательной с повесткой и документированием всех договоренностей
2.Ретроспектива - это встреча команды для анализа прошлых результатов: что сделано хорошо, что можно улучшить и какие есть препятствия.
Нужна для того, чтобы собрать обратную связь со всех участников команды, придумать идеи по улучшению работы в команде, вовлечь всех участников команды в работу над внедрением изменений.
Встреча должна быть регулярной, например раз в месяц, для встречи необходима какая-то онлайн доска (писал про доски отдельный пост ссылка на пост) где вы можете стикерами отмечать, что было хорошо и что можно улучшить, фасилитатором встречи может быть любой участник команды.
Обе встречи полезны для раннего выявления проблем в команде или у конкретного человека, что поможет избежать неожиданных увольнений
#ретро #1на1 #команда
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5❤1
Друзья, совсем скоро я буду выступать на крутой IT-конференции UIC Dev в Ижевске.
UIC Dev - событие для специалистов из интернет-сферы: от HR-ов до IT-директоров. Да, оно не только для разработчиков, но и для аналитиков, тестировщиков, дизайнеров, маркетологов, SEO-шников, копирайтеров и т.д.
В этом году будетт:
6 направлений: разработка, управление и анализ, бизнес+IT, дизайн и контент, маркетинг и digital, UIC Talks
70+ докладов про инструменты, кейсы, "боли" IT-сообщества, AI и будущее
Обсуждение актуальных событий, разбор трендов из области IT и не только
Общение с единомышленниками, дискуссии, обмен опытом, новые идеи
Интерактивы и розыгрыши призов
Вечером первого дня пройдет афтепати с выступлением группы “Стихи на окнах подъезда №8”, дискотекой и развлечениями.
🎁 И у меня есть приятный бонус для подписчиков —
Просто используйте код
Приходите, будет интересно! Встретимся на конференции и пообщаемся лично 🙌
UIC Dev - событие для специалистов из интернет-сферы: от HR-ов до IT-директоров. Да, оно не только для разработчиков, но и для аналитиков, тестировщиков, дизайнеров, маркетологов, SEO-шников, копирайтеров и т.д.
В этом году будетт:
6 направлений: разработка, управление и анализ, бизнес+IT, дизайн и контент, маркетинг и digital, UIC Talks
70+ докладов про инструменты, кейсы, "боли" IT-сообщества, AI и будущее
Обсуждение актуальных событий, разбор трендов из области IT и не только
Общение с единомышленниками, дискуссии, обмен опытом, новые идеи
Интерактивы и розыгрыши призов
Вечером первого дня пройдет афтепати с выступлением группы “Стихи на окнах подъезда №8”, дискотекой и развлечениями.
🎁 И у меня есть приятный бонус для подписчиков —
TORGASHOV со скидкой 30% на покупку билетов! Просто используйте код
TORGASHOV при регистрации на сайте https://uic.dev/#tickets и получайте билет по супервыгодной цене.Приходите, будет интересно! Встретимся на конференции и пообщаемся лично 🙌
🔥7❤1
Оценка - это прогноз ваших работ, производственные метрики такие как lead time и troughput (пропускная способность), - это факт ваших работ. На этом можно закончить пост...Но я попробую раскрыть, что имеется ввиду.
Основная проблема, которую должна решать оценка задач, - это сроки их (задач) выполнения.
1.Но вот те же Story point это не про сроки.
SP - это единица измерения, отражающая усилия, необходимые для завершения элемента незавершенной работы по продукту.
SP включает три ключевых измерения:
-Объем работы (требуемое время для выполнения);
-Сложность (умственная нагрузка);
-Неопределенность (риски и сомнения в возможности выполнения).
Story points были придуманы, чтобы запутать оценки, чтобы "определенные менеджеры" не давили на команду по поводу оценок ©Рон Джеффрис (создатель Story points).
2.Оценка задач в часах — это прогноз времени, необходимого для выполнения задачи: джун справится за 10 часов, сеньор — за 5. Однако в процессе выполнения могут возникнуть непредвиденные обстоятельства, такие как отпуск, болезнь или увольнение, что может удлинить оценку с 10 до 20 часов. Оценка может работать в заказной разработке, когда вам надо перевести это все в деньги.
Если вы все еще сомневаетесь, проведите эксперимент, описанный Павлом Ахметчановым в этом докладе: возьмите все задачи, оцененные в SP, и сравните их фактическое время выполнения, выгрузив метрики из таск-менеджера. Скорее всего, вы не найдете закономерностей в оценках, так как разные задачи, оцененные в 1/3/5 SP каждая, выполнялись за разное время.
Что же тогда использовать? Метрики Lead time и Throughput (пропускная способность). Если вы условно сделали 100 задач по 85 перцентилю за 40 дней, то 101 задачу вы сделаете за 40 дней или раньше. Да, могут быть всплески больше 40 дней (каждый такой всплеск надо разбирать отдельно, по каким причинам вырос lead time?), которые уйдут за 85 перцентиль, это надо объяснить заказчику, когда будете озвучивать сроки.
Полезные ссылки про планирование на основе статистики и метрик:
Метод Монте-Карло
Статья Павла Ахметчанова про который писал выше
Видео про планирование на основе статистики, тоже от Паши
Может по холиварим в комментариях?
#sp #storypoints #оценка #прогноз #метрики
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5❤1
Всем успешной доставки! Давайте обсудим, как сосредоточиться на доставке ценности клиенту в целом, а не на ее отдельных частях.
Возьмем пример шавермы (привет, Денис). Когда мы заказываем шаверму в кафе, нам не нужны отдельно мясо или овощи — они не представляют ценности сами по себе. Нам нужна готовая шаверма, а для этого нужно собрать все ингредиенты вместе и только потом передать клиенту.
Теперь перенесем это на фичу (назовем это продуктовым эпиком), которую мы хотим реализовать.
У нас есть два этапа: discovery и delivery. После этапа discovery фича переходит в delivery, где появляется сущность ЗВК (запрос в команду).
ЗВК - это такая задача, с которой к нам пришел заказчик, без декомпозиции, ради организации процесса производства, т.е. ЗВК = шаверма.
ЗВК должен иметь ценность для заказчика/клиента/команды.
Сосредоточившись на ЗВК, команда фокусируется на доставке ценности, а не на её частях. Например, клиенту не нужно колесо от машины — ему нужна вся машина.
ЗВК может быть разбит на более мелкие задачи, которые сами по себе ценности не несут, но только выполнив все мелкие задачи, мы можем релизить ЗВК и доставить ценность клиенту.
Зачем нужно ЗВК?
-Фокус команды на доставки ценности.
-Видимость "налога на фичи", т.е. понимание количества задач и времени, которое команда тратит не только на фичи, но и на технические ЗВК.
-Отвечать на вопрос как быстро и стабильно мы доставляем ценность клиент, настроив метрики (lead time, пропускная способность) для ЗВК.
Как это выглядит в таск трекере (у нас jira):
1.Все ЗВК заводятся эпиком, у эпика есть поле "тип изменений", данное поле отображает вид работ которая делает команда, например: развитие функционала (фича), техническое развитие, технический долг, тестовый долг, ошибка. Для своей команды вы сами можете определить тип изменений.
2.Продуктовый эпик может жить в одном jira проекте (например так где у вас визуализирован e2e процесс), ЗВК может быть в другом jira проекте (где у вас живет продуктовая команда).
Надеюсь, хоть чуть-чуть стало понятней, с этой темой я выступал в понедельник в Ижевске на конференции #uicdev
Возьмем пример шавермы (привет, Денис). Когда мы заказываем шаверму в кафе, нам не нужны отдельно мясо или овощи — они не представляют ценности сами по себе. Нам нужна готовая шаверма, а для этого нужно собрать все ингредиенты вместе и только потом передать клиенту.
Теперь перенесем это на фичу (назовем это продуктовым эпиком), которую мы хотим реализовать.
У нас есть два этапа: discovery и delivery. После этапа discovery фича переходит в delivery, где появляется сущность ЗВК (запрос в команду).
ЗВК - это такая задача, с которой к нам пришел заказчик, без декомпозиции, ради организации процесса производства, т.е. ЗВК = шаверма.
ЗВК должен иметь ценность для заказчика/клиента/команды.
Сосредоточившись на ЗВК, команда фокусируется на доставке ценности, а не на её частях. Например, клиенту не нужно колесо от машины — ему нужна вся машина.
ЗВК может быть разбит на более мелкие задачи, которые сами по себе ценности не несут, но только выполнив все мелкие задачи, мы можем релизить ЗВК и доставить ценность клиенту.
Зачем нужно ЗВК?
-Фокус команды на доставки ценности.
-Видимость "налога на фичи", т.е. понимание количества задач и времени, которое команда тратит не только на фичи, но и на технические ЗВК.
-Отвечать на вопрос как быстро и стабильно мы доставляем ценность клиент, настроив метрики (lead time, пропускная способность) для ЗВК.
Как это выглядит в таск трекере (у нас jira):
1.Все ЗВК заводятся эпиком, у эпика есть поле "тип изменений", данное поле отображает вид работ которая делает команда, например: развитие функционала (фича), техническое развитие, технический долг, тестовый долг, ошибка. Для своей команды вы сами можете определить тип изменений.
2.Продуктовый эпик может жить в одном jira проекте (например так где у вас визуализирован e2e процесс), ЗВК может быть в другом jira проекте (где у вас живет продуктовая команда).
Надеюсь, хоть чуть-чуть стало понятней, с этой темой я выступал в понедельник в Ижевске на конференции #uicdev
👍8❤2
Всем успешной доставки!
Подвожу итог по каналу: в прошлое воскресенье (13.10) ему исполнилось 2 месяца, за это время набралось 95 подписчиков. Опубликовано 15 постов. Также настроен бот, который автоматически публикует посты на Дзене , но там ситуация с просмотрами и подписчиками печальная😁 .
Самые просматриваемые посты:
1.Про Kanban 278 просмотров, 5 репостов.
2.Про плагины для Jira 276 просмотров, 7 репостов .
3.Про DOR/DOD/AC 257 просмотров, 1 репост.
4.Про этап Discovery 225, 1 репостов.
Если вы еще не видели эти посты, то кажется они будут очень полезны вам.
Остальные посты набирали 100+ просмотров.
Радует, что пост про Kanban 🚀 на первом месте! Классно, что просмотров больше, чем подписчиков.
Ближайшая цель — достичь 100 подписчиков и заказать рекламу канала, но пока неясно, где и у кого.
Если есть идеи для новых постов, пишите в комментариях.
Подвожу итог по каналу: в прошлое воскресенье (13.10) ему исполнилось 2 месяца, за это время набралось 95 подписчиков. Опубликовано 15 постов. Также настроен бот, который автоматически публикует посты на Дзене , но там ситуация с просмотрами и подписчиками печальная
Самые просматриваемые посты:
1.Про Kanban 278 просмотров, 5 репостов.
2.Про плагины для Jira 276 просмотров, 7 репостов .
3.Про DOR/DOD/AC 257 просмотров, 1 репост.
4.Про этап Discovery 225, 1 репостов.
Если вы еще не видели эти посты, то кажется они будут очень полезны вам.
Остальные посты набирали 100+ просмотров.
Радует, что пост про Kanban 🚀 на первом месте! Классно, что просмотров больше, чем подписчиков.
Ближайшая цель — достичь 100 подписчиков и заказать рекламу канала, но пока неясно, где и у кого.
Если есть идеи для новых постов, пишите в комментариях.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8🫡3❤1
Всем успешной доставки!
Как я уже писал ранее Delivery Manager - это менеджер изменений, который приносит в компанию/команду новые изменения и внедряет их.
Сегодня обсудим, как осуществлять эти изменения
Когда вы пытаетесь внедрить какие либо изменения, то скорее всего вы сталкиваетесь с большим сопротивлением со стороны участников этих изменений.
Чтобы минимизировать это сопротивление, можно использовать популярную модель управления изменениями ADKAR, разработанную компанией Prosci.
ADKAR включает пять ключевых элементов для успешного внедрения изменений.
Каждая буква в акрониме обозначает одну из стадий:
A - Awareness (Осведомлённость): Понимание необходимости изменений и осознание причин, по которым они необходимы. Какую проблему решаем и какой профит получит команда/компания.
D - Desire (Желание): Стремление поддерживать изменения и участвовать в процессе.
K - Knowledge (Знание): Осознание того, как именно будут реализованы изменения и какие навыки нужны для этого.
A - Ability (Способность): Практическое применение знаний и навыков для реализации изменений.
R - Reinforcement (Подкрепление): Устойчивое внедрение изменений в организационную культуру и признание успехов.
Для внедрения изменений необходимо пройти три фазы:
1.Подготовка изменений: включает осведомлённость и желание.
2.Управление изменениями: включает знание и способность.
3.Закрепление изменений: включает окончательную стадию — подкрепление.
Чтобы начать процесс внедрения по модели ADKAR или другой, важно понять, какую проблему вы решаете, и вовлечь команду.
Этот путь проходит через: стресс (метрика, показывающая проблемы в команде) -> рефлексия (встреча для обсуждения решения проблемы) -> лидерство (инициатива действий).
Ну и самое главное, что нужно сделать перед внедрением любого изменения - определить спонсора изменения, если у вас нет спонсора , то у вас 30% на успех внедрения изменения.
Рассказывайте в комментариях по какой модели вы внедряете изменения?)
#adkar #изменения #deliverymanager
Как я уже писал ранее Delivery Manager - это менеджер изменений, который приносит в компанию/команду новые изменения и внедряет их.
Сегодня обсудим, как осуществлять эти изменения
Когда вы пытаетесь внедрить какие либо изменения, то скорее всего вы сталкиваетесь с большим сопротивлением со стороны участников этих изменений.
Чтобы минимизировать это сопротивление, можно использовать популярную модель управления изменениями ADKAR, разработанную компанией Prosci.
ADKAR включает пять ключевых элементов для успешного внедрения изменений.
Каждая буква в акрониме обозначает одну из стадий:
A - Awareness (Осведомлённость): Понимание необходимости изменений и осознание причин, по которым они необходимы. Какую проблему решаем и какой профит получит команда/компания.
D - Desire (Желание): Стремление поддерживать изменения и участвовать в процессе.
K - Knowledge (Знание): Осознание того, как именно будут реализованы изменения и какие навыки нужны для этого.
A - Ability (Способность): Практическое применение знаний и навыков для реализации изменений.
R - Reinforcement (Подкрепление): Устойчивое внедрение изменений в организационную культуру и признание успехов.
Для внедрения изменений необходимо пройти три фазы:
1.Подготовка изменений: включает осведомлённость и желание.
2.Управление изменениями: включает знание и способность.
3.Закрепление изменений: включает окончательную стадию — подкрепление.
Чтобы начать процесс внедрения по модели ADKAR или другой, важно понять, какую проблему вы решаете, и вовлечь команду.
Этот путь проходит через: стресс (метрика, показывающая проблемы в команде) -> рефлексия (встреча для обсуждения решения проблемы) -> лидерство (инициатива действий).
Ну и самое главное, что нужно сделать перед внедрением любого изменения - определить спонсора изменения, если у вас нет спонсора , то у вас 30% на успех внедрения изменения.
Рассказывайте в комментариях по какой модели вы внедряете изменения?)
#adkar #изменения #deliverymanager
👍5🔥4❤3😁1
Всем успешной доставки!
Несколько постов назад, я писал про Канбан метод.
Если вы планируете его внедрять, вам необходимо использовать подход STATIK. Сегодня расскажу подробней про него.
🟢 STATIK- подход, который упрощает внедрение Канбана в команды. Он включает совместные встречи для анализа и совершенствования процессов, что позволяет всем участникам команды работать более эффективно. Этот подход также акцентирует внимание на адаптации инструментов в зависимости от нужд команды.
Основные этапы:
1. Сбор информации:
-Определите ключевых участников и заинтересованных лиц.
-Соберите данные о текущем процессе, включая объем работы, детали задач и временные затраты.
- Определите источники неудовлетворенности
2. Определение текущих процессов:
-Проанализируйте, как работа выполняется в данный момент.
-Используйте визуализацию потоков работы, чтобы понять шаги, которые проходят задачи.
3. Выявление ограничений:
-Найдите и проанализируйте проблемы или узкие места в текущем процессе.
-Сосредоточьтесь на том, что можно улучшить для повышения эффективности.
4. Создание модели потока работы:
-Постройте визуальную карту вашего процесса (можно попробовать VSM), включая все этапы, от начала до завершения работы.
-Это поможет команде увидеть полную картину и принять более обоснованные решения.
5. Определение параметров управления:
-Установите лимиты на количество задач на каждом этапе (Work In Progress, WIP).
-Определите ключевые показатели эффективности (KPI) для мониторинга работы команды.
-Обсудите какие классы обслуживания есть в вашей команде
6. Реализация изменений:
-Запустите Канбан доску
-Обучите команду новым процессам и инструментам.
7. Мониторинг и корректировка:
-Периодически пересматривайте и корректируйте процессы на основании обратной связи и данных.
-Постоянное улучшение должно стать частью культуры команды.
STATIK можно проводить тремя способами:
1.Воркшоп - cоберите всю команду в одном месте (онлайн или офлайн) для обсуждения всех вопросов.
Плюсы: Полное вовлечение команды и обсуждение всех аспектов.
Минусы: Требует 10-16 часов работы всей команды, что может затормозить выполнение задач.
2.Персональный сбор информации через интервью - проводите индивидуальные интервью с участниками для сбора информации.
Плюсы такого способа: не отвлекает всю команду на длительное время
Минусы такого способа: участники могут не чувствовать вовлеченности и сопротивляться изменениям.
3.Персональное построение канбан-системы менеджером изменений/руководителем - информация собирается из документации и базы знаний без участия всей команды.
Плюсы такого способа: команда не отвлекается.
Минусы такого способа: не вся информация есть в документации и базе знаний, команда будет сопротивляться, так как не принимала участие в этих изменениях.
Не начинайте внедрение Канбан метода без проведения Statik!🍌
#Kanban #STATIK
Несколько постов назад, я писал про Канбан метод.
Если вы планируете его внедрять, вам необходимо использовать подход STATIK. Сегодня расскажу подробней про него.
Основные этапы:
1. Сбор информации:
-Определите ключевых участников и заинтересованных лиц.
-Соберите данные о текущем процессе, включая объем работы, детали задач и временные затраты.
- Определите источники неудовлетворенности
2. Определение текущих процессов:
-Проанализируйте, как работа выполняется в данный момент.
-Используйте визуализацию потоков работы, чтобы понять шаги, которые проходят задачи.
3. Выявление ограничений:
-Найдите и проанализируйте проблемы или узкие места в текущем процессе.
-Сосредоточьтесь на том, что можно улучшить для повышения эффективности.
4. Создание модели потока работы:
-Постройте визуальную карту вашего процесса (можно попробовать VSM), включая все этапы, от начала до завершения работы.
-Это поможет команде увидеть полную картину и принять более обоснованные решения.
5. Определение параметров управления:
-Установите лимиты на количество задач на каждом этапе (Work In Progress, WIP).
-Определите ключевые показатели эффективности (KPI) для мониторинга работы команды.
-Обсудите какие классы обслуживания есть в вашей команде
6. Реализация изменений:
-Запустите Канбан доску
-Обучите команду новым процессам и инструментам.
7. Мониторинг и корректировка:
-Периодически пересматривайте и корректируйте процессы на основании обратной связи и данных.
-Постоянное улучшение должно стать частью культуры команды.
STATIK можно проводить тремя способами:
1.Воркшоп - cоберите всю команду в одном месте (онлайн или офлайн) для обсуждения всех вопросов.
Плюсы: Полное вовлечение команды и обсуждение всех аспектов.
Минусы: Требует 10-16 часов работы всей команды, что может затормозить выполнение задач.
2.Персональный сбор информации через интервью - проводите индивидуальные интервью с участниками для сбора информации.
Плюсы такого способа: не отвлекает всю команду на длительное время
Минусы такого способа: участники могут не чувствовать вовлеченности и сопротивляться изменениям.
3.Персональное построение канбан-системы менеджером изменений/руководителем - информация собирается из документации и базы знаний без участия всей команды.
Плюсы такого способа: команда не отвлекается.
Минусы такого способа: не вся информация есть в документации и базе знаний, команда будет сопротивляться, так как не принимала участие в этих изменениях.
Не начинайте внедрение Канбан метода без проведения Statik!
#Kanban #STATIK
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7❤2👍1
Всем успешной доставки! Для эксперимента я решил сделать дайджест постов за октябрь.
В этом месяце вышло 5 постов:
1.Как мне кажется, самый холиварный и самый просматриваемый пост (200 просмотров) - Оценка задач в story pointах/часах/попугаях не нужна.
2.Интересная тема - ADKAR, как внедрять изменения.
3.Трудная для восприятия тема - ЗВК (запрос в команду) с которым я выступал на конференции в Ижевске.
4.Самая базовая информация - STATIK в Канбан методе.
5.Небольшой итог по каналу за 2 месяц, на момент написания поста было 95 подписчиков, а сегодня уже 116 🚀
Если вы еще не видели эти посты, то стоит обратить внимание 😎
Новые посты уже на подходе в ноябре, темы будут интересны!
В этом месяце вышло 5 постов:
1.Как мне кажется, самый холиварный и самый просматриваемый пост (200 просмотров) - Оценка задач в story pointах/часах/попугаях не нужна.
2.Интересная тема - ADKAR, как внедрять изменения.
3.Трудная для восприятия тема - ЗВК (запрос в команду) с которым я выступал на конференции в Ижевске.
4.Самая базовая информация - STATIK в Канбан методе.
5.Небольшой итог по каналу за 2 месяц, на момент написания поста было 95 подписчиков, а сегодня уже 116 🚀
Если вы еще не видели эти посты, то стоит обратить внимание 😎
Новые посты уже на подходе в ноябре, темы будут интересны!
🔥8👍2❤1
Всем успешной доставки! Давайте снова обсудим визуализацию 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.Внедрить метрики на ПЭ, такие как ТТМ, пропускная способность.
Ранее уже писал пост про discovery и delivery , ЗВК и продуктовые эпики . Важно не только визуализировать процесс доставки ценности клиенту, но и грамотно с ним работать.
Сегодня хочу вам рассказать про "продуктовый эпик (ПЭ)", у вас в компании он может называться по другому.
ПЭ - это сущность, с которой работает продакт на всем end-to-end процессе, от discovery и до delivery, представляющая собой ценность (фичу), которую нужно доставить клиенту.
На этапе discovery ПЭ проходит этапы определение проблемы, валидация гипотез решения и защита 1 pagerа
ПЭ необходим для:
1. Фокусировки на потребностях клиента.
2. Отслеживания эффективности продукта:
* Мы доставляем то, что нужно клиенту.
* Скорость доставки ценности.
* Улучшение процессов доставки ценности.
3. Правильного распределения нагрузки среди команд разработки. Если у вас три команды, работающие над одним ПЭ, достаточно его декомпозировать на три подзадач
Основное правило ПЭ, он всегда должен быть один.
Нельзя делить ПЭ на платформы (например IOS и Android) или на части функционала, так как ценность надо доставить для всех клиентов, не зависимо от платформы.
У ПЭ могут быть разные типы работ, если вы как продукт делаете не только фичи, но и какую-то другую работу (например проводить качественные или количественные исследования), то можете отразить это в поле ПЭ и выбрать нужный тип работ.
Как внедрить:
1.Визуализировать весь end-to-end процесс
2.Определить флоу для этапов discovery и delivery
3.Определить типы работ для ПЭ, если такие имеются
4.Внедрить метрики на ПЭ, такие как ТТМ, пропускная способность.
🔥5👍2❤1
Всем успешной доставки!
Сегодня хочу рассказать вам про одну полезную практику, которую вы можете внедрить в свои команды, если, конечно, еще не внедрили.
Практика называется "3 Амиго" 😂, представляют собой подход к разработке, который фокусируется на тесном сотрудничестве между тремя ключевыми ролями:
-бизнес-аналитиком(у вас он может называться по другому, тот кто придумал фичу и написал тз),
-разработчиком
-тестировщиком
В основном это встреча на троих, где вышеперечисленные роли обсуждают фичу, которую планируют взять в работу; такие встречи проходят до точки принятия обязательств, чтобы найти все подводные камни и вести разработку без дополнительных вопросов.
Как это работает:
Совместные обсуждения требований: Все три роли собираются на встречи, чтобы обсудить требования, что способствует лучшему пониманию и выявлению неполных или противоречивых требований еще на начальном этапе.
Создание спецификаций: Вместе они могут разрабатывать Acceptance Criteria (критерии приемки), которые служат основой для тестирования и проверки готовности продукта.
Проверка понимания: Каждая роль может задавать вопросы и вносить предложения, что увеличивает шансы на окончательное согласование требований.
Обратная связь: Регулярные встречи позволяют участникам делиться обратной связью о процессе и достигнутых результатах, что способствует постоянному улучшению
Зачем нужно?
Нужно это для того, чтобы сократить количество недоразумений после взятия фичи в работу и повысить качество продукта, так как все участники процесса работают как единая команда, направленная на достижение общих целей.
#3amigo #3амиго
Сегодня хочу рассказать вам про одну полезную практику, которую вы можете внедрить в свои команды, если, конечно, еще не внедрили.
Практика называется "3 Амиго" 😂, представляют собой подход к разработке, который фокусируется на тесном сотрудничестве между тремя ключевыми ролями:
-бизнес-аналитиком(у вас он может называться по другому, тот кто придумал фичу и написал тз),
-разработчиком
-тестировщиком
В основном это встреча на троих, где вышеперечисленные роли обсуждают фичу, которую планируют взять в работу; такие встречи проходят до точки принятия обязательств, чтобы найти все подводные камни и вести разработку без дополнительных вопросов.
Как это работает:
Совместные обсуждения требований: Все три роли собираются на встречи, чтобы обсудить требования, что способствует лучшему пониманию и выявлению неполных или противоречивых требований еще на начальном этапе.
Создание спецификаций: Вместе они могут разрабатывать Acceptance Criteria (критерии приемки), которые служат основой для тестирования и проверки готовности продукта.
Проверка понимания: Каждая роль может задавать вопросы и вносить предложения, что увеличивает шансы на окончательное согласование требований.
Обратная связь: Регулярные встречи позволяют участникам делиться обратной связью о процессе и достигнутых результатах, что способствует постоянному улучшению
Зачем нужно?
Нужно это для того, чтобы сократить количество недоразумений после взятия фичи в работу и повысить качество продукта, так как все участники процесса работают как единая команда, направленная на достижение общих целей.
#3amigo #3амиго
🔥8❤1
Всем успешной доставки!
Давайте представим, что у вас уже зрелые команды: отличная визуализация, настроены WIP лимиты, написаны DOR/DOD/AC на каждом этапе производства.
Как еще можно ускорить доставку ценности?
Сегодня поговорим про работу с заблокированными задачами. Если задача заблокирована, она занимает больше времени, что увеличивает метрики Time to market и Lead time, снижает пропускную способность команды и в целом увеличивает время доставки до клиента.
Как анализировать заблокированные задачи?
1.Начните с указания причины блокировки. Если вы используете Jira, при блокировке задачи (когда добавляете флаг) всегда указывайте причину: блокировка другой командой, отсутствие ресурсов или технические ограничения (причины могут быть разные). Главное прийти к "jira гигиене", всегда пишем причину блокировки, обсудите это с командой на ретро, зафиксируйте в документации.
2.Когда команда научилась всегда ставить причину блокировок, надо проанализировать сколько блокировок у вас возникает в единицу времени (например месяц), это позволит понять, а есть ли у вас проблема с заблокированными задачами, может вы супер крутые и ничего у вас не блокируется.👍
3.Если проблема подтверждена, классифицируйте блокировки и найдите "низко висящие фрукты" — проблемы, которые можно решить быстро. Например, если вас часто блокирует соседняя команда, соберите факты (количество блокировок) и обсудите с ними, как избежать этого.
4.Регулярно обозревайте заблокированные задачи. Лучше всего делать это на отдельной встрече (например, на обзоре потока или метрик), но можно начать с дейли команды, выделяя заблокированные задачи и решая проблемы всей командой.
5.Автоматизируйте отчет, который собирает все заблокированные задачи и на основе ИИ (просто предложение) классифицирует причины блокировок. 😎
6.Стремитесь к процессу доставки, при котором задачи не блокируются, но это, похоже, из идеального мира.
Давайте представим, что у вас уже зрелые команды: отличная визуализация, настроены WIP лимиты, написаны DOR/DOD/AC на каждом этапе производства.
Как еще можно ускорить доставку ценности?
Сегодня поговорим про работу с заблокированными задачами. Если задача заблокирована, она занимает больше времени, что увеличивает метрики Time to market и Lead time, снижает пропускную способность команды и в целом увеличивает время доставки до клиента.
Как анализировать заблокированные задачи?
1.Начните с указания причины блокировки. Если вы используете Jira, при блокировке задачи (когда добавляете флаг) всегда указывайте причину: блокировка другой командой, отсутствие ресурсов или технические ограничения (причины могут быть разные). Главное прийти к "jira гигиене", всегда пишем причину блокировки, обсудите это с командой на ретро, зафиксируйте в документации.
2.Когда команда научилась всегда ставить причину блокировок, надо проанализировать сколько блокировок у вас возникает в единицу времени (например месяц), это позволит понять, а есть ли у вас проблема с заблокированными задачами, может вы супер крутые и ничего у вас не блокируется.
3.Если проблема подтверждена, классифицируйте блокировки и найдите "низко висящие фрукты" — проблемы, которые можно решить быстро. Например, если вас часто блокирует соседняя команда, соберите факты (количество блокировок) и обсудите с ними, как избежать этого.
4.Регулярно обозревайте заблокированные задачи. Лучше всего делать это на отдельной встрече (например, на обзоре потока или метрик), но можно начать с дейли команды, выделяя заблокированные задачи и решая проблемы всей командой.
5.Автоматизируйте отчет, который собирает все заблокированные задачи и на основе ИИ (просто предложение) классифицирует причины блокировок. 😎
6.Стремитесь к процессу доставки, при котором задачи не блокируются, но это, похоже, из идеального мира.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍9❤3🔥1
Всем успешной доставки! До нового года осталось 25 дней, и многие, вероятно, начинают подводить итоги, для этого как раз есть одна полезная практика - ретроспектива 😎
Ретроспектива - это метод анализа и оценки завершённых процессов или проектов, который помогает командам осмыслить пройденный путь, выявить успешные моменты, а так же области для улучшения.
Виды ретроспектив:
Ретроспектива по завершении проекта: Проводится после завершения проекта для оценки его результатов и выявления успешных и проблемных аспектов
Итерационная ретроспектива: Используется для анализа завершенной итерации с целью улучшения будущих итераций.
OKR ретроспектива: Проводится для анализа и оценки результатов работы команды или организации в рамках метода OKR за определенный период, например за квартал.
Тематическая или фокусная ретроспектива: Сосредотачивается на конкретной теме, проблеме или аспекте работы команды, например разбор долгой фичи, которую вы делали больше чем планировали.
Зачем проводить ретроспективу:
Повышение эффективности: Выявление проблем и областей для улучшения позволяет сделать процессы более эффективными.
Обучение и развитие: Позволяет команде учиться на собственных ошибках и достигнутых успехах.
Оптимизация процессов: Помогает выявить неэффективные практики и заменить их более продуктивными.
Многие команды проводят ретроспективы онлайн, и большинство онлайн-досок предлагает шаблоны для этого, например, такой в Unidraw
#retro #unidraw #команда
Ретроспектива - это метод анализа и оценки завершённых процессов или проектов, который помогает командам осмыслить пройденный путь, выявить успешные моменты, а так же области для улучшения.
Виды ретроспектив:
Ретроспектива по завершении проекта: Проводится после завершения проекта для оценки его результатов и выявления успешных и проблемных аспектов
Итерационная ретроспектива: Используется для анализа завершенной итерации с целью улучшения будущих итераций.
OKR ретроспектива: Проводится для анализа и оценки результатов работы команды или организации в рамках метода OKR за определенный период, например за квартал.
Тематическая или фокусная ретроспектива: Сосредотачивается на конкретной теме, проблеме или аспекте работы команды, например разбор долгой фичи, которую вы делали больше чем планировали.
Зачем проводить ретроспективу:
Повышение эффективности: Выявление проблем и областей для улучшения позволяет сделать процессы более эффективными.
Обучение и развитие: Позволяет команде учиться на собственных ошибках и достигнутых успехах.
Оптимизация процессов: Помогает выявить неэффективные практики и заменить их более продуктивными.
Многие команды проводят ретроспективы онлайн, и большинство онлайн-досок предлагает шаблоны для этого, например, такой в Unidraw
#retro #unidraw #команда
🔥7❤1👍1
Всем успешной доставки!
Agile мертв🆘 Недавно в Linkedin (нужен VPN для доступа) появилось интересное обсуждение, которое собрало почти 72 тысячи лайков и 5 тысяч комментариев.
Основная идея поста заключается в том, что Agile мертв по следующим причинам:
1. Agile стал чек-листом вместо философии.
2. Масштабирование происходило без изменения культуры.
3. Ориентация на быструю реализацию проектов заменяет фокус на качестве и реальной ценности.
4. Сопротивление со стороны руководства.
5. Agile превратился в продукт.
6. Игнорирование человеческого фактора привело к выгоранию и снижению вовлеченности.
Некоторые тезисы кажутся справедливыми, но утверждение "Agile мертв" вызывает у меня сомнения.
Как дела обстоят в вашей компании или команде? Agile у вас мертв или все же жив? 😎
#agile #scrum #kanban
Agile мертв
Основная идея поста заключается в том, что Agile мертв по следующим причинам:
1. Agile стал чек-листом вместо философии.
2. Масштабирование происходило без изменения культуры.
3. Ориентация на быструю реализацию проектов заменяет фокус на качестве и реальной ценности.
4. Сопротивление со стороны руководства.
5. Agile превратился в продукт.
6. Игнорирование человеческого фактора привело к выгоранию и снижению вовлеченности.
Некоторые тезисы кажутся справедливыми, но утверждение "Agile мертв" вызывает у меня сомнения.
Как дела обстоят в вашей компании или команде? Agile у вас мертв или все же жив? 😎
#agile #scrum #kanban
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4🤔2❤1
This media is not supported in your browser
VIEW IN TELEGRAM
Не обижайте ДМов 🤣
мем украл из канала https://news.1rj.ru/str/OgileKambanScram
мем украл из канала https://news.1rj.ru/str/OgileKambanScram
😁5❤2👍1
Всем успешной доставки!
После подведения итогов разумно подумать о планах на следующий год, для чего поможет методология 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 #цель
После подведения итогов разумно подумать о планах на следующий год, для чего поможет методология 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 #цель
👍4🔥2❤1
Всем успешной доставки!
Сегодня расскажу, как мы используем Канбан в командах. Я работаю с 12 продуктовыми командами, и в каждой из них применяются различные практики Канбан, от "визуализации" до "улучшайте совместно, развивайтесь экспериментально".
Для визуализации этапа delivery мы используем ЗВК (запрос в команду), а для discovery — продуктовые эпики. Эти сущности часто расположены в разных проектам Jira: по продуктовым эпикам измеряем TTM, а по ЗВК — Lead Time и другие метрики команды.
У нас описаны DOR/DOD/AC на каждом этапе, проводятся регулярные встречи по обзору процессных метрик и ретро команды. Мы находимся в постоянном состоянии улучшения наших процессов.
Для всех этих практик у нас есть полезный инструмент — practice map, представляющий набор лучших практик и инструментов для команд, которые позволяют повысить скорость и качество.
Каждая практика решает конкретную проблему, например, если у вас много задач и низкая пропускная способность, внедрите WIP лимиты.
Новые практики периодически появляются после внедрения их в команды и получения результатов.
Единственное, что постоянное - это изменение 😎 Не сдавайтесь и продолжайте внедрять изменения 🚀
#practicemap #dor #dod #ac
Сегодня расскажу, как мы используем Канбан в командах. Я работаю с 12 продуктовыми командами, и в каждой из них применяются различные практики Канбан, от "визуализации" до "улучшайте совместно, развивайтесь экспериментально".
Для визуализации этапа delivery мы используем ЗВК (запрос в команду), а для discovery — продуктовые эпики. Эти сущности часто расположены в разных проектам Jira: по продуктовым эпикам измеряем TTM, а по ЗВК — Lead Time и другие метрики команды.
У нас описаны DOR/DOD/AC на каждом этапе, проводятся регулярные встречи по обзору процессных метрик и ретро команды. Мы находимся в постоянном состоянии улучшения наших процессов.
Для всех этих практик у нас есть полезный инструмент — practice map, представляющий набор лучших практик и инструментов для команд, которые позволяют повысить скорость и качество.
Каждая практика решает конкретную проблему, например, если у вас много задач и низкая пропускная способность, внедрите WIP лимиты.
Новые практики периодически появляются после внедрения их в команды и получения результатов.
Единственное, что постоянное - это изменение 😎 Не сдавайтесь и продолжайте внедрять изменения 🚀
#practicemap #dor #dod #ac
👍6🔥3❤1
Всем успешной доставки!
Год почти завершился, и я хочу подвести итоги канала, скорее для себя. Ранее я делал промежуточный отчет за два месяца работы канала , а теперь — итог за 2024 год.
Итоги
1.На 28.12 146 подписчиков (максимально было 148). Хотелось конечно видеть цифру 200, но мне кажется это тоже хороший результат.
2.С момента создания канала (13.08) опубликовано 25 постов, что в среднем составляет 5 постов в месяц; пока сложно сказать, много это или мало.
3.Максимальное количество просмотров одного поста — 377.
4.0 купленной рекламы (пока не знаю как и где это делать).
Планы на 1 квартал 2025:
1.Достигнуть 200 подписчиков.
2.Сохранять план в 5 постов в месяц.
3.Запустить рекламу канала
Прикреплено фото, которое символизирует состояние на конец года🔥
Год почти завершился, и я хочу подвести итоги канала, скорее для себя. Ранее я делал промежуточный отчет за два месяца работы канала , а теперь — итог за 2024 год.
Итоги
1.На 28.12 146 подписчиков (максимально было 148). Хотелось конечно видеть цифру 200, но мне кажется это тоже хороший результат.
2.С момента создания канала (13.08) опубликовано 25 постов, что в среднем составляет 5 постов в месяц; пока сложно сказать, много это или мало.
3.Максимальное количество просмотров одного поста — 377.
4.0 купленной рекламы (пока не знаю как и где это делать).
Планы на 1 квартал 2025:
1.Достигнуть 200 подписчиков.
2.Сохранять план в 5 постов в месяц.
3.Запустить рекламу канала
Прикреплено фото, которое символизирует состояние на конец года
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥5👍3🎉1🤗1
KMM практики (2).jpg
5.5 MB
Всем успешной доставки!
Салаты закончились, и я решил рассказать вам о Kanban Maturity Model (KMM).
Даже будет правильней написать такKanban Maturity Model - это прагматичное и прикладное руководство, основанное на данных, для определения зрелости организаций.
Канбан сообществом было проанализировано порядка 300 организаций, что позволило выявить общие шаги на разных этапах развития организации.
Всего таких шагов 7, от 0 до 6, сегодня поговорим про первые три шага (если вы считаете, что сейчас находитесь на шаге ML3, то я бы с вами поспорил 😎):
ML0 - Рассеянный - Боязнь правил и регламентов, стремление справиться с личной нагрузкой.
ML1 - Командно-ориентированный - Фокус на командном результате, зарождение командной культуры, все делается командами вокруг команд.
ML2 - Клиенто-ориентированный - Поставляем задачи клиенту вовремя, но не всегда, то что нужно клиенту, появление end-to-end процесса.
На каждом шаге применяются определенные практики (см. картинку к посту), но главное тут, что наличие всех практик на уровне, не гарантирует переход на следующий уровень, нужно осознвоать зачем вам этот переход и какие выгоды он принесет команде или компании.
Переход на следующий уровень, это получение outcomes этого уровня.
Если вам известны примеры компаний в России на уровне 4 и выше, напишите в комментариях — будет интересно!
#kmm #kanban #уровеньзрелости
Салаты закончились, и я решил рассказать вам о Kanban Maturity Model (KMM).
Даже будет правильней написать так
Канбан сообществом было проанализировано порядка 300 организаций, что позволило выявить общие шаги на разных этапах развития организации.
Всего таких шагов 7, от 0 до 6, сегодня поговорим про первые три шага (если вы считаете, что сейчас находитесь на шаге ML3, то я бы с вами поспорил 😎):
ML0 - Рассеянный - Боязнь правил и регламентов, стремление справиться с личной нагрузкой.
ML1 - Командно-ориентированный - Фокус на командном результате, зарождение командной культуры, все делается командами вокруг команд.
ML2 - Клиенто-ориентированный - Поставляем задачи клиенту вовремя, но не всегда, то что нужно клиенту, появление end-to-end процесса.
На каждом шаге применяются определенные практики (см. картинку к посту), но главное тут, что наличие всех практик на уровне, не гарантирует переход на следующий уровень, нужно осознвоать зачем вам этот переход и какие выгоды он принесет команде или компании.
Переход на следующий уровень, это получение outcomes этого уровня.
Если вам известны примеры компаний в России на уровне 4 и выше, напишите в комментариях — будет интересно!
#kmm #kanban #уровеньзрелости
👍7❤4
Всем успешной и быстрой доставки!
Я написал много постов о метриках, и описал практики работы с этими метриками. Однако я упустил важный аспект — Jira гигиену.
Jira гигиена - это определенные действия, которые помогают вам поддерживать порядок на вашей доске в таск трекере Jira 😂.Она включает в себя набор действий и рекомендаций, направленных на поддержание актуальности информации. Соответственно если у вас любой другой таск-трекер, называться будет по другому, но работает в любом.
Ключевой аспект Jira гигиены — регулярное обновление статусов задач, что обеспечивает прозрачность процесса и позволяет собирать точные метрики (метрики собираются по времени нахождения задачи в каждом статусе). Если статусы не обновлять, метрики будут искажены, что может привести к неверным выводам. Часто команды забывают или не хотят обновлять статусы. Для решения этой проблемы можно:
1.На дейли начинать с проверки актуальности статусов, предварительно объяснив команде важность этого процесса.
2.Создать бота, который будет подсвечивать задачи, долго находящиеся в одном статусе.
3.Настроить автоматизацию которая будет переводить задачу из одного статуса в другой по определенному событию.
4.Периодически проверять наличие забытых задач, которые давно выполнены, но не закрыты в трекере.
Если это не помогает, то можно вызвать стресс у команды: тимлид сообщает о жалобах бизнеса на "долгую разработку", команда утверждает, что работает быстро. Показываем метрики (например, Lead Time) по "забытой задаче", команда, скорее всего, признает, что просто забыла обновить статус. На этом примере подсвечиваем еще раз зачем держать задачи в актуальных статусах.
Поддержание Jira гигиены способствует повышению эффективности работы команды, улучшению коммуникации и снижению вероятности ошибок в подсчете метрик.
Перед тем как внедрять различные метрики и практики, надо добиться регулярного обновления статусов у задач.🤟
#jiraгигиена #jira #taskmanager
Я написал много постов о метриках, и описал практики работы с этими метриками. Однако я упустил важный аспект — Jira гигиену.
Jira гигиена - это определенные действия, которые помогают вам поддерживать порядок на вашей доске в таск трекере Jira 😂.Она включает в себя набор действий и рекомендаций, направленных на поддержание актуальности информации. Соответственно если у вас любой другой таск-трекер, называться будет по другому, но работает в любом.
Ключевой аспект Jira гигиены — регулярное обновление статусов задач, что обеспечивает прозрачность процесса и позволяет собирать точные метрики (метрики собираются по времени нахождения задачи в каждом статусе). Если статусы не обновлять, метрики будут искажены, что может привести к неверным выводам. Часто команды забывают или не хотят обновлять статусы. Для решения этой проблемы можно:
1.На дейли начинать с проверки актуальности статусов, предварительно объяснив команде важность этого процесса.
2.Создать бота, который будет подсвечивать задачи, долго находящиеся в одном статусе.
3.Настроить автоматизацию которая будет переводить задачу из одного статуса в другой по определенному событию.
4.Периодически проверять наличие забытых задач, которые давно выполнены, но не закрыты в трекере.
Если это не помогает, то можно вызвать стресс у команды: тимлид сообщает о жалобах бизнеса на "долгую разработку", команда утверждает, что работает быстро. Показываем метрики (например, Lead Time) по "забытой задаче", команда, скорее всего, признает, что просто забыла обновить статус. На этом примере подсвечиваем еще раз зачем держать задачи в актуальных статусах.
Поддержание Jira гигиены способствует повышению эффективности работы команды, улучшению коммуникации и снижению вероятности ошибок в подсчете метрик.
Перед тем как внедрять различные метрики и практики, надо добиться регулярного обновления статусов у задач.🤟
#jiraгигиена #jira #taskmanager
👍5❤2✍1