Мы заботимся о пользователях Авито. В те моменты, когда мы накосячили, и пользователи сообщили нам об этом, мы должны оперативно отреагировать на проблему, предоставив альтернативный вариант решения, и постараться максимально быстро её исправить. А ещё мы хотим знать мнение пользователей об изменениях на Авито и собирать идеи по улучшению продукта.
Для работы инженерных команд с обращениями пользователей у нас есть отдельный процесс. Мы называем его SPT — это сокращённое название проекта Support в Jira.
Обращения пользователей приходят из HelpDesk, соцсетей, магазинов приложений, от клиентских менеджеров и других каналов. Обращения мы делим на три типа задач:
| Тип задачи | Описание |
|---|---|
| Bug (баг) | Ошибка из-за которой Авито работает не так, как должен. Например, пользователь не может опубликовать объявление или оплатить услугу. |
| Crash (крэш) | Непредвиденное завершение работы приложения Авито на iOS или Android. |
| Feature (фичареквест) | Просьба пользователя добавить новую функциональность на сайт или в приложение. Например, пожелание добавить в фильтры породу вельш-корги. К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет. |
Основным и самым крупным каналом для нас является HelpDesk.
При обращении пользователя в поддержку в HelpDesk автоматически формируется тикет-инцидент. Если пользователь сообщает о баге, то агент заводит тикет-проблему и связывает его с тикетом-инцидентом. Тикет-проблема нужен для агрегации одинаковых инцидентов.
А на основе тикета-проблемы SPT-координаторы заводят задачу в Jira в проекте SPT и назначают её на нужный юнит.
Приоритет багов и крашей зависит от их критичности. У нас есть пять разных приоритетов для того, чтобы видеть, что нужно делать в первую очередь:
- P0 (Blocker).
- P1 (Critical).
- P2 (Major).
- P3 (Normal).
- P4 (Minor).
Приоритет задаче в Jira выставляется в соответствии с нашей политикой обработки ошибок. Мы используем матрицу, которая объединяет в себе серьёзность бага и вероятность/частоту его возникновения. Вот она в упрощённом виде:
| Частота возникновения/ серьёзность |
Crash | Failure | Flaw | Annoyance |
|---|---|---|---|---|
| Всегда | P0 | P0 | P2 | P3 |
| Иногда | P1 | P1 | P3 | P4 |
| Редко | P2 | P2 | P4 | P4 |
Для багов SPT дополнительно обращаем внимание на:
- Общее количество обращений пользователей по этой проблеме.
- Наличие обращений профессиональных клиентов крупного и среднего бизнеса.
- Дополнительную нагрузку на сотрудников поддержки, например, нужно ли агенту сходить в админку и поменять какой-либо параметр.
При получении задачи ответственная за функциональность команда:
- Меняет статус задачи.
- Выставляет её приоритет.
- Описывает временное решение для пользователя. Если временное решение отсутствует, это нужно указать.
Возможен вариант, когда исправлять проблему или делать фичу мы не будем. Если такое происходит, то ответственная команда пишет в задаче комментарий о том, почему было принято такое решение, чтобы можно было донести его до пользователя.
Закрываем SPT-задачи мы только тогда, когда исправили проблему и её фикс уже на проде. Если проблема исправлена, а релиза ещё не было, то для закрытия задачи нужно его дождаться.
Успешность работ по SPT мы отслеживаем на отдельном дашборде. Мы не просто фиксим проблемы, а ещё и анализируем причины их возникновения. Это помогает сократить количество новых багов в будущем.