Как мы внедрили Yandex Tracker в процессы, а процессы в Yandex Tracker. Базовые метрики поставки

Я Delivery manager в компании Chatpush. Мы занимаемся разработкой сервиса для рассылок уведомлений клиентам: максимально полезная и удобная штука для салонов красоты, фотостудий, фитнес-клубов и других сервисов по оказанию услуг. У нас своя команда разработки и несколько продуктов. Мы долгое время вели задачи в Notion. Удобно на старте: база знаний и трекер задач в одном месте, умный поиск и AI ассистент. С ростом команды мы задумались о выборе другой трекинговой системы из-за отсутствия в Notion базовых метрик поставки и удобных инструментов планирования. Финальным штрихом стал уход Notion из России.

Хочу показать на нашем примере, как мы настроили и улучшили процессы с помощью Yandex Tracker. Сразу скажу, что никаких специальных знаний для настройки Yandex Tracker не потребовалось: все ответы можно найти в документации и в их группе поддержки в Telegram. Но практических примеров в сети мало, поэтому я решила поделиться нашим опытом.Итак, первое о чем я рекомендую задуматься, это о показателях, которые хочется измерять и какие проблемы решить. Начнем с метрик поставки.

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

Пропускная способность показывает производительность команды. Измеряем числом закрытых SP за спринт. На основе этих данных планируем будущие спринты.

Эффективность потока измеряет, сколько времени тратится на полезную работу. Считаем, что показатель больше 30% - хороший, если он ниже, то обсуждаем на ретро почему задачи зависают между статусами и что с этим можно сделать.

Time To Market оценивает время с момента появления идеи до момента ее передачи клиенту. Отрезвляюще показывает сроки на реализацию крупных проектов.

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

Динамика беклога показывает количество задач в беклоге во времени. Если видим рост беклога - назначаем встречу по грумингу, чтобы разобрать и приоритизирвоать новые задачи. Рост беклога может быть сигналом к неэффективной работе команды или к тому, что команду нужно увеличивать.

Практически все эти метрики в Yandex Tracker можно измерять с помощью дашбордов, давайте посмотрим, как это сделать.

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

Для разметки продуктов мы используем поле Компонент. Для некоторых продуктов у нас выделены отдельные очереди, но Компонент все равно в них заполняем, чтобы строить этот график.

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

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

Существенный недостаток этого и других графиков в Yandex Tracker в том, что они строят статистику по количеству задач. Нет возможности работать с размерами задач, оценками в часах или Story Points. Если задачи в работе существенно разного размера, то проценты будут сильно искажены.

Что мы с этим делаем? Для оперативного планирования спринтов мы принимаем такой уровень абстрацкии и стараемся декомпозировать большие задачи.Для юнит-экономики я перерасчитываю данный показатель в Story Points через сводные таблицы и Excel.

Для измерения этого показателя используем виджет График событий. В качестве ключевого параметра используем дату завершения. Выбираем в источнике задач нужные типы задач: Задачи, Исследования и Ошибки, Epics нам здесь не нужны. Выбираем статус Закрыт, потому что для задач в статусе Отменен тоже есть дата завершения, но они нас не интересуют. Группировку лучше делать по размеру спринта, в нашем случае - это неделя.

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

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

Этот показатель не рассчитывается в Yandex Tracker. Есть виджет Поток, но показатель эффективности потока он не рассчитывает. Зато можно видеть сколько задач одновременно у команды в работе. Если видим резкий подъем - скорее всего последует увеличение показателя Lead Time, нужно сосредоточиться на решении задач в работе и сократить количество новых задач.

Для измерения этих показателей используем виджет Время цикла. Для Lead Time начальным является статус принятия обязательств - в нашем случае это Будем делать, а для Time To Market начальный статус Новый. Исключаем фильтрами Отмененные задачи, задачи с типом Epic и задачи, которые мы намеренно хотим исключить (например, заблокированные на долгое время). Инструмент Jira flow companion умеет делать такое из коробки, а в Yandex Tracker мне пришлось накостылять кастомное поле Исключить из Leadtime.

Как читать статистику: 95% задач, взятых в работу, закрыты менее чем за 19 дней. 75% задач, взятых в работу, закрыты менее чем за 13 дней. В среднем задачи закрываются за 7 дней.

Смотрим на виджете Создано/Решено. Чтобы этот график построился при завершении задач должна заполняться резолюция. Резолюция может заполняться автоматически при закрытии задач (смотрите настройки автоматизации в описании Пропускной способности) или выбираться вручную на экране перехода в рабочем процессе.

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

#deliverymanagement