Привет, Хабровчане! Я Юля Федотова, директор по продукту в Топвизоре. Прежде чем официально заняться продуктовой работой, я 5 лет проработала в отделе поддержки и частенько бесилась от отношения разработчиков к моим задачам: они могли сделать совсем не то, что требовалось; дать формальную отписку, хотя чтобы помочь пользователю, требовалось сделать чуть больше; или отменить задачу, потому что в «тэзэ» не была указана какая-то мелочь.
Но цель этой статьи, как ни странно — не объявить войну всем программистам. Чем опытнее я становилась и чем больше я с ними общалась, тем больше понимала, что у них есть причины поступать именно так. И что проблема не в них и не во мне, а в том, как поставлены цели и как налажено взаимодействие между командами в нашей компании. А самое главное — что от нашего недопонимания страдают качество продукта и клиентского сервиса.
В статье — о том, что может провоцировать напряжённость между разработчиками и агентами поддержки и что мы сделали для того, чтобы максимально её снизить. Расскажите, как это взаимодействие работает у вас в команде: мы будем рады у вас поучиться.
По каким вопросам пересекаются отделы поддержки и разработки и почему это важно
Зачем вообще задумываться о том, как должны взаимодействовать отделы поддержки и разработки? Хотя бы потому что у нас, например, это одни из самых часто взаимодействующих отделов в компании. Точек пересечения у этих отделов очень много, и все они так или иначе влияют на удовлетворенность клиентов:
Баги. Пользователи сообщают о них в службу поддержки, а разработчики их исправляют.
Тестирование. Прежде чем передать баг на исправление, его надо поймать и описать. Иногда этим занимаются тестировщики, иногда вторая линия саппорта. У нас линий нет, и передачей багов в разработку занимаются агенты поддержки.
Новые фичи. В идеале все обновления в сервисе должны быть описаны в публичном справочном руководстве, а ещё во внутренней документации с какими-то подробностями, но так бывает не всегда. И у нас не раз случалось так, что обновления выкатывались без их описания, и если в поддержку прилетал тикет, приходилось идти к разработчикам, чтобы они что-то пояснили. Сейчас глобально такой проблемы нет — мы с техническим писателем делаем так, чтобы новый функционал был подробно описан и выясняем детали ещё на этапе постановки задач. Однако наши пользователи обладают таким потрясающим воображением и способностями к тестированию, что всегда умудряются обнаружить какой-то несусветный сценарий, и приходится идти к разработчикам и спрашивать, баг это или фича.
Старые особенности работы продукта. Вопросы могут возникнуть не только по новому функционалу, но и по старому. У нас аналитический сервис: много цифр, таблиц и графиков. И иногда данные могут не совпадать или по-разному отображаться в разных разделах и источниках. Не всегда понятно, это баг (и надо ставить задачу на исправление) или какая-то особенность отображения данных (и этому есть ли какое-то логичное объяснение, которое нужно дать в тикете). В таком случае также приходится обращаться к разработчикам, чтобы они проверили, что и как работает.
Что провоцирует напряжённость между агентами поддержки и разработчиками
Срочность решения вопросов. Как правило, такие проблемы как баги и сбои в работе сервисе нужно решать быстро, и это давит на участников процесса. Агенты поддержки вынуждены пинговать разработчиков, если они не отвечают; а те не любят, когда их торопят. На агентов ругаются пользователи, а если ошибку не удаётся так просто устранить, негатив поддержки может перекинуться на программистов.
Сложность вопросов. Как правило, решаемые этими отделами вопросы технически сложные и требуют нетривиального анализа. Есть сценарии и чек-листы по анализу проблем, но в любом случае нужно включать голову и к каждому случаю относиться внимательно. Каждый кейс может стать тем кейсом, после которого вам потребуется переписывать документацию.
Пропасть между знаниями агентов поддержки и программистов. И это усугубляется сложностью, которую мы разобрали в предыдущем пункте. Даже если агент поддержки подкован по технической части, между его знаниями в этом и знаниями программиста огромная пропасть. И ему далеко не очевидны многое вещи, которые с первого взгляда понятны программисту. Если с обеих сторон не развиты навыки коммуникации, агенты поддержки могут считать программистов высокомерными душинилами, а программисты агентов — девочками на телефоне.
(у него уже 42 тикета по этой проблеме)
Что может случиться, если мы не наладим взаимодействие между ними
Ухудшится качество сервиса. Оно крайне важно для клиентов и особенно для их удержания. Дольше будут чиниться баги, дольше будут решаться другие вопросы пользователей, и им это не нравится. А некоторые баги вообще не дойдут до разработчиков, поскольку агенты поддержки могут делать вид, что их не замечают.
Вырастет напряжённость в команде. Это может провоцировать личную неприязнь, которая будет мешать эффективно достигать совместных рабочий целей, действовать сообща. А со временем личная неприязнь может перекинуться и на рабочие задачи и стать саботажем.
Саботаж, в том числе скрытый. «Саботаж равнодушием». Ведь разработчик, скорее всего, не может публично сказать: «Я не буду это чинить». Но он может как бы не заметить алерта о баге, заниматься другой задачей и затягивать исправление бага. Может нехотя объяснять какой-то механизм работы сервиса поддержке. А поддержка, в свою очередь, может неохотно эскалировать инциденты, вообще не передавать какие-то минорные баги в разработку, не пытаться тестировать экзотические сценарии, а просто отмахиваться: «Баг не ловится? Ну, дорогой пользователь, твои проблемы». И не пытаться помочь пользователю через разработку, потому что просто не захочет связываться с программистами.
Сотрудники будут демотивированы. Даже если сотрудники не будут заниматься саботажем, в обстановке некачественного сервиса, напряженности и вражды они просто выгорят и совсем перестанут нормально делать то, что должны, или вообще уволятся.
Качество сервиса будет проседать не сразу, а медленно падать в результате этой холодной войны в команде, а в конечном счёте это скажется на количестве клиентов и прибыли бизнеса.
Что со всем этим делать
Используйте таск-трекер
Если у вас ещё нет таск и баг-трекера, заведите. Не буду останавливаться тут, почему он нужен — маякните в комментариях, если об действительно стоит написать, чтобы вы скинули директору ещё одну статью о том, зачем нужен таск-трекер. Потому что даже сейчас я знаю команды, которые коммуницируют по вопросам разработки в телеграме, а баги скидывают в какой-то общий чат в нём. Не надо так! Топвизор использует Redmine, но трекеров огромное множество: Яндекс Трекер, Jira, YouTrack и другие.
Организуйте работу в таск-трекере
Организуйте трекер таким образом, чтобы взаимодействовать в нём было удобно. Большую часть времени разработчикам и поддержке надо взаимодействовать именно там, и на моей памяти поддержка у нас создаёт и закрывает больше всего задач, поэтому настроить трекер нужным образом — это важно.
Рассказываю, как сделано у нас; в зависимости от типа бизнеса у вас может быть что-то по-другому, но на самом деле структура универсальная, и подойдёт если не любой, то большинству систем.
В таск-трекере должно быть несколько проектов (пространств), чтобы разные задачи не путались друг с другом, а список исполнителей был не слишком большим. У нас есть разные проекты для маркетинга, дизайна, контента; и основной проект для поддержки и разработки.
У задач должны быть разные трекеры (типы), например, «Разработка Frontend» и «Разработка Backend», «Ошибка», «Тема для разговора». Так, «Ошибка» нужна, чтобы отделить функционал, который сломался, от функционала, которого нет на сайте, который добавляется в трекере «Разработка». А «Тема для разговора» нужна, чтобы уточнить какой-то алгоритм работы инструмента или когда непонятно, является ли что-то ошибкой или нет.
Добавьте группы и сделайте группу «Разработчики», чтобы поддержка могла поставить всех разработчиков исполнителями. Агенты поддержки, как правило, не знают, какой разработчик может сделать ту или иную задачу. Можно ставить все задачи на руководителя разработки или тимлида, но так разработчикам будет неудобно заходить в чужие задачи. Лучше объединить разработчиков в группу и дать возможность назначить задачу на эту группу. Так каждый участник группы сможет видеть задачу в своем списке задач, а тимлид назначит её на конкретного исполнителя или даже какой-то разработчик сам это сделает.
Пишите заголовок задачи в повелительном наклонении, например, «Исправить ошибку X», «Починить отображение такого-то элемента». Мой опыт показывает, что разработчиков фрустрируют заголовки вроде «Ошибка на странице Y» или «Х не работает», потому что непонятно, что с этим делать. Если эта задача — тема для обсуждения, то ее можно начинать с вопроса «Почему». Однако и тут надо задавать импульс, потому что на вопрос вроде «Почему появляется ошибка TOO_MANY_CONNECTIONS» разработчик ответит, потому что к сайту совершаются слишком много обращений, и будет формально прав. Сразу задайте вопрос о том, как сделать так, чтобы она не появлялась. А ещё это даёт широкий простор для саботажа: когда не сказано, что конкретно нужно сделать, легко понять задачу по-своему и быстро «решить» (в терминах работы с таск-трекером) её, не вникая в изначальную проблему.
Указывайте, как должно быть или как было до этого. Разработчики, особенно если они недавно в компании, могут не знать, как должен работать какой-то функционал или как выглядело окно. Хорошо, если в задаче сразу сказано, как должен развиваться описанный сценарий, и совсем отлично, если есть скриншоты, старые задачи или выдержки из документации, которые это доказывают. Однако без фанатизма: каждое окошко тоже не заскринишь.
Создайте инструкции и чек-листы по анализу проблем
Чтобы создавать задачи быстро и без ошибок, а также чтобы в них была вся нужная для разрбочиков информация, поддержке нужны инструкции и шаблоны для создания задач. Проанализируйте типы ваших ошибок и создайте инструкции по их первичному анализу. Логов у поддержки обычно много, и в них легко запутаться. Поэтому объясните им, что если мы видим ошибку Х, смотрим логи Х и создаём задачу Х. Если видим ошибку Y, смотрим логи Y и создаём задачу по шаблону Y. Например, у нас есть разные инструкции и логи для задач с JS-ошибками, БД-ошибками и ошибками парсинга, и есть инструкции по тому, как их друг от друга отличать. Чтобы поддержка ничего не упустила при создании задачи (если помните, то у нас уже создана довольно сложная структура в таск-трекере), создайте шаблоны с предсозданными полями, в которых нужно только заполнить данные. В современных трекерах такая возможность обычно встроена, например, в YouTrack, а в Redmine можно добавить в закладки ссылки на создание новой задачи с нужными параметрами.
Для ASAP-ошибок создайте отдельный чат
Иногда у нас бывают массовые сбои, когда тикеты не успеваешь отрабатывать, не то что создавать задачу. Для таких суперсрочных ошибок у нас есть отдельный чат #incidents. Туда мы кидаем массовые сбои, когда, например, что-то с БД, и у всех пользователей ошибка на всех страницах сайта. Разработчики знают, что сразу смотреть на все сообщения в этом чате — обязательно. Так они понимают, на какие ошибки можно реагировать в обычном режиме — до одного рабочего дня. А какие нужно действительно исправить ASAP.
Развивайте продуктовый подход во всех сотрудниках компании
Помните, что главная цель взаимодействия всей команды — это успех продукта, удовлетворенность пользователей, а не удовлетворение чьего-то ЧСВ. При работе в поддержке ты постоянно сталкиваешься с тем, что старые инструкции перестают работать, или с ситуациями, для которых никаких инструкций и логов нет, и иногда ты просто не понимаешь, что делать. Поэтому все правила должны быть формализованными, но не формальными.
Каждая задача, которую создаёт агент поддержки, потенциально может быть инцидентом, в результате которого придётся обновлять половину документации. Или инцидентом, который встретился впервые. Поэтому задачам необязательно быть идеальными, чтобы над ними начали работу. Если разработчику не хватает какой-то информации в задаче, он может просто вернуть её на доработку (например, у нас за это отвечает специальный статус «Требуется консультация»), или написать в чат, чем нужно дополнить таску. У нас есть чат поддержки с разработчиками, где можно задавать подобные вопросы и обсудить какие-то особенности по логам, попросить консультацию в сложных вопросах.
Если у людей общая цель, они всегда быстро договариваются, проявляют гибкость, а главное — делают всё от них зависящее, чтобы к ней прийти и не делают свою работу «на отвали». Если стороны не заинтересованы в общем конечном результате, если им всё равно, то у них находятся тысяча и одна формальная и неформальная причина что-то не делать или не реагировать. Поэтому поставьте перед поддержкой и разработкой эту общую цель.
Найдите амбассадоров с обеих сторон
Да, мы ставим цель перед всей командой, и её желательно осознавать каждому. Однако в любой команде есть тимлид или лидер мнений, который дополнительно должен транслировать то, что вам нужно, настраивать команду и разрешать конфликты. Идеально, если эти люди могут еще и переводить с программистского на обычный и наоборот. То есть пояснять какие-то технические вещи простым языком, объяснять смыслы, общие принципы архитектуры сервиса, потому что разбираться в причинах ошибок, в том, какой и где надо смотреть лог, намного проще, если ты не исполняешь формальные инструкции, а хотя бы примерно понимаешь, о чём речь и как все это работает.
Объясняйте, почему нужно делать так, а не иначе. И записывайте!
Написать формальные инструкции недостаточно. Давайте экскурс в архитектуру сервиса простым языком. Поощряйте вопросы о том, как какой-то функционал работает под капотом. Главное — сохраняйте всю эту информацию в своей документации или базе знаний, хотя бы пишите в гугл-док, потому что мы всё-таки стараемся экономить время друг друга, и если разработчик будет каждому новому агенту поддержки что-то заново разъяснять — это нехорошо. Обычно эту ответственность берет на себя тимлид поддержки, потому что обладает в силу компетенций и опыта в продукте достаточными знаниями для корректной фиксации такой информации. Но готовые инструкции можно давать проверить разработчикам на всякий случай.
В нашей практике были и агенты поддержки, которые не утруждали себя анализом логов и отправляли разработчикам сырые задачи. И разработчики, которые не интересовались тем, как скорость их реагирования на инциденты влияет на лояльность пользователей к сервису. Этот опыт помог нам вырасти и задуматься о том, как сделать взаимодействие между разработчиками и агентами поддержки более комфортным и продуктивным для обеих сторон.
В результате мы получили спокойных сотрудников, имеющих общую цель, и успешный продукт, в котором пользователи не страдают от того, что разработчик не увидел задачу на баг от поддержки или на исправление прислали непротестированный баг, который разработчику непонятно как ловить.
А лучшее доказательство этого — отзывы от пользователей в тикетах, которые нередко пишут приятности не только поддержке, но и разработчикам, и высоко ценят скорость, с которой они разбираются с багами:
