Система управления проектами+ EasyBI: как мы превратили задачи в метрики, а метрики — в решения

Привет Хабр! Мы команда бизнес-анализа Группы MOEX, и сегодня хотим поделиться своим подходом как мы определяем эффективность нашей работы.

Показателями эффективности являются метрики.

Метрика — это число, которое показывает, как и кто работает. Это не описания, не мнения — только цифры, по которым можно понять: всё хорошо или нужно что-то менять.

Для нашей команды, мы определили следующие критерии эффективности:

• Понимание загрузки команды 

• Контроль за продуктивностью команды

• Компетенции

• Развитие и мотивация 

Мы не стали изобретать новые инструменты: все контрольные точки работы над задачей фиксируем в таск-трекере.

По датам:

• Дата назначения задачи

• Дата начала работ над задачей

• Дата окончания работ над задачей

• Дата и причина приостановки работы над задачей

• Дата возобновления работы над задачей

и т.п.

По дополнительной информации:

• к какому домену аналитики (предметная область) относится задача

• кто является заказчиком задачи

• какие системы затрагивает задача

По трудозатратам

• первоначальная оценка

• потраченное время

Для отображения метрик мы используем EasyBI, который превращает набор данных из задач, эпиков и комментариев в понятные аналитические дашборды без сложной настройки.

Просто выбираем поля: кто сделал, когда, сколько времени заняло, статус и EasyBI автоматически построит графики, таблицы и метрики. 

1. Настройка WorkFlow задач.

В системе управления проектами  мы настроили статусную модель задачи:

Ниже мы рассмотрим примеры наших дашбордов на основе данного Work flow

2. Панель мониторинга задач

Цель метрики: Визуальный контроль над ходом выполнения задач и своевременное выявление «узких мест»

При анализе данной панели мы можем видеть следующие кейсы:

• Если «В очереди» и в «Ожидании БА» скопилось много задач, мы понимаем, что у нас нехватка ресурсов команды и нам необходимо нанимать новых сотрудников.

• Если «В очереди» и в «Ожидании БА» небольшое количество задач — мы понимаем, что: 

  • не сформирован бэглог по задачам 

  • количество аналитиков больше количества задач, и это является сигналом к уменьшению численности команды 

• Если много задач «В оценке», то это «узкое место» в работе команды, надо перераспределить роли. 

• Статус «Приостановлен» мы используем для отражения влияния внешних стоп-факторов, блокирующих работу аналитика над задачей. Например:

  • ожидание архитектурного решения

  • согласование концепции продукта заказчиком.

Если задач в статусе «Приостановлен» много, это сигнал для эскалации проблемы на более высокий уровень

5. Если много задач скопилось в статусе «Передано в разработку», то это сигнал для ИТ лидера разработки обратить внимание на планирование ресурсов.

 

3. Количество проанализированных задач за месяц

Цель. Предоставить объективный, измеримый показатель производительности и эффективности команды

Цели метрики на примерах:

• Оценка производительности команды
  Позволяет ответить на ключевой вопрос: «Увеличивается ли объём работы, который команда может выполнить за единицу времени?»
  Сравнение показателей по месяцам помогает выявить:

  • Рост производительности — больше задач → лучше процессы, больше ресурсов, меньше блокировок

  • Снижение производительности — меньше задач → возможны проблемы: перегрузка, нехватка ресурсов, технический долг

📉 Пример:
Пик в марте (81 задача) — максимальная продуктивность в начале года, связанная с запуском новых инициатив и планированием.
Спад в августе (51 задача) — сезонное снижение на 37% из-за отпусков и замедления решений со стороны стейкхолдеров.
Восстановление к декабрю (61 задача) — постепенный возврат к стабильным темпам работы. 

• Планирование ресурсов и нагрузки
  На основе среднего количества задач в месяц можно:

  • Прогнозировать объём работы на следующий месяц/квартал

  • Планировать найм, перераспределение задач, ресурсов между доменами аналитики и привлечение внешних ресурсов

  • Избегать перегрузки, выгорания сотрудников

📉 Пример:
Если команда в среднем делает 100 задач/месяц, а в следующем месяце запланировано 140 — нужно понимать:
→ Это реалистично?
→ Нужны ли дополнительные ресурсы?
→ Или задачи можно приоритизировать /сократить?

• Выявление проблем в процессах
  Резкое падение количества выполненных задач — сигнал тревоги:

  • Появились «узкие места» 

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

  • Неправильно проведена декомпозиция задачи, появились «слоны» (объёмные задачи, множество интеграций, неопределённость в законодательстве)

4. Затрачиваемое время на проработку ФЗ 

Цель метрики: измерить, насколько быстро проведена аналитика по задаче.

Перед командами всегда стоит цель сократить время работы над задачей до минимально возможного значения и не потерять качество аналитики.

Нам удалось уменьшить время работы над задачами, с помощью следующих шагов:

• Упрощение и стандартизация декомпозиции задач

• Привлечение наставников

• Модернизация шаблонов 

• Автоматизация рутинных процессов

• Ограничение количества задач в работе (фокусировка аналитика на топ-3 задачи)

• Повышение компетенции аналитиков

📉 Пример:
Аналитику в работу поступила интеграционная задача между ИТ-системами

• Была проведена качественная декомпозиция с привлечением наставника

• На раннем этапе анализа была проработана архитектура решений

• Контроль за нагрузкой аналитика 

С учетом применения данных мер, время Cycle Time существенно сократилось, о чем говорит график выше

 

5. График в разбивке по месяцам и по размеру задачи.

Цель метрики: контроль за объёмными задачами, чтобы в будущем подвергать декомпозиции 

В каждом месяце мы отслеживаем, сколько задач разных размеров — больших, средних и маленьких — команда успевает завершить.

