Когда релиз? Как мы оптимизировали процессы с помощью метрик

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

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

Почему висят задачи

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

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

Список любимых метрик

Метрики есть у любого бизнеса — это веб-аналитика, конверсии, MAU, DAU. Есть технические метрики — RPS, метрики доступности, которые собираются по логам. И эффективность работы команды также можно измерить.

Понять, что на самом деле происходит, мне помогли вот эти метрики:

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

• Cycle time — время от взятия задачи в работу до релиза (включает именно процесс разработки).

• Time to market — время от генерации идеи до релиза (включает проработку бизнес-процессов).

• Распределение по типам работ — помогает увидеть, сколько времени выделяется на технический долг, фичи и устранение ошибок. Плохо, если на ошибки есть мало времени, но при этом много багов. Или, если всё время уходит на фичи, но при этом копится техдолг.

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

• Отношение времени разработки к оценке — позволяет прогнозировать время, которое будет затрачено на выкатку фичи. Чем больше данных накоплено, тем точнее будет прогноз. Если время разработки совпало с оценкой — это 100%.

Как мы вводили метрики

Подготовку к сбору метрик можно разделить на четыре этапа:

1. Заводим таск-менеджер. Фиксировать всё где-нибудь на бумажке или стикерах вряд ли получится. Важно, чтобы данные сохранялись в программе, и их можно было оттуда вытащить. 

2. Прорабатываем флоу переходов по статусам. Чётко прописываем всю цепочку работы, например: «Готово к разработке» — «разработка» — «ревью» — «ожидание стейджа» и т.д. Важно максимально точно описать процесс, с учетом статусов ожидания, потому что от этого зависит качество метрик и правильность их интерпретации.

   

3. Пинаем команду. Это, пожалуй, самая сложная часть. Мало продумать точный флоу, надо сделать так, чтобы каждый сотрудник фиксировал переход по статусам. В нашем случае разработчики делают это давно, но ушло много месяцев на то, чтобы сформировать нужную привычку у продактов.

4. Выгружаем данные. Через месяц–два можно начинать работать с метриками. Для этого нужен аналитик или любой другой человек, который может сделать запрос к базе данных, посчитать цифры и нарисовать графики. 

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

Какие проблемы мы обнаружили

Мы ввели метрики в июле 2023 года. За несколько месяцев регулярного сбора данных они помогли увидеть три проблемы: 

Проблема №1. Ревью кода занимает в два раза больше времени, чем разработка.

Вернее, оказалось, что не само ревью, а его ожидание. Задачи по проверке просто висят в таск-трекере, потому что разработчики заняты другими тасками.  

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

Итог — график выровнялся, код перестал зависать на этапе проверки, уменьшился Cycle Time. На другие статусы это практически не повлияло, поскольку больше времени мы тратить не стали.

Проблема №2. Задачи блокируют друг друга.

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

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

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

Итог — средняя уменьшилась в три раза. Это не сильно повлияло на Time to market, но хорошо подтянуло Cycle time, поскольку задача все равно провела бы это время в режиме ожидания. За счет более тщательной подготовки мы оптимально используем ресурсоёмкость команды.

Проблема №3. Потеря времени из-за возвратов.

Возвраты — индикатор проблемы. Но задачу возвращают не потому, что разработчик — дурак, или тестировщик — негодяй. Часто случаются ситуации, когда одно сделали, а другое — сломали. Тестировщики несколько раз проводят полное регрессионное тестирование руками и возвращают всё назад. В результате задача двигается медленно и приходится повторять одну и ту же работу. Разработчики теряют контекст и отключаются от текущих задач, чтобы поправить предыдущую.

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

Что скрывается за цифрами

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

Например, Time to market — время от генерации идеи до релиза — по сути просто цифра. Она не может быть ни хорошей, ни плохой. Показатель зависит от очень большого количества факторов, например, объёма задачи и самого разрабатываемого продукта. Для каждой команды целевой Time to market будет свой. 

Более того, он зависит не только от отдела разработки. Прежде, чем задача доберётся до нас, она пройдёт много других этапов.

То же самое касается Cycle time. Более сложная задача будет дольше разрабатываться, тестироваться, у неё будет больше возвратов. Важно смотреть не число, а общий тренд, и сравнивать команду с самой собой. Если тренд увеличивается, возможно, в команде есть проблемы с декомпозицией, задачу недостаточно проработали или не хватает компетенций для её решения.

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

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

Почему вам тоже нужны метрики

Кажется, что сам факт появления метрик повлиял на скорость выполнения задач 🙂 

Но можно выделить и другие преимущества:

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

• Команда перестала быть «чёрным ящиком» и превратилась в прозрачный. Теперь руководство может в любой момент посмотреть метрики и сделать выводы самостоятельно без моего участия.

• Можно наблюдать динамику. Метрики позволяют увидеть, как меняются процессы в команде и как наши действия влияют на конечный результат. 

• Проактивно реагировать на проблемы. Чем больше данных накоплено, тем легче увидеть возможные проблемы в будущем. Как только на каком-то этапе производства начинают скапливаться задачи или увеличивается количество техдолга в бэклоге, сразу понимаешь, к чему это может привести, и думаешь, как на это повлиять. Например, в дизайне скопилась очередь, значит через пару недель всё это обрушится на отдел разработки. Можно заранее предпринять меры, чтобы сгладить пики. 

А вы используете метрики для оценки эффективности работы команды? Делитесь своим опытом в комментариях!