За время жизни продукта, безусловно, приходится собирать большое количество данных, анализировать и принимать на их основе решения.
В своей работе мы собираем множество метрик — мониторим качество продакшена, поведение пользователей и процесс автоматизации. И, конечно, отслеживаем внутренние процессы — например, успеваемости сотрудников, приближения дедлайнов, сгорания задач и тому подобные.
Но как сделать так, чтобы всеми метриками было удобно пользоваться? Чтобы не приходилось собирать всё вручную, а была бы единая точка входа к данным, и сама полученная информация помогала контролировать состояние дел и проводить верную оценку.
Мы нашли для себя удобный способ сбора и отображения данных о проектах и сотрудниках, которые в них задействованы, и хотим поделиться этим способом в статье. Как всегда, мы открыты к диалогу и надеемся, что это решение пригодится в работе или вы адаптируете его по-своему.
Какие метрики собираем?
Ниже приведу основные метрики, которые собираются на проекте. Для удобства для себя мы делим их на четыре категории — QA, технической поддержки, метрики безопасности и процессные показатели. Важно понимать, что этих метрик на самом деле намного больше, и все они пригождаются на разных этапах проекта и в разных непредвиденных ситуациях.
1. Техподдержка
дашборд качества
поступающие задачи
2. QA
покрытие
тестовая документация
покрытия автотестами
результаты прогонов
нагрузочное тестирование
скорость написания автотестов
3. Безопасность
загруженность отдела
покрытие тестами безопасности
4. Процессные метрики
загруженность производства
сгорание задач
срывы сроков задач
сложность релизов
приближение дедлайна
Вместо дисклеймера
Существует заблуждение, что сбор метрик — это целиком и полностью ответственность менеджера, а значит он сам в состоянии собрать то, что ему необходимо для отчетов. Но по факту, менеджеры в большинстве своем не обладают такими техническими компетенциями. Мы учитываем это у нас в компании, и поэтому менеджер работает в связке с QA-специалистом. И уже QA работает с инструментами, про которые мы расскажем ниже, и воплощает в жизнь те метрики, которые необходимы менеджеру.
Как это реализовано?
Data Studio — инструмент для анализа данных, отслеживания KPI и генерации отчетов. Он может собирать «под одной крышей» информацию из множества сервисов, и это очень удобно. К большому сожалению среди этих сервисов нет Jira Cloud, поэтому нам пришлось придумать костыль хитрое решение.
У Bob Swift Atlassian Apps есть плагин Database Exporter for Jira Cloud, который может выгружать все задачи в базу данных Postgres, а Google Data Studio может работать с Postgres.
Таким образом у нас получилась следующая связка:
Задачи заводятся в таск-трекере Jira:
В Jira установлен плагин, который раз в 15 минут подключается к нашей базе и выгружает все изменения в задачах.
В Postgres хранятся все изменения задач (комментарии, статусы, сроки и т. д.) в актуальном состоянии. Эти данные мы можем использовать в разных целях, в том числе и для построения процессных метрик.
В Google Data Studio, используя PostgreSQL connector, подключаемся в нашу базу с задачами с помощью SQL запросов получаем данные и строим метрики.
Для удобства, чтобы каждый раз не писать большие запросы, на стороне СУБД написали виртуальную таблицу (VIEW) со всеми необходимыми столбцами:
CREATE
OR REPLACE VIEW all_issues AS
SELECT DISTINCT "ISSUEKEY" AS "issue_key",
COALESCE(t1."СОЗДАНО", t1."CREATED") AS "create_date",
COALESCE(t1."ОПИСАНИЕ", t1."DESCRIPTION") AS "description",
COALESCE(t1."СРОК_ИСПОЛНЕНИЯ", t1."DUE_DATE") AS "deadline",
COALESCE(t1."РЕШЕНО", t1."RESOLVED") AS "ready",
COALESCE(t1."P_", t1."SUMMARY") AS "resume",
t2."NAME" AS "project",
t3."NAME" AS "status",
t4."NAME" AS "priority",
t5."NAME" AS "issue_type",
t6."VALUE" AS "severity",
CASE
WHEN t7."TO_STRING" IS NULL THEN 'false'::boolean
ELSE 'true'::boolean
END AS "reopen",
t8."CREATED" as "closed_date",
case
when t10."NAME" is null then Null
else concat(t2."NAME", ' | ', t10."NAME")::CHARACTER VARYING
end AS release_name,
CASE
WHEN t11."ID" IS NULL THEN 'false'::BOOLEAN
ELSE 'true'::BOOLEAN
END AS "bug_in_prod",
t8."CREATED" ::date-COALESCE(t1."СРОК_ИСПОЛНЕНИЯ"::date, t1."DUE_DATE"::date) AS deadline_breakdown,
t13."DISPLAY_NAME" as responsible,
"EPIC_LINK" AS epic_link,
"СЛОЖНОСТЬ_ЗАДАЧИ" AS "story_points",
t1."ISSUE_ID"::text AS issue_id,
trunc(coalesce("СУММАРНОЕ_ЗАТРАЧЕНОЕ_ВРЕМЯ", "AGGREGATE_TIME_SPENT")/3600, 2) AS time_tracked,
t14."DISPLAY_NAME" AS assignee,
trunc(coalesce("СУММАРНАЯ_ПЕРВОНАЧАЛЬНАЯ_ОЦЕНКА", "AGGREGATE_ORIGINAL_ESTIMATE")/3600, 2) AS original_estimate,
t1."START_DATE" AS start_date,
t16."CREATED" AS "last_modification",
CASE
WHEN t17."ID" IS NULL THEN 'false'::boolean
ELSE 'true'::boolean
END AS "automation_task",
CASE WHEN t10."RELEASED"='false'::BOOLEAN THEN NULL
ELSE t10."RELEASE_DATE"
END AS release_date
FROM "ISSUE_FIELD_VALUES" t1
LEFT JOIN "PROJECTS" t2 ON coalesce(t1."ПРОЕКТ_PROJECT_ID", t1."ПРОЕКТ_ID", t1."PROJECT_ID") = t2."ID"
LEFT JOIN "STATUSES" t3 ON coalesce(t1."СТАТУС_STATUS_ID", t1."СТАТУС_ID", t1."STATUS_ID") = t3."ID"
LEFT JOIN "PRIORITIES" t4 ON coalesce(t1."ПРИОРИТЕТ_PRIORITY_ID", t1."ПРИОРИТЕТ_ID", t1."PRIORITY_ID")= t4."ID"
LEFT JOIN "ISSUE_TYPES" t5 ON coalesce(t1."ТИП_ЗАДАЧИ_ISSUE_TYPE_ID", t1."ТИП_ЗАДАЧИ_ID", t1."ISSUE_TYPE_ID") = t5."ID"
LEFT JOIN "FIELD_OPTIONS" t6 ON t1."СЕРЬЕЗНОСТЬ_FIELD_OPTION_ID" = t6."ID"
LEFT JOIN (SELECT *
FROM "ISSUE_HISTORY"
WHERE "TO_STRING" = 'Reopen') t7 ON t1."ISSUE_ID" = t7."ISSUE_ID"
LEFT JOIN done_issues t8 ON t1."ISSUE_ID" = t8."ISSUE_ID"
LEFT JOIN "ISSUE_FIX_VERSIONS" t9 ON t1."ISSUE_ID" = t9."ISSUE_ID"
LEFT JOIN "PROJECT_RELEASES" t10 ON t9."PROJECT_RELEASE_ID" = t10."ID"
LEFT JOIN "ISSUE_БАГ_НА_ПРОДЕ" t11 ON t11."ISSUE_ID"=t1."ISSUE_ID"
LEFT JOIN (SELECT DISTINCT ON ("ISSUE_ID") *
FROM "ISSUE_HISTORY"
WHERE "FROM_STRING" IN ('Open','To Do','To do') AND "TO_STRING" IN ('InProgress', 'In Progress', 'В работе')
) t12 ON t1."ISSUE_ID" = t12."ISSUE_ID"
LEFT JOIN "USERS" t13 ON t13."ID"=t12."AUTHOR_USER_ID"
LEFT JOIN "USERS" t14 ON t14."ID"=t1."ASSIGNEE_USER_ID"
LEFT JOIN (SELECT DISTINCT ON ("ISSUE_ID") t15."ISSUE_ID", "CREATED"
FROM (SELECT * FROM "ISSUE_HISTORY" WHERE "FIELD" !='Workflow' ORDER BY "CREATED" ASC) t15) t16 ON t16."ISSUE_ID"=t1."ISSUE_ID"
LEFT JOIN "ISSUE_ЗАДАЧА_АВТОМАТИЗАЦИИ" AS t17 ON t17."ISSUE_ID" = t1."ISSUE_ID"
Теперь мы можем использовать эту виртуальную таблицу в Google Data Studio для получения нужных данных. Например, тренд по багам за период:
SELECT to_char(create_date, 'MM.YYYY') AS month, project, severity, count(severity) FROM all_issues
WHERE issue_type IN ('Bug','Ошибка') AND severity IS NOT NULL
GROUP BY 1, 2, 3
Как внедрить свои первые метрики? Пошаговая инструкция
После того как мы собрали все инструменты вместе, самое время создать свою первую метрику. Собрали пошаговую инструкцию, чтобы построить отчет в Google Data Studio для количества задач в разрезе статусов и типов в процентах. Ниже мы используем стандартные поля в Jira. В вашем конкретном случае настройки в таблицах могут отличаться.
Пошаговая инструкция
Установить плагин Database Exporter for Jira Cloud в Jira. Необходимо иметь права администратора Jira
Настроить подключение к базе PostgreSQL:
После настройки подключения начнется синхронизация. Когда пройдет полная синхронизация задач в базе появятся следующие таблицы (основная информация по задачам находится в таблице ISSUE_FIELD_VALUES ):
Перейти в Google Data Studio и создать отчет:
Выбрать источник данных:
Настроить подключение до базы с задачами и написать запрос для получения данных:
SELECT t1."ISSUEKEY" AS "issue_key",
t2."NAME" AS "status",
t3."NAME" AS "project",
t4."NAME" AS "issue_type"
FROM "ISSUE_FIELD_VALUES" t1
LEFT JOIN "STATUSES" t2 ON coalesce(t1."СТАТУС_STATUS_ID", t1."СТАТУС_ID", t1."STATUS_ID") = t2."ID"
LEFT JOIN "PROJECTS" t3 ON coalesce(t1."ПРОЕКТ_PROJECT_ID", t1."ПРОЕКТ_ID", t1."PROJECT_ID") = t3."ID"
LEFT JOIN "ISSUE_TYPES" t4 ON coalesce(t1."ТИП_ЗАДАЧИ_ISSUE_TYPE_ID", t1."ТИП_ЗАДАЧИ_ID", t1."ISSUE_TYPE_ID") = t4."ID"
Готово. Если предыдущие шаги выполнены правильно, то должна появиться таблица с задачами на пустой странице:
Нажать на эту таблицу и в правой стороне страницы добавить дополнительные параметры для отображения, удалить показатель и передвинуть немного вниз. Названия столбцов можно менять нажав на «ABC» правее от названия параметра:
Добавить круговую диаграмму которая показывает процент задач в разрезе статусов:
Добавить еще одну такую же диаграмму для отображения процента задач в разрезе типов:
Добавить управляющий элемент для выбора проекта (фильтр по проекту для построения метрик в отчете):
Добавить текст в шапке отчета и настроить стиль:
Выбрать цвет фона заголовка таблицы и цвет шрифта:
Изменить название отчета и нажать открыть для просмотра результата:
Готово:
Почему именно эта связка инструментов?
Конечно, существует много разных инструментов с уже готовыми решениями. Это такие системы как YouTrack с собственным конструктором дашбордов или Jira со встроенной статистикой. Мы пробовали использовать эти стандартные инструменты, но поняли, что нам их не хватает. Есть еще множество дорогостоящих решений, которые тоже нам не подошли.
По сути, мы используем полностью бесплатное решение. Его несложно доработать и адаптировать под собственные цели и особенности проекта.
Какие результаты приносят метрики?
Использование метрик приносит определенные плоды. С точки зрения менеджмента видим следующие плюсы:
У менеджеров складывается актуальное представление о том, чем занимается отдельно взятый сотрудник, команда или отдел. Если задачи выполняются медленно, это повод поговорить и понять, что не так — может сотрудник начинает перегорать или испытывает трудности
Позволяет грамотно планировать релиз и не срывать сроки
Получается оперативно реагировать на ошибки и сбои
Единая точка входа — ничего не разбросано по чатам и трекерам, а собрано в одном месте
Если сотрудник уходит из офиса на удаленку, его прогресс хорошо виден
Плюсы для ребят в команде тоже имеются:
Растет удовлетворенность слаженной работой команды и процессами
Дает возможность как контролировать себя, так и помочь другому сотруднику
Мотивирует на достижение результата
Что дальше?
У этого инструмента большой потенциал развития внутри компании.
Во-первых, мы рассчитываем, что подобный инструмент будет внедряться не только в отделы, где ведется разработка, но и в другие — например, в отделы безопасности, маркетинга или обеспечения. Это позволит эффективнее выстраивать процессы во всей компании и улучшать коммуникации друг с другом.
Во-вторых, введение таких удобных метрик — часть построения внутренней системы геймификации. Планируем, что часть метрик будет переведена в корпоративную CRM и будет служить на благо всех сотрудников. В одной из следующих статей расскажем подробнее о нашей корпоративной CRM собственной разработки.
