(Б-21) Реєстр територіальних громад Киева : С пользователями системы (SLA)

С пользователями системы (SLA)


Общая информация.

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

  1. Отреагировать на запрос клиента в регламентное время.
  2. Разобраться в чьей зоне ответственности находится задача.
  3. Дать ответ клиенту, сообщив номер тикета и отдел, на который передан запрос
  4. Решить проблему в регламентированный срок.


Пояснительная информация:

I.                 Зоны ответственности отделения технической поддержки

     Таб.1. Зоны ответственности подразделений

Разработка
* Консультации технической поддержки;
* Устранение багов;
* Устранение инцидентов;
* Выполнение доработок\изменений функционала.

    II.            Каналы коммуникации Каналы коммуникации – средства передачи информации, по которым должна происходить коммуникация по рабочим вопросам между подразделением технической поддержки компании. Официальные каналы, связи по которым должна происходить коммуникация приведены в таблице ниже. Таб.2. Каналы коммуникации

Канал коммуникации Техническая поддержка
JIRA (общий пользователь подразделения в системе).support
Почта rtgk@itsup.kiev.ua
Телефон (044)-290-18-56

(___)-___-__-__.
Другое




 III.            Сроки реакции и решения  запросов В данном разделе описаны сроки реакции подразделения технической поддержки на обращения от клиентов, сроки выполнения задач\запросов. Срок реакции – время, за которое подразделение технической поддержки обязано отреагировать на запрос\задачу в зависимости от типа обращения, т.е. предоставить обратную связь по запросу или принять задачу в работу. Сроки устранения \выполнения – время, за которое подразделение технической поддержки обязано устранить инцидент либо передать задачу в подразделение разработки для произвдения доработки, предоставления консультации или устранения бага и по факту выполнения задачи уведомить клиента. Сроки могут корректироваться в зависимости от блокирующих факторов или приоритета запроса. Таб.3. Сроки реакции и устранения\выполнения.

Тип обращения Категория Сроки реакцииСроки устранения \выполнения
Инцидент Авария 15 минут 3 часа
Серьезная неисправность45 минут 6 часов
Мелкая неисправность 3 часа 24 часа
Доработки\измененияНовый функционал 24 часа 6-9 спринтов
Существующий функционал24 часа 3-6 спринтов
Другое 24 часа 9 спринтов
Баг Критичный 24 часа 3-6 раб. дней
Важный 24 часа 3 спринта
Некритичный 24 часа 6 спринтов
Консультация Критичный 3 час 6 часов
Важный 6 часа 12 часов
Некритичный 16 часа 32 часа


Под часом иметься в виду один час рабочего времени. Следовательно, срок реакции в 8 часов подразумевает, что сотрудник технической поддержки должен отреагировать на запрос в течении 8 рабочих часов. Процесс коммуникации по задачам (эскалирование задач) Эскалирование задач осуществляется путем передачи задачи (или подзадачи) ответственному сотруднику на стороне разработки или общему пользователю подразделения. Алгоритм эскалирования задач Для ответственного сотрудника технической поддержки:

  1. Актуализировать задачу:

1.1.   Установить соответствующий приоритет. По умолчанию должен быть выставлен средний приоритет. 1.2.   Актуализировать поля в задаче (смотри соответствующий раздел документа): 1.2.1.      Внести всю необходимую информацию в описание; 1.2.2.      Описать проделанные действия по задаче; 1.2.3.      Указать дополнительную информацию по задаче.

  1. Назначить задачу ответственному пользователю в тикет-системе.
  2. Получить обратную связь по реакции на задачу в соответствии с регламентными сроками – удостовериться, что задача принята в работу.

3.1.   При необходимости проконсультировать сотрудника разработки, уточнить необходимую информацию. 3.2.   В случае, если нет реакции в регламентное время – связаться с ответственным сотрудником по телефону и уточнить причины.

  1. Получить задачу после ее выполнения другим подразделением для получения обратной связи от заказчика о корректности ее выполнения.

4.1.   При некорректном выполнении задачи – эскалировать задачу на ответственного пользователя разработки. Для ответственного сотрудника разработки:

  1. Отреагировать на переданную задачу и принять ее в работу в регламентное время.

1.1.   При необходимости уточнить детали или вернуть задачу в техническую поддержку.

  1. Выполнить задачу в регламентное время.

2.1.   При невыполнении регламентных сроков – уведомить сотрудника технической поддержки в виде комментария в задаче или посредствам других каналов связи 2.2.   Описать резолюцию. 2.3.   Удостоверится о корректности ее выполнения.

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

В каких случаях можно использовать другие каналы связи для коммуникации с подразделением разработки?

  1. Телефон:

1.1.   При авариях с высоким приоритетом, которые полностью блокируют выполнение основных бизнес процессов заказчика или других подобных случаях и их устранение должно быть выполнено в кратчайшие сроки. 1.2.   При невыполнении регламентных сроков реакции и выполнения задач. 1.3.   При необходимости проконсультироваться по нетривиальным задачам, описания которых нет в БЗ и которые имеют высокий приоритет.

  1. Почта:

2.1.   Информирование коллег. 2.2.   Коммуникация по вопросам оптимизации взаимодействия.
   V.            Описание типов обращений Все обращения, которые фиксируются в тикет-системе делятся на 4 основных типа. У каждого из типов есть своя категория. Общая схема типизации изображена на рисунке ниже.
