Сервис технической поддержки - это единая система обработки заявок от пользователей - интернет-ресурс для обращения Пользователей https://trivium-group.atlassian.net/servicedesk/customer/portals на базе Jira Service Manager

Для получения технической поддержки в онлайн-режиме Пользователю необходимо зарегистрироваться в Сервисе технической поддержки. Пользователи с уровнем доступа Гость не могут создавать Запросы. Все зарегистрированные пользователи Сервиса технической поддержки направляют Запросы в он-лайн режиме на сайте https://trivium-group.atlassian.net/servicedesk/customer/portal/

Содержание

1 Порядок регистрации в Сервисе технической поддержки
2 Типы обращений
3 Работа с обращениями, отслеживание статуса

Порядок регистрации в Сервисе технической поддержки

Для регистрации на Портале поддержки:

Зайдите на страницу https://trivium-group.atlassian.net/servicedesk/customer/portal/
Нажмите кнопку sign up
Введите адрес своей электронной почты
Нажмите Send link
Откройте свою почту и перейдите по ссылке, указанной в письме
Укажите имя, фамилию и пароль
Нажмите sign up

Типы обращений

Ошибка - обращение, связанное с несоответствием Продукта установленным требованиям к функциональности, описанным в документации на Продукт
Консультация - обращение, связанное с получением рекомендаций по использованию Продукта или помощи в использовании ресурсов платформы
Запрос на новую функциональность - обращение, связанное с разработкой новой функциональности Продукта

SLA

Приоритеты

5 приоритетов обращений:

Ошибки, консультации

Приоритет	Определение	Определение "на пальцах"
Наивысший	Проблема влечёт за собой остановку или полную потерю работоспособности Системы. Становятся недоступны основные функции Системы и ситуация является критической. Проблемы данного приоритета обычно имеют одну или несколько характеристик: Недоступны основные функции Продукта; Продукт зависает на неопределённое время, бесконечно занимая ресурсы и не давая отклика; Продукт аварийно останавливается и не может начать работать после перезапуска. Необходимо обоснование выставление приоритета (например на этапе разработки - это запланированная сдача этапа или демонстрация заказчику).	Всё сломалось. Заинтересованные лица начинают немедленно решать эту проблему, обычно работа ведётся в круглосуточном режиме.
Высокий	Проблема влечет за собой значительную потерю работоспособности Продукта. Критические функции Продукта становятся недоступными, и нет применимого обходного пути решения, однако, Продукта сохраняет работоспособность в ограниченном объёме, и работы по решению будут вестись в рабочее время.	Проблема в самом деле критична, но не настолько всё плохо, чтобы переходить в круглосуточный режим.
Средний	Проблема влечет за собой несущественную потерю работоспособности Продукта, следствием чего является неудобство в работе или необходимость использовать альтернативные или обходные пути решения (workaround).	Проблема критична, но допускает ручной или иной способ обхода (workaround).
Низкий	Данная проблема не влечет потери работоспособности Продукта. Это незначительная ошибка или неудобство, ошибка в документации и т.п., которые не препятствуют проведению операций в Продукте.	Проблема должна быть решена, но не является критичной.
Наинизший	Не является проблемой, пожелание в развитии платформы, которая не влияет на работоспособность продукта.	Проблемы нет, но есть пожелание в изменении

Новая функциональность

Приоритет	Определение
Наивысший	Функционал заявленный в требовании необходим для сдачи проекта в кратчайшие сроки и блокирует сдачу этапа проекта, обхода нет. Существенные денежные потери при отсутствии этой функциональности. Данный приоритет должен быть подтвержден РП и указаны требуемые сроки с привязкой к датам сдачи этапа/проекта.
Высокий	Функционал заявленный в требовании необходим в течение ближайших 2-х месяцев для показа, сдачи этапа проекта, обхода нет. Отсутствие этой функциональности блокирует выполнение договоренностей с заказчиком. Существуют возможные денежные потери при отсутствии данной функциональности. Данный приоритет должен быть подтвержден РП и указаны требуемые сроки с привязкой к датам показа/сдачи этапа/проекта.
Средний	Функционал заявленный в требовании необходим в ближайшие полгода для запланированных работ по проекту. Можно реализовать через обход, но затруднительно / не оптимально. Денежные потери при отсутствии данной функциональности неизвестны или отсутствуют.
Низкий	Реализация требования на сроки сдачи этапа проекта не влияет. Может повышать удобство про настройке объектов. Пожелания по развитию платформы 3v.
Наинизший	Не является проблемой, пожелание в развитии платформы, которая не влияет на работоспособность продукта.

Время реакции

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

Приоритет	Для типа обращения «Ошибка»	Для типа обращения «Консультация»
Наивысший	4 рабочих часа	4 рабочих часа
Высокий	8 рабочих часов	8 рабочих часов
Средний	Не учитывается	Не учитывается
Низкий	Не учитывается	Не учитывается
Наинизший	Не учитывается	Не учитывается

Когда обращение уходит в статус Уточнение, то время, проведенное в данном статусе, не учитывается в расчете времени реакции на обращение.
По обращениям с приоритетом Средний и ниже, команда поддержки( для ошибок - ОБ, для консультаций - ПМ по блоку), первую среду каждого месяца просматривает список обращений,

и для каждого обращения, которое планируется взять в работу поднимает приоритет на High (и работа по нему идет стандартным процессом) с соответствующим комментарием.

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

Важно! Для обращения с типом "Запрос на новую функциональность" приоритет влияет на очередность включения в ближайший спринт.

Доступность технической поддержки

