Всем успешной доставки! Ранее я обсуждал два этапа производства: discovery и delivery. Сегодня сосредоточимся на этапе Discovery 🪩 и его важности.
Discovery представляет собой процесс выявления потребностей клиента, который является ключевым моментом.
Необходимо понять, для кого вы создаете продукт, какие у клиентов есть болевые точки и как ваш продукт может их решить.

Представьте, что вы разрабатываете фичу пол года, тратите ресурсы (деньги) аналитика, дизайнера, разработки и тестирования, а после релиза вашей фичей ни кто не пользуется или пользуется меньше клиентов чем вы планировали, выглядит не очень классно?

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

Есть интересная методология Triple diamond 🚀, которая ясно описывает, как продуктовая команда должна действовать на этапе Discovery:
1.Команда получает сигналы о возникшей проблеме - источником может быть: обращение в поддержку, аналитика продукта, интервью клиентов, анализ конкурентов и трендов, различные исследования (NPS, CSAT)
2.Формулирует суть проблемы
3.Проверяет, что проблема действительно есть
4.Приоритизирует проблему среди уже существующих проблем
5.Генерирует возможные решения этой проблемы
6.Валидирует решения проблемы - различные исследования, опросы, mvp, UX тестирование, A/B тесты

Только после этого начинается этап Delivery 🚚, где осуществляется разработка и внедрение выбранного решения для клиентов.

Чеклист, чтобы проверить, эффективен ли ваш процесс Discovery:
1.Решаете проблемы клиентов, а не выполняете задачи просто ради задач
2.Все решения принимаются на основе полученных данных, а не интуиции 🤣
3.Этапы discovery — delivery у вас непрерывны

Резюмирую: чтобы этот процесс функционировал эффективно и без сбоев, продуктовой команде необходимо находиться в постоянном цикле «discovery — delivery». Этот цикл способствует экономии ресурсов и предотвращает внедрение некорректных решений на клиентов.

Всем успешной доставки! Давайте обсудим Kanban и его роль в доставке ценности клиенту. Существует множество мифов о Kanban, включая:
-Это конвейер
-Он подходит только для команд поддержки
-Это всего лишь Kanban-доска.

В сети можно встретить различные определения Kanban, для себя выбрал следующее:
Kanban метод - способ улучшения производственных процессов, предусматривающих значительное использование умственного труда.

Как Kanban помогает в доставке ценности? Соблюдая основные принципы и практики Kanban, можно организовать полный процесс (discovery&delivery) доставки ценности, сосредоточиться на важных задачах и непрерывно улучшать процесс:

Принципы:
-Начните с того, что сейчас есть - уважайте результаты которые есть сейчас
-Договоритесь об эволюционном развитие - не делайте сразу много изменений
-Поощряйте проявление лидерства - терпимость к ошибкам

Практики:
-Визуализация процесса производства - отображайте работу и ее поток
-Ограничение количества незавершенной работы (wip лимиты) - перестаньте начинать, начните заканчивать
-Управление потоком - управляйте потоком, чтобы он был плавным и предсказуемым
-Делайте правила явными - создавайте согласованные правила работы, видимые для всех участников
-Использовать петли обратной связи - встречи по обзору вашего сервиса
-Совместное развитие на основании моделей и научного подхода - изменения основанные на гипотезах, проводите контролируемые эксперименты

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

Основной посыл который хочется донести в этом посте: рассматривайте для себя Kanban как набор инструментов для анализа и улучшения процессов!

Если вы еще не перешли на Kanban, то это фатальная ошибка 🤣

При подготовке поста использовал:
Книга Алексея Пименова Канбан Метод. Базовая практика
Официальное руководство по Канбан-методу

Всем успешной доставки! Продолжая тему Kanban и доставку ценности, хочу поделиться полезными ссылками на материалы, каналы и конференции, связанные с Kanban.

Конференции, где можно послушать про Kanban/Agile/Прости господи Scrum 🤔
Flow Days  проходит с 2019 года. В прошлом году была отдельная секция про Kanban, следующая конференция состоится 13 сентября 2024.✅
Agile Days  проходит с 2008 года, предлагает свежие кейсы, мини-тренинги и возможность сетевого общения с экспертами.✅

