🚀 Всем успешной доставки!
Этап 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

Самая недооценённая метрика: "Blocked Time" ⏱️⛔️
Всем успешной доставки, на связи рубрика "Метрика недели"

Сегодня пишу про "более зрелую" метрику Blocked time, почему "более зрелую"?
Почему ее называют «более зрелой метрикой»?
Команды, которые начинают её считать, уже вышли за рамки базовых показателей вроде Lead Time или WIP.
Blocked Time требует осознанного анализа: что именно мешает нам двигаться?
Она не только показывает факт задержки, но и помогает вскрывать системные проблемы взаимодействия.

Blocked time - это время, которое задача была «заблокирована» ⛔️.
То есть команда не могла продвигать её дальше из-за внешних или внутренних зависимостей:
-ждём ревью у другой команды,
-не пришли данные от заказчика,
-согласование у юристов.
-фриз на релиз

🔥 Какую проблему решает?
-Помогает отделить «мы работали долго» от «мы не могли работать, потому что ждали».
-Делает узкие места прозрачными: видно, что тестирование ждёт доступ к стенду по 5 дней, или заказчик согласовывает требования неделями.
-Даёт аргументы на встречах с заказчиком и внутри компании: «Сами мы сделали за 2 дня, но 10 дней ушло на ожидание согласования».

📈 Использование Blocked Time в динамике:
Если показатель системно высокий → проблема в процессе (надо оптимизировать взаимодействие).
Если блокеры случайные и редкие → нормальная рабочая ситуация, главное фиксировать и обсуждать.

📝 Чек-лист: стоит считать Blocked Time, если…
-у вас уже есть базовые метрики (Lead Time, WIP),
-ощущаете, что «задачи буксуют», но непонятно где,
-хотите объяснять сроки на языке данных, а не эмоций.

А у вас в команде считается Blocked Time? Делитесь опытом 👇

🔧 Инструмент недели: Jira Metrics Plugin - Analytics & Insights
Если вы работаете с Jira и хотите глубже понимать, как движутся задачи в команде, это расширение может стать отличным помощником.

📊 Что это такое?
Jira Metrics Plugin - это расширение для Chrome, которое добавляет на вашу доску в Jira кнопку «Analyze Metrics».
Нажав на нее, вы получаете доступ к визуализациям ключевых процессных метрик:
-Гистограмма времени выполнения задач (Cycle Time) с анализом по процентилям;
-Отчет по пропускной способности (Throughput) с трендами и паттернами;
-Диаграмма старения задач (Aging Chart) для текущих задач в работе;
-Кумулятивная диаграмма потока (CFD) для анализа стабильности процесса;

⚙️ Простота установки и использования
-Быстрая установка как расширения Chrome;
-Не требует настройки сервера;
-Работает с Jira Cloud и Jira Server;
-Автоматически интегрируется с вашими досками в Jira.

🎯 Для кого это полезно?
-Project managerам/Delivery managerам, стремящихся к принятию решений на основе данных;
-Тимлидам, желающих оптимизировать рабочий процесс;
-Командам/команиям, фокусирующихся на непрерывном улучшении процессов.
-Всем кто использует data-driven подход 😎

✅ Преимущества плагина
-Помогает выявлять узкие места в процессе;
-Улучшает прогнозируемость сроков выполнения задач;
-Экономит время на ручной сбор отчетов.
-Бесплатная версия
У ребят есть канал в телеграм, где можно задавать вопросы по плагину
#jira #метрики #plugin

🔧 Инструмент недели: Jira Metrics Plugin - Analytics & Insights
Если вы работаете с Jira и хотите глубже понимать, как движутся задачи в команде, это расширение может стать отличным помощником.

📊 Что это такое?
Jira Metrics Plugin - это расширение для Chrome, которое добавляет на вашу доску в Jira кнопку «Analyze Metrics».
Нажав на нее, вы получаете доступ к визуализациям ключевых процессных метрик:
-Гистограмма времени выполнения задач (Cycle Time) с анализом по процентилям;
-Отчет по пропускной способности (Throughput) с трендами и паттернами;
-Диаграмма старения задач (Aging Chart) для текущих задач в работе;
-Кумулятивная диаграмма потока (CFD) для анализа стабильности процесса;

⚙️ Простота установки и использования
-Быстрая установка как расширения Chrome;
-Не требует настройки сервера;
-Работает с Jira Cloud и Jira Server;
-Автоматически интегрируется с вашими досками в Jira.

🎯 Для кого это полезно?
-Project managerам/Delivery managerам, стремящихся к принятию решений на основе данных;
-Тимлидам, желающих оптимизировать рабочий процесс;
-Командам/команиям, фокусирующихся на непрерывном улучшении процессов.
-Всем кто использует data-driven подход 😎

✅ Преимущества плагина
-Помогает выявлять узкие места в процессе;
-Улучшает прогнозируемость сроков выполнения задач;
-Экономит время на ручной сбор отчетов.
-Бесплатная версия
У ребят есть канал в телеграм, где можно задавать вопросы по плагину
#jira #метрики #plugin

🎯 Метрика недели Lead Time
Когда мы обсуждаем метрики, хочется напомнить:
📌 метрики - это не инструмент давления на команду, а возможность улучшать процессы основываясь на фактах.

🕐 Что такое Lead Time?
Lead Time - это время от момента принятия обязательств до момента завершения задачи.
Говоря проще: задача перешла в колонку “In Progress” (или другой этап, где команда уже взялась за дело) - и пошёл отсчёт.
Завершили (например, “Done” или “Released”) - таймер остановился.
Это честное измерение: сколько времени заняло выполнение задачи после того, как вы сказали "мы это сделаем".

