# SPT: работа с обращениями пользователей
Мы заботимся о пользователях Авито. В те моменты, когда мы накосячили, и пользователи сообщили нам об этом, мы должны оперативно отреагировать на проблему, предоставив альтернативный вариант решения, и постараться максимально быстро её исправить. А ещё мы хотим знать мнение пользователей об изменениях на Авито и собирать идеи по улучшению продукта.  

Для работы инженерных команд с обращениями пользователей у нас есть отдельный процесс. Мы называем его SPT — это сокращённое название проекта Support в Jira.

## Типы задач
Обращения пользователей приходят из HelpDesk, соцсетей, магазинов приложений, от клиентских менеджеров и других каналов. Обращения мы делим на три типа задач:

Тип задачи  | Описание
------------- | -------------
| Bug (баг)     | Ошибка из-за которой Авито работает не так, как должен. Например, пользователь не может опубликовать объявление или оплатить услугу.
| Crash (крэш)  | Непредвиденное завершение работы приложения Авито на iOS или Android.
| Feature (фичареквест)  | Просьба пользователя добавить новую функциональность на сайт или в приложение. Например, пожелание добавить в фильтры породу вельш-корги. </br> </br>К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет. 

## Задача из HelpDesk 

Основным и самым крупным каналом для нас является HelpDesk.

При обращении пользователя в поддержку в HelpDesk автоматически формируется тикет-инцидент. Если пользователь сообщает о баге, то агент заводит тикет-проблему и связывает его с тикетом-инцидентом. Тикет-проблема нужен для агрегации одинаковых инцидентов.

А на основе тикета-проблемы SPT-координаторы заводят задачу в Jira в проекте SPT и назначают её на нужный юнит. 

## Приоритеты задач
Приоритет багов и крашей зависит от их критичности. У нас есть пять разных приоритетов для того, чтобы видеть, что нужно делать в первую очередь:
1. P0 (Blocker).
2. P1 (Critical).
3. P2 (Major).
4. P3 (Normal).
5. P4 (Minor). 

Приоритет задаче в Jira выставляется в соответствии с нашей политикой обработки ошибок. Мы используем матрицу, которая объединяет в себе серьёзность бага и вероятность/частоту его возникновения. Вот она в упрощённом виде:

Частота возникновения/</br>серьёзность | Crash | Failure | Flaw | Annoyance
------------- | ------------- | ------------- | ------------- | -------------
| Всегда  | P0 | P0 | P2 | P3 
| Иногда  | P1 | P1 | P3 | P4
| Редко   | P2 | P2 | P4 | P4

Для багов SPT дополнительно обращаем внимание на: 
- Общее количество обращений пользователей по этой проблеме. 
- Наличие обращений профессиональных клиентов крупного и среднего бизнеса.
- Дополнительную нагрузку на сотрудников поддержки, например, нужно ли агенту сходить в админку и поменять какой-либо параметр. 

При получении задачи ответственная за функциональность команда:
- Меняет статус задачи. 
- Выставляет её приоритет.
- Описывает временное решение для пользователя. Если временное решение отсутствует, это нужно указать.

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

Закрываем SPT-задачи мы только тогда, когда исправили проблему и её фикс уже на проде. Если проблема исправлена, а релиза ещё не было, то для закрытия задачи нужно его дождаться. 

## Метрики
Успешность работ по SPT мы отслеживаем на отдельном дашборде. Мы не просто фиксим проблемы, а ещё и анализируем причины их возникновения. Это помогает сократить количество новых багов в будущем.