Лекция

Жалоба на смене и документ для чужой команды

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

Это ремесло, и оно измеримо. В опросе разработчиков Apache, Eclipse и Mozilla шаги воспроизведения назвали важным элементом отчёта 83%, а поле severity — 0%. В выборке из 188 319 отчётов 17% закрылись формулировкой «не воспроизводится», и живут такие отчёты примерно на три месяца дольше остальных. Плохой отчёт не просто не чинится — он держит чужое время.

О чём речь

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

Границы обозначим сразу. Здесь не учат чинить дефекты и ставить диагноз коду — этим занимается разработка. Здесь не разбирают методологию поиска первопричины — это отдельная дисциплина и отдельная лекция каталога. Здесь не про передачу обращения внутри поддержки и не про метрики смены. Только про документ, который уходит наружу, в продукт, и про решения, которые специалист принимает до того, как нажать «создать».

Аудитория — специалист поддержки со сменами, тикетами и SLA. Не тестировщик и не разработчик. Примеры меняют отрасль от темы к теме: маркетплейс, банковское приложение, SaaS для бизнеса, онлайн-школа, телеком.

Тема 1 из 16 · Документ и его читатель

Что читает тот, кто будет чинить

Начнём с измерения, а не с мнения. Bettenburg, Just, Schröter, Weiss, Premraj и Zimmermann в работе «What Makes a Good Bug Report?» (FSE-16, 2008) опросили участников проектов Apache, Eclipse и Mozilla: 872 человека, 466 ответов; выводы по разработчикам построены на 130 согласованных ответах.

872
участника опроса
466
полученных ответов
130
согласованных ответов разработчиков

Вопрос был прямой: какие элементы отчёта помогают вам чинить. Ответы разложились так — доля разработчиков, назвавших элемент важным:

Что разработчик считает важным в отчёте
Шаги воспроизведенияважны для 83%
Стек-трейс57%
Тест-кейс51%
Наблюдаемое поведение33%
Скриншоты26%
Ожидаемое поведение22%
Примеры кода14%
Краткое описание13%

Хвост списка выглядит ещё интереснее: версия — 12%, сообщение об ошибке — 12%, сборка — 8%, продукт — 5%, ОС — 4%, компонент — 3%. А два элемента набрали ровно ноль.

Два поля из опроса, которые не набрали ни одного голоса
ЭлементВажен для
Severity (важность)0%
Железо0%
Главное число темы

Поле, которое поддержка заполняет с наибольшим накалом, читающему разработчику не даёт ничего. Ноль процентов — это цифра из таблицы, а не риторическая фигура. Дальше будет видно, кому severity всё-таки нужно (не тому, кто чинит), а пока запомните пропорцию: 83 против 0.

Как это выглядит на смене. Маркетплейс, у части клиентов после обновления приложения не применяется промокод. Специалист пишет: «Критично! У клиентов не работают промокоды, много обращений, срочно чините». В отчёте есть накал и severity — и нет ровно того единственного, ради чего отчёт открывают.

Какой элемент отчёта разработчики в опросе Bettenburg назвали важным чаще всех?
83% против 26% у скриншота, 4% у ОС и 0% у severity. Скриншот и версия полезны, но они дополняют шаги, а не заменяют их: по картинке сбой не повторишь.
Severity в том же опросе набрала 0%. Как правильно распорядиться этим фактом на смене?
Ноль процентов означает не «поле лишнее», а «оно не помогает чинить». Severity работает на другом этапе — при разборе очереди отчётов. А завышение важности не ускоряет ничего: оно ломает сортировку у тех, кто эту очередь разбирает.
Бесплатный доступ

Дальше нужен аккаунт

Прогресс и монеты сохранятся.