Рис.1. Типизация обращений  ucplatform.atlassian.net_wiki_download_attachments_42747_d0_a2_d0_b8_d0_bf_d0_b8_d0_b7_d0_b0_d1_86_d0_b8_d1_8f_20_d0_be_d0_b1_d1_80_d0_b0_d1_89_d0_b5_d0_bd_d0_b8_d0_b9.jpg Тип обращения – атрибут задачи, который используется для различения поступающих в службу технической поддержки запросов. Категория – атрибут задачи, который используется для разграничения задач по конкретному типу, исходя со сложности, глобальности и критичности обращения. Определения типов обращений: Инцидент – обращение Заказчика которое описывает проблемы в работе системы, не связанные с ошибками на уровне программного кода или некорректной логикой работы функционала. Доработки/изменения – обращение Заказчика с запросом о проведении дополнительных работ, необходимых для изменения текущей конфигурации системы с целью внесения изменений в процессы Заказчика. Консультация – коммуникация с заказчиком в письменной, устной или демонстративной форме с целью объяснения ситуаций и решения, связанных с ними проблем. Баг – обращение Заказчика, которое описывает некорректное или неожиданное поведение системы из-за ошибок на уровне программного кода. Описание категорий В инцидентах существуют три категории, которые базируются на критичности нарушения реализации основных бизнес-процессов Заказчика:

Доработки\изменения имеют две категории, которые основаны на наличии или отсутствии функционала в системе:

Тип задач Баг имеет три категории, которые основаны на критичности некорректной работы или поведения системы. Критичный баг – обращение, которое описывает:

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

Примером такого бага может быть невозможность просмотреть заполненную форму после ее редактирования без перелогина в систему. Некритичный баг – обращение, которое описывает:

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


 VI.            Описание приоритетов обращений В зависимости от сложности, глобальности и важности обращения, существуют 3 основных приоритеты обращений которые применимы ко всем типам обращений. На схеме ниже приведены эти приоритеты.
Рис.2. Приоритеты обращений %D0%9F%D1%80%D0%B8%D0%BE%D1%80%D0%B8%D1%82%D0%B5%D1%82%D1%8B%20%D0%BE%D0%B1%D1%80%D0%B0%D1%89%D0%B5%D0%BD%D0%B8%D0%B9.jpg?version=1&modificationDate=1495431995798&cacheVersion=1&api=v2&width=503&height=161
Описание приоритетов приведено в таблице ниже. Таб.4. Приоритеты обращений.

ПриоритетОписание
Срочный Критический, безотлагательный статус обращения, который предусматривает продуктивное выполнение задачи в кратчайшие сроки
Высокий Максимальный приоритет обращения, который подразумевает:

* невозможность выполнять основные бизнес процессы заказчика;
* нарушения выполнения основных бизнес процессов.
Средний Стандартный приоритет задач. Не подразумевают нарушения выполнения основных бизнес процессов заказчика.
Низкий Обращения, которые имеют низкий приоритет и никак не влияют на выполнения основных или вторичных бизнес процессов заказчика.

- VII.            Описание полей в тикет системе. Таб.5. Описание основных полей в системе учета заявок Поле Описание Поле Описание Проект* Данное поле необходимо для сопоставления задачи с проектом (заказчиком) для которого она выполняется. Тип обращения* Данное поле обозначает зону ответственности выполнения задачи. Т.е. показывает сложность задачи и понимание, какой квалификации специалист нужен для ее выполнения, а также, в зоне ответственности какого департамента находиться выполнения данной задачи. Категория задачи* Поле предназначено для категоризации задач и их разграничения исходя со сложности, глобальности и других факторов. У каждого типа обращения имеется своя категория задачи. Тема* Тема – краткое по содержимому поле, которое описывает суть задачи. Приоритет* Поле, которое указывает критичность задачи в зависимости от различных факторов. Исполнитель* Сотрудник (пользователь в системе JIRA), которому назначается задача. Автор* Сотрудник, который создал (создает) задачу. По умолчанию именно тот пользователь, который создает конкретную задачу При необходимости можно указывать конкретного пользователя. Срок исполнения* Дата выполнения задачи или предоставления промежуточной резолюции по задаче заказчику. Deadline Крайний срок выполнения задачи. Необходим для понимания конечного срока, когда задача должна быть выполнена. Изменяется и устанавливается только по согласованию с заказчиком или PM Контактные данные* Поле, в котором указываются контактные данные заказчика задачи, по которым с ним можно связаться. Описание* Данное поле должно содержать краткое описание задачи\запроса, с которым обратился заказчик или описание сути задачи Организация Район, с которого поступило обращение в поддержку Статус задачи* Поле указывает на состояние конкретной задачи. Существуют следующие состояния:

Таб.6. Дополнительные поля

Поле Описание
Комментарий Поле, необходимо для комментирования состояния и каких-либо действий по задаче.
WorkLog Поле для фиксирования и описания затраченного сотрудником времени по действиям в рамках выполнения конкретной задаче.
Категория задачи*Поле предназначено для описания резолюции при закрытии задач. Обязательное поле при закрытии задачи.

Предусмотрены следующие резолюции:

* Выполнена
* Исправлено
* Не выполнена
* Отменена
* Невозможно воспроизвести
* Дубликат
* Недостаточно информации


 VIII.            Workflow для задач поддержки Workflow – графическое представление последовательности действий при выполнении задач.