Опция	Период доступности
Прием и регистрация запросов: Сервис технической поддержки: https://trivium-group.atlassian.net/servicedesk/customer/portals	Круглосуточно
Консультации, поиск вариантов решений проблем, исправление ошибок	пн-пт с 9.00 до 18.00 (Мск)

Алгоритм действий при возникновении Ошибки

Алгоритм

Проверить, нет ли текущей ошибки в списке зарегистрированных обращений с типом "Ошибка".
Если ошибки нет в списке, необходимо создать обращение с типом "Ошибка" в Сервисе технической поддержки
Для создания обращения в Сервисе технической поддержки необходимо зарегистрироваться. Пользователи с уровнем доступа Гость не могут создавать Обращения.

Заполнение полей

1. Заполните краткое наименование ошибки, чтобы оно отражало суть ошибки. Например, "Отчеты. При изменении параметра отчета падает ошибка 500".

пример заполнения данных

2. Далее необходимо подробно описать ошибку, которая возникает при работе с платформой:

Описание проблемы, которую вы пытаетесь решить или которая мешает вам в работе.
Шаги для повторения проблемы, которые воспроизводимы без знания бизнес логики объектов.
Опишите ожидаемый результат после ваших действий, и фактический результат, который возникает.
Приложите скриншоты экрана: с текстом возникающей ошибки, примером демонстрирующим ошибочное поведение, скриншоты помогающие понять проблему.
Логи запросов при возникновении ошибки (как правильно снять логи, смотри раздел "Добавление лога к обращению" в данной статье).
Если есть возможность доступа к системе, укажите ссылку (url) на пример на котором воспроизводится ошибка, с указанием логина для доступа в систему. Пароль при необходимости можно отправить на почту jira@trivium.group после отправки обращения, указав дополнительно полученный номер заявки вида SR3V-XXXX. Это поможет гораздо быстрее локализовать проблему.
Если есть возможность, сделать и прикрепить к обращению пример на https://study.3v-cloud.com/, в котором упрощенно проявляется проявляется данная ошибка, так мы гораздо быстрее сможем понять и решить вашу проблему или предложить способ обхода.
Название проекта, в рамках которого выполняется работа.

3. Критичность обращения, отражающее на ваш взгляд существенность ошибки. Пожалуйста, при определении критичности воспользуетесь следующими критериями по ссылке. В случае Highest и High критичности обязательно укажите в обращения причину в соответствии с критериями.

4. В поле "Вложение" возможно прикрепить любые файлы, которые помогут более точно разобраться в ошибке: скриншоты, логи, json текст объекта платформы, видео воспроизведения ошибки.
В качестве логов возможно прикрепление:

HAR файл.

В меню Chrome выберите Инструменты - Инструменты разработчика. Внизу страницы откроется панель разработчика в панели разработчика выберите закладку "Сеть". Обновите содержимое страницы и воспроизведите шаги для повторения. Затем, в панели разработчика выберите пункт "Сохранить как HAR", укажите имя файла и сохраните его на диск. Этот файл возможно прикрепить к сообщению.

Cкриншот с ошибкой запроса на сервис вместе с логом ошибки запроса (Response).

В меню Chrome выберите Инструменты - Инструменты разработчика. Внизу страницы откроется панель разработчика в панели разработчика выберите закладку "Сеть". Обновите содержимое страницы и воспроизведите шаги для повторения. При возникновении ошибки, запрос с данной ошибкой будет выделен красным цветом и содержать код ответа с ошибкой. Правой кнопкой мыши можно нажать на данный запрос и выбрать Копировать ответ (copy response). Данный ответ можно приложить к обращению.

Лог консоли.

В меню Chrome выберите Инструменты - Инструменты разработчика. Внизу страницы откроется панель разработчика в панели разработчика выберите закладку "Консоль". Обновите содержимое страницы и воспроизведите шаги для повторения. После воспроизведения ошибки ошибки скопируйте содержимое вкладки сообщений (messages).

5. Заполните последнее поле Затронутые версии. В этом поле укажите версию платформы 3v, в которой воспроизводится ошибка. Чтобы узнать значение версии, можно воспользоваться инструкцией: Версия платформы

6. Если вы хотите сделать доступной ваше обращением доступным для всей организации, оставьте название организации в комбобоксе "Поделиться с"

Описание процесса

Заказчик добавляет ошибку с заполненными обязательными полями. Устанавливается статус «Новая».
Все новые заявки просматриваются и переводятся на рассмотрение. Устанавливается статус «На рассмотрении».
Заявка первично обрабатывается(проверяется заполнение обязательных полей, воспроизведение ошибки, поиск аналогичных ошибок). После этого статус заявки может быть изменён на один из следующих:
- «На уточнении», если требуется уточнение у заказчика. Если заявка находится в статусе «На уточнении» больше 3-х недель она автоматически закрывается.
- «Закрыта», если
  - существует аналогичная ошибка. В комментарии указывается ссылка
  - в заявке описано запланированное поведение
  - не воспроизводится(определяется в статусе «На уточнении» с подтверждением заказчика)
- «В очереди», если заявка правильно составлена.
При статусе «В очереди» заказчику видны все заявки (от всех пользователей) отсортированные в порядке приоритета (от высшего к низшему). С данного шага задачи берутся в работу (в первую очередь берутся заявки с наибольшим приоритетом). Когда начинается работа по заявке устанавливается статус «В работе».
Заявка выполняется. По завершению, указывается версия продукта, в котором есть исправление. Устанавливается статус «Приемка»
Заказчик проверяет исправление по заявке, при удовлетворительной реализации устанавливает статус «Закрыто». При неудовлетворительной реализации устанавливает статус «На рассмотрении». Если заявка висит в приемке больше 3-х недель она автоматически закрывается.