Бэклог при агентах тает быстрее: узким местом становятся ваши решения

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

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

Например, «сделать экспорт» ещё не объясняет, кто им воспользуется. Если сотрудник каждый день переносит одни и те же записи вручную, у задачи есть получатель и наблюдаемая потеря времени. Дальше нужна постановка задачи агенту: что изменить и как принять результат. Здесь выбираем, какая из задач заслуживает такой подготовки.

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

На живой странице /services 7 октября 2026 года у нашей машины 112 готовых задач в неделю в среднем за последние 30 дней. Единица этого счётчика: принятая и влитая в основную ветку правка, оформленная отдельным запросом на слияние кода, PR. Инженер ведёт машину агентов; это замер работы сайта, а не норматив для чужого проекта.

На /open есть другой ряд: 115 задач из реплик владельца, исторический срез 27 августа 2026 года. Медиана составляет 25 минут; 64 % задач уложились в час. Там измеряли путь от реплики до слияния кода. Это не среднее время всех работ машины и не обещание срока клиенту.

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

Закрывать больше карточек полезно, если решаются нужные проблемы. Раздробить одну правку на мелкие карточки и объявить рост производительности значит исказить картину работы. Сравнивайте похожие виды работы и отдельно смотрите, что изменилось у её получателя.

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

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

Для первого отбора достаточно спросить: что теряем, пока задача ждёт, и откуда известно, что её решение поможет? Остановившуюся публикацию можно наблюдать сейчас. Новую функцию «на всякий случай» надо сначала подтвердить. Технический долг тоже поднимается в очередь, если из-за него повторяется сбой или дорожает каждая следующая правка.

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

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

У восстановления и нового правила разные критерии приёмки. Сначала нужная страница снова открывается или лента снова публикует. Затем проверка воспроизводит причину сбоя и замечает её, если она вернётся. Пункт «всё починить» скрывает это различие.

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

Так замыкается петля: заметили сбой, выбрали исправление, проверили восстановление, закрепили правило. Общий пункт «поддержка сайта» такой петли не даёт. Для постоянных требований есть отдельная статья о правилах для ИИ-агентов.

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

Например, до восстановления формы заявок не обязательно запускать новый раздел. А независимую правку текста можно держать следующей в очереди. Если очередь уже подготовлена, но результаты копятся без приёмки, нужна работа с проверкой и влитием; это тема статьи «Руководитель разработки и агенты».

Наша медиана 25 минут и формулировка сервиса «задача в среднем за 48 часов» относятся к разным вещам. Первая характеризует исторический замер машины на собственном сайте; вторая описывает ориентир клиентской услуги, а не гарантированный срок каждой задачи. Условия, зависимости и ожидание подробно разобраны в статье о сроках разработки.

В подписке на разработку бэклог клиента превращается в готовые правки: «Ставите задачи своими словами, голосом или скриншотом»; «Поток — одна задача в работе».

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

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

Фиксируйте рядом с правкой сигнал, ожидаемый результат и способ его проверки. Тогда список пополняется следующим наблюдением, а не фантазией о том, чем занять свободное исполнение.

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

1. Пересмотрите старые идеи, прежде чем превращать их в готовую очередь агентам.
2. Выбирайте по потере от ожидания и подтверждению пользы; пересчитывайте полные усилия после ускорения кода.
3. Разделяйте завершение разработки, приёмку и результат для пользователя.
4. После сбоя добавляйте проверку причины, а после выпуска правки возвращайтесь к исходной проблеме.