Не всем нравится работать в поддержке. Огромное количество людей выгорает на ней. Так может не стоит вообще её иметь? Какую выгоду она несёт? Можно ли как-то не выгорать от поддержки? Попробуем найти ответы в этой статье.

Расскажу пару слов о себе. В данный момент я работаю C# программистом в компании PVS-Studio, которая занимается разработкой одноименного статического анализатора. К слову, я успел приложить руку к нему. Писал диагностические правила и ядро ломал улучшал. Сейчас работаю в отделе Tools&DevOps, в котором занимаюсь не только очевидными для него вещами, но и оказываю техническую поддержку пользователям.

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

Свой опыт обращения в поддержку

Начну с рассказа о моём первом обращении в поддержку. В общем, дело было так. Шли школьные годы, я играл в World of Warcraft, если память не изменяет, дополнение Mist of Pandaria. Все шло прекрасно, как вдруг столкнулся я с технической проблемой – игра посчитала, что у меня другой класс, и тем самым давала мне неподходящие вещи. Нагуглить решение не получилось, и я решил написать в поддержку.

Мой предыдущий опыт обращения в поддержку других компаний заканчивался обычно одинаково: либо мне просто не отвечали, либо отвечали через неделю что-то в духе "спасибо за ваш отзыв, мы попробуем исправить вашу проблему". Решения, как вы понимаете, я так и не получал. Поэтому надежды на решение моей проблемы я не чаял, но делать что-то надо было. Однако это были ещё те самые старые Blizzard. Написав сообщение, я получил ответ с решением своей проблемы в чат игры менее чем за 5 минут! Меня поразила скорость и качество работы данной компании.

После этого случая я понял как должна действовать поддержка.

Про нашу поддержку

Сразу отмечу, что у нас нет call-центра и всё общение происходит в почте. Также мой отдел (как и другие программисты в нашей компании) не занимается поддержкой задач первичной обработки заявок. Этим занимается небольшая команда с большим опытом. Им удается ответить на большинство вопросов пользователей, кроме технически сложных, которые требуют повозиться с кодом. И здесь уже подключаемся мы, программисты, авторы этого кода. При этом разработчики сами напрямую общаются с пользователями. Мы считаем, что такой подход позволяет не только улучшить качество поддержки, но и показать программистам значимость, востребованность их работы.

Поддержку, которую я оказываю в рамках направления Tools&DevOps, можно разделить на:

• У меня не работает в утилите\плагине для [название] вот такой функционал;

• Я хочу попросить вас добавить в утилиту\плагин для [название] вот такой функционал.

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

Во втором же случае нужно для начала понять, насколько предложенная идея практична, удобна, полезна и так далее. Обсудить идею с менеджерами и решить будем ли мы это делать. Если решили, что делаем, то об этом сообщается пользователю, ставится задача, и я начинаю писать код. Опционально после выполнения работы пишется статья о новом функционале.

Теперь, внимание, вопрос: "А зачем вообще всё это нужно?" В чём, собственно, плюс для нас и для пользователей?

Плюс поддержки для пользователей

Плюсы поддержки для пользователей очевидны: проблема решается, улучшается опыт работы с продуктом, периодически добавляется желаемый функционал (или его добавление происходит быстрее). Например, у нас был в далёких планах плагин для CLion. Однако большое количество запросов пользователей явно сказало нам, что его нужно делать. И чем быстрее, тем лучше. Если интересно, то вот статья моего коллеги о его разработке.

При этом хочу заметить, что мы оказываем поддержку и бесплатным пользователям. И даже из этого мы получаем профит.

Плюс поддержки для нас

На самом деле, из поддержки мы, возможно, получаем даже больше пользы, чем пользователи. Давайте по порядку.

Решая проблему вида "что-то не работает", мы улучшаем качество нашего продукта. Тут всё просто. Тестами покрыть все возможные варианты как, где и с чем использовать наши программы невозможно. У нас уже достаточно большое количество утилит и плагинов, и, соответственно, сценариев их использования. Например, из последнего, нас пробовали использовать в uVisionKeil, о чём пользователь написал очень хорошую статью.

Ещё, из-за специфики технологии статического анализа неизбежны ложные срабатывания. Ложные срабатывания – это ошибочные предупреждения, которые выдаёт анализатор. С данной проблемой борются наши отделы, которые разрабатывают диагностические правила, но всего предусмотреть невозможно. Поэтому, когда пользователь скидывает нам пример кода, на который мы ошибочно ругнулись, мы его исправляем. Тем самым делаем анализатор в каком-то смысле умнее.

Реализуя запросы по добавлению нового функционала от пользователей, мы делаем именно то, что действительно нужно пользователям. Особенно, когда нам об этом написали не один раз. Плюс, когда долго работаешь над чем-то, то взгляд "замыливается", и уже можешь не замечать, например, что чего-то не хватает или что-то неудобно. В такие моменты обратная связь очень выручает. К слову, за полгода, начиная с 2021, мы сделали по предложениям клиентов следующий функционал:

• Утилита Blame Notifier теперь может сортировать предупреждения по номерам и датам коммитов. Это позволяет видеть предупреждения на правки кода за определённый день;

