В процессе внутренного обсуждения одной штуки с разработчиком написал краткое изложение своих взглядов на работу с проблемами, приходящими от пользователей. Я убежден в правильности этих принципов.

Решил вынести их из внутренних комментариев, чтобы сохранить себе и вам показать.

Смотри, я опишу общий подход, который я считаю правильным.

1.Наша цель – решить проблему, а не закрыть тикет. Если проблема существует, то закрытие тикета нам же никак не помогает – у чувака по прежнему будет все нехорошо. А если у него нехорошо – он нас не будет использовать и уже нам будет нехорошо.

2.Если жалуется один чувак, это не значит, что проблема только у одного. Как правило если жалуется нам один, проблему видит на самом деле гораздо бо́льшее количество людей. Это всегда так – вот вспомни как кто-то жалуется на что-то: как правило жалуются многие, а о проблеме в сервис/компанию сообщают мало кто.

3. Лучший способ прокачаться – делать штуки, которые не очевидны сразу. Копать глубже. Чтобы делать клевые штуки и решать сложные проблемы надо делать сложные вещи.

4. Если мы не можем решить проблему, надо сделать все, что нужно, чтобы в следующий раз мы смогли это сделать. Разумеется не все проблемы можно решить по обращению – это нормально. Но нам надо сделать что-то, чтобы в следующий раз мы проблему смогли решить и узнали о ней не от пользователя.

Потому что если проблема возникнет опять и чувак не даст HAR – мы опять ничего не выясним. А HAR он может и не дать – это сложно, да и пока ему посоветуют собрать HAR, то пройдет время и проблема может уйти (если она спорадическая). Поэтому нам нужно понять, как мы можем мониторить скорость загрузки NNNN и ее MMMM, добавить нужное логирование и так далее – чтобы в следующий раз, когда мы узнаем о проблеме, у нас было больше информации.

(тикет - запись/таск во внутренней системе отслеживания задач, HAR — специальный файл, который можно сгенерировать в браузере, который расскажет как в деталях загружался сайт)