Что хотят услышать интервьюеры:

Если все задачи объявлены критичными, значит приоритизация сломана: не хватает общих критериев срочности и влияния. В такой ситуации нужно быстро вернуть единые правила оценки, собрать стейкхолдеров и разложить задачи по влиянию на бизнес, рискам и дедлайнам. Важно не просто выбрать «самую громкую» задачу, а зафиксировать прозрачный порядок и компромиссы.

Определение:

Когда все задачи помечены как «критичные», это означает, что термин потерял смысл и не помогает принимать решения. Критичность должна быть редким статусом, который отражает реальную угрозу бизнесу, пользователям или срокам. Задача PM — восстановить шкалу приоритетов: отделить действительно срочные и важные задачи от просто желательных.

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

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

Пояснение кода:

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

Зафиксировать, что именно делает задачу «критичной»: простой сервиса, потеря денег, юридический риск, блокировка ключевого клиента.
Собрать все запросы в один список и убрать дубли.
Оценить каждую задачу по понятным критериям: влияние, срочность, число пользователей, стоимость задержки, наличие обходного решения.
Согласовать приоритеты со стейкхолдерами и явно показать, что если берётся одна задача, другая сдвигается.
Если критичных задач много, разделить их на уровни: «блокер», «высокий приоритет», «можно отложить».
Вернуться к команде с прозрачным решением, чтобы не было ощущения произвольности.

Ключевые моменты:

«Критично» — это не эмоция, а измеримый статус с последствиями.
Если всё критично, значит нужно не ускоряться, а пересматривать критерии приоритизации.
Решение должно опираться на влияние на бизнес, пользователей, риски и дедлайны.
Важно фиксировать компромиссы: какая задача берётся сейчас и что откладывается.
PM должен быть медиатором, а не просто передавать самый громкий запрос в разработку.
Хороший ответ на собеседовании показывает, что приоритизация — это система, а не разовая договорённость.

Что делать, если все задачи "критичные"?