Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Мы внедрили 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-ов, которые добавляют свой анализ по выполненным задачам.
