[Управление проектами, Управление продуктом] OLAP-куб для аналитики процессов техподдержки

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
31-Мар-2021 13:31

Цитировать

Мы внедрили OLAP-куб, чтобы в реальном времени анализировать процессы техподдержки в наших продуктах. Рассказываем, как работает эта система и какие преимущества она нам обеспечила.Процессы техподдержки объединяют всех участников работы над продуктом: и инженеров поддержки, и разработчиков, и конечно же, PM и заказчика. На нижнем уровне нам важно следить за исправлением багов по SLA, на верхнем – контролировать общее состояние продукта, чтобы ошибки не тормозили его развитие.Когда мы взялись за создание аналитики нашей техподдержки, главной целью было обеспечить прозрачность процессов. Заявки на поддержку у нас собираются в Jira, а разработчики создают задачи в TFS. Прямой связи нет, отслеживать статусы приходилось вручную. Поэтому контролировать общую картину было очень сложно.Поэтому в прошлом году команда поддержки задумалась над метриками, которые позволили бы всем заинтересованным сторонам иметь консолидированную информацию по динамике загрузки, скорости обработки обращений на стороне поддержки и разработки.Под капотом OLAP-кубаНаша аналитика работает на базе следующих метрик:1. Открытые задачи: что передано в поддержку, что находится у разработчиков на исправлении.2. Закрытые задачи: с чем поддержка справилась сама, где потребовалось привлечь разработчиков, какие проблемы перешли в бэклог (если по согласованию с заказчиком команда решила, что исправление какой-то фичи сейчас не приоритетно).Некоторое время команда поддержки собирала эти метрики вручную, чтобы мы убедились, что нам нужны именно эти показатели. После этого силами BI-инженеров и специалистов инфраструктурного отдела мы процесс автоматизировали и собрали куб.

Он работает на базе BI-линейки Microsoft (ETL – MS SSIS, аналитика – MS SSAS, БД – MS SQL). К Jira мы подключаемся по API и получаем всю необходимую информацию по заявкам: когда создана каждая из них, с каким статусом, к какой задаче привязана в TFS и т.д. А с TFS работаем напрямую, забирая данные из её базы.Помимо текущих состояний, из Jira тянется история всех изменений в задаче. Это позволяет нам корректно рассчитывать все переходы между состояниями задач, чтобы, к примеру, в данных не было задвоений, если задачу несколько раз закрывали и открывали.Одна из сложностей – это установить связь между заявкой в Jira и задачей в TFS. Ссылку на TFS инженеры поддержки добавляют сами, а где свободный ввод данных, там и риск ошибок и неточностей. Мы разработали систему проверок, которые помогают установить корректные связи по косвенным признакам: проекты, даты, исполнители и т.п.Под каждую метрику мы можем прописывать любые правила, обогащая логику расчёта. Дополнительные контроли проверяют, чтобы связи между результирующими метриками не нарушались. Так что в будущем мы сможем добавлять метрики без ущерба для итоговой картины. Такой подход также позволит добавлять данные из других принципиально новых источников – например, связать задачи со статьями в Confluence.Какие мы получили результатыКуб показывает загрузку техподдержки, динамику отработки обращений по продуктам, динамику выполнения задач в командах разработки, созданных техподдержкой. Весь объём заявок обрабатывается примерно за минуту, так что обновление происходит фактически в реальном времени.В результате PM-ы, руководители и сама служба техподдержки может контролировать:

Насколько эффективно взаимодействуют команды поддержки и разработки, как быстро решают задачи друг друга.
Хорошо ли в рамках техподдержки работает problem solving, как идёт передача знаний от разработчиков инженерам поддержки – если всё хорошо, то количество заявок от поддержки в разработку по продукту должно уменьшаться.
Хватает ли нам специалистов техподдержки на продуктах – как быстро уменьшается объём обращений.

И самое важное – мы можем отлавливать рассинхрон статусов между Jira и TFS, т.е. когда в TFS задача закрыта, а в Jira открыта и наоборот. Второй сценарий – это серьёзный риск для команды, потому что это значит, что поддержка посчитала задачу закрытой, а разработчики на самом деле продолжают над ней работать. В каждом таком случае нужно быстро разбираться – это кто-то забыл статус перещёлкнуть или в коммуникациях произошёл сбой.Наконец, куб автоматизировал подготовку регулярных отчётов по поддержке продуктов, которые мы предоставляем нашим заказчикам. Больше не приходится собирать данные вручную – 90% работы происходит по нажатию одной кнопки. Оставшиеся 10% - это интеллектуальный вклад поддержки и PM-ов, которые добавляют свой анализ по выполненным задачам.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_proektami (Управление проектами), #_upravlenie_produktom (Управление продуктом), #_tehpodderzhka (техподдержка), #_analitika (аналитика), #_olap, #_upravlenie_proektami (
Управление проектами
), #_upravlenie_produktom (
Управление продуктом
)

Профиль ЛС

Ответить на тему

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

Текущее время: 22-Ноя 23:15
Часовой пояс: UTC + 5