Лекция «Баг-репорт и обратная связь продукту — как превратить жалобу клиента в документ, по которому сбой воспроизведут без вас»

Около 60 минут на 16 тем. Прогресс сохраняется, поэтому лекцию можно проходить частями и возвращаться к ней позже.

Начало — да: первые 1 тема открыты сразу, без регистрации. После бесплатной регистрации откроются темы до 2-й — вместе с частью из 36 тестов и монетами за верные ответы. Полная лекция — 99 ₽ навсегда, либо подписка на все лекции платформы от 499 ₽ в месяц.

Шестнадцать тем об одном документе — отчёте, который поддержка передаёт команде продукта. Начало с измерения, а не с мнения: в опросе 872 участников проектов Apache, Eclipse и Mozilla (466 ответов, 130 согласованных ответов разработчиков) шаги воспроизведения назвали важными 83%, стек-трейс — 57%, тест-кейс — 51%, скриншот — 26%, а severity и железо — ровно 0%. Оттуда же information mismatch: самое полезное читателю одновременно самое трудное для составителя, и закрыть разрыв инструментом не вышло — прототип CUEZILLA угадывал качество отчёта с точностью 31–48%. Дальше словарь: цепочка ошибка → дефект → отказ по ISTQB и правило, что поддержка видит только отказ; severity против приоритета с каноническими примерами расхождения (опечатка на логотипе против падения на редком legacy-браузере); инцидент, проблема и известная ошибка по ITIL 4 с тремя оговорками, которые обычно теряют; и ISO/IEC/IEEE 29119-3, где incident report назван зонтичным термином для bug report, defect report, issue и trouble report — спор о названии записи стандарт уже закрыл. Центральная часть — про то, отчего отчёты умирают: 188 319 записей из шести репозиториев, 17% невоспроизводимых, лишние три месяца жизни такого отчёта, 68% отказов прямо из начального статуса, и разбор 1 643 случаев по причинам, где «не хватило данных» только третья строка с 14%, а первые две — связь с другим отчётом (45%) и различия среды (24%). Из этого выводится порядок действий смены: повторить сбой самому, найти существующую запись, зафиксировать окружение, записать шаги протоколом. Финал — границы полномочий: severity как техническое наблюдение, срок собственного ответа вместо срока починки, правило маскирования персональных данных на фоне поправок 420-ФЗ в статью 13.11 КоАП, действующих с 30 мая 2025 года, требование уведомить регулятор до начала трансграничной передачи по статье 12 152-ФЗ и разбор двух цифр-зомби, которыми аргументировать нельзя.

Стороной границы. Там разбирают методологию поиска причины: как дойти до системного объяснения и не остановиться на человеке. Здесь поддержка причину не ищет вовсе — по ITIL 4 это работа управления проблемами, а первая линия работает на стороне инцидента и поставляет доказательства. Предмет этой лекции — документ: что в него попадает, что в нём проверяемо и почему 17% отчётов закрываются словами «не воспроизводится». Формулировка «я нашёл причину» в отчёте специалиста поддержки — не достоинство, а частый источник ложного следа: диагноз коду ставит разработка.

Да, и особенно про вас. Носитель отчёта — не предмет разбора: стандарт ISO/IEC/IEEE 29119-3 прямо называет incident report зонтичным термином, под которым живут bug report, defect report, issue, problem report и trouble report, — спорить о названии и форме бессмысленно, спорить надо о содержании полей. Всё, что здесь разобрано, работает и в сообщении в чате: шаги воспроизведения вместо пересказа жалобы, окружение восемью строками, идентификаторы вместо персональных данных, масштаб и наличие обходного пути вместо слова «критично». Разница только в том, что в чате нет поиска по существующим записям — а значит, риск дубля и потери отчёта выше, и первый шаг порядка действий приходится делать руками.