Собственно все содержание статьи уместилось в заголовке.nnПеред нами стояла задача оценить качество работы сотрудников службы технической поддержки, которые работали в Jira на протяжении последних 3х месяцев.nnКонечно же, сказать — проще, чем сделать. И первый вопрос, который перед нами встал – как оценивать.nnДля этого были определены некоторые абстрактные понятия, которые формировались на базе конкретных чисел.n
Мы пытались найти:
Эффективность работы = коэффициент скорости работы + коэффициент качества работы.nnПод понятием скорость на самом деле скрывалось время выполнения одной усредненной задачи, а качество работы основывалось на количестве задач с превышенным SLA (service level agreement).n
Что упростило нам задачу
В команде был разработан набор положений, согласно которому достаточно легко можно было определить критерии SLA, которых нужно придерживаться. Также был выстроен бизнес-процесс, достаточно детально фиксирующий каждый этап требуемых работ. В рамках бизнес-процесса требовалось заполнение поля, которое относило задачу к определенной категории. Также сотрудники вели учет времени, затраченного на решение зафиксированного вопроса.n
С какими трудностями мы столкнулись при анализе в жира
Не всегда все поля задачи при прохождении по статусам бизнес процесса заполнялись корректно. У заказчика не оказалось инструментов для анализа имеющихся данных в Jira. Права на получение данных были ограничены одним проектом.n
Как мы вышли из положения:
Мы использовали бесплатный плагин JIRA Misc Custom Fields для Жира, который позволяет создавать калькулируемые поля, в том числе, отражающие время выполнения определенной транзакции. Это позволило нам получить наиболее приближенные к реальным временным рамкам сроки поиска решения задачи и применение этого решения. Для определения нарушения SLA.
nnИспользуя Project Pivot Report мы получили данные по всем законченным задачам за анализируемые 3 месяца. И отдельно – количество незаконченных задач, и их перечень. По поиску причин наличия незаконченных задач руководство провело отдельную работу. Мы же занимались анализом завершенных задач.nnПолученные данные мы экспортировали в Excel, а оттуда в таблицу Access. Это позволило использовать инструменты SQL для анализа полученной таблицы с данными. Выбор пал именно на Access только по тому, что это ПО было проще всего применить в нашем случае. В принципе подошел бы любой движок баз данных.nnС помощью нескольких несложных SQL запросов мы разделили все категории задач на три группы по общему времени выполнения задачи. Быстро выполняемые, задачи средней скорости выполнения, долго выполняемые. Задач второй группы оказалось около 70% , поэтому дальнейший анализ работы сотрудников выполнялся именно по ним, однако мы рекомендовали руководству рассмотреть и оставшиеся 2 группы по предложенному нами принципу.
nnИтак, мы за каждый месяц определили количество задач, выполненных каждым сотрудником, среднее время выполнения задачи, отношение числа просроченных задач к общему количеству выполненных задач.nnДанные экспортировали обратно в excel. По каждому из показателей построили графики и сформировали тренд.nnПолучились такие картинки: 
nn nnОказалось, что тренд соответствует ожиданиями руководства по изменению нагрузки на специалистов службы Service Desk заказчика. Работа сотрудников, показатели которых явно выпадали из среднестатистических, была проанализирована дополнительно. Что помогло выявить причины и помочь устранить их. В частности, одному из специалистов требовалось дополнительное обучение по узконаправленной тематике, с которой пришлось столкнуться в процессе работы, а другой был перегружен из-за совмещения задач технического специалиста и руководящих обязанностей.nnСпециалисты с высокой скоростью работы и минимальным количеством «просроченных» задач получили материальное вознаграждение.
nnДля будущих анализов при формировании качества работы мы также предложили учитывать количество возвратов задачи на исполнение после проверки контролирующими персонами. (Бизнес-процесс заказчика позволяет это сделать.) А также добавить коэффициент удовлетворенности потребителя, то есть создателя задачи, который обратился в службу технической поддержки со своей проблемой. Ну и, конечно же, обзавестись удобным инструментом, для получения наглядных графиков и диаграмм.nnПодводя итог, можно сказать, что выводы можно сделать практически из любого набора данных, а вот правильность их зависит от качества имеющейся информации. Если Вы планируете делать аналитику на базе информации накопленной в Жира, первое, о чем нужно подумать – какую информацию Вы хотите получить. Затем необходимо оценить, хватает ли входных данных, для получения нужных цифр для ожидаемого вывода. После чего – выбрать наиболее простой инструмент для удобного получения и отображения накопленной статистики, а также формирования цифр, которые помогут сформировать требующийся результат.n
Если Вам все это кажется достаточно сложным и утомительным делом – обращайтесь к нам, [email protected]. Мы всегда готовы предложить простые решения для сложных проблем!