Телеграм-каналы о Kanban и смежных темах:
Kanban Talks самый популярный канал про Kanban в СНГ
Алексей Пименов канал о Kanban и внедрении изменений.
T-Process Improvement про внедрение изменений от Т-Банка
Kanban Events анонсы платных и бесплатных Канбан-событий

Компании, проводящие обучение Kanban:
Neogenda
Scrumtrek

Что еще полезного можно было добавить в пост?

Всем успешной доставки!
🆘Всю неделю буду в командировке и трудно будет писать новые посты.
Но я уже составил список следующих тем:

1.визуализация, wip лимиты и буферные статусы
2. Dor/Dod/Ac
3. 1 на 1 и ретро команды

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

Всем успешной доставки! Сегодня обсудим практики Kanban: визуализацию, WIP-лимиты и буферные статусы.
Более детально про каждую практику:

1.Визуализация - помогает команде/заказчику видеть текущий статус работы.
Отображает нагрузку - команды могут увидеть, где возникают узкие места и как распределена работа между членами команды.
Повышает прозрачность - все участники команды/заказчики могут легко отслеживать прогресс выполнения любой задачи.

2.Wip лимиты -это ограничения на количество задач в каждой стадии рабочего процесса.
Они снижают многозадачность и позволяют команде сосредоточиться на завершении текущей работы.
Wip лимиты бывают:
-персональные
-на рабочий процесс CONWIP
-на команду
-на агрегированную доску сервиса
Запомните: "Перестаньте начинать, начните заканчивать."

3.Буферные статусы - обозначают промежуточные состояния задач (например, ожидание тестирования). Они помогают управлять переходами между стадиями (например, от завершения разработки к тестированию).
Если кто-то закончил работу-это не значит, что кто-то другой начал ее.

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

После визуализации определите WIP-лимиты. Начните с персональных лимитов для каждого участника, а по мере повышения зрелости команды пересмотрите их.

Вроде получилось кратко, не забывайте, визуализацию, wip лимиты и буферные статусы можно пересматривать вместе с повышение зрелости команды!🏐

Всем успешной доставки! Вы визуализировали свою работу, внедрили wip-лимиты, но все еще бывают задачи, которые требуют уточнение после точки принятия обязательств? Тогда этот пост для вас 😏, обсудим сегодня Definition of Ready (DoR), Acceptance Criteria (AC), Definition of done (DoD).

Начнем с определений:
1.DoR - это набор критериев, которые должны быть выполнены для для готовности задачи к работе. Он служит своеобразным "фильтром": если задача не соответствует DoR, команда может отказаться брать ее в работу
Зачем нужен DoR - не брать в работу не проработанные задачи, позволяет однозначно понимать, что нужно сделать команде.

2.АС - это критерии приемки конкретной задачи(этим отличается от Dod), которые определяют ожидаемое поведение и функционал, что дает представление о том, какие результаты должны быть достигнуты.
Зачем нужны AC - они помогают удостовериться, что конечный продукт соответствует требованиям заказчика и ожиданиям пользователей

3.DoD - это набор критериев, которым должна соответствовать задача, чтобы считаться завершенной, отличается от АС тем, что DoD одинаков для всех задач и в него включаются какие-то общие правила, например выполненное тестирование, документирование, код-ревью.
Зачем нужен DoD - позволяет команде повысить прозрачность и минимизировать риски незавершенной или некачественной работы.

Что нужно, чтобы внедрить DoR, DoD, AC?

1.Вовлеченность команды - организуйте совместные встречи с участниками команды (разработчики, тестировщики, аналитики и т.д.) для обсуждения и согласования подходящих критериев для DoD, DoR, AC.

2.Сформулируйте критерии - на основании обсуждений составьте списки для DoD и DoR, учитывающие практики и процессы вашей команды. Убедитесь, что формулировки критериев ясны и понятны всем.

