Пивтрекер: как мы сократили сборку плана спринта с 90 до 20 минут

Я тимлид, и у меня была команда, которая до этого полгода не попадала в роадмап. Чтобы понять, кто чем занят и что мы реально успеем, я начал рисовать спринт по дням и людям в Miro.

Это сработало, но за сутки доска расходилась с трекером, и сводить её обратно приходилось руками. Тогда я за вечер собрал в Cursor прототип планера, а через несколько месяцев на нём планировал весь отдел RnD.

Продукт называется Пивтрекер. Он не заменяет трекер: задачи, статусы и спринты остаются в Яндекс Трекере или Jira, а Пивтрекер раскладывает их по людям и дням и кладёт факт рядом с планом. Код открыт и запускается одной командой docker compose.

Планирование по готовому бэклогу не работало по трём причинам:

Классика: всё горит и всё надо делать. Но если важно всё, то не важно ничего.

Отсюда первое правило — приоритизация. Второе — сроки: важное и быстрое берём первым, неважное и долгое последним.

Чтобы «быстро» и «долго» значили для всех одно и то же, мы переводим стори поинты во время:

Правило простое: задача не длиннее двух-трёх дней. Выбиваемся из срока — останавливаемся, декомпозируем и берём то, что осталось.

Раньше работали на канбане в Яндекс Трекере. По доске не видно ни порядка задач с учётом блокеров, ни того, укладываемся ли мы в сроки.

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

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

На первый черновик уходило до полутора часов. На дейли обсуждали распределение задач и согласовывали итоговый план спринта.

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

С влётами тоже стало проще: нагрузка видна, и понятно, куда поставить задачу, что подвинуть и чем мы из-за этого рискуем.

Подход сработал, но появились проблемы.

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

Однажды вечером я сказал себе «хватит это терпеть» и выписал требования к будущему продукту, который решил бы все наши боли:

Стек взял знакомый: React, Next.js, Tailwind, pnpm. И сел собирать прототип в Cursor, по платной подписке.

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

После первого промпта появилось то, что дальше можно было развивать.

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

День делился на три части, каждая треть — 1 SP. С нашей таблицей это сходилось плохо, но на старте хватало. Задачи можно было двигать по дням, менять им исполнителя и длительность.

Дальше я привёл в порядок интерфейс: поправил стили, основную информацию по задачам перенёс в теги. Привет любителям тего-ориентированного дизайна.

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

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

Он жил у меня на машине и закрывал потребности одной команды. На процессном комитете обсудили, чего остальным командам не хватает для переезда. Цели команды ведут в трекере, шкала оценки у каждой своя, а часть команд сидит в старом планере (о нём ниже).

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

С этим именем мы с Cursor взялись за планер уже для всего отдела.

Цели мы держали в трекере так как таким образом проще снимать метрики, и источник правды один. Оформляли их задачей типа goals. Название строго по формату <Команда> <гг><номер спринта в году>, а сами цели — чеклист внутри задачи, чтобы забирать их через API. Изощрённо, зато цели считались без отдельного инструмента.

Для переезда в планер появилась вкладка «Спринт»: там цели ведутся и отмечаются. Там же спринт запускается и закрывается. Перед запуском планер проверяет три вещи: цель на месте, каждый участник загружен по договорённостям команды, задачи размечены как надо.

Потом заведение целей упростили и переложили на планер целиком. От отдельной задачи в трекере отказались.

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

Позже шкала стала настройкой организации. У других компаний свои договорённости, и навязывать наши не хотелось. День делится на 2, 3 или 4 части. Оценку можно вести в этих частях, в днях или задать свою таблицу: сколько частей занимают 1, 2, 3, 5 и 8 SP.

Несколько лет назад в компании уже был свой похожий планер с другим UX. Он давно не обновлялся, но несколько команд продолжали им пользоваться.

Основа плана — клетка. Клетки закрашиваются, но логика рутинная: выбираешь исполнителя, как цвет заливки, и кликаешь по клеткам. Чтобы стереть клетку, нужно снова выбрать того же исполнителя. Неудобно.

Зато был режим, где строки — не люди, а задачи. Планируешь от эпика, а не от человека.

Чтобы не переучивать всех в один день, этот вид перенесли как есть.

Для тех, кто привык к доске в трекере, добавил канбан и заодно светлую тему.

Продукт развернули во внутреннем контуре и решили перевести на него все команды. 4 марта 2026 года в отделе RnD началась бета.

Сборка плана стала быстрее. Если на спринт уже набрано хотя бы 80% задач, на их распределение уходит:

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

В отделе планером уже пользовались, и захотелось открыть его всем. Яндекс Трекер есть не у всех, поэтому первым делом я сделал адаптер к Jira. Код при этом не должен знать, с каким трекером работает.

Роут берёт клиент того трекера, который выбран у организации, и ходит в его API: доски, задачи, спринты. Пагинация, авторизация, статусы и история изменений живут в адаптере, роут их не видит.

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

Потом выяснилось, что Jira — это два разных трекера, Cloud и Data Center. Разные версии API и разный вход: OAuth и персональный токен. Одним адаптером оба не закрыть. Появился отдельный адаптер для Jira Cloud, и всего их стало три.

Планер хорошо показывал план, а факт оставался в трекере. Появился модуль, который забирает оттуда историю статусов. По этим данным под планом рисуется строка факта.

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

Доска стала общей, и на ритуалах хотелось видеть чужие действия, как в Miro. Поэтому мы добавили совместное редактирование. Когда над планом работают несколько человек, видно, кто что делает: смотрит, тянет карточку, меняет длительность или просто сидит рядом. Карточку, которую уже тянут, другой сдвинуть не может.

Дальше захотелось тратить меньше времени уже на сам планер. Так был разработан OAuth MCP и уже через него можно подключить Cursor или Claude.

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

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

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

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

Вид «по задачам», планировщик эпиков и квартальный план я убрал из интерфейса. Код на месте, но дальше я развиваю только то, с чего всё начиналось: планер спринта, бэклог, план и факт.

Пивтрекер открыт под лицензией Apache 2.0: github.com/Dinkimom/beer-tracker. На GitHub он называется Beer Tracker. Его можно бесплатно использовать и дорабатывать. В нашем отделе с ним стало проще планировать. Вдруг пригодится и вам.

Запускается так:

cp env.example .env # POSTGRES_PASSWORD, AUTH_SESSION_SECRET (≥32), ORG_SECRETS_ENCRYPTION_KEY (64 hex) docker compose -f docker-compose.yml -f docker-compose.hub.yml up -d

После запуска откройте http://localhost:3000 и подключите свой трекер. Поддерживаются Яндекс Трекер, Jira Cloud и Jira Data Center.

Если планируете спринт в Miro, в Excel или в голове — попробуйте. Буду рад обратной связи: пишите, чего не хватает, в комментариях или в issues на GitHub. Проект обновляется.

А как планируете спринты вы?