Как повысить эффективность использования баг-трекера
В качестве вводных
Баг-трекер — система для хранения задач для вашего проекта или продукта. На разных этапах работы баг-трекеры полезны менеджерам, тестировщикам, разработчикам, аналитикам и другим членам команды. Если вы представляете одну из этих ролей и хотите улучшить сценарии использования баг-трекера, то эта статья как раз кстати.
Здесь я не буду описывать процесс выбора баг-трекера, потому что это сильно зависит от ваших потребностей и возможностей. Будем предполагать, что система уже выбрана и готова к работе. Осталось начать заполнять ее тикетами — сущностями, в которых содержится описание задачи. Наверняка вы уже это делаете, и я хочу поделиться опытом, который получил за время работы в продуктовой команде. Мы прошли путь от коротких описаний “надо добавить вот такую штуку” до системы с выстроенными процессами, в которую заносится каждая деталь.
Поэтому далее я хочу сфокусироваться на оптимизации сценариев использования баг-трекера.
Улучшаем процессы
В баг-трекерах ведется учет важных задач: найденных проблем, планируемых доработок и необходимых настроек. Это позволяет назначать задачи исполнителям и отслеживать статус их выполнения.
Подобные системы имеют богатый набор функций, которые можно затачивать под нужды вашей команды. Такая гибкость дает много возможностей, позволяя даже использовать систему не совсем по назначению.
Чтобы не теряться в многообразии возможностей, я перечислю основные моменты, которые нужно учитывать при работе с системой. Итак, поехали!
Добавляйте все в баг-трекер
Существуют разные подходы к вопросу наполнения баг-трекера, но наша команда остановилась на таком: тикеты заводятся для всех найденных ошибок и для всех планируемых улучшений. Один тикет — это одна ошибка или одно улучшение, которое можно взять в работу изолированно от других.
У такого подхода есть плюс: в системе хранится история всех тикетов, поэтому в любой момент можно посмотреть, знаем ли мы о проблеме и почему мы ее не исправляем.
Есть и минус: большим объемом информации сложно управлять, в нем сложно найти нужное.
Определите структуру
В этом вопросе тоже существуют разные подходы, но мы выбрали такой:
- Описание проблемы содержится в тикете и только там;
- Описание улучшений делится на две части. На отдельном портале с удобными инструментами форматирования и иерархии страниц подробно описываются детали доработки с разделением на страницы или абзацы внутри одной страницы. Тогда в тикетах достаточно привести ссылку на нужную страницу, дополнив ее критериями приемки, сценариями тестирования и другой информацией, которая поможет на этапе тестирования. Важно, чтобы описание в тикете и на портале не повторялось, тогда вам не придется вносить изменения в двух местах.
Такое разделение нужно, потому что описание ошибок вполне умещается внутри одного тикета. Однако улучшения могут содержать описания новых модулей, которые лучше хранить в более структурированном виде.
Присваивайте понятные названия
Если в системе много тикетов, то понятные названия помогут быстрее в них ориентироваться. “Некорректная работа приложения” — плохое название, оно не дает никакой информации. “Приложение зависает при запуске в полнолуние” — хорошее название, из него понятно, что и при каких обстоятельствах пошло не так.
Добавляйте как можно больше атрибутов
Помимо названия, тикеты можно дополнять метками, лейблами, именами затронутых модулей. Любые дополнительные атрибуты помогают проще находить задачи при поиске.
Ищите дубликаты
Перед созданием любого тикета всегда нужно убедиться, что он действительно новый. Иначе возможна ситуация, когда одной и той же задачей занимаются разные люди. Если все наши тикеты имеют понятные названия и дополнительные атрибуты, то поиск станет заметно проще.
Используйте шаблоны
Тикеты будет проще читать, если они оформлены в однообразном стиле. Некоторые баг-трекеры могут автоматически подставлять шаблоны, тогда вам останется просто вписать недостающее. Но даже если такой возможности нет, договоритесь с командой о структуре внутри тикетов. В них должна быть отражена вся необходимая информация.
Приводите всю доступную информацию
Тикет — это самостоятельная единица, поэтому в нем должна содержаться вся необходимая информация или хотя бы ссылка на такую информацию. Поэтому все нужное для дальнейшей работы над тикетом должно быть внутри: модель устройства, точные шаги воспроизведения проблемы, потенциальное влияние на пользователей, частота возникновения проблемы, логи, скриншоты, ссылки на документацию. В идеальной ситуации исполнитель получает тикет и сразу начинает над ним работать без необходимости задавать уточняющие вопросы.
Валидируйте данные
Многие баг-трекеры позволяют делать определенные поля обязательными при создании тикета. В каких-то системах доступны более сложные сценарии валидации с зависимостями одних полей от значений других. Такой функцией обязательно нужно пользоваться, это поможет акцентировать внимание на заполнении важных полей и повысить информативность тикетов.
Выставляйте правильные приоритеты
В команде должен быть человек, который понимает приоритетность задач в зависимости от потребностей бизнеса. Определение приоритетности будет проще, если тикет правильно составлен. Тогда сразу будет видно, что здесь проблема возникла у одного пользователя и не мешает остальным, а вот здесь могут пострадать все пользователи из Нарнии.
Поддерживайте актуальность
Любые изменения нужно отражать в тикете: появилась дополнительная информация, поменялся исполнитель, увеличилось количество затронутых пользователей, выросла трудоемкость задачи из-за новых вводных — все это должно быть отражено в тикете. Если команда привыкла обсуждать задачи в чатах или во время звонков, то сложно заставить себя выписывать итоги обсуждения в тикеты, но это полезная рабочая процедура. Невозможно держать все в голове, поэтому переложите эту ношу на баг-трекер.
Не забывайте про интеграции
Баг-трекеры могут иметь возможность интеграции со сторонними системами:
- Уведомления о новых тикетах могут отправляться прямиком в корпоративный мессенджер, откуда вы сможете назначать на них ответственных лиц или выставлять приоритет. Так вы сможете оперативнее решать рутинные задачи;
- Форма обратной связи на вашем сайте может автоматически генерировать тикеты. Так ничего не потеряется.
Если вам не хватает какого-то сценария использования баг-трекера, то первым делом проверьте, не решается ли он с помощью интеграции.
Заключение
Выстроенные процессы не будут хорошо работать, если команда не понимает их ценности. Поэтому не менее важно объяснить всем участникам, зачем им тратить время на подробные описания, актуализацию статусов и написание уточнений. Здесь важно привести примеры выгоды, которую получат участники:
- Менеджеры наглядно видят, какими задачами занята команда. Это полезно и для планирования, в том числе;
- Тестировщики получают единую точку входа для сохранения всех найденных проблем. Больше никаких отдельных чатов с разработчиками, в которых легко потеряться;
- Разработчики получают полное описание работы со всей дополнительной информацией в виде скриншотов, связанных задач и комментариев.
Когда команда на деле увидит прибавку к производительности, вам останется только прислушиваться к обратной связи и продолжать улучшать процессы. Кстати, обратную связь можно также собирать в баг-трекере :)
Об авторе
Systems Analyst и Product Owner в команде CT Software в группе компаний CT Customertimes corp — CT Customertimes, CT Consulting, Masterdata, CT Cloud.
Участвует в разработке продуктов компании в качестве Systems Analyst. Управляет пакетом CT Mobile внутри платформы Salesforce в качестве Product Owner.
Больше информации о продуктах, кейсы и истории успеха здесь:
Сайт: https://masterdata.ru/
LinkedIn: https://www.linkedin.com/company/masterdata/
Instagram: https://www.instagram.com/masterdata_cis/
Facebook: https://www.facebook.com/1masterdata
