Блокер — это задача, выполнение которой  невозможно или существенно затруднено из-за зависимости от другой задачи, ресурса или внешнего фактора. 

Практика работы с блокерами позволяет уйти от субъективного восприятия проблем к объективному анализу системы. Она помогает ответить на ключевые вопросы:

Как часто возникают проблемы и ккакова их продолжительность?
Главная задача, которую я ставил перед собой, — понять, почему может увеличиваться Lead Time, а также:

— Выявлять причины задержек, анализируя данные, а не полагаясь на догадки;,

— Отслеживать повторяющиеся тенденции в блокировках задач;,

— Формулировать выводы и улучшать процессы на основе объективных данных.

Разделение зависимостей на внутренние и внешние

Блокеры можно разделить на две основные категории по области возникновения:

• Внешние (OUT) —– когда проблемы возникают вне нашей команды (например, зависимостиь от бизнеса, серверов, DevOps и других внешних факторов);.

• Внутренние (IN) —– когда проблемы возникают внутри команды, где взаимодействуют аналитики, дизайнеры и разработчики.

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

• в IN блокер привязан к конкретному типу работ (например, дизайн, аналитика, Android, iOS и т. д.).

• в OUT чаще всего нет четких типов работ, поэтому используются теги (например, DevOps или Бизнес).

Можно было бы завести отдельный список типов блокеров (например, «Ожидание дизайнера», «Ожидание аналитика» и т. д.), но это усложнило бы выбор: список стал бы слишком длинным, а вероятность ошибки увеличилась бы. Система тегов проще и быстрее в использовании, её единственный недостаток — можно забыть поставить тег. Но если регулярно проверять доску с блокерами, то пропущенные теги легко заметить и добавить.

Ещё мы классифицировали блокеры по причинам возникновения зависимости. Сначала выделили пять причин, но по мере работы появлялись всё новые и новые, и сейчас их около 15. Не так много, как, например, в крупных компаниях.

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

Внутренние

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

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

Внешние

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

Как я реализовывал работу с блокерами в нашей команде

Я использовал таск-трекер ClickUp и BI-систему Superset, но в ClickUp нет встроенной поддержки блокеров, поэтому пришлось делать множество обходных решений. Я думаю, они подойдут вам в других таск-трекерах, где нет функции «блокировка карточки».

Первое — это проведение мастер-класса для команды, где я на примерах показывал и рассказывал, для чего нужны блокеры и как они помогут команде отвечать на вопросы: «Почему так долго?», «Какие причины чаще всего приводят к задержкам?»

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

• выявлять наиболее значимые блокеры;

• оценивать их влияние на процесс;

• приоритезировать их решение.

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

Техническая реализация ClickUp

Сначала мы создали для блокеров отдельную доску. Затем автоматизировали <что?> на досках разработки. Когда разработчик ставит метку blocker, на нашей доске блокеров автоматически создаётся задача, а соответствующая задача на доске разработки переводится в статус blocked. Порядок действий такой: выбираем область возникновения блокера, отмечаем тегом тип работ и выбираем тип блокера.

Вот как это выглядит на доске:

Недостатки реализации со статусом blocked

Первый недостаток — нелинейность процесса. Входящий буфер перестаёт существовать, так как все заблокированные задачи сразу переходят в этот статус.

Без статуса blocked невозможно автоматически рассчитать доли активного и заблокированного времени по каждой задаче. Альтернативный вариант — ручной подсчёт через сопоставление ссылок между задачами, но это значительно усложняет процесс.

Если не создавать отдельные задачи на доске блокеров, то данные могут затираться, и в итоге будет фиксироваться только один блокер с суммарным временем блокировки, без детализации по каждому случаю.

BI-аналитика в Superset

Аналитику мы проводим так. Сначала вычисляем продолжительность блокеров по полям «Дата создания блокера» и «Дата закрытия блокера», чтобы выяснить, как долго у нас была блокировка. Затем добавляем типы блокеров в запрос и разделение на платформы (у нас это реализовано через теги). Строим графики, для этого я использовал Pie Chart.

Потом добавляем поле month для фильтрации, которое разбивает блокеры по месяцам.

Считаем количество повторений определенного типа блокеров из месяца в месяц, чтобы определить, насколько часто мы сталкиваемся с такой блокировкой. В моём случае из месяца в месяц есть недоступность специалиста в мобильной разработке. 

Дашборд мониторинга

Позднее мы добавили дашборд для мониторинга блокеров:

Он помогает выявлять наиболее частые блокеры и понимать их причины, определять тренды и принимать управленческие решения.

Ключевые столбцы и их значение:

Примеры использования

Блокер «Недоступность специалиста»

 при разработке под Android повторяется из месяца в месяц, медианное время ожидания составило 21 день. Это говорит о том, что разработчики перегружены или отсутствуют необходимые ресурсы.

В подобных случаях не нужно бежать и согласовывать разработчика, лучше сначала проанализировать:

• По бэклогу оценить загрузку мобильной команды на перспективу.

• Обсудить ситуацию с командой разработки и продактом, чтобы понять, есть ли у нас задачи на будущее или нас всё устраивает.

Блокер «Зависимость от реализации»

При разработке под Android повторяется из месяца в месяц, медианное время ожидания составило 14,5 дней. Это говорит о том, что команда не может приступить к задаче до завершения определённой части работы другой команды или платформы.

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

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

• Обсудить приоритеты с командами и продуктологом, чтобы понять, стоит ли ускорить выполнение зависимой задачи или пересмотреть план работ.

Блокер «Ожидание релиза»

При разработке под Android и iOS возникает регулярно. Медианное время ожидания составило 12 дней. Это говорит о том, что задачи готовы к выпуску, но задерживаются из-за графика релизов или их приостановки.
Таблица с данными по блокеру «Ожидание релиза» для обеих платформ:

Дополнительно были зафиксированы две типичные ситуации:

1. Технические причины задержки релиза, связанные с проверкой и одобрением приложений в Google Play или App Store, что может увеличить время ожидания.

2. Зависимость от релизов другой команды: мы не выпускаем некоторые доработки или низкоприоритетные баги сразу после их исправления, поскольку есть прямая зависимость от графика релизов другой команды. В таких случаях важно понять, была ли задержка запланированной или возникла из-за непредвиденных проблем.

Если задачи имеют высокую приоритетность и критичны для бизнеса, мы делаем внеплановые релизы. В них попадают:

• Хотфиксы, устраняющие критические баги.

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

Итоги работы с блокерами

После внедрения системы отслеживания блокеров в команде удалось достичь нескольких ключевых результатов:

1. Объективное понимание проблем. Мы избавились от субъективных оценок и начали работать с реальными данными, что позволило точно определить, почему возникают задержки и какие блокеры оказывают наибольшее влияние на процессы.

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

3. Метрики и визуализация. Использование BI-инструментов для визуализации данных о блокерах наглядно продемонстрировало динамику проблем. Месячные отчеты и анализ повторений типов блокеров помогли выявить закономерности и лучше прогнозировать риски в будущем.

4. Совместная работа и ретро. Появилась возможность для коллективного обсуждения проблем и поиска точек улучшения. Ретроспективы стали продуктивнее , так как команда могла оперировать точными фактами и данными, а не обсуждать абстрактные причины.