3.Зафиксируйте договоренности - после согласования критериев, утвердите DoD, DoR и AC, зафиксировав их в виде документа или на доске (например в jira можно вынести их отдельным свимлейном).

4.Внедряйте в работу - договоритесь со всем участниками команды и заказчиками, что теперь без этих критериев вы не берете задачи в работу.

5.Регулярный пересмотр и улучшение - собирайте обратную связь от команды о том, насколько эффективно применяются DoD, DoR и AC, например на ретро команды.

Поздравляю, вы и ваша команда великолепны 🚀
#dor #dod #ac #delivery #discovery #jira

Всем успешной доставки! Сегодня обсудим практики, не касающиеся напрямую доставки ценности, но влияющие на команду: 1:1 встречи и ретроспектива команды.

Раскрою каждую практику отдельно:

1.1:1- индивидуальные встречи между тимлидом (или любым менеджером) и членом команды для обсуждения различных тем, не обязательно связанных с работой.
Зачем нужно тимлиду: позволяет предоставить сотруднику конструктивную обратную связь, наладить доверительные отношения в команде.
Зачем нужно сотруднику: важно понимать как оценивается его работа, как и куда он может расти как профессионал (например составить ИПР), рассказать про свои проблемы, вынести какие-то предложения по своей работе.
Встреча должна быть регулярной и частой, например раз в 1 или 2 недели, обязательной с повесткой и документированием всех договоренностей

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

Обе встречи полезны для раннего выявления проблем в команде или у конкретного человека, что поможет избежать неожиданных увольнений 😎
#ретро #1на1 #команда

🆘Оценка задач в story pointах/часах/попугаях не нужна, всем успешной доставки! Давайте поговорим про оценку задач и почему она не работает 🔥
Оценка - это прогноз ваших работ, производственные метрики такие как 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 #оценка #прогноз #метрики

Всем успешной доставки!

Подвожу итог по каналу: в прошлое воскресенье (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 подписчиков и заказать рекламу канала, но пока неясно, где и у кого.

Если есть идеи для новых постов, пишите в комментариях.

Всем успешной доставки!
Несколько постов назад, я писал про Канбан метод.
Если вы планируете его внедрять, вам необходимо использовать подход 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

Всем успешной доставки!
Давайте представим, что у вас уже зрелые команды: отличная визуализация, настроены WIP лимиты, написаны DOR/DOD/AC на каждом этапе производства.
Как еще можно ускорить доставку ценности?
Сегодня поговорим про работу с заблокированными задачами. Если задача заблокирована, она занимает больше времени, что увеличивает метрики Time to market и Lead time, снижает пропускную способность команды и в целом увеличивает время доставки до клиента.

Как анализировать заблокированные задачи?

1.Начните с указания причины блокировки. Если вы используете Jira, при блокировке задачи (когда добавляете флаг) всегда указывайте причину: блокировка другой командой, отсутствие ресурсов или технические ограничения (причины могут быть разные). Главное прийти к "jira гигиене", всегда пишем причину блокировки, обсудите это с командой на ретро, зафиксируйте в документации.

2.Когда команда научилась всегда ставить причину блокировок, надо проанализировать сколько блокировок у вас возникает в единицу времени (например месяц), это позволит понять, а есть ли у вас проблема с заблокированными задачами, может вы супер крутые и ничего у вас не блокируется. 👍

3.Если проблема подтверждена, классифицируйте блокировки и найдите "низко висящие фрукты" — проблемы, которые можно решить быстро. Например, если вас часто блокирует соседняя команда, соберите факты (количество блокировок) и обсудите с ними, как избежать этого.

4.Регулярно обозревайте заблокированные задачи. Лучше всего делать это на отдельной встрече (например, на обзоре потока или метрик), но можно начать с дейли команды, выделяя заблокированные задачи и решая проблемы всей командой.

5.Автоматизируйте отчет, который собирает все заблокированные задачи и на основе ИИ (просто предложение) классифицирует причины блокировок. 😎

6.Стремитесь к процессу доставки, при котором задачи не блокируются, но это, похоже, из идеального мира.