Платформа 3V/Инструкция по работе с платформой/Инструкция по работе с сервисом технической поддержки проектов на платформе 3V
< Платформа 3V | Инструкция по работе с платформой
Перейти к навигации
Перейти к поиску
Версия от 08:36, 28 января 2022; Il.iashin (обсуждение | вклад)
Содержание
- 1 Общие положения
- 2 Инициация старта взаимодействия проекта с продуктом
- 3 Проработка архитектурных и технических решений (взаимодействие с продуктом)
- 4 Сервис технической поддержки
Общие положения
Стандарт технической поддержки определяет порядок взаимодействия между командой, выполняющей проект в интересах конечного заказчика на платформе, и командой разработки продукта (платформы 3V).
Участники процесса:
- Проектная команда
- Продуктовая команда
Типы взаимодействия участников процесса
По каждому проекту должно быть организовано 3 этапа взаимодействия:
- Инициация старта взаимодействия проекта с продуктом
- Проработка архитектурных и технических решений
- Оперативное взаимодействие на этапе разработки и внедрения системы, а также гарантийной поддержки - сервис технической поддержки платформы
Для доступности информации и одинакового понимания договоренностей между всеми участниками процесса, каждый этап взаимодействия имеет свои правила фиксации шагов и результатов, которые более детально расписаны ниже.
Инициация старта взаимодействия проекта с продуктом
До старта проекта должна быть организована коммуникация между проектной и продуктовой командами для совместной выработки архитектурных и технических решений проекта на платформе. Первым шагом проектной команде необходимо провести инициацию проекта.
Алгоритм действий для инициации проекта
| Описание шага | Комментарий | Ответственный | Срок | Где выполняется шаг | Результат шага |
|---|---|---|---|---|---|
| Создать обращение в сервисе технической поддержки с типом "Проект" (правила оформления обращения описаны в разделе "Сервис технической поддержки"). | В заголовке указывается название проекта, данное название будет использоваться при дальнейших обращениях | РП со стороны проектной команды | Максимально заранее до старта проекта, как только появляется понимание об объеме проекта и сроках старта | Сервис технической поддержки: https://trivium-group.atlassian.net/servicedesk/customer/portals | Созданное в сервисе технической поддержки обращение с типом "Проект" |
К обращению приложить исчерпывающую информацию о проекте:
|
РП со стороны проектной команды | Максимально заранее до старта проекта, как только появляется понимание об объеме проекта и сроках старта | Информация должна быть приложена в момент создания запроса.
Информация может быть представлена в виде ссылки на внешний ресурс |
К обращению приложена вся требуемая информация из чек-листа |
Проработка архитектурных и технических решений (взаимодействие с продуктом)
После того, как направлен запрос на инициацию проекта и исчерпывающая информация, продуктовая команда инициирует процесс проработки архитектурных и технических решений.
| Описание шага | Комментарий | Ответственный | Срок | Где выполняется шаг | Результат шага |
|---|---|---|---|---|---|
| Анализ исчерпывающей информации, полученной от проектной команды | В случае, если какой-то информации недостаточно, направляется запрос на уточнение \ предоставление доп. информации | Продуктовая команда | 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 числа каждого месяца заказчики не увидели изменений по своим обращениям с приоритетом Средний и ниже, и критичность не изменилась, то обращение не будет взято в работу в ближайший месяц.
Важно! Для обращения с типом "Запрос на новую функциональность" приоритет влияет на очередность включения в ближайший спринт.
Доступность технической поддержки
| Опция | Период доступности |
|---|---|
Прием и регистрация запросов:
|
Круглосуточно |
| Консультации, поиск вариантов решений проблем, исправление ошибок | пн-пт с 9.00 до 18.00 (Мск) |
Алгоритм действий при возникновении Ошибки
Алгоритм
- Проверить, нет ли текущей ошибки в списке зарегистрированных обращений с типом "Ошибка".
- Если ошибки нет в списке, необходимо создать обращение с типом "Ошибка" в Сервисе технической поддержки
- Для создания обращения в Сервисе технической поддержки необходимо зарегистрироваться. Пользователи с уровнем доступа Гость не могут создавать Обращения.
Обязательные сведения для подачи заявки
- Заголовок с кратким описанием ошибки
- Критичность (наивысшая, высокая, средняя, низкая, наинизшая)
- Если критичность наивысшая или высокая, то нужно указать основание критичности
- Проект, на котором используется платформа и возникла ошибка
- Описание ошибки
- Пример повторения ошибки: шаги для повторения, url, пользователь/пароль и иная информация, по которой незнакомый с проектом человек сможет повторить ошибку. Крайне желательно, указывать, в качестве примера для повторения ошибки, пример в минимальном объеме требуемым для повторения ошибки (Например, убрать лишние столбцы, сократить объем данных, убрать лишние элементы управления)
- Версия платформы, которая используется на проекте
Описание процесса
- Заказчик добавляет ошибку с заполненными обязательными полями. Устанавливается статус «Новая».
- Все новые заявки просматриваются и переводятся на рассмотрение. Устанавливается статус «На рассмотрении».
- Заявка первично обрабатывается(проверяется заполнение обязательных полей, воспроизведение ошибки, поиск аналогичных ошибок). После этого статус заявки может быть изменён на один из следующих:
- «На уточнении», если требуется уточнение у заказчика. Если заявка находится в статусе «На уточнении» больше 3-х недель она автоматически закрывается.
- «Закрыта», если
- существует аналогичная ошибка. В комментарии указывается ссылка
- в заявке описано запланированное поведение
- не воспроизводится(определяется в статусе «На уточнении» с подтверждением заказчика)
- «В очереди», если заявка правильно составлена.
- При статусе «В очереди» заказчику видны все заявки (от всех пользователей) отсортированные в порядке приоритета (от высшего к низшему). С данного шага задачи берутся в работу (в первую очередь берутся заявки с наибольшим приоритетом). Когда начинается работа по заявке устанавливается статус «В работе».
- Заявка выполняется. По завершению, указывается версия продукта, в котором есть исправление. Устанавливается статус «Приемка»
- Заказчик проверяет исправление по заявке, при удовлетворительной реализации устанавливает статус «Закрыто». При неудовлетворительной реализации устанавливает статус «На рассмотрении». Если заявка висит в приемке больше 3-х недель она автоматически закрывается.
Алгоритм действий при необходимости получения Консультации
Алгоритм
- Самостоятельный поиск ответов на вопросы в руководстве пользователя, Wiki, Ask Bot. Онлайн-документация и Wiki доступны без авторизации.
- В случае, если ответ не найден самостоятельно, создается обращение в Сервисе технической поддержки с типом "Консультация"
- Для создания обращения в Сервисе технической поддержки необходимо зарегистрироваться. Пользователи с уровнем доступа Гость не могут создавать Обращения.
Обязательные сведения для подачи заявки:
- Заголовок с кратким описание обращения
- Критичность (наивысшая, высокая, средняя, низкая, наинизшая)
- Если критичность наивысшая или высокая то нужно указать обоснование критичности
- Проект на котором используется платформа
- Тип обращения (консультация, проблема)
- Описание проблемы, которую не удается решить с использованием платформы
- Описание примера, по возможности сопровождая скриншотами или ссылками на реальную систему. При попытках решить проблемы самостоятельно, расписать варианты
- Версия платформы, которая используется на проекте
Описание процесса
- Заказчик добавляет обращение с заполненными обязательными полями. Устанавливается статус «Новая».
- Все новые заявки просматриваются и переводятся на рассмотрение. Устанавливается статус «На рассмотрении».
- Заявка первично обрабатывается(проверяется заполнение обязательных полей, воспроизведение ошибки, поиск аналогичных ошибок). После этого статус заявки может быть изменён на один из следующих:
- «На уточнении», если требуется уточнение у заказчика. Если заявка находится в статусе «На уточнении» больше 3-х недель она автоматически закрывается.
- «В очереди», если заявка правильно составлена
- «Закрыто», если
- есть аналогичная заявка. В комментарии указывается ссылка
- является ошибкой. В комментарии указывается ссылка
- является новой функциональностью. В комментарии указывается ссылка
- не воспроизводится(определяется в статусе «На уточнении» с подтверждением заказчика)
- При статусе «В очереди» заказчику видны все заявки (от всех пользователей) отсортированные в порядке приоритета (от высшего к низшему). С данного шага задачи берутся в работу (в первую очередь берутся заявки с наибольшим приоритетом). Когда начинается работа по заявке устанавливается статус «В работе».
- Заявка выполняется. По завершению, указывается вариант решения или заключение. Устанавливается статус «Приемка». Если заявка находится в статусе «Приемка» больше 3-х недель она автоматически закрывается.
- При необходимости проводится совместное с заказчиком обсуждение результатов работы по заявке.
- Фиксируется договоренности или рекомендации по решению. Устанавливается статус "Закрыто"
Алгоритм действий при необходимости фиксации обращения "Запрос на новую функциональность"
Алгоритм
- Проверить, нет ли аналогичного запроса на новую функциональность.
- Если требования нет в списке, необходимо создать обращение с типом "Запрос на новую функциональность" в Сервисе технической поддержки
- Для создания обращения в Сервисе технической поддержки необходимо зарегистрироваться. Пользователи с уровнем доступа Гость не могут создавать Обращения.
Обязательные сведения для подачи заявки:
- Заголовок с кратким описанием функциональности
- Критичность (наивысшая, высокая, средняя, низкая, наинизшая)
- Если критичность наивысшая или высокая то нужно указать обоснование критичности
- Проект, на котором используется платформа и планируется использовать функциональность
- Тип обращения (запрос на новую функциональность)
- Описание проблемы, которую предполагается решить с помощью требуемой функциональности
- Описание сценария использования
- Версия платформы, которая используется на проекте
Описание процесса
- Заказчик добавляет заявку на новую функциональность с заполненными обязательными полями. Устанавливается статус «Новая»
- Все новые заявки просматриваются и переводятся на рассмотрение. Устанавливается статус «На рассмотрении»
- Заявка первично обрабатывается(проверяется заполнение обязательных полей, поиск аналогичных заявок. После этого статус заявки может быть изменён на один из следующих:
- «На уточнении», если требуется уточнение у заказчика. Если заявка находится в статусе «На уточнении» больше 3-х недель она автоматически закрывается.
- «Анализ», если требуется анализ функциональности
- «Готово», если
- существует аналогичный запрос на новую функциональность. В комментарии указывается ссылка
- является ошибкой. В комментарии указывается ссылка
- не является функционалом применимым к продукту
- «В очереди», если заявка правильно составлена.
- При статусе «В очереди» заказчику видны все заявки (от всех пользователей) отсортированные в порядке приоритета (от высшего к низшему). С данного шага задачи берутся в работу (в первую очередь берутся заявки с наибольшим приоритетом). Заявки берутся в работу раз в три недели. Когда начинается работа по заявке устанавливается статус «В работе».
- Заявка выполняется. По завершению, указывается версия продукта, в котором есть исправление, пример и описание использования. Устанавливается статус «Приемка».
- Заказчик проверяет проверяет функциональность, при удовлетворительной реализации устанавливает статус «Закрыто». При неудовлетворительной реализации устанавливает статус «На рассмотрении». Если заявка висит со статусом "Приемка" больше 3-х недель она автоматически закрывается.