From 87f38bc585204d979faf6e43097e05b5d7752384 Mon Sep 17 00:00:00 2001 From: classy-faker Date: Wed, 4 May 2022 12:04:38 +0300 Subject: [PATCH] Update spt.md --- spt.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/spt.md b/spt.md index 7d351da..2fbab95 100644 --- a/spt.md +++ b/spt.md @@ -12,6 +12,14 @@ | Crash (крэш) | Непредвиденное завершение работы приложения Авито на iOS или Android. | Feature (фичареквест) | Просьба пользователя добавить новую функциональность на сайт или в приложение. Например, пожелание добавить в фильтры породу вельш-корги.

К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет. +## Задача из HelpDesk + +Основным и самым крупным каналом для нас является HelpDesk. + +При обращении пользователя в поддержку в HelpDesk автоматически формируется тикет-инцидент. Если пользователь сообщает о баге, то агент заводит тикет-проблему и связывает его с тикетом-инцидентом. Тикет-проблема нужен для агрегации одинаковых инцидентов. + +А на основе тикета-проблемы SPT-координаторы заводят задачу в Jira в проекте SPT и назначают её на нужный юнит. + ## Приоритеты задач Приоритет багов и крашей зависит от их критичности. У нас есть пять разных приоритетов для того, чтобы видеть, что нужно делать в первую очередь: 1. P0 (Blocker). @@ -33,7 +41,12 @@ - Наличие обращений профессиональных клиентов крупного и среднего бизнеса. - Дополнительную нагрузку на сотрудников поддержки, например, нужно ли агенту сходить в админку и поменять какой-либо параметр. -Возможен вариант, когда исправлять проблему или делать фичу мы не будем. Если такое происходит, то ответственная команда напишет в задаче комментарий о том, почему было принято такое решение, чтобы можно было донести его до пользователя. +При получении задачи ответственная за функциональность команда: +- Меняет статус задачи. +- Выставляет её приоритет. +- Описывает временное решение для пользователя. Если временное решение отсутствует, это нужно указать. + +Возможен вариант, когда исправлять проблему или делать фичу мы не будем. Если такое происходит, то ответственная команда пишет в задаче комментарий о том, почему было принято такое решение, чтобы можно было донести его до пользователя. Закрываем SPT-задачи мы только тогда, когда исправили проблему и её фикс уже на проде. Если проблема исправлена, а релиза ещё не было, то для закрытия задачи нужно его дождаться.