Как происходит приоритизация задач?
Что проверяют
Есть ли у вас воспроизводимый способ принимать решения и защищать их. Слушают, на что вы опираетесь, кроме «попросил самый громкий стейкхолдер», и умеете ли вы отказывать так, чтобы отношения с заказчиком сохранялись.
Как отвечать
Стройте ответ на своём реальном случае по схеме: критерий, оценка, решение, последствия.
- Критерий выводится из цели периода. Задача, не связанная с целью команды, не имеет приоритета, у неё есть только автор.
- Метод называйте вслух и по делу: RICE или ICE для продуктового бэклога, WSJF (стоимость задержки, делённая на размер) там, где важен момент выхода, MoSCoW при фиксированном объёме релиза. Матрица Эйзенхауэра работает для личных задач, но для бэклога слаба: в ней нет ни охвата, ни трудоёмкости.
- Опирайтесь на числа: сколько пользователей затронуто, деньги, обращения в поддержку, доля отвалов на шаге воронки. Где данных нет, честно назовите допущение и способ его проверить.
- Разделяйте ёмкость по корзинам: продуктовые задачи, технический долг, баги и прерывания. Иначе срочное съедает всё, а долг накапливается незаметно.
- Опишите правило для входящего срочного: что именно вытесняется, кто узнаёт об этом и когда.
- Коммуникация: приоритеты видны всем, отказ звучит как «не сейчас, потому что», а разговор с заказчиком идёт про выбор между вариантами, а не про спор.
Реальный опыт выдают конкретные числа, названный конфликт и его исход, а также признание ошибки приоритизации и того, что после неё изменили в процессе.
Где спотыкаются
Перечисляют фреймворки списком, но не могут сказать, какой применяли сами и почему именно его.
Отвечают «делаю то, что просит бизнес». Это отказ от роли: интервьюер как раз проверяет наличие собственного критерия.
Называют всё срочным и важным. Приоритизация начинается там, где что-то сознательно откладывают.
Не говорят про последствия. Ответ без цены решения (что не сделали и чем это обернулось) звучит как теория из статьи.