Итак, на дворе 2023 год. У нас происходит трансформация ИТ отдела, и мы начинаем общение с программистами, чтобы определить узкие места в работе. Стоит, наверное, отметить что компания не самая маленькая, количество основных баз 3, в каждой из них по 600+ человек, но штат 1С-ников +- 5 человек.
И, как оказалось, самая большая проблема - это отсутствие первой линии службы поддержки (далее СП), как и в целом службы поддержки. Все валилось на программиста: была ли это ошибка кода, ошибка ввода данных, ошибки работы сетевого стека, ошибки RDP серверов. ВСЁ падало на программиста 1С, если пользователь в этот момент работал в 1С.
И вот в одном из общений с нашим программистом (он был из другого города, и встреча была организована лично) он показал список его задач, повествуя, что он уже не понимает, что приоритетнее из них, а что нет, но ему все равно поступают звонки с просьбами и новыми задачами. В глазах он "умолял" нас сделать линию консультации (первую линию поддержки).
Взвесив все ЗА и ПРОТИВ, и приняв тот факт, что у нас есть отличный планировщик задач в виде Atlassian JIRA, мы решили как-то наладить этот механизм.
Понимая, что JIRA позволяет использовать REST API, и изучив документацию, мы решили сделать инструмент, который покроет ряд первостепенных задач:
- механизм "Единого окна". Общение постановщика задачи напрямую, не выходя из 1С, с СП
- формирование статистики и классификация проблем
- сбор информации для написания документации. В дальнейшем это позволит отвечать на вопросы разработанными инструкциями, своевременно их актуализировать
- оценка работы СП
- повышение уровня работы пользователя 1С
- привлечение программиста только по требуемым задачам
Пользователь, получая ошибку, должен иметь возможность отправить сформированный набор данных, причем не только текст с описанием проблемы, но и как гласит поговорка: "Лучше один раз увидеть, чем сто раз услышать", мы задумались о том, чтобы делать скриншот экрана с ошибкой. Тут нас поджидала проблема, потому что часть наших баз работают на конфигурации УПП, а значит, это обычные формы, и у них нет возможности использовать механизма отображения ошибок (ссылка). Копаясь в документации и в переписке с разработчиками, нас убедили, что с обычными формами мы не получим готового механизма, и решили сделать свой.
Итак, у нас появилась форма для формирования обращения в СП:
На стороне планировщика заданий JIRA мы создали проект и настроили в нем Бизнес-процесс.
Задача, прилетая из 1С, встает в статус " В ожидании поддержки", из которого в случае ответа СП попадает в статус "В ожидании клиента", или при необходимости работник СП переводит в статус "Застряла", подключает для решения вопроса аналитика или программиста. Далее опять в статус "В ожидании клиента", и уже после этого постановщик задачи отмечает ее статус "Решена" с отметкой оценки о качестве выполнения задачи, или в статус "Отмена".
При формировании задачи в 1С сохраняем данные в регистре сведений из JIRA о созданной задаче, чтобы в последующем могли синхронизировать между двумя системами. Данные о задачах отображаем в окне формы Службы поддержки. В зависимости от статуса можем окрасить задачи для "читабельности". К задаче прикрепляем опционально скриншот экрана, и формируем XML файл с последними 10 записями журнала регистрации. Этого хватает, чтобы увидеть, есть ли какие то ошибки в модулях и если есть, то в каких строках.
Для удобства общения задачу можно открыть чтобы дополнить данными, добавить информацию или сделать еще скриншот, в случае понимания свой ошибки ее можно отменить, или завершить.
Так же чтобы JIRA могла оповещать о том, что в задаче произошли изменения, в систему 1С на стороне JIRS настраиваем webhook-и, и начинаем кидать в сторону 1С информацию об изменениях в конкретной задаче.
На стороне 1С поднят HTTP метод для приема сообщений от JIRA, и записи изменения статуса в регистр сведений.
Также был реализован редактор скриншотов для удобства пользователя не искать сторонние инструменты, чтобы "точечно" указать о проблеме.
Ну и чтобы не заставлять пользователя бегать в поисках, был ответ или нет, мы подвесили обработчик ожидания для проверки изменения статуса по задаче. В случае изменения, пользователю выскакивало окно с оповещением и предлагается открыть задачу и посмотреть по ней комментарии СП, или отложить открытие или продолжить работу.
Пример рабочего пространства в обеих системах:
Мы получили ощутимый результат по всем показателям, которые ставили перед собой!!!
Формирование документации стало отдельной историей, которая несет положительные результаты!!!
Сейчас мы перенесли данный функционал на расширение и используем его на типовых конфигурациях (ДО, ЕРП).
