Привет! Я Арсен, разработчик в DDPlanet. Хочу рассказать, как мы делали свою систему KPI для оценки - кто и сколько реально работает.
Почему мы решили создать сервис KPI?
Сначала всё было просто. У нас был Azure DevOps, и через него мы вели задачи. Но со временем стало ясно - не хватает прозрачности. Нельзя было нормально понять, кто сколько сделал, сколько времени ушло, где узкие места.
Мы хотели видеть сводку по команде - без ручного копания в тасках. А еще важно было, чтобы сами сотрудники могли смотреть, на что у них уходит время.
Так и появилась идея - собрать свой KPI-сервис. Он сам вытягивает данные из Azure DevOps и показывает всё на наглядных дашбордах. Руководители видят, кто как работает, а сотрудники - сколько времени потратили и на что.
Простое решение, которое закрыло сразу несколько проблем.
Как мы создавали первую версию
Когда мы разрабатывали первую версию сервиса KPI, был выделен список целей:
Импорт данных – сбор необходимых данных в реальном времени из различных систем (в первую очередь из Azure DevOps).
Общая статистика в разрезе проектов – отображение кол-ва User Story, багов в различных состояниях, суммарных показателей затраченного времени и т.п..
Показатели в разрезе сотрудников – таблица сотрудников, отражающая кол-во закрытых и решенных часов, отклонения от нормы.
Детальная страница сотрудника – страница с детализацией закрытых, решенных и текущих задач относительно сотрудника.
Отправка отчетов руководителям и сотрудникам – руководителям нужно было отправлять ежедневный отчет по KPI своей команды, а сотрудникам подобный отчет о своих задачах и затраченном времени.
Необходимо было определить стек технологий. На тот момент основу нашей компании составляли .NET разработчики. Этот факт и определил будущую платформу для крайне необходимого на тот момент сервиса.
Таким образом мы выбрали:
ASP.NET – для создания веб-интерфейса и API сервиса.
SQL Server – для хранения всех данных в рамках сервиса
Hangfire – для организации фоновых задач по импорту и обработке данных из Azure DevOps.
Highcharts JS – для формирования графиков.
В конечном итоге в проекте были реализованы сервисы:
KPI.Scheduler – Hangfire-сервис с запланированными задачами, который автоматически загружал данные о сотрудниках, отделах, задачах, их статусах и затраченном времени из Azure DevOps. Помимо этого, данные о сотрудниках также связывались с данными из Битрикс24. Также сервис занимался периодической отправкой отчетов.
KPI.Service – основной ASP.NET - проект, содержащий Views и обрабатывающий данные из БД по запросу.
Авторизация производилась по LDAP в Active Directory.
Данные обновляются с точностью до дня.
В таблице и на графике задачи берутся по дате создания. Расчет соотношения багов к таскам делается по следующей формуле:
По количеству: кол-во багов / (кол-во тасков + кол-во багов)
По времени: затраченное время на баги / (затраченное время на таски + время затраченное на баги)
Значение в точке на графике относится к периоду от даты текущей точки до даты следующей (либо до конечной даты, если точка последняя).
Часы в Resolved (когда задача решена, но все еще не закрыта) не используются в расчете и носят исключительно информационный характер.
Впоследствии нам потребовалось корректировать коэффициенты рабочего времени для сотрудников с неполным рабочим днем, а также иметь возможность вручную отключать сотрудника от системы. Таким образом необходимо было ввести в проект ролевую систему и разграничить логику относительно роли.
Первый прототип сервиса дал нам возможность анализировать данные и принимать на основе этого управленческие решения. Однако мы быстро поняли, что поддерживать для этого кастомное веб-приложение накладно, тогда мы стали искать альтернативное решение для визуализации данных.
Переход на систему визуализации данных
Со временем стало понятно - добавление новых отчетов и визуализаций в наше веб-приложение занимает слишком много времени и сил. Всё упиралось в ресурсы команды. Мы выделили несколько причин, почему нужно было менять подход:
Поддержка UI - дорого. Любое обновление: пиши код, тестируй, выкатывай. Много рутины.
Гибкости - почти ноль. Руководители не могли сами добавить дашборд или поменять фильтры - снова всё через разработчиков.
Медленные изменения. От идеи до релиза проходило слишком много шагов.
Не хватало инструментов. У нас не было продвинутой аналитики, удобной фильтрации и подключения к разным источникам.
Сложность росла. Данных становилось больше, UI начинал тормозить, и его всё чаще приходилось оптимизировать.
В какой-то момент стало очевидно, что тащить свой UI дальше - не вариант.
Мы начали искать готовое решение - с удобной визуализацией, гибкими настройками и открытым кодом. Отобрали несколько вариантов и начали сравнивать.
Grafana
Apache Superset
Metabase
Redash
На тот момент у нас был опыт работы с Grafana в качестве визуализатора данных для аналитического хранилища проекта. В целом Grafana может похвастаться одним из самых активных коммьюнити разработчиков, а также мощным и богатым на фичи визуализатором данных и метрик. Таким образом наш выбор пал именно на этот инструмент.
Для некоторых панелей мы задействовали нативные средства Grafana, а для более сложных используем плагины:
HTML Graphics – для создания кастомных панелей с использованием HTML, CSS, JS.
Timepicker Buttons Panel – создание панелей со списком кнопок которые задают временной фильтр для дашборда.
Business Forms – позволяет вставлять и обновлять данные в БД.
Также внешний вид Grafana можно кастомизировать. Подробнее описано здесь.
Мы перенесли все ключевые дашборды в Grafana и получили более удобный и настраиваемый инструмент для анализа данных.
Теперь мы можем создавать и редактировать дашборды без необходимости писать код, легко настраивать подключения к различным источникам данных, включая основную базу KPI-сервиса, а также быстро настраивать метрики и фильтры.
Автоматизация отчетов и уведомлений
Одной из важных задач KPI-системы стала автоматизация отчетности. Руководителям и сотрудникам необходимо было получать актуальные данные без необходимости вручную запрашивать их в системе. На первом этапе мы реализовали это рассылкой на почту, ожидая, что сотрудники будут уведомлены о закрытых часах и будут поддерживать показатель отклонения от нормы на нулевом значении. Однако наши ожидания не оправдались.
Тогда мы приняли решение интегрироваться с мессенджерами, в которых сотрудники работают над проектом. Проблемой являлось то, что у всех проектов разный способ коммуникации. Кто-то использует Skype, кто-то Discord. Таким образом мы разработали систему распределенных уведомлений, которые отсылались в отдельные общие чаты в зависимости от мессенджера на проекте. Отправкой по расписанию занимается все тот же KPI.Scheduler с помощью Hangfire. Пример для одного из наших проектов:
В данном случае сообщения отправляются каждый час в будние дни до 18 вечера с упоминанием участников чата, которые не заполнили свои часы.
Для более наглядных отчетов в Grafana есть плагин - Grafana Rendering, позволяющий делать скриншоты панелей с заданными параметрами. Затем мы встраиваем их в отчет и отправляем адресатам.
Переход на Apache Airflow
Когда система KPI разрослась, мы начали упираться в ограничения Hangfire. Для простых фоновых задач он норм, но когда понадобилось выстраивать сложные цепочки обработки данных - стало тесно.
Нам нужен был инструмент, который:
умеет работать с зависимостями между задачами,
показывает, что сейчас выполняется,
и может масштабироваться, если данных станет больше.
Так мы нашли Apache Airflow.
Сначала протестировали его на пилотном проекте. Результат удивил, в хорошем смысле. Настроили DAG-пайплайны, где каждый шаг был на виду. Появилась четкая структура, а добавление новых шагов больше не ломало всё подряд.
Сейчас Airflow полностью заменил Hangfire. Он стал ядром всей обработки:
— тянем данные из Azure DevOps и Битрикс24,
— преобразуем,
— собираем метрики,
— подаем их в Grafana.
Что это нам дало:
1. Оркестрация задач
Вся логика теперь в одном месте. Видно, что запускается, в каком порядке, где узкое место и куда лезть, если что-то пошло не так.
2. Умное расписание
Можно настраивать запуск задач не просто "каждый час", а по сложным условиям - хоть на основе внешних данных.
3. Мониторинг
У Airflow хороший интерфейс. Всё видно: статус задач, история, ошибки. Падает - сам перезапускает.
4. Масштабируемость
Если данных стало больше - просто подключаем новых воркеров.
5. Расширяемость
Уже пишем свои операторы под задачи, подключаем нужные API и базы.
В итоге процессы стали стабильнее и понятнее. А ещё мы теперь на шаг ближе к полноценной аналитической платформе.
Итоги и дальнейшие планы
Разработка KPI-системы сильно упростила контроль за задачами и сделала работу команд прозрачнее. Теперь руководители видят ключевые метрики в реальном времени и могут быстрее реагировать. А сотрудники - понимают, на что уходит их время и как это влияет на общую картину.
Система продолжает развиваться. Вот что планируем дальше:
Более глубокий анализ — хотим подключить новые источники данных и улучшить расчет метрик.
Точнее алгоритмы - добавим параметры, которые лучше отражают реальную нагрузку и эффективность.
Автоматизация отчётности - сделаем уведомления и отчеты умнее и понятнее.
Интеграции - смотрим в сторону других аналитических систем, чтобы расширить возможности мониторинга.
Мы не закрываем тему, наоборот, интересно узнать, как это устроено у других. Какие инструменты вы используете для оценки работы команд? Как считаете метрики? Расскажите, как у вас - обмен опытом точно не повредит.