«Нам нечего обсуждать, давайте пропустим» — такую реакцию на идею провести очередную ретроспективу мы слышали столько раз, что сбились со счёта.
В теории всё красиво: собрались на отдельную встречу (чтобы сфокусировано обсудить нужную тему), вспомнили недавнюю работу (пока не забылось), определили области для улучшений (итеративное развитие — наше всё).
На практике же ретроспективы часто получаются поверхностными и малопродуктивными. Участники отмалчиваются или обсуждают одни и те же боли из раза в раз; скучают или параллельно занимаются другими делами; уходят со встречи с ощущением впустую проведенного времени.
Хорошие новости: можно по‑другому. Повысить вовлеченность команды в ретроспективу, помочь увидеть конкретный результат своих усилий по улучшению работы. Уйти от вопросов «Что будем обсуждать на ретро?» и «У нас все хорошо?» к прозрачной картине того, что происходит с командой, чего удалось достичь и куда двигаться дальше. Помогут нам в этом процессные метрики.
Преобразование ретроспектив через данные
Идея такая: на ретроспективе обсуждать не абстрактные темы в духе «что было хорошо, что плохо, что изменить», а смотреть на метрики команды — какой уровень сейчас, какая динамика. И уже от этого отталкиваться, чтобы определять точки роста. Изменить как подготовку к ретро, так и сам процесс проведения встречи.
В Сравни завязанные на метрики ретроспективы стали неотъемлемой частью нашего рабочего процесса. За счёт такого подхода нам удалось повысить качество наших ретроспектив (по обратной связи от команд и технических лидеров), дать ребятам более четкое и систематизированное понимание того, какие есть возможности для развития внутри команды и организации в целом.
Мы пришли к этому не сразу. Как это часто бывает с инициативами по части процессов, прошли здесь путь от пилота в одной команде до масштабирования по разным продуктам и направлениям.
В процессе не обошлось без трудностей:
Информационная перегрузка — по началу получали фидбэк, что метрик много, командам было бы комфортнее работать в формате «1–2 главные штуки, на которых фокусируемся».
Разночтение метрик в разных командах.
Сопротивление со стороны участников команды, кто чувствовал, что нововведения добавляют дополнительную нагрузку.
С временем польза от метрик перевесила сложности, а ребята в командах прошли все классические стадии от отрицания до принятия.
В этой статье хотим подробно рассмотреть один из аспектов этой истории — какие конкретные метрики мы выбрали для наших ретроспектив, как их измерять и анализировать, а также какие есть ограничения и потенциальные трудности, связанные с каждой из метрик. Поехали!
Метрика 1: пропускная способность команды
Эта метрика показывает, сколько элементов бэклога команда может выполнить за определенный период времени от начала до конца. Этот показатель нужен для понимания реальных фактических возможностей команды и для планирования.
На что тут обращаем внимание:
Анализ тренда пропускной способности за несколько спринтов.
Увеличение пропускной способности может указывать на улучшение эффективности команды, прокачивание навыков, успешное внедрение новых инструментов. С другой стороны, снижение может указывать на трудности — увеличение сложности задач, недостаточное планирование или внешние помехи.
Сравнение пропускной способности до и после внесения изменений в процессы.
Это помогает оценить, насколько эффективно внедрение новых методик или инструментов повлияло на работу команды.
Отслеживание вариабельности (выбросов и резкого снижения) в пропускной способности может быть особенно полезным. Например, резкие изменения уровня метрики могут указывать на непредвиденные сложности с реализацией задач, изменения в составе команды, отпуск, увольнение, новые требования.
Скачки в метрике могут быть вызваны не учтенными при планировании внешними зависимостями — когда только в процессе работы выясняется, что команда А зависит от команды Б.
Важно использовать показатель для анализа работы команды в целом, а не для оценки производительности отдельных сотрудников. Превращение пропускной способности в инструмент оценки индивидуальной производительности может создать нездоровую рабочую атмосферу и повлиять на моральный дух команды (показательный индикатор — шутки про измерения в бане).
Вместо этого фокус должен быть направлен на поиск способов улучшения и оптимизации рабочих процессов.
Метрика 2: время цикла
Это время, необходимое для выполнения элемента бэклога от момента начала работы над ним до завершения. Метрика важна для понимания эффективности рабочих процессов команды и прогнозирования сроков реализации. На ретроспективах это может быть показателем, который помогает команде определить, как изменения в процессах влияют на скорость выполнения работы.
Для оценки времени цикла необходимо отслеживать временные метки начала и завершения каждой задачи.
Использование метрики помогает обнаруживать этапы в рабочем процессе, на которых задачи сталкиваются с задержками или требуют больше времени для выполнения, чем предполагалось.
Наример, в одной из команд мы заметили, что метрики стала расти на протяжении нескольких спринтов подряд. Вынесли обсуждение на ретроспективу и обнаружили, что на этапе разработки команда практически всё время была занята багами и почти не занималась новыми задачами, хотя планы были как раз про новые фичи. По итогу обсуждения договорились пересмотреть приоритеты, назначили дежурных по багам; остальная часть команды получила возможность сфокусироваться на новой функциональности.
Постоянное увеличение времени цикла на определённых этапах сигнализирует о присутствии проблемных зон, которые являются узкими местами процесса. Распознавание и исправление этих узких мест способствует повышению эффективности работы и уменьшению общего времени, необходимого для завершения задач.
Пример: в команде заметили увеличение времени цикла, стали разбираться — узким местом процесса оказалось участие одного из разработчиков в задачах другой команды на 50% времени («там очень надо, пожар»). В итоге пересмотрели договоренности, полностью выделили человека только в одну команду — время цикла стабилизировалось.
Продолжительные периоды выполнения задач могут также указывать на нехватку ресурсов, несоответствие квалификации сотрудников или неправильное распределение рабочих нагрузок. Наблюдаемые различия в продолжительности выполнения аналогичных задач выявляют нестабильность процессов.
Время цикла — возможный индикатор того, насколько удачно организована декомпозиция в команде. Стоит только «нарезать слишком крупно», как зачастую можно увидеть увеличение метрики.
Анти‑паттерн: использовать время цикла для сравнения разных команд или проектов. Задачи могут существенно различаться по сложности, объему и приоритетам. Использование метрики для сравнения команд может привести к недопониманию и несправедливым ожиданиям, а также создать нездоровую конкуренцию, нацеленную на «показатели» вместо реальной ценности.
Вместо этого, стоит сосредоточить внимание на улучшении времени цикла внутри команды, учитывая её уникальные условия и задачи.
Метрика 3: «старение» элементов бэклога
Метрика показывает, сколько времени задача находится в бэклоге, прежде чем команда начинает над ней работать. Позволяет обсуждать и переоценивать приоритеты, улучшать подход к выбору задач.
Для оценки метрики проверяются даты создания задач и начала работы над ними. Это помогает команде понять, как долго задачи остаются в ожидании и почему некоторые из них могут быть отложены или забыты.
Одно из ключевых применений этой метрики — выявление задач, которые остаются без внимания и могут требовать переоценки или изменения приоритетов.
В бэклоге могут оказаться элементы, которые могли быть изначально важными, но со временем потеряли свою актуальность из‑за изменений в проекте или внешней среде. Наблюдая на «старением» бэклога, команды могут принимать обоснованные решения о том, следует ли эти задачи перепланировать, доработать их описание и цели, или же полностью исключить из бэклога, чтобы освободить ресурсы для более приоритетных и актуальных работ.
На ретроспективах обсуждение метрики старения элементов бэклога может способствовать более осмысленному и сбалансированному планированию.
Из рисков: иногда случается избыточный фокус на новых задачах, что может привести к упущению важных, но недооцененных старых задач. Важно уделять внимание не только новым запросам, но и тем задачам, которые долго находятся в бэклоге, чтобы гарантировать, что все важные задачи получают должное внимание и ресурсы.
Метрика 4: доля переходящих задач
Это процент задач, которые не были завершены в течение текущего спринта и перешли в следующий. Метрика помогает команде понимать, насколько реалистично они планируют свои спринты и какие препятствия мешают своевременному выполнению задач.
Подсчет делается через сравнение между числом задач, запланированных для спринта, и тех, которые были фактически выполнены. Это дает представление о проценте элементов бэклога, не завершенных в установленные сроки.
Метрика может быть использована для выявления повторяющихся причин задержек в реализации задач. Если некоторый тип задач регулярно переносится на следующий спринт, это может указывать на необходимость переоценки их сложности, приоритетов или ресурсов, необходимых для выполнения. Причины могут быть как внутренние, так и внешние (зависимости от других команд, например).
Важно избегать использования этой метрики как единственного критерия оценки успешности спринта. Фокус только на количестве перенесенных задач может привести к недооценке качества выполненной работы и упущению аспектов, таких как слаженность работы в команде, творческий подход к задачам и удовлетворенность процессом или результатами.
Также важно учитывать, что некоторые задачи могут быть заведомо сложными или нестандартными, что неизбежно приводит к их переносу на следующий спринт без отражения на общей эффективности команды.
Необходимые условия успеха в использовании метрик
Есть несколько технических моментов, без которых велик риск того, что инициатива с регулярным отслеживанием процессных метрик не сработает.
Качество данных
Нам пришлось уделить особое внимание дисциплине ведения и качеству заполнения полей в таск‑трекере. Если раньше задачи можно было перемещать по доске как угодно, то теперь команды следуют общим единым правилам перемещения слева направо, через оговоренный список этапов. Только так можно обеспечить необходимое качество данных для анализа.
Время для анализа
Изначально анализ графиков процессных метрик на ретроспективах занимал много времени и был довольно трудоемким. Теперь мы заранее выделяем время для анализа и проводим его перед ретроспективой, что значительно повысило эффективность встреч.
У многих команда Delivery‑менеджер накануне завершения спринта (как правило, в четверг) уже собирает метрики, анализирует и отправляет их в общий командный чат.
Запуск мониторинга процессных метрик: чеклист
Ключевые элементы сетапа для трекинга процессных метрик и анализа этих показателей на ретроспективах мы сформулировали для себя так:
Культура работы с данными: уделите много внимания обучению команды правильному и последовательному введению данных. Это основа для полезных аналитических выводов.
Онбординг: объясняйте, помогайте, обучайте и снова объясняйте.
Постепенное внедрение: начните с одной или двух метрик, добавляйте другие поэтапно, дайте коллегам возможность привыкнуть и освоиться.
Подготовка: планируйте анализ данных заранее, чтобы на самой встрече сосредоточиться на обсуждении и планировании улучшений.
У нас в командах мы проводили внутренние митапы, на которых разбирали теорию по метрикам; практику наращивали не только на рабочих задачах, но и с помощью игр‑симуляций.
Главный совет — прежний: перепроверьте, на какие принципы опирается культура ИТ‑команды. Если пойдёте продвигать инициативу про метрики, а вокруг в компании ребята будут видеть упор на экспертную оценку вместо данных, то рискуете оказаться «не на той волне», забуксовать, потому что «у нас так не принято». И наоборот — если в компании ценят, умеют и практикуют работу с данными, а вы пока не занимаетесь такими вещами, опираетесь только на мнения людей, то возможно с инициативой про процессные метрики стоит ускориться.
Что бы там ни обнаружилось в культуре ИТ‑команды, желаем вам успехов с ретроспективами в частности и улучшениями процессов в целом!
Расскажите в комментариях — за какими процессными метриками вы следите? Что ещё используете для улучшения ретроспектив?