• Большая задача — время работы над задачей превысило 120 часов

• Средняя задача — время работы над задачей от 40 часов до 120 часов

• Маленькая задача — время работы над задачей менее 40 часов

📉 Пример: 

На графике мы наблюдаем, что в августе процент больших задач достиг максимума.

📉 Сигнал тревоги

Принятые меры:

• идентифицирован домен аналитики, где появились «слоны» 

• пересмотрен бэклог домена аналитики на предмет декомпозиции

Данные меры стабилизировали процент больших задач в следующих периодах

 

6. Размер первоначальной оценки по задаче и фактически затраченное время в разрезе каждого БА

Цель. Насколько точно оцениваем производительность каждого сотрудника

Цели метрики на примерах:

• Показывает, насколько точно команда оценивает работу
  Сравнивает то, что планировали (первоначальная оценка) и то, что реально потратили (затраченное время).

  🔍 Пример:
  Для аналитика А задачу оценили в 8 часов — аналитик потратил 12 часов → недооценил на 50%
  Для аналитика Б задачу оценили в 12 часов — аналитик потратил 10 часов → переоценил на 17%

• Помогает выявить системные проблемы в оценках
  Если у всех в команде первоначальная оценка ниже затраченного времени, значит:

o   не учитываются риски (незнакомая область анализа, «трудный» заказчик, операционные риски и т.п.)

o   не учитывается изменение концепции по задаче

o   оценка задачи произведена без учета опыта и компетенций аналитика

Если у всех в команде первоначальна оценка намного выше (превышает в 2 раза) затраченного времени, значит:

o   Команда не уверена в себе

o   Команда боится «не успеть» и завышает для «запаса»

o   Процесс оценки требует пересмотра

📉 Сигнал тревоги:
У 80% сотрудников затраченное время > первоначальной оценки → команда систематически недооценивает → планы постоянно срываются.

• Улучшает прогнозирование сроков и планирование

Если мы выявили, что в среднем команда занимает на 30% больше времени, чем оценивает — мы можем:

• Умножать оценки на 1.3 при планировании

• Не обещать заказчикам «всё за 2 дня», если реальность 3-4

📊 Пример:
Среднее отклонение: оценка — 8 ч, реальность — 10.4 ч → +30% → При планировании спринта: берём 130% от оценки → план становится реалистичным.

 

7. Компетенции сотрудников

Цель метрики: понять какие компетенции есть в команде

Цели метрики на примерах:

• Эффективное распределение задач и проектов

На основании этой метрики мы сформировали матрицу компетенций, где можно сопоставить задачу с компетенциями сотрудника.

📊 Пример:

Необходимо внедрить новую систему мониторинга.

В матрице компетенций отражается следующая информация:

Аналитик 1: эксперт по «Система 1» + «Система 3»

Аналитик 2 : средний уровень

Аналитик 3: не владеет

Задача назначается на Аналитика 1. Аналитик 2 может участвовать как бэкап

Управление рисками в команде

Если все знания сосредоточены у одного человека — это рискованно.

📊 Пример:

Метрика показывает, что только Аналитик 1 знает систему X и есть риск, что при отсутствии Аналитика 1 будет отсутствие компетенций по системе Х.

На основе метрики запускается программа наставничества, с помощью которой в команде вырастет количество экспертов по системе Х.

• Поддержка гибкости и мобильности в команде
  Когда аналитики расширяют компетенции, они могут:

  • брать задачи вне своей «зоны»  

  • заменять друг друга при отпусках или болезнях  

  • переключаться между проектами без простоев

• Планирование обучения и развития

  • позволяет строить индивидуальный план развития сотрудника 

  • проводить обучающие митапы

  • формировать базу знаний по системам и компетенциям.

8.  Мониторинг процесса согласования по задачам

Цель метрики: необходима для обеспечения прозрачности, контроля и эффективности процессов управления задачами в команде.

Цели метрики на примерах:

• Метрика фиксирует сроки согласования задач

Это помогает управлять процессом согласования и предотвратить задержки согласования

📊 Пример: 

Если задача не согласована с юридическим отделом более 5 рабочих дней — для аналитика это сигнал об эскалации проблемы на руководителя.

Если задачи систематически не согласовываются в срок конкретным сотрудником компании — это сигнал к смене ответственного за согласование.

• Повышение ответственности участников

Мы фиксируем ответственных лиц по согласованию задачи, которые осознают свою роль в цепочке производственного процесса.

Снижается количество неформальных, устных согласований.

• Улучшение качества решений

Метрика помогает контролировать риски доработок 

• Прогнозирование сроков и планирование

На основе исторических данных по согласованию можно строить более точные прогнозы сроков выполнения задач

📊 Пример: 

В нашей команде среднее время согласования — 5 рабочих дней, то при планировании проекта это время уже включается в оценку.

• Выявление проблем в коммуникациях

Резкие скачки в метрике (например, рост времени согласования) могут сигнализировать о:

o   сложностях коммуникации между подразделениями

o   перегрузке ответственных лиц

o   неясности в требованиях

 

9. Вывод

Метрики превращают управление задачами из интуитивного процесса в точную, управляемую систему.

Использование системы управления проектами и EasyBI позволило нам легко автоматизировать сбор данных и визуализировать ключевые показатели в реальном времени. 

Благодаря метрикам можно:

• выявить проблему

• подсветить «узкие места» 

• улучшить существующий процесс

• замотивировать команду. 

Без метрик мы действуем вслепую, а с ними осознанно и эффективно.

Инструменты для сбора и построения метрик могут быть самыми мощными, дорогими и продвинутыми, но если команда игнорирует отклонения в показателях данных и смотрит на метрики как на обычный отчет, то все инструменты превращаются в дорогую игрушку.

Метрики не цель, а средство стать лучше.