Выпустите что-нибудь на несколько тысяч пользователей, и первое, что вы узнаете: баг-репорты не приходят по одному на баг.
Одно сломанное оформление заказа за полдня даёт сорок отчётов. Если разбирать их в лоб, это сорок записей, которые надо прочитать, сорок — разложить по категориям и тридцать девять — закрыть как дубликаты. Самый загруженный день баг-трекера приносит меньше всего информации.
Отчёты и задачи — разные вещи
BugDump хранит их раздельно, и на этом структурном решении держится всё остальное.
Отчёт — это одна отправка от одного пользователя в один момент: его описание плюс всё, что собрал SDK. Отчёты — неизменяемые доказательства. Их никогда не редактируют, не сливают и не дедуплицируют.
Задача — то, что вы исправляете. У неё есть публичный ID, колонка на доске, комментарии и история изменений.
К одной задаче привязывается много отчётов. Сорок отчётов об оформлении заказа становятся одной задачей с сорока доказательствами.
Это разделение — не бюрократия. Оно отражает реальное положение дел: доказательства и работа — разные объекты с разным жизненным циклом. Доказательства копятся и не меняются. Работа проходит через состояния и когда-нибудь заканчивается. Системы, которые их смешивают, заставляют выбирать: либо вы теряете доказательства, сливая дубликаты, либо тонете в записях, потому что каждое доказательство — ещё и задача.
Дубликаты — это ценность
Как только отчёты привязываются к задачам, дубликаты перестают быть шумом. Они становятся лучшим сигналом для отладки.
Сорок отчётов в одной задаче дают то, чего не даст ни один отчёт по отдельности: пересечение.
Если все сорок из Safari, это баг Safari, и вы узнали это, ещё не открыв отладчик. Если браузеры разные, но у всех вьюпорт уже 768px, дело в адаптивной вёрстке. Если отчёты собрались в пятнадцатиминутное окно, а потом прекратились, виноват деплой, и смотреть надо на то, что выкатили, а не на свой код.
Такой анализ занимает секунды, когда отчёты сгруппированы, и почти невозможен, когда это сорок отдельных строк в списке. Самый частый вид настоящего инцидента — много людей натыкаются на одно и то же — плоский список входящих обрабатывает хуже всего.
Здесь же пригождается MCP-сервер. «Прочитай отчёты по #17 и скажи, какие браузеры затронуты» — на такой вопрос агент отвечает за секунды, прочитав все сорок. Сравнивать отчёты между собой настолько нудно, что люди это пропускают, поэтому это и стоит автоматизировать.
Доска
Задачи живут на канбан-доске с колонками, которые вы задаёте сами. Каждая колонка относится к одному из двух состояний: открытая или закрытая.
Важна именно эта привязка, а не название. Например, колонки могут быть такими:
Разбор → Подтверждено → В работе → Готово → Не будем исправлять
Первые три здесь open, последние две — closed. А можно устроить всё совсем иначе: благодаря модели из двух состояний система понимает, какая работа ещё не сделана, как бы вы ни назвали колонки.
Два состояния, а не пять. Любая классификация вроде «Отложено / Заблокировано / Нужна информация / Ждём клиента», которую я видел, заканчивается одинаково: колонкой, которая заполняется задачами, на которые больше никто не смотрит. Если задача не сделана, она открыта, а открытая работа должна быть на виду.
То, что Не будем исправлять относится к closed, тоже сделано намеренно. Решение не исправлять — это полноценный итог задачи. Такая задача должна уйти из очереди открытых.
Цикл разбора, который работает
Прочитайте новые отчёты и сгруппируйте их. Большинство — дубликаты. Привяжите их к существующим задачам. Это самые результативные десять минут всего процесса: сорок записей превращаются в шесть.
Создайте задачи для того, что действительно новое. По одной на каждый отдельный баг.
Используйте пересечение. Если у задачи несколько отчётов, посмотрите, что у них общего, прежде чем смотреть в код.
Переносите, а не комментируйте. Место на доске и есть статус. Задача в колонке В работе с комментарием «вообще-то заблокировано» — это задача не в той колонке.
Закрывайте задачи. В том числе те, которые не будете исправлять.
Замкните цикл
Каждый проект может опубликовать публичный портал по адресу your-project.bugdump.com, где авторы отчётов следят за своими задачами.
Эту часть большинство инструментов пропускают, а именно от неё зависит, будут ли вам и дальше присылать отчёты.
Пользователь, который сообщил о баге и не услышал ответа, делает вывод, что сообщать бесполезно. И это разумный вывод из того, что он видит. Когда в следующий раз что-то сломается, он молча обойдёт проблему, а вы потеряете сигнал.
Пользователь, который видел, как его задача переехала из Подтверждено в Готово, усвоил обратное. Он сообщит о следующем баге, и о том, что будет после него.
Можно разрешить авторам самим привязывать отчёты к задачам. Если включён allowTaskAttach, тот, кто знает публичный ID задачи, отправляет отчёт прямо в неё. Для внутренних QA и бета-тестеров, которые и так следят за ID ваших задач, это полностью убирает этап разбора: авторы сами группируют свои дубликаты.
Отчёты — доказательства, задачи — работа
Отчёты — это доказательства. Задачи — это работа. Держите их раздельно, позвольте дубликатам копиться как доказательствам вместо того, чтобы с ними бороться, оставьте на доске два настоящих состояния и показывайте авторам отчётов, что произошло.
Сорок отчётов превращаются в шесть багов, и у этих шести доказательства лучше, чем мог бы дать любой отчёт по отдельности.
Читайте также
Как разбирать баги быстрее: работа с клавиатуры — процесс, который убирает лишнюю навигацию вокруг решения, а не требует думать быстрее.
У меня всё работает: определитель невоспроизводимых багов — восемь различий между машинами, из-за которых баг не воспроизводится, и признаки каждого.
Пусть ваш ИИ-агент читает баг-репорты — как Claude Code через MCP-сервер сам достаёт отчёты, логи консоли и сетевые запросы.