Блокер — это задача, выполнение которой невозможно или существенно затруднено из-за зависимости от другой задачи, ресурса или внешнего фактора.
Практика работы с блокерами позволяет уйти от субъективного восприятия проблем к объективному анализу системы. Она помогает ответить на ключевые вопросы:
Как часто возникают проблемы и ккакова их продолжительность?
Главная задача, которую я ставил перед собой, — понять, почему может увеличиваться 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 дней. Это говорит о том, что задачи готовы к выпуску, но задерживаются из-за графика релизов или их приостановки.
Таблица с данными по блокеру «Ожидание релиза» для обеих платформ:
Дополнительно были зафиксированы две типичные ситуации:
Технические причины задержки релиза, связанные с проверкой и одобрением приложений в Google Play или App Store, что может увеличить время ожидания.
Зависимость от релизов другой команды: мы не выпускаем некоторые доработки или низкоприоритетные баги сразу после их исправления, поскольку есть прямая зависимость от графика релизов другой команды. В таких случаях важно понять, была ли задержка запланированной или возникла из-за непредвиденных проблем.
Если задачи имеют высокую приоритетность и критичны для бизнеса, мы делаем внеплановые релизы. В них попадают:
Хотфиксы, устраняющие критические баги.
Значимые для бизнеса задачи, которые несут ценность для клиентов и не могут ждать следующего планового релиза.
Итоги работы с блокерами
После внедрения системы отслеживания блокеров в команде удалось достичь нескольких ключевых результатов:
Объективное понимание проблем. Мы избавились от субъективных оценок и начали работать с реальными данными, что позволило точно определить, почему возникают задержки и какие блокеры оказывают наибольшее влияние на процессы.
Выявление трендов и частых проблем. Системное отслеживание блокеров показало повторяющиеся проблемы, особенно в мобильной разработке, что помогло целенаправленно их решать.
Метрики и визуализация. Использование BI-инструментов для визуализации данных о блокерах наглядно продемонстрировало динамику проблем. Месячные отчеты и анализ повторений типов блокеров помогли выявить закономерности и лучше прогнозировать риски в будущем.
Совместная работа и ретро. Появилась возможность для коллективного обсуждения проблем и поиска точек улучшения. Ретроспективы стали продуктивнее , так как команда могла оперировать точными фактами и данными, а не обсуждать абстрактные причины.
