Работал менеджером по продажам, продавцом кроссовок в Адидасе.

Когда мы вышли на рынок, поиск работы занял всего 3 недели.

Спустя 700 откликов получили оффер от KFC (Rostic's) 😮

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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