📊 Как считать Lead time ?
Хорошая практика - смотреть не только на среднее, а на перцентили.
Например:
50-й (медианный) перцентиль покажет, сколько занимает "типичная" задача;
85-й и 95-й — как обстоят дела с «хвостом» (долгими задачами);
Это помогает понять разброс и стабильность процесса, а не просто «в среднем по больнице».

📈 Зачем считать Lead Time?
-Чтобы понимать, насколько быстро команда доставляет ценность;
-Улучшать прогнозируемость и делать более реалистичные планы;
-Выявлять узкие места и неоптимальные этапы в процессе;
-Повышать надежность сроков: если вы знаете, как ведёт себя 85-й перцентиль, вы уверенно можете говорить о дедлайнах.

⚠️ Важное уточнение
Если вы хотите снизить Lead Time, не забывайте про пропускную способность (Throughput).Сократить время выполнения одной задачи можно, но если при этом падает общее количество завершённых задач - значит, мы просто «перераспределили» усилия, а не улучшили процесс.
Баланс важен: быстрее ≠ меньше.

🧩 Как внедрить Lead Time в практике?
-Визуализируйте процесс от момента, когда задача становится обязательством;
-Отмечайте даты входа и выхода задач;
-Собирайте данные, стройте графики, считайте перцентили;
-Обсуждайте это на ретро, а лучше заведите отдельную встречу по обзору метрик: где вы отвечаете себе на вопрос "почему зависают задачи, и что с этим делать?"

💬 А вы считаете Lead Time? Какой у вас 85-й перцентиль?
#метрики #leadtime

🚀 Как превратить ваш тасктрекер в помойку? 😳

Типичные ошибки:
1.100500 статусов в workflow
— «В работе», «Почти в работе», «Ждет Саши», «Проверить у Марьиванны», «На паузе»...
— Чем плохо? Команда тратит больше времени на перетаскивание карточек, чем на работу.

2.Задачи без DOR/DOD
— DOR (Definition of Ready): Когда задача готова к работе.
— DOD (Definition of Done): Когда задача считается завершенной.
— Чем плохо? Разработчики берут в работу сырые задачи, а тестировщики не понимают, что проверять.

3.«Забытые» карточки годами в бэклоге
— Задача «Обновить логотип», созданная в 2020-м, до сих пор висит в бэклоге.
— Чем плохо? Бэклог превращается в свалку, а приоритеты теряются.

Чеклист: как навести порядок в вашем тасктрекере
Шаг 1: Аудит
— Удалите дубликаты задач.
— Закройте всё, что неактуально (если страшно — переместите в архив).
Шаг 2: Упростите workflow
— Оставьте 3-5 ключевых статусов которые полностью отражают ваш процесс производства (например: To Do, In Progress, Review, Done).
— Удалите лишние переходы между статусами.
Шаг 3: Внедрите DOR/DOD
— Пример DOR: «Задача имеет ТЗ, оценку и приоритет».
— Пример DOD: «Код проверен, тесты пройдены, документация обновлена».
Шаг 4: Разберите бэклог
— Удалите задачи старше 6 месяцев (кажется если задачу не делают больше 6 месяцев, то она "протухла" и делать ее уже не будут).
Шаг 5: Настройте автоматизацию
— Уведомления для заблокированных задач (например: «Висит в Review > 3 дней», не меняла статуса n дней).
Шаг 6: Запланируйте регулярный аудит
— Раз в месяц(определите эту периодичность самостоятельно) удаляйте мусор и проверяйте актуальность DOR/DOD.

Что вы получите?
✔️ Команда тратит на 30% меньше времени на «администрирование» задач.
✔️ Задачи закрываются быстрее, потому что все понимают, что делать.
✔️ Бэклог больше не вызывает панических атак.🙂

А ваш тасктрекер уже идеален? Делитесь лайфхаками в комментариях! 💬
#jira #jiraгигиена #метрики #workflow

🎯 Метрика недели: Пропускная способность (Throughput)
Давайте разберёмся, что такое throughput и зачем его вообще считать.

Что это такое?
Throughput показывает, сколько задач команда завершает за единицу времени (обычно за месяц). Это может быть количество пользовательских историй, багов, фич - в зависимости от того, что вы считаете завершённым.
📊 Например:
- 25 задач за месяц → throughput = 25
- 6 багфиксов и 4 фичи → throughput = 10 (или можно разделять по типам задач - это даёт дополнительную глубину анализа)

Зачем считать?
📈 Оценка скорости команды - понимаем, насколько стабильно двигаемся.
🔍 Анализ трендов - замечаем, когда темп падает или растёт.
📅 Прогнозирование сроков - throughput помогает понять, сколько времени займёт бэклог.
⚖️ Балансировка нагрузки - при падении throughput ищем причины: перегруз, блокеры, неоптимальные процессы.
📂 Глубокий анализ - можно смотреть throughput отдельно по типам задач, чтобы увидеть перекосы (например, много багов, мало фич).
🤝 Прозрачность - метрика легко объясняется и хорошо работает на демонстрациях.

Важно помнить
✅ Это не метрика продуктивности отдельного человека. Это командная метрика.
✅ Рост throughput - это не цель сама по себе. Главное стабильность и предсказуемость.
✅ Следите, чтобы при снижении Lead Time не пострадал throughput - важно сохранять баланс.

Как начать считать?
- Определите, какие задачи считаются «завершёнными» (например, в статусе Done).
- Считайте завершённые задачи за месяц (чтобы сгладить колебания).
- Смотрите динамику по неделям/месяцам.
- Разделите throughput по типам задач: баги, фичи, техдолг - это даст более точные инсайты.
- Используйте визуализацию (графики, диаграммы, трекеры).

📌 Через месяц можно увидеть первую динамику. А дальше уже строить прогнозы и находить точки для улучшений.
#метрики #throughput