Обратная связь из прода: обращения и инциденты как источник новых задач

Через месяц после релиза в поддержке десятое обращение об одном и том же. До аналитика оно не доходит: каждое закрывают ответом «так задумано» — и формально это правда.

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

Откуда приходит обратная связь

Источник	Что из него видно	Как обычно теряется
Обращения в поддержку	Где пользователи не понимают систему или она ведёт себя не так, как они ждут	Закрываются ответом «так задумано» и не доходят до аналитика
Инциденты	Где система отказала: часто — нефункциональные требования, которых не было	Разбор заканчивается исправлением кода, постановка не меняется
Данные использования	Чем не пользуются вовсе и где люди бросают сценарий	Их никто не смотрит после релиза
Разговоры продаж и менеджеров	Чего не хватает, чтобы купить или продлить	Приходят как готовые решения: «сделайте как у конкурента»
Ручная работа вокруг системы	Таблицы, которые ведут рядом, потому что в системе нельзя	Не видны вообще, пока не спросишь

«Так задумано» — самый дорогой ответ

Поддержка отвечает пользователю, что система работает правильно, и закрывает обращение. Формально верно: поведение совпадает с постановкой. Но если таких обращений десятки, неверна постановка — она описала не то, чего ждут люди. Это тот же разбор, что в статье о спорных дефектах, только со стороны пользователя: «работает как написано» не значит «работает как нужно».

Отсюда правило для поддержки: обращения, закрытые ответом «так задумано», не исчезают, а копятся по темам и раз в несколько недель попадают к аналитику. Читать каждое не нужно — нужна сводка: тема, сколько обращений, примеры формулировок.

Как построить канал до аналитика

Метка функции в обращении. Если обращения помечают функцией или номером требования, их можно посчитать по каждому релизу. Это та же связь «дефект → требование», что в разборе трассировки, только для обращений.
Регулярный разбор, а не случайный. Раз в две-четыре недели — полчаса со старшим поддержки по сводке. Без расписания разбор происходит только после громкой жалобы.
Срок после релиза. Через месяц после выпуска заметной функции — отдельный взгляд на обращения по ней. Тогда же сверяется метрика успеха, если она была записана.

Разбор инцидента глазами аналитика

Разбор инцидента обычно отвечает на вопрос «что сломалось и как не допустить». У аналитика к нему три своих вопроса:

Было ли требование, которое нарушено? Если да — почему проверка его не поймала.
Если требования не было — должно ли оно было быть? Чаще всего это нефункциональное требование: объём, нагрузка, поведение при отказе соседа.
Что меняется в постановке теперь — чтобы следующая задача в этой области начиналась уже с этим знанием.

Разбор без поиска виноватых здесь не вежливость, а условие: если за инцидент наказывают, о недосказанностях постановки перестают говорить вслух.

Обращение пользователя — тоже просьба. «Добавьте кнопку отмены» из поддержки — такое же готовое решение, как просьба заказчика. Прежде чем заводить задачу, к нему применимы те же вопросы из разбора выявления потребности: что человек пытался сделать и что ему помешало.

Что из этого становится задачей

Не каждая жалоба — задача. Ориентиры для решения:

Частота и цена. Десять обращений в неделю об одном и том же стоят времени поддержки — это уже число, которое можно сравнить с ценой исправления.
Обходной путь. Если люди нашли обход и пользуются им, проблема есть, но не горит. Если бросают сценарий — горит.
Запись как проблемы. В бэклог попадает не «кнопка отмены», а «покупатели не могут отменить заказ после оплаты, 40 обращений за месяц». Решение выбирается при постановке, а не при приёме жалобы.

Признак, что обратной связи нет: о том, как пользуются функцией, аналитик узнаёт из презентации для руководства через полгода.

Проверка за пятнадцать минут

Возьмите функцию, выпущенную месяц назад. Ответьте на два вопроса: сколько обращений в поддержку о ней было и сдвинулась ли метрика, ради которой её делали? Если на оба ответ «не знаю», канала от прода к постановке нет.

Что дальше

Обратная связь из прода — вход следующей задачи. Найденная проблема снова проходит путь требования: выясняется потребность, проверяется готовность постановки, очерчиваются границы. Цепочка замыкается — и начинается заново, с Definition of Ready.