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

Только как быть, если в вашей команде уже не 5 человек, а 15, и вручную отслеживать данные стало непросто?

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

Под катом рассказываем, как мы начали (и продолжаем) централизованно мониторить эффективность нашего QA-направления. Поэтапно и с практическими советами. 

Привет, Хабр! Меня зовут Василий, я Deputy CTO в Сравни. Уже пару лет мы централизованно мониторим производительность в командах, чтобы видеть реальную рабочую нагрузку, выявлять сложности в процессах и влиять на персональное развитие сотрудников. Речь, по сути, о визуализации данных из корпоративного таск-трекера — по настраиваемым полям получаем на дашбордах данные в нужном нам разрезе, на их основе делаем выводы. 

Технически все устроено просто: DWH подтягивает сырые данные из таск-трекера по API — по сути, табличку с JSON. В ней представлен полный набор данных по всем возможным полям, настроенным нашими командами: для каждой задачи, статуса, дня и так далее. И есть вьюшка, которая разбирает JSON по полям. Если исходя из потребностей команд нужны новые поля, при помощи команды сервисной аналитики мы дорабатываем вьюшку — внесение новых требований к данным занимает не более часа.

1. Кому это нужно

Короткий ответ: продуктовым и техническим командам численностью 10+ человек, в которых есть потребность систематически отслеживать рабочую нагрузку и процессные метрики. То есть нужна некая «база» по отслеживанию качества процессов.

В нашем случае стимулом к внедрению инструмента стал активный рост направления QA. Поскольку в Сравни мы строим команды по принципу кроссфункциональности, свои тестировщики есть в каждой из 30+ команд. Когда QA-специалистов у нас было всего восемь человек, мониторинг эффективности не вызывал затруднений: прогресс по задачам стандартно отслеживали в таск-трекере, а процессные сложности выявляли с коллегами на синках (в корпоративном чате или на созвонах). 

Вслед за ростом количества продуктов в компании тестировщик стало больше в четыре раза. «Вручную» отслеживать специфику процессов тестирования становилось все сложнее.

2. С чего начать

Короткий ответ: использовать таск-трекер с возможностью выгружать данные по API + инструмент визуализации.

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

Вскоре у нас появилась возможность получать данные из DWH. С помощью коллег-аналитиков мы интегрировали таск-трекер в хранилище, получили первые дашборды. Стали более прицельно мониторить реальную нагрузку тестировщиков: это помогало понимать, пора ли задуматься о расширении команды. Если видели высокую нагрузку на тестировщика, то заблаговременно приходили к нему с незапланированным 1-to-1, обсуждали положение дел. Плюс смотрели, в каких именно процессах заключается проблема; общались с другими ролями в команде, чтобы исправить ситуацию. 

3. Как продолжить

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

Помимо нагрузки, с помощью дашбордов мы стали мониторить время нахождения багов в тестировании и в ожидании тестирования. Если скорость работы была недостаточной (в связи с чем вырастали показатели нагрузки), смотрели, в чем проблема: возможно, в команде нарушены процессы или отсутствуют необходимые компетенции. В течение последующих месяцев стали углубляться в аналитику полученных данных, попутно формировали запросы на развитие и доработку дашбордов. 

Постепенно начали визуализировать метрики по критичности багов. А после — мониторить метрики качества работы с ними: соотношение багов в тестировании и на проде. Благодаря этому стали видеть незапланированную нагрузку на тестировщика: исходя из качества кода, который он получает. На основании полученных данных наблюдали, как у команд формируется техдолг, и во взаимодействии с лидами разработки могли влиять на контроль. 

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

На этом этапе наша команда DWH уже использовала SuperSet.

4. Как унифицировать процесс

Короткий ответ: внедрить и закрепить стандарты для всех команд.

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

• работу со статусами таск-трекера (не у всех команд доска была настроена в соответствии со стандартами статусной модели)

