Инструкция по работе с сервисом технической поддержки проектов на платформе 3V

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

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

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

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

1. Зайдите на страницу https://trivium-group.atlassian.net/servicedesk/customer/portal/
2. Нажмите кнопку sign up
3. Введите адрес своей электронной почты
4. Нажмите Send link
5. Откройте свою почту и перейдите по ссылке, указанной в письме
6. Укажите имя, фамилию и пароль
7. Нажмите 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. Проверить, нет ли текущей ошибки в списке зарегистрированных обращений с типом "Ошибка".
2. Если ошибки нет в списке, необходимо создать обращение с типом "Ошибка" в Сервисе технической поддержки
3. Для создания обращения в Сервисе технической поддержки необходимо зарегистрироваться. Пользователи с уровнем доступа Гость не могут создавать Обращения.

Обязательные сведения для подачи заявки

• Заголовок с кратким описанием ошибки
• Критичность (наивысшая, высокая, средняя, низкая, наинизшая)
• Если критичность наивысшая или высокая, то нужно указать основание критичности
• Проект, на котором используется платформа и возникла ошибка
• Описание ошибки
• Пример повторения ошибки: шаги для повторения, url, пользователь/пароль и иная информация, по которой незнакомый с проектом человек сможет повторить ошибку. Крайне желательно, указывать, в качестве примера для повторения ошибки, пример в минимальном объеме требуемым для повторения ошибки (Например, убрать лишние столбцы, сократить объем данных, убрать лишние элементы управления)
• Версия платформы, которая используется на проекте

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

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

Алгоритм действий при необходимости получения Консультации

Алгоритм

1. Самостоятельный поиск ответов на вопросы в руководстве пользователя, Wiki, Ask Bot. Онлайн-документация и Wiki доступны без авторизации.
2. В случае, если ответ не найден самостоятельно, создается обращение в Сервисе технической поддержки с типом "Консультация"
3. Для создания обращения в Сервисе технической поддержки необходимо зарегистрироваться. Пользователи с уровнем доступа Гость не могут создавать Обращения.

Обязательные сведения для подачи заявки:

• Заголовок с кратким описание обращения
• Критичность (наивысшая, высокая, средняя, низкая, наинизшая)
• Если критичность наивысшая или высокая то нужно указать обоснование критичности
• Проект на котором используется платформа
• Тип обращения (консультация, проблема)
• Описание проблемы, которую не удается решить с использованием платформы
• Описание примера, по возможности сопровождая скриншотами или ссылками на реальную систему. При попытках решить проблемы самостоятельно, расписать варианты
• Версия платформы, которая используется на проекте

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

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

Алгоритм действий при необходимости фиксации обращения "Запрос на новую функциональность"

Алгоритм

1. Проверить, нет ли аналогичного запроса на новую функциональность.
2. Если требования нет в списке, необходимо создать обращение с типом "Запрос на новую функциональность" в Сервисе технической поддержки
3. Для создания обращения в Сервисе технической поддержки необходимо зарегистрироваться. Пользователи с уровнем доступа Гость не могут создавать Обращения.

Обязательные сведения для подачи заявки:

• Заголовок с кратким описанием функциональности
• Критичность (наивысшая, высокая, средняя, низкая, наинизшая)
• Если критичность наивысшая или высокая то нужно указать обоснование критичности
• Проект, на котором используется платформа и планируется использовать функциональность
• Тип обращения (запрос на новую функциональность)
• Описание проблемы, которую предполагается решить с помощью требуемой функциональности
• Описание сценария использования
• Версия платформы, которая используется на проекте

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

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