Блокер проекта - это не просто неудобство или потенциальный риск, а препятствие, которое уже остановило работу или мешает выполнить следующий шаг. Например, нет доступа к системе, не согласован договор, не получен ответ от клиента, зависимая задача просрочена, нет тестового окружения или подрядчик не передал нужные данные.
Проще говоря, риск может случиться в будущем, а блокер уже случился. Задача не движется, пока кто-то не примет решение, не даст доступ, не снимет зависимость, не уточнит требования или не выделит ресурс. Поэтому блокер должен быть виден в статус-отчете и иметь конкретного владельца.
Блокер отличается от обычной задачи. Задача отвечает на вопрос “что нужно сделать”. Блокер отвечает на вопрос “что мешает сделать это сейчас”. Например, “написать интеграцию OAuth” - задача, а “security не выдал доступ к OAuth app уже 2 дня” - блокер. Если блокер не выделить отдельно, он потеряется внутри общего списка задач.
Хорошая запись о блокере содержит: что заблокировано, источник сигнала, owner, impacted task, когда обнаружено, сколько дней стоит, влияние на срок, следующий шаг, кто должен помочь, дедлайн решения, уровень срочности и ссылку на evidence: задачу, комментарий, meeting note, письмо или лог.
AI-агент для управления проектами может находить блокеры по статусам `blocked`, комментариям, просроченным зависимостям, словам “ждем”, “нет доступа”, “не согласовано”, “зависит от”, отсутствию ответа и повторяющимся вопросам. Но агент не должен объявлять блокер без доказательства. В статус-отчете нужно показывать источник и объяснять, почему это блокер, а не просто догадка.
Блокер важен не сам по себе, а как повод к действию. Если у блокера нет владельца и next step, это просто тревожная заметка. Нормальный процесс требует назначить ответственного, срок решения и правило эскалации: кому писать, когда поднимать выше, что делать, если ответа нет.
В проектных AI-сценариях полезен режим draft + approval. Агент может найти блокер, предложить формулировку, создать черновик action item или статус-отчета, но изменение сроков, приоритетов, владельцев и публичных обещаний клиенту лучше подтверждать человеку.
Примеры
- Разработчик не может начать интеграцию, потому что security уже два дня не выдает доступ к тестовому OAuth-приложению.
- Релиз заблокирован, потому что юридический отдел не согласовал публичные условия тарифа.
- QA не может проверить сценарий оплаты, потому что staging-платежи не работают и нет тестовых карт.
- Дизайн-задача стоит, потому что клиент не прислал брендбук и финальные материалы.
- Команда ждет решение владельца продукта по спорному scope, а без него нельзя закрыть sprint goal.
Где используется
- статус-отчеты проекта
- еженедельный project review
- управление задачами в Jira и Linear
- контроль зависимостей
- эскалация проблем
- meeting follow-up
- risk and blocker log
- подготовка отчета руководству
- AI-агент для управления проектами
- release readiness check
Связанные термины
Частые вопросы
Что такое блокер проекта простыми словами?
Это препятствие, из-за которого работа уже не может двигаться дальше. Например, нет доступа, нет решения, зависимая задача просрочена или внешний участник не дал нужные данные.
Чем блокер отличается от риска?
Риск может случиться в будущем, а блокер уже мешает работе сейчас. Риск можно мониторить, а блокер нужно разбирать через владельца, следующий шаг и часто эскалацию.
Какие данные нужны для хорошей записи о блокере?
Нужны заблокированная задача, причина, источник, владелец, дата обнаружения, влияние на срок, следующий шаг, дедлайн решения, кому эскалировать и ссылка на evidence.
Как AI-агент понимает, что задача заблокирована?
Он смотрит статус blocked, комментарии, просроченные зависимости, отсутствие ответа и формулировки вроде “ждем”, “нет доступа”, “не согласовано”. Но вывод должен подтверждаться ссылкой на источник.
Что делать, если блокер найден?
Назначить владельца, описать следующий шаг, поставить срок решения, обновить статус-отчет и при необходимости эскалировать. Без owner и next step блокер останется просто заметкой.
