Как мы построили сервис KPI для сотрудников

Привет! Я Арсен, .NET-разработчик в 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 – для формирования графиков.

В конечном итоге в проекте были реализованы сервисы:

1. KPI.Scheduler – Hangfire-сервис с запланированными задачами, который автоматически загружал данные о сотрудниках, отделах, задачах, их статусах и затраченном времени из Azure DevOps. Помимо этого, данные о сотрудниках также связывались с данными из Битрикс24. Также сервис занимался периодической отправкой отчетов.

Авторизация производилась по 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-системы сильно упростила контроль за задачами и сделала работу команд прозрачнее. Теперь руководители видят ключевые метрики в реальном времени и могут быстрее реагировать. А сотрудники - понимают, на что уходит их время и как это влияет на общую картину.

Система продолжает развиваться. Вот что планируем дальше:

• Более глубокий анализ — хотим подключить новые источники данных и улучшить расчет метрик.

• Точнее алгоритмы - добавим параметры, которые лучше отражают реальную нагрузку и эффективность.

• Автоматизация отчётности - сделаем уведомления и отчеты умнее и понятнее.

• Интеграции - смотрим в сторону других аналитических систем, чтобы расширить возможности мониторинга.

Мы не закрываем тему, наоборот, интересно узнать, как это устроено у других. Какие инструменты вы используете для оценки работы команд? Как считаете метрики? Расскажите, как у вас - обмен опытом точно не повредит.