Регламент взаимодействия между (внутренними подразделениями компании) технической поддержкой и разработкой.   Общая информация. В данном документе регламентирован процесс взаимодействия посредством каналов связи между подразделениями компании на основании зон ответственности и сроков реакции\устранения инцидентов и запросов.       I.            Зоны ответственности Таб.1. Зоны ответственности подразделений

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

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

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

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. Типизация обращений   Тип обращения – атрибут задачи, который используется для различения поступающих в службу технической поддержки запросов. Категория – атрибут задачи, который используется для разграничения задач по конкретному типу исходя со сложности, глобальности и критичности обрушения. Определения типов обращений Инцидент – обращение Заказчика которое описывает проблемы в работе системы, не связанные с ошибками на уровне программного кода или некорректной логикой работы функционала. Доработки\изменения – обращение Заказчика с запросом о проведении дополнительных работ, необходимых для изменения текущей конфигурации системы с целью внесения изменений в процессы Заказчика. Консультация – коммуникация с заказчиком в письменной, устной или демонстративной форме с целью объяснения ситуаций и решения, связанных с ними проблем. Баг – обращение Заказчика которое описывает некорректное или неожиданное поведение системы из-за ошибок на уровне программного кода. Описание категорий В инцидентах существуют три категории, которые базируются на критичности нарушения реализации основных бизнес процессов Заказчика:

• Авария – неисправность, характеризующаяся полным отсутствием работоспособности Системы или ее части, связана с невозможностью реализации процессов, выполняемых Заказчик, и которая не может быть устранена путем перезагрузки сервера или клиентского приложения.
• Серьезная неисправность – неисправность, которая характеризуется отсутствием стабильности в работе Системы или ее части, которая обусловлена периодической (более, чем один раз в течение суток) потерей способности Системы реализовывать процессы, которые выполняет Заказчик, и которая может быть устранена путем перезагрузки сервера или клиентского приложения.
• Мелкая неисправность – неисправность, которая характеризуется незначительными отклонениями от нормы в работе Системы, не влияет на возможность реализации процессов, выполняемых Заказчиком.

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

• Новый функционал – запрос по созданию нового функционала, который не настроен\внедрен на проекте.
• Существующий функционал – запрос по модернизации\правке\доработке существующего ф-ла который внедрен на проекте.

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

• блокирование взаимодействия пользователя с системой;
• невыполнение основных функций системы;
• сбои;
• потери данных;
• нарушение логики работы
• и другие подобные моменты связанные с нарушением выполнения основных функций системы

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

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

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

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

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

• Критичная консультация – описывает необходимость предоставить консультацию Заказчику, предоставление которой блокирует выполнение основных бизнес процессов. Например, консультация по добавлению нового поля в форму, без которого не можно создавать карточки жителей.
• Важная консультация – описывает необходимость предоставления консультации Заказчика, для устранения некорректного взаимодействия пользователя с системой. Например, консультация по тому, как корректно редактировать форму без ее пересоздания.
• Некритичная консультация – описывает необходимость предоставить консультацию Заказчику по некритичным вопросам и функционалу. Например, консультация по вопросам работы фильтров выборки поиска страницы.

 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=2&modificationDate=1495191143668&cacheVersion=1&api=v2&width=503&height=161
Описание приоритетов приведено в таблице ниже. Таб.4. Приоритеты обращений.

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

• На выполнении
• В работе
• Решена
• Обратная связь

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

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