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

Общие положения

Стандарт технической поддержки определяет порядок взаимодействия между командой, выполняющей проект в интересах конечного заказчика на платформе, и командой разработки продукта (платформы 3V).

Участники процесса:

1. Проектная команда
2. Продуктовая команда

Типы взаимодействия участников процесса

По каждому проекту должно быть организовано 3 этапа взаимодействия:

1. Инициация старта взаимодействия проекта с продуктом
2. Проработка архитектурных и технических решений
3. Оперативное взаимодействие на этапе разработки и внедрения системы, а также гарантийной поддержки - сервис технической поддержки платформы

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

Инициация старта взаимодействия проекта с продуктом

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

Алгоритм действий для инициации проекта

Описание шага	Комментарий	Ответственный	Срок	Где выполняется шаг	Результат шага
Создать обращение в сервисе технической поддержки с типом "Проект" (правила оформления обращения описаны в разделе "Сервис технической поддержки").	В заголовке указывается название проекта, данное название будет использоваться при дальнейших обращениях	РП со стороны проектной команды	Максимально заранее до старта проекта, как только появляется понимание об объеме проекта и сроках старта	Сервис технической поддержки: https://trivium-group.atlassian.net/servicedesk/customer/portals	Созданное в сервисе технической поддержки обращение с типом "Проект"
К обращению приложить исчерпывающую информацию о проекте: Название проекта, конечный заказчик, сроки реализации проекта Техническое задание Описание объема проекта (количество и сложность форм отчетов, карточек, дашбордов, объем данных, количество пользователей и т.д.), объем требований на среднесрочный и долгосрочный горизонт (фиксированный объем требований, который обсуждается с продуктовой командой и глобально не меняется в среднесрочной (квартал) и долгосрочной перспективе (год)). График реализации проекта по этапам(по договоренности с заказчиком) Предварительное видение архитектурного и технического решения проекта (архитектурная схема), включая: подсистемы \ модули системы интеграционные потоки внешнее ПО Eсли сервисом технической поддержки предполагается использование сразу несколькими участниками проектной команды, то необходимо зарегистрировать пользователей и приложить перечень почт участников, чтобы в дальнейшим видеть обращения в тех.поддержку всех участников проекта. Последующее добавление в группу проекта происходит с помощью обращения с типом "Консультация" от участника команды		РП со стороны проектной команды	Максимально заранее до старта проекта, как только появляется понимание об объеме проекта и сроках старта	Информация должна быть приложена в момент создания запроса. Информация может быть представлена в виде ссылки на внешний ресурс	К обращению приложена вся требуемая информация из чек-листа

Проработка архитектурных и технических решений (взаимодействие с продуктом)

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

Описание шага	Комментарий	Ответственный	Срок	Где выполняется шаг	Результат шага
Анализ исчерпывающей информации, полученной от проектной команды	В случае, если какой-то информации недостаточно, направляется запрос на уточнение \ предоставление доп. информации	Продуктовая команда	5 рабочих дней с момента получения обращения (при среднем приоритете)	Анализ - вне системы Задача с типом Проекта переводится в "На уточнение"	1. Продуктовая команда ознакомлена со всей необходимой информацией по проекту. 2. В системе регистрации обращений добавлен проект в список проектов 3. Добавлены задачи (тип задача) для проработки архитектурного решения
Проработка архитектурного решения с участием архитектурного комитета для принятия решения Состав архитектурного комитета: Представители от проектной команды (РП, Главный аналитик, Руководитель группы прикладной разработки) Представители от продуктовой команды (Архитектор, ПМ, Руководитель группы разработки - по необходимости)	На архитектурном комитете проводится обсуждение архитектурных и технический решений по проекту в привязке к задачам, на основании информации, полученной от проектной команды на шаге 1 "Инициация проекта".	Продуктовая команда		Архитектурный комитет - вне системы (очная или удаленная встреча проектной и продуктовой команды) Фиксация результатов принятого решения, архитектурная схема - на каком-либо информационном ресурсе, к которому организован доступ всему заинтересованному кругу лиц	1. Утвержденная архитектурная схема проекта с указанием обоснования выбранного решения, доступная на информационном ресурсе всем участникам процесса со стороны продуктовой и проектной команды. Выложен на ресурс. 2. Рекомендуемый состав команды разработки проекта 3. Перечень запросов на новую функциональность

Сервис технической поддержки

После утверждения архитектурной схемы стартует разработка системы. В процессе разработки, внедрения и гарантийной поддержки системы оперативное взаимодействие проектной и продуктовой команды ведется через Сервис технической поддержки.

ВАЖНО! В работу продуктовой командой берутся только те обращения, которые укладываются в утвержденную на этапе "Проработка архитектурных и технических решений" схему. Например, если на архитектурном комитете было принято решение реализовать функциональность прикладным способом, а проектная команда (в обход согласованному решению) решила сделать эту функциональность на продукте, то в таком обращении может быть отказано.

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

Возможные типы обращений:

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

Каналы поступления обращений:

• Сервис технической поддержки: https://trivium-group.atlassian.net/servicedesk/customer/portals

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-х недель она автоматически закрывается.