Рано или поздно в любом трекере задач появляются пользовательские поля, и каждая команда, которая их получает, проходит один и тот же путь: всплеск энтузиазма, одиннадцать новых полей, а через шесть недель — форма, где девять из них пусты в каждом тикете.
Проблема не в пользовательских полях. Проблема в том, что «было бы полезно это знать?» — неправильный вопрос перед созданием поля. Полезно знать почти всё.
Проверка, которую стоит применять
Прежде чем добавить поле, спросите: какое решение из-за него изменится?
Не «что оно нам скажет», а что вы будете делать иначе. Если честный ответ — «мы сможем это видеть», то через месяц поле будет пустым, потому что никто не заполняет поле, которое ничего не меняет.
Два примера, где одна и та же информация проходит и не проходит проверку:
Затронутая версия в команде, которая выпускает релиз каждую неделю и поддерживает две версии: проходит. От неё зависит, нужен ли бэкпорт.
Затронутая версия в веб-приложении с непрерывным деплоем: не проходит. У всех одна и та же версия. Это поле, которое записывает дату в худшем формате.
Поле одно и то же. Решение — нет.
Вторая проверка: кто его заполняет?
Поле, которое заполняет тот, кто разбирает баги, — рабочее. Поле, для которого нужна информация, которая есть только у автора отчёта или у инженера после расследования, при разборе пропускают и к нему больше не возвращаются.
Если на вопрос поля можно ответить только поздно, это не поле для разбора. Поставьте его рядом с приоритетом — и оно будет тормозить каждый разбор, оставаясь при этом пустым.
Поля, которые стабильно окупаются
Уровень клиента (выбор из списка). Если срочность бага действительно зависит от того, кто на него наткнулся, это поле сильнее всех остальных меняет порядок разбора. Проверку «какое решение изменится» оно проходит без оговорок.
Регрессия? (чекбокс). Один бит, заполняется при разборе и делит бэклог на «это сломали мы» и «это никогда не работало правильно». Это две разные очереди с разной срочностью.
Связанный PR (URL). Не для отслеживания, а для того, кто через четыре месяца снова откроет баг и захочет узнать, что уже пробовали.
Ревьюер или ответственный за QA (участник). Только если второй человек действительно должен принять работу. Если в вашей команде единственная роль — «исполнитель», это поле всегда будет равно исполнителю.
Поля, от которых стоит отказаться
Всё, что можно вычислить. Дней открыта, число отчётов, есть вложения — трекер это уже знает, а копия, которую ведут руками, устареет, как только кто-нибудь забудет её обновить.
Второй статус. Заблокирована, Нужна информация, Ждём клиента в виде поля рядом с колонкой доски означают, что реальное состояние задачи живёт в двух местах, которые начнут друг другу противоречить. Если это состояние, то это колонка, а если колонку под него вы не хотите, то, скорее всего, вам не нужно и само состояние.
Свободный текст там, где нужен список. В текстовом поле Компонент накопятся checkout, Checkout, check-out и chkout, и потом по нему не получится ни фильтровать, ни считать. Если вы хотите по нему группировать, это должен быть фиксированный список.
Всё, что вы добавляете, потому что кто-то однажды попросил. Поля дёшево создавать и дорого удалять: удаление приходится обсуждать с людьми. Планка должна быть выше, чем «кто-то об этом упомянул».
Как выбрать тип поля
Типы — не украшение. От них зависит, что вы потом сможете спросить у доски.
Тип | Когда использовать | Что даёт |
|---|---|---|
Выбор из списка | Фиксированный набор вариантов | Чисто фильтровать и группировать |
Множественный выбор | Несколько вариантов из фиксированного набора | Спросить «затрагивает iOS или Android» |
Число | Настоящее количество | Фильтровать по диапазону |
Дата | Момент времени | Фильтровать по диапазону |
Чекбокс | Один бит | Разделить доску надвое |
Текст / URL | Всё остальное | Только поиск по подстроке |
Главная ошибка — брать текст, потому что его быстрее всего настроить. Текст — это тип, который выбирают, когда смирились с тем, что по этому полю никогда не будут фильтровать.
В BugDump тип свойства нельзя изменить после создания, потому что уже сохранённые значения имеют форму этого типа, — так что тридцать секунд на выбор потрачены не зря.
Меньше полей, но заполненных
Доску полезной делает не то, сколько она может записать, а то, что записанному можно доверять.
Три поля, заполненные в каждой задаче, лучше одиннадцати, каждое из которых заполнено в трети задач. Редко заполняемое поле хуже, чем никакого: оно выглядит как данные, поэтому по нему фильтруют, и фильтр молча отбрасывает каждую задачу, где кто-то торопился.
Полезная привычка: через месяц посмотрите, как часто заполнено каждое пользовательское поле. Всё, что меньше примерно половины, либо плохо названо, либо плохо расположено, либо отвечает на вопрос, которого ни у кого нет. Удалите его. В BugDump удаление свойства убирает его и его значения, но не трогает задачи, так что чистка стоит только решения.
Как это работает в BugDump
Пользовательские свойства живут на странице проекта Свойства, рядом с пятью встроенными — статусом, исполнителем, приоритетом, метками и сроком, — которые построены на том же механизме и редактируются так же.
Типов восемь — текст, число, дата, чекбокс, URL, выбор из списка, множественный выбор и участник, — и у каждого на доске свой фильтр: чекбоксы для списков, диапазон для чисел и дат, поле «содержит» для текста. Фильтры объединяются логическим И и хранятся в URL, так что отфильтрованная доска — это ссылка.
Свойства доходят и до вашего ИИ-агента. MCP-сервер возвращает каждое свойство с его вариантами, а list_tasks принимает фильтры по свойствам, так что «открытые задачи, где Уровень клиента — Enterprise» — это один вызов, а не «загрузить всё и перебрать».
Пользовательские свойства доступны на тарифах Pro и Ultra; пять встроенных, включая редактируемый список приоритетов, — на всех тарифах.
Читайте также
Уровни приоритета багов: почему четыре фиксированных варианта никогда не подходят — зачем вообще нужна шкала приоритетов, сколько в ней должно быть уровней и почему слова в ней должны быть вашими.
Метрики баг-трекинга, которые стоит считать — четыре метрики, которые показывают, успевает ли команда за багами, и еженедельный пятиминутный обзор на их основе.
Уведомления в баг-трекере: кому сообщать об изменении — как поле типа «Участник» решает, кто узнаёт об изменениях задачи, без списков наблюдателей.