Пользователь говорит, что все сломалось, но что сломалось и как – объяснить не может. Твои действия?

Прилетает тикет с заголовком «НИЧЕГО НЕ РАБОТАЕТ!!!», а в описании пусто. Ни скриншотов, ни шагов, а одна паника 😳

Да, такое бывает постоянно, а не только на собесах. Но твоя задача не чинить баг (это зона поддержки, QA и разработки). А понять, что именно накрылось – требование, процесс или реализация.

И передать команде в адекватном виде.

Что важно НЕ делать: • Не начать чинить вслепую • Не доказывать пользователю, что у него все работает • Не ограничиться фразой «без шагов ничего не можем сделать»

Как рассуждать и действовать: 1. Сначала понимаем проблему, а не ищем баг Я бы начал с уточнения, что именно не так работает:

• что пользователь ожидал увидеть • что увидел на самом деле • с какого момента это началось

В 30% случаев выясняется, что это вообще не баг, а просто новая хотелка или непонимание в бизнес-логике 🤷‍♂️

2. Собираем контекст по кусочкам Если пользователь не помнит точных шагов – не страшно. Выясняем другое:

• устройство, браузер, версия приложения • время и примерный сценарий («после оплаты», «после обновления») • это было один раз или повторяется

Задача – сузить зону поиска, а не получить идеальный сценарий.

Пример: «Я вчера вечером загружал отчет в Excel, а он вместо цифр выдал иероглифы. У Наташи из соседнего отдела – то же самое». Уже  что-то конкретное.

3. Проверяем масштаб проблемы Дальше иду к коллегам:

• есть ли похожие обращения в поддержке • что показывают логи, метрики, мониторинг • есть ли у QA похожие кейсы

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

4. Пробуем воспроизвести Даже без точных шагов можно попробовать:

• пройти основной сценарий пользователя • проверить пограничные кейсы • сверить, как система работает сейчас, с тем, как она должна работать по требованиям

По сути, ищу не сам баг, а где мог сломаться процесс или требование.

5. Оформить понятный тикет Итог работы – внятный вход для команды:

• четкое описание проблемы • классификация: bug (дефект) / feature request (доработка) / process issue (проблема процесса) и т.д. • приоритет и бизнес-последствия • условия, при которых проблема проявляется или может проявиться (даже примерные)

Такое уже можно спокойно передать в разработку или QA 🗃

Как отвечать на собесе: Если пользователь говорит, что все сломалось – я не буду сразу чинить все сам. Я разберусь, какой процесс дал сбой, и оформлю это так, чтобы разработчики или продакт точно поняли, что и зачем менять.

В идеале, чтобы следующий такой тикет не возникал вообще, потому что требование будет точным.

Что важно показать в ответе: • Используй фразы «я бы начал с…», «я бы проверил…» и т.д. • Всегда разделяй симптом и причину • Покажи, что твой результат – не переписка с пользователем, а четкий вход для команды

Интервьюер в этот момент хочет понять: будет ли с тобой спокойно работать, когда ничего не понятно и все нервничают.

Если в ответе есть логика, спокойствие и адекватность – этого обычно более чем достаточно 😴