Files
dev-roadmap-avito-playbook/spt.md
classy-faker a5b33f5670 Create spt.md
2022-04-28 11:33:53 +03:00

5.0 KiB
Raw Blame History

SPT: работа с обращениями пользователей

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

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

Типы задач

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

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

К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет.

Приоритеты задач

Приоритет багов и крашей зависит от их критичности. У нас есть пять разных приоритетов для того, чтобы видеть, что нужно делать в первую очередь:

  1. P0 (Blocker).
  2. P1 (Critical).
  3. P2 (Major).
  4. P3 (Normal).
  5. P4 (Minor).

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

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

Для багов SPT дополнительно обращаем внимание на:

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

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

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

Метрики

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