Сообщаем о проблемах так, чтобы их тут же решали: коротко, внятно и по делу
✅ Цель: как можно быстрее и точнее описать баг. К хорошему репорту не будет дополнительных вопросов (а во сколько конкретно? а если включить и выключить?), разработчики быстрее среагируют и лучше поймут задачу. Поэтому работу над хорошим сообщением о баге мы начинаем в тот же момент, когда встретились с багом: изучаем его со всех сторон, делаем скриншот, фиксируем время встречи и всю нужную техническую информацию.
❌ Точно не цель: оценить интеллектуальный уровень разработчиков / поделиться возмущением, что продукт — отстой / выразить неудовольствие процессами, которые допускают такие баги. Для всего этого есть другие места, не багрепорты.
Общие советы
Во-первых, убираем лишнее: эмоциональную составляющую, канцеляризм, формальные обороты и специфический сленг, потому что мы не уверены, что все в курсе значения слов «отбивка», «эвейл» и«хулиганка».
Во-вторых, добавляем нужное:
Что я сделал: последовательность действий, расписанная по шагам
Что я хотел получить (ожидаемый результат)
Что я реально получил (фактический результат)
Детали и исключения (я попробовал так и сяк)
Техническая информация и окружение (ссылка на страницу, браузер, ОС смартфона или что-то другое)
Когда в первый раз столкнулись, удалось ли воспроизвести ошибку, и если да, то во сколько
Скриншот/скринкаст, фото/видео
Известные данные о задаче: кто её делал? где?
Убедись, что задача отдана в нужные руки и её увидели
Теперь проблема ясна, указана область поиска и есть ссылка для проверки и отладки. Проблему легко обработать сразу или перенести в баг-трекер, и меньше шансов, что баг будет проигнорирован, потому что в нём лень разбираться, или исправлен неверно из-за нехватки данных.
А ещё его просто приятно читать — чувствуется уважение к времени других и желание помочь, а не набросить на вентилятор.
Пример
Возьмём за пример обычную ситуацию в саппорте, когда у пользователей что-то сломалось, и нужно быстро сообщить об этом команде: Всё сломалось! У юзеров в личном кабинете не отображаются платежи за прошлый месяц. Что за бардак, от нас уйдут же все клиенты?
Убираем шум
Чистим сообщение от эмоций, оставляем суть: Есть репорты с прода от трёх пользователей: в личном кабинете не отображаются платежи за прошлый месяц
Описываем ожидаемый и реальный результат
Сформулируйте суть проблемы и как должно работать: Есть репорты с прода от трёх пользователей: в разделе «История платежей» за июнь нет данных, хотя платежи были. Ожидают, что там отобразятся все транзакции
Тестируем на себе
Добавляйте условия воспроизведения: Есть репорты с прода от трёх пользователей: в разделе «История платежей» за июнь нет данных, хотя платежи были. Транзакции должны отображаться. В приложении всё корректно, проблема только в десктопной версии.
Добавляем ссылки и технические данные
Пишите даже очевидные вещи — разработчик может не знать контекста: Есть репорты с прода от трёх пользователей (user1@pocta.ru, user2@pochta.ru, user3@pochta.ru): в разделе «История платежей» (site.com/payments)за июнь нет данных, хотя платежи были. Транзакции должны отображаться. В приложении всё корректно, проблема только в десктопной версии.
Находим ответственных
Если пишете в общий чат, уточните, кто должен реагировать на сообщение. Если проблема связана с конкретным функционалом или командой, добавьте её: Есть репорты с прода от трёх пользователей (user1@pocta.ru, user2@pochta.ru, user3@pochta.ru): в разделе «История платежей» (site.com/payments) за июнь нет данных, хотя платежи были. Транзакции должны отображаться. В приложении всё корректно, проблема только в десктопной версии. Раздел разрабатывала команда биллинга, контакт —@billing_support. Женя, сможешь посмотреть сегодня?
Ориентируемся во времени
Это поможет связать баг с релизами и быстрее найти причину: Есть репорты с прода от трёх пользователей (user1@pocta.ru, user2@pochta.ru, user3@pochta.ru): в разделе «История платежей» (site.com/payments) за июнь нет данных, хотя платежи были. Транзакции должны отображаться. В приложении всё корректно, проблема только в десктопной версии. Первый репорт — вчера в 17:20, до этого жалоб не было.
Раздел разрабатывала команда биллинга, контакт —@billing_support. Женя, сможешь посмотреть сегодня?
Добавляем скриншоты, видео и логи
Покажите проблему наглядно: Есть репорты с прода от трёх пользователей (user1@pocta.ru, user2@pochta.ru, user3@pochta.ru): в разделе «История платежей» (site.com/payments) за июнь нет данных, хотя платежи были. Транзакции должны отображаться. В приложении всё корректно, проблема только в десктопной версии. Первый репорт — вчера в 17:20, до этого жалоб не было.
Скриншоты от пользователей: https://… Скриншоты СМС, видно платежи за вчерашний вечер: https://…
Раздел разрабатывала команда биллинга, контакт —@billing_support. Женя, сможешь посмотреть сегодня?
Получилась красота: чёткое описание проблемы, понятен маштаб (три пользователя со вчерашего вечера), есть данные для воспроизведения, указаны контакты и ответственные.
Команде не нужно уточнять детали — баг готов к исправлению.
«Ой, это было не вам» — фраза, которая хотя бы раз заставляла кровь стынуть в жилах любого саппорта. Ещё не отправляли клиенту скриншот своего чата с подругой вместо ответа по тикету? Ваш час придёт. Встретьте его во всеоружии.
Извинения в поддержке — универсальная затычка для ситуации, в которой клиент предположительно: расстроен, зол, страдает, вынужден делать лишнее или терпеть неудобства (подчеркнуть нужное). А после извинений общение вроде бы можно и завершать, уточнив, что нам искренне жаль.