В начале своей карьеры у меня сложилось неверное впечатление, что общение с клиентами ниже моего уровня.
У меня сложилось такое представление, потому что я работал в крупной компании, а стандартная корпоративная иерархия поощряла такой менталитет.
В результате эта идея стала довольно распространенной в нашей профессии. Даже если люди этого не говорят, они действуют так.
Позже в моей карьере меня спросили в интервью, как я буду вести отношения между командами поддержки и командами разработки программного обеспечения. Ответ, вероятно, заключается в том, что стоила мне этой работы, но я бы не стал ее менять.
Разработчики программного обеспечения должны поддерживать ротацию.
Как это работает, каждую неделю пусть хотя бы 1 разработчик в вашей команде объединяется с кем-то из команды поддержки и решает самые сложные проблемы, с которыми им приходилось сталкиваться.
Не обязательно на целый день. Всего 1–2 часа имеют огромное значение для всех участников.
Во-первых, вы получаете лучшее программное обеспечение. Даже в самых неприятных водопадных процессах разработчикам придется принимать решения, которые не входят в требования. Программное обеспечение слишком сложное, чтобы записывать все в требования (а я написал документы с требованиями на 500 страниц).
Эти решения часто бывают небольшими, например, сообщение об ошибке в крайнем случае. Или добавление состояния загрузки для людей с медленным интернет-соединением.
Иногда эти решения являются крупными техническими решениями, но большую часть времени они невидимы для пользователя. К сожалению, когда пользователи замечают их, результаты часто крайне запутанны как для пользователей, так и для персонала службы поддержки. То, как вы обрабатываете параллелизм, попадает в эту категорию.
Об этих решениях часто не говорят, так как они либо слишком технические, либо их огромное количество. Хотя каждый из них обычно не имеет большого значения, в совокупности они оказывают огромное влияние на общий UX вашего приложения.
Взаимодействие с группами поддержки дает разработчикам больше информации о том, как на самом деле используется их программное обеспечение. Это не только создает эмпатию, но также обеспечивает критический контекст, необходимый для принятия этих скрытых решений.
Результатом станут лучшие решения, лучший UX и, в конечном счете, лучшее программное обеспечение.
Вы также получите лучший внутренний инструментарий. Многие запросы в службу поддержки часто требуют поиска информации. Некоторые из этих вещей может быть нелегко запросить.
Разработчики ненавидят тратить время вручную, делая одно и то же снова и снова. Я знаю, что. Это приведет к тому, что они создадут больше внутренних инструментов, чтобы упростить эти запросы. Это сделает вашу службу поддержки более эффективной и ускорит решение проблем, что в конечном итоге сделает ваших клиентов счастливее.
Наконец, объединение разработчиков с вашими командами поддержки — лучшее обучение, которое могут получить ваши команды поддержки. Большинство из них получают что, 1-2 недели «обучения» тому, как работает продукт? Затем они погружаются в бездну, отвечая на вопросы клиентов.
Никто не может разумно ожидать, что они будут экспертами в продукте в то время. Результатом является большее количество обращений в службу поддержки, направляемых команде разработчиков. Инженеры-менеджеры пытаются остановить эту волну с помощью большего количества процессов, но они просто пинают банку в сторону. В конце концов, пользователям нужны ответы.
Регулярные 1–2-часовые занятия с разработчиками каждую неделю будут чрезвычайно эффективными в обучении ваших групп поддержки. Они узнают, как на самом деле работает продукт, и станут более независимыми при решении проблем.
Долгосрочный эффект от этого? Разработчики тратят меньше времени на изучение отчетов об ошибках.
Первоначально опубликовано на https://blog.professorbeekums.com.
