Привет! Я Саша и примерно 4 года назад стал тимлидом одной из команд первичной недвижимости в Циан, а до этого ещё два года в ней же писал бекенд на .NET. За это время наше направление выросло из десятка человек в одной команде разработки до 5 команд с более 50 человек в направлении. 

Моя команда занимается монетизацией застройщиков — предоставляем инструменты продвижения контента застройщиков на сайте, даём возможность гибко управлять рекламным бюджетом, собирать статистику. Команда гибкая: у нас есть и питонисты, и шарписты на бекенде, фронтендеры, QA. Иногда мобильные разработчики заглядывают.

Когда я стал тимлидом, мне нужно было найти ориентиры. Как понять, что я веду команду в правильном направлении? Какой эффект был от изменений в процессах тестирования в команде? А не навредил ли я качеству, убирая обязательную еженедельную встречу команды на час? Правильно ли мы нашли узкое горлышко в процессах команды? На эти и другие вопросы довольно сложно ответить умозрительно, не подтверждая их «на цифрах». 

Мы в Циан активно используем данные для принятия управленческих решений. Не только продуктовых, но и при управлении командами разработки.

В статье я расскажу, как это устроено у нас в компании, и покажу на примере своих метрик, как это можно использовать у себя.

Как это выглядит

В Циан руководители команд разработки используют метрики разработки для анализа ситуации и принятия управленческих решений. Например, одно из продуктовых направлений на метриках мы видим примерно так:

Как это работает

Результат работы каждого разработчика попадает в ряд различных метрик. Эти метрики мы выводим на дашбордах и отправляем пульсы в каналы в слаке. Например, так мы получаем ежедневно сводку по открытым багам в канале команды.

В качестве фронтенда для метрик мы используем инструмент Metabase. Он позволяет гибко настраивать разные виды графиков, собирать их в дашборды и делать кастомные SQL-запросы прямо из UI. Под капотом всё это хранится в Postgres, так что можно подключиться из удобного инструмента и «крутить» данные как угодно.

Данные берём буквально отовсюду: из Jira, из Git, из нашей системы CI/CD, даже из 1С тянем кадровую информацию – отпуска, праздники и др.

Импорт данных возможен, потому что процессы работы над задачами у нас стандартизированы. Все задачи с кодом у нас проходят через Jira по жёстко зафиксированному процессу. В обход этого процесса доставить код на прод не получится. Каждый тип задач имеет свои метаданные, заполняемые руками (например, оценка в часах или майках) или автоматически (например, дата смены статуса или название репозитория в Git).

Все изменения в интересующих нас системах мы выгружаем в самописный обработчик, который преобразует поступающие данные в удобоваримый вид. Дальше уже тимлиды и проджекты смотрят в существующие визуализации метрик или делают что-то под себя. Новый график можно вывести, написав запрос на сыром SQL, а можно настроить через интерфейс.

Что нам это даёт

Вот несколько примеров, где мне помогают метрики разработки:

• Подтвердить или опровергнуть гипотезу по работе команды. Задачи в одном компоненте делаются дольше, чем в других. А действительно это так? А насколько дольше в среднем? А сколько мы там задач сделали за квартал? Команда говорит, что сложности в прогоне тестов, а это действительно так? Пойду соберу сводку по компонентам команды, количеству задач, средней их оценке, количеству найденных багов и по времени нахождения в разных статусах задач.

• Оценить эффективность внедрённых изменений. В Циан внедрили правило «среда — день без встреч». Как это сказалось на моей команде?

• Смотреть «на радарах», насколько хорошо и стабильно мы идём. После релиза крупного проекта 1 марта количество деплоев в команде упало в 2 раза. Это мы «выдохнули» и надо дать время восстановиться, или какая-то проблема с новыми проектами? Надо пойти разобраться.

Если смотреть на реальные кейсы, то больше всего мне нравится пример с оптимизацией нашего Code Review во всей компании несколько лет назад. 

Тогда мы заметили, что после отправки задач в Review проходит где-то 20–30 часов до попадания изменений на прод. Это очень много, учитывая, что новый код в нашем CI/CD микросервисе может быть готов к запуску на проде в канареечном релизе за несколько минут. 

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

Всё это время автор задачи не может полноценно переключиться на следующие задачи, часто они просто заблокированы релизом предыдущей.

После внедрения автоматизации в процесс ревью время от ревью до релиза сократилось в несколько раз. Сейчас более 80% задач с кодом в Циан попадают на прод быстрее 8 рабочих часов.

Это всё хорошо и красиво, но пример старый.

А что по актуальным примерам?

Пример 1. Весь квартал команда делала 1 крупный проект с релизом к 1 марта и ряд поддерживающих задач и проектов по необходимости

Посмотрим график количества деплоев на прод по неделям в одной из команд с начала года.

По графику видно, что в начале года команда «разгонялась», в середине квартала (S6) набрала свой максимальный темп, и далее он пошёл на спад. Без контекста выглядит так себе.

Задача руководителя понять, всё ли идёт хорошо или нужно принимать какие-то меры? Желательно заранее. Этот график — сигнал задуматься, а всёли я как руководитель вижу и понимаю в своей команде. Если я с ходу не могу объяснить такое состояние — это повод углубиться в детали и разобраться в происходящем.

По итогу здесь с командой всё хорошо — в начале года проектировали, договаривались и декомпозировали главный проект. Далее распараллелились в разработке и активно разрабатывали. С 7 спринта проект перешёл в стадию интеграции и тестирования, а в S10 — поддержку релиза и старт следующих проектов. S11 ещё только начался.

Пример 2. В команде изменились процессы тестирования

В другой команде применялся «стандартный» подход к тестированию — комбинация из покрытия задачи тестами разработчиком и ручного тестирования через QA. В ручном тестировании находились баги, и задачи отправлялись на доработку, отвлекая разработчика от следующих задач и замедляя движение по проекту. Нагляднее всего это видно в графике быстрых задач. Видно, что целевой показатель в 70%+ «быстрых» задач достигался не в каждом спринте.

Со следующего года в команде внедрили практику девтестинга — когда разработчик сам тестирует свою задачу руками, не привлекая QA. По сути, разные части проекта теперь тестируются разработчиками, а QA отвечает за end-to-end интеграцию проекта. 

Это изменение ускорило доставку задач до прода, потому что перестали активно реопать и доделывать задачи после этапа Code Review. 

Разработку самих задач не ускорили, иногда даже замедлили, ведь разработчики ещё и тестировать начали. Но теперь эти задачи надо меньше держать в фокусе после завершения этапа разработки и можно активнее подключаться к следующим.

Ещё одно последствие — на прод стало попадать больше багов, даже появились Major баги. Это и понятно — разработчики не такие опытные в тестировании, но этот эффект сгладили со временем. Аналогичный опыт есть у соседних команд.

Пример 3. Сводка по сделанной работе

На скриншоте сводка по двум командам направления. Такая сводка полезна, чтобы подбить итог по сделанной работе за последние 2—3 месяца.

Не серебряная пуля

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

Очень важно не сделать метрики самоцелью, иначе за стремлением попасть к какой-то цифре на графике мы забудем изначальные цели и не получим нужного результата в продукте.

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

Полезно перепроверять свои гипотезы из метрик на практике и наоборот. Кажется, что стали делать мало задач? А может часть задач просто создана неправильно и попала в другую команду?

При анализе показателей стоит смотреть шире, учитывая соседние метрики. У нас замедлилась скорость доставки задач до прода? Стоит посмотреть, какие были причины реопенов. А может команда была в расфокусе из-за всплеска багов?

Итого

Метрики помогают лучше ориентироваться в происходящем. С их помощью я нахожу подтверждения или опровержения каким-то своим гипотезам по команде. Метрики позволяют вовремя находить и лечить проблемы. С помощью метрик я могу ставить более конкретные цели, а также отслеживать прогресс по внедряемым изменениям. Без метрик я бы делал всё на своей «чуйке», что могло бы дать совершенно другой эффект на команду.

Если хочется узнать детали реализации, задавайте вопросы в комментариях. И расскажите, какие метрики используете в своих командах.

А еще можете почитать статью на эту же тему. от нашего CTO Алексея Чеканова.