• В утилиту для проверки C++ и C# Visual Studio проектов PVS-Studio_Cmd.exe добавлена возможность передавать файл подавленных сообщений напрямую через командную строку. До этого подавленные сообщения можно было добавлять только на уровне проектов и solution'а;

• Добавлена поддержка проверки проектов, использующих компилятор MPLAB XC8;

• В утилиту для отслеживания вызовов C++ компилятора CLMonitor.exe добавлен режим проверки списка файлов с учётом зависимостей компиляции между исходными и заголовочными файлами. Данный режим можно использовать для автоматизации проверки merge и pull request'ов. Также добавлен новый режим "AbortTrace", который позволяет останавливать работу монитора без запуска анализа.

Если вам вдруг стало интересно, что ещё было сделано, то вот тут можно посмотреть историю версий.

Далее, не стоит забывать и про повышение своего рейтинга в глазах клиентов. Ведь когда к вам обратился человек и получил вместо молчания быстрый ответ и решение проблемы, отношение к вам улучшается. Это также может склонить чашу весов, например, в вопросе продления сотрудничества.

Дополнительно хочу указать на неочевидную, на первый взгляд, вещь. Оказание технической поддержки улучшает наше понимание кода продукта. Смотрите, программы сейчас обширные, кода много и есть участки, в которые просто так уже никто не полезет. Например, какой-то механизм в ядре работал без перебоев пару лет. Ну работает и работает, что лезть-то в него. Вдруг вам пишет пользователь с проблемой. Изучая её, вы залезаете в такие места в коде, о которых, возможно, и не слышали. А чтобы понять, в чем заключается проблема, нужно разобраться, что происходит в коде. Тем самым вы лучше понимаете всю архитектуру и все взаимодействия в вашей программе.

Иногда, если общение и исследование проблемы было интересным, можно поделиться этим в заметке. Дополнительная реклама продукта и самого примера поддержки. Пример: "Ложные срабатывания в PVS-Studio: как глубока кроличья нора".

Наверное, если ещё посидеть и подумать, то можно найти другие плюсы. Однако я считаю, на этом хватит. Теперь поговорим, как, собственно, не выгорать.

Борьба с выгоранием

Работа в технической поддержке – не самая простая вещь, которая, к тому же, требует общения с людьми. В общем, вполне себе такое место для успешного выгорания. Сначала расскажу, как мы в компании с этим боремся.

Основное – это то, что человек у нас не занимается постоянно одной только поддержкой. В этом нам помогают ротации. То есть этот месяц я занимаюсь поддержкой, следующий я работаю с плагинами, далее занимаюсь оптимизаций рабочего процесса (Jenkins, скрипты, все дела), затем я улучшаю утилиты и так далее, и так по кругу. Кроме того, можно вообще перейти на ротацию в другой отдел и, например, поделать диагностические правила. Всё это помогает не заскучать и разнообразить рабочие будни. Про разнообразие самих задач я вообще молчу.

Кроме того, как вы уже поняли, занятие поддержкой у нас – это не только одно общение с клиентом. Это общение, воспроизведение, решение проблемы (часто с написанием кода) и получение приятных слов благодарности :)

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

Также у нас постоянно по желанию проходят всякие мероприятия: бильярд, картинг, боулинг, страйкбол и так далее. А ещё у нас есть выездные корпоративы. Например, вот в такое красивое место:

Конечно, пандемия внесла свою лепту в подобного рода мероприятия.

Однако это были пункты, которые относятся к фирме. Поэтому, если у вас ничего такого нет, то не отчаивайтесь. Ещё есть возможность и самолично вести борьбу с этим проклятым выгоранием. Ведь спасение утопающих – дело рук самих утопающих.

Для начала – удовольствие после получения благодарности от человека, проблему которого ты решил. Поверьте, тёплые слова всегда приятно слышать. А когда за ними стоят трудозатраты, которые ты совершил – их слушать вдвойне приятнее. Лично меня не раз этот пункт заряжал позитивом и энергией для дальнейшей работы.

Ещё можно поиграть в детектива и потешить внутри себя маленького Шерлока. Я говорю про расследование сложного случая, когда не работает то, что в теории должно работать всегда. При этом зацепок мало, и вот ты начинаешь своё расследование. Об одном таком я уже написал статью. Там рассказывается об интересном случае с WCF и TraceSource. Можете почитать, мне будет приятно :)

Также не забывайте, что работа должна быть на работе. То есть старайтесь, когда завершается рабочий день, тут же переключить свои мысли на что-то другое. Идеально, если у вас есть хобби. Например, у меня это музыка и игры.

Вывод

Надеюсь, что смог донести до вас своё видение, почему поддержка – это добро, и как от неё получать пользу. Ну а чтобы от неё не выгорать, нужно своеобразно организовывать процессы работы и отдыха. Поэтому не стесняйтесь задавать вопросы своим менеджерам :)

Лично мне очень интересно услышать о том, как вы боретесь с выгоранием. Поэтому, пожалуйста, напишите свои способы в комментариях.

Спасибо за внимание.

Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Nikolay Mironov. Technical support: what it's for and how to avoid burnout?.