• процесс ведения багов (не все QA оставляли артефакты в виде задач после тестирования, то есть в принципе заводили баги)

• отражение актуальной критичности проблем (бывало, что кто-то тестировал задачу в статусе backlog или done)

На разработку каждого пункта нашего стандарта потратили время: собирались, обсуждали, фиксировали. (Важно сразу учесть: поскольку настроить систематический мониторинг работы по 30+ командам непросто, для реализации идеи понадобится заряженная команда лидов. Отдельное спасибо @DesertEagleза всестороннюю помощь в процессе!).

Затем начали просматривать данные по всем командам, точечно ходить к ним и отлаживать процесс работы со стандартами. Параллельно фиксили недоработки в механике — например, изначально поле «критичность» в описании багов проставлялось автоматически, со статусом «минорный», из-за чего бизнес не мог сформировать правильный приоритет. В итоге сделали это поле обязательным и стали более осознанно назначать критичность багов, в целом пристальнее обращать внимание на их градацию по критичности (критические, блокирующие, минорные). 

Составили общий глоссарий: что такое блокер, что такое минор, и так далее.

Около года шлифовали стандарты: наблюдали, как коллеги заводят баги, почему именно так, соблюдаются ли общие правила. 

5. К чему мы пришли

В итоге мы стали получать весь необходимый набор данных, которыми можем оперировать, понимать процессы в командах и то, что на них влияет. Начали точнее понимать нагрузку на тестировщиков: например, выявили, что люди брали в работу по нескольку задач, просто чтобы их «проверить» — а это нарушение договоренностей, из-за этого их нагрузка отображалась некорректно. (Мы используем практику «быстрых релизов», по которой можем доставлять в разные микросервисы на продакшн сколько угодно изменений в день).

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

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

На дашбордах мы также видим соотношение багов с саббагами. Если второй показатель низкий, а количество багов высокое, это повод детальнее посмотреть, что происходит в команде. Возможно, задачи проходят мимо тестировщика (ему не хватает компетенций, либо он занят другим); если же с людьми все хорошо, но баги растут, то проблема в самих процессах тестирования — их срочно надо оптимизировать. 

В итоге на основе наших метрик мы мониторим эффективность — как в разрезе всей команды, так и по конкретным людям. Эти же данные помогают проводить перфоманс-ревью: смотрим информацию персонализированно по каждому тестировщику, так как данные по метрикам в разных командах могут отличаться (с учетом, например, отпусков и больничных). 

Как поменялись метрики. Дальнейшие планы

Проанализировав совокупность метрик, для каждой команды мы составили свод рекомендаций: на что обратить внимание, чтобы выровнять процессы. Первыми рекомендациями поделились в конце прошлого года — и довольно быстро быстро увидели эффект. Например, в случае с одной из наших команд следование рекомендациям позволило сократить скорость выкатки релизов в 15-16 раз. 

В ближайшее время планируем ряд шагов по развитию нашего подхода к мониторингу:

• Начнём визуализировать не только процессные, но и технические метрики, вроде 400-х и 500-х ошибок. Сейчас они отслеживаются в Grafana, планируем дублировать в Superset — опять же, чтобы все было видно в одном месте. Плюс будем мониторить таким образом аптайм сервисов: покомандно показывать % времени без падения. Это позволит точнее отслеживать аффект наших решений на продукты. 

• Экстраполируем мониторинг метрик на автоматизированное тестирование, где пул основных метрик будет несколько отличаться. Пока что прогресс по этому направлению отслеживаем вручную. 

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

• При участии бизнеса закрепим наш подход в качестве стандарта для оценки дел в компании — не только в процессах тестирования. Чтобы бизнес всегда имел мгновенный доступ к ключевым показателям по своим направлениям, и по этим метрикам был определён SLA.

О результатах и сделанных выводах традиционно расскажем на Хабре. 

А как вы работаете с ключевыми командными метриками? Делитесь в комментариях!