Кто регистрировал инциденты и баги от пользователей
Что проверяют
Как в вашей прошлой команде был устроен путь жалобы пользователя до исправления и где в этом пути стояли вы. Интервьюер хочет понять, работали ли вы с инцидентами на проде или только с багами со стенда. Следом обычно спрашивают, чем инцидент отличается от бага и как вы выставляли приоритет.
Как отвечать
Опишите цепочку, которая была у вас, и свою роль в ней. Типичная схема:
- первая линия поддержки: принимает обращение в service desk, регистрирует его как инцидент, собирает время, окружение, скриншоты и отвечает пользователю в рамках SLA;
- вторая линия: отсеивает ошибки пользователя и проблемы настроек, ищет совпадения в базе известных ошибок;
- QA: воспроизводит на стенде или по логам прода, локализует проблему (Kibana или OpenSearch Dashboards, Grafana, Sentry), оформляет дефект в трекере и связывает его с инцидентом;
- разработка и дежурный: чинят, для критичного выпускают хотфикс вне релизного цикла.
Покажите, что различаете понятия. В терминах ITIL инцидент это незапланированное прерывание или ухудшение сервиса, и цель работы с ним в том, чтобы как можно быстрее восстановить работу, иногда обходным путём. Проблема это корневая причина одного или нескольких инцидентов. Баг это дефект в коде. Один дефект может породить десяток обращений от разных пользователей, их связывают с одной задачей, а не заводят десять.
Про приоритет: severity отражает техническую тяжесть, priority задаёт очередь исправления. Опечатка в названии продукта на главной странице имеет низкую severity и высокий priority.
Если с продом вы не работали, скажите честно и расскажите, как обрабатывали обращения, которые доходили до вас от поддержки или от внутренних пользователей.
Где спотыкаются
Отвечают «пользователи сами заводят баги в трекер». Так бывает во внутренних продуктах, но обычно между пользователем и трекером стоит поддержка, и её роль стоит назвать.
Не отличают инцидент от бага и заводят дефект на каждое обращение. Разработчики получают дубли, а связь между жалобами теряется.
Путают severity и priority или считают их одним полем. Это классическая ловушка, и её почти всегда задают следом.