— Дима, посмотри, пожалуйста, тикет по саппорту, ЭТО ОЧЕНЬ СРОЧНО!!!
Было время, когда ответы на такого рода сообщения занимали большую часть рабочего времени нашей дежурной смены от команды разработки. К счастью, постепенно ситуацию удалось исправить.
Подходами, за счет которых это получилось сделать, как раз и хочется поделиться в этой статье. Если у вас, как и у меня, от упоминания технической поддержки начинает дергаться глаз, а необходимость ей заниматься не вызывает ничего, кроме чувства вселенского уныния, добро пожаловать под кат. Серебряной пули не обещаю, но что-то полезное, может, и найдется.
Немного контекста
В статье я буду рассказывать о продукте нашей компании, в команде которого я тружусь. Это типичное энтерпрайс-приложение, у которого есть своя служба поддержки пользователей. Ребята хорошо знают бизнес-логику продукта, но далеки от техники (БД, API внешних систем и т. д.). Еще есть служба общей технической поддержки, которая сопровождает все сервисы компании. Тут ситуация обратная — есть технические знания и навыки, но нет глубокого понимания бизнес-логики.
У продукта есть особенность — наличие интеграции с несколькими внешними системами, при работе с которыми очень многое может идти не по плану. Для разрешения проблемных ситуаций такого рода нужны как технические навыки, так и понимание бизнес-логики продукта. Пересечение этих двух условий исключало участие в решении проблем обеих групп поддержки и перекладывало это бремя на хрупкие плечи команды разработки.
По мере роста пользовательской базы продукта нашей команде приходилось тратить все больше и больше времени на техническую поддержку. Мы уставали даже несмотря на регулярную ротацию дежурных. Вопросы приходилось решать и в нерабочее время (рано утром, поздно вечером, иногда и на выходных). У бизнеса ситуация энтузиазма тоже не вызывала. Времени на разработку новой функциональности становилось все меньше. Оценивать доработки тоже становилось сложнее — нельзя знать заранее, сколько времени уйдет на техническую поддержку в следующем спринте. В общем, так жить дальше было нельзя, и мы решили действовать.
Путь проб и ошибок
Сначала самым очевидным выходом из положения показалось написание скриптов для проблемных кейсов и их передача в общую техническую поддержку компании. У ряда смежных продуктов уже был такой опыт. Но в нашем случае это оказалось неэффективным, и вот почему:
большая часть проблем требует комплексного анализа, который включает в себя просмотр логов, переписку со службой поддержки внешних систем и походы в БД. Написать линейные скрипты на все случаи просто невозможно — важно понимать, что происходит в системе, и принимать решения, основываясь на этой информации;
система со временем меняется, и скрипты нужно адаптировать соответствующим образом. Если забыть это сделать, то использование скрипта в какой-то момент может стать лекарством, которое будет хуже самой болезни.
Поэтому от скриптов решили отказаться. Переложить работу на общую службу технической поддержки M2 не вышло. И мы решили попытать счастья со службой поддержки пользователей.
Идея состояла в следующем. Ребята хорошо разбираются в том, что происходит в системе, но для самостоятельного решения нештатных ситуаций им не хватало пары вещей. Во-первых, информации о том, что происходит в системе, в понятном для них виде. Во-вторых, возможности вносить изменения в работу системы, которые опасно давать обычным пользователям.
Следующим шагом нужно было понять, какие именно инструменты нужны. Для этого мы взяли за правило фиксировать все проблемы, возникающие за время дежурств. Также стали проводиться еженедельные созвоны с ребятами из поддержки пользователей. На них обсуждалось, какую функциональность можно было бы добавить в систему для решения той или иной проблемы без привлечения разработки. В свою очередь, ребята делились тем, что «болит» у пользователей. Результатом этих встреч становились задачи в Jira, которые мы брали в спринты наряду с добавлением новой функциональности в систему и техническим долгом.
По мере добавления в продукт функциональности для технической поддержки был выработан набор обобщенных практик, которым мы начали неукоснительно следовать.
Обеспечиваем максимальную информативность
В случае возникновения нештатной ситуации на UI должно выводиться как можно больше информации о том, что произошло, почему это произошло и что стоит предпринять, чтобы это исправить. Например, мы ищем данные по нескольким критериям. Вместо того чтобы показывать пустой список в случае отсутствия совпадения по всем критериям, мы выводим записи, для которых найдено совпадение хотя бы по одному из критериев, и подсвечиваем, по каким критериям совпадение отсутствует. До того как это было сделано, к нам часто приходили с жалобами на то, что поиск работает некорректно.
Встраиваем опции администрирования в UI продукта
С функциональностью для администрирования все не так просто. С одной стороны, поддержке хочется видеть тот же UI, что и у пользователя, так как переброска скриншотов и объяснение по телефону на пальцах — это время и нервы. С другой стороны, поддержке нужен инструментарий, которым небезопасно делиться с обычными пользователями.
В итоге мы вынесли функциональность для поддержки пользователей в виде отдельной вкладки прямо на страницах приложения. Вкладка видна только при наличии соответствующих привилегий, которые есть у ребят из поддержки пользователей. Таким образом, поддержка пользователей может видеть тот же UI, что и сами пользователи, а специальный инструментарий для разбора проблемных ситуаций всегда под рукой.
Создаем отдельную панель администрирования
Есть функциональность, которая нужна поддержке, но которую нет смысла связывать с интерфейсом пользователя. Например, кнопка переключения на резервную внешнюю систему, если основная система стала недоступна.
Для таких случаев мы разработали отдельную панель администрирования и дали к ней доступ поддержке пользователей. В панели администрирования также обосновались всевозможные настройки, белые и черные списки, околотехнические отчеты и все то, с чем обычно дергают команду разработки.
Ведем историю изменений данных
Хочу отдельно рассказать о таком инструменте администрирования, как история изменений для различных сущностей системы. Поддержке пользователей порой важно знать, что происходило в системе до того, как произошла та или иная проблемная ситуация. Очень часто это знание помогает точно и оперативно разобраться в причинах проблемы и предпринять шаги по ее исправлению без привлечения разработки.
В нашем случае хватило простой таблицы с тремя колонками — email пользователя, который делал изменение, дата изменения и произвольное текстовое описание.
Заранее рассказываем об изменениях в системе
Поддержке важно знать об изменениях в продукте до того, как их увидят пользователи. Поэтому мы заранее оповещаем ребят о том, какая функциональность войдет в состав очередного релиза. Также мы отдельно сообщаем о проведении тех или иных технических работ, которые могут негативно повлиять на систему (например, сложные миграции данных или масштабный рефакторинг сервисов).
Что в итоге
Со временем выбранный нами подход дал положительный результат. Объем задач по технической поддержке, с которыми сталкивались разработчики во время дежурств, значительно сократился. Команда поддержки пользователей получила возможность решать большую часть инцидентов своими силами. Это сильно уменьшило время решения проблем пользователей. Бизнес тоже остался доволен, так как команда разработки получила возможность реализовывать больше функциональности, планирование спринтов также упростилось.
Напоследок хочется сказать, что все компании разные, так же как и продукты, которые они разрабатывают. Далеко не факт, что приведенные в статье практики будут полезны всем без исключения. Пробуйте разные подходы и применяйте на постоянной основе те из них, которые хорошо себя зарекомендуют. А также welcome в комментарии — будет интересно узнать о вашем опыте борьбы с технической поддержкой.