Как ты расставляешь приоритеты при дедлайне?
Что проверяют
Умение резать объём и прозрачно коммуницировать, а не «успею всё, буду работать ночами». Зрелый ответ — про договорённости и риски, а не про героизм.
Скелет ответа
- Критерий: влияние на пользователя и релиз / усилия. Сначала то, без чего релиз невозможен (блокеры, крэши, legal), затем ключевой сценарий, nice-to-have — в следующую версию.
- Scope, а не качество: режем функциональность, а не тесты и ревью — иначе дедлайн сдвигается на неделю багфиксов.
- Ранняя эскалация: о риске говорим в момент, когда он виден, а не за день до релиза; предлагаем варианты (меньше scope / больше срок / больше людей — последнее обычно не работает).
- Прозрачность: список «входит / не входит» согласован с продуктом письменно; feature flag для того, что не успели.
- Защита фокуса: минимум переключений, парная работа на критическом пути.
Пример ответа
S: За две недели до релиза, привязанного к маркетинговой кампании, оставалось три фичи: новый онбординг, экспорт в PDF и тёмная тема.
T: Понять, что реально выпустить, и договориться с продуктом.
A: Оценил с командой остаток: онбординг — 6 дней, экспорт — 5, тёмная тема — 4, плюс неделя на регрессию. Не укладывались. Предложил продукту матрицу: онбординг обязателен (на него ведёт кампания), экспорт нужен 3% пользователей, тёмную тему можно выпустить через flag позже. Зафиксировали в трекере, что выходит, что нет. Экспорт доделали под флагом, не включая.
R: Релиз вышел в день кампании без критичных багов; экспорт включили через неделю одним переключением флага. Продукт в следующий раз сам пришёл с приоритизацией заранее.