Bug Manager из тех.поддержки как адвокат клиентских проблем для разработчиков
Как сказал бы Капитан Очевидность, “эффективная коммуникация саппорта с программистами и с клиентами, плюс своевременная правка багов сильно повышает лояльность клиентов”. А если серьёзно, то я посмотрела абсолютно шикарный доклад : “Как организовать работу поддержки с клиентом и найденными багами” (ссылка в конце статьи). В нём есть всё: как ребята строили у себя грамотный процесс правки багов, которые нашли клиенты; как ввели новую роль Bug Manager в компании; какие грабли собрали и как решили абсолютно все сопутствующие проблемы (баги подвисали в бэклоге, клиенты жаловались на низкие скорость и приоритет при их правке, разработчики были отдалены от проблем клиентов). Как результат — отлично налаженный процесс и Satisfaction Score в 95% за прошедший год, причём для международного рынка, в частности — для американских клиентов, это не то же самое, что Россия, там совсем другой подход к клиентскому сервису.
И отдельно хочется отметить просто эталонную схему коммуникации с клиентом — как с частным случаем, когда клиент находит и сообщает поддержке о баге, так и с внезапно всплывшими критическими ошибками, которые затрагивают функционал всех клиентов.
Мы у себя в компании внедряли похожие схемы и бизнес-процессы, многое получилось успешно, но даже близко не подошло по успешности к тому, что описывает этот доклад, снимаю шляпу :)
Ниже мои выборочные заметки по данному видео, в целом рекомендую смотреть целиком, а потом скачать слайды по ссылке в описании и посмотреть на картинки в презентации. Например, там есть подробная картинка функционала фоллоу-апов в Zendesk, который позволяет тех.поддержке в нужный день написать уведомление клиенту.
- Две отличные внутренние метрики: то, насколько больше багов правится, чем создается (здесь отвечают product owner’ы) и то, сколько критических багов всплыло и их нашли клиенты (здесь отвечают тестировщики).
- Замечательная идея — вместе с разработкой и product owner’ом читать текст клиентских сообщений о багах. Подтверждаю, работает: программисты становятся более клиентоориентированными :)
- В JIRA вводится отдельный статус для багов, которые клиенты несут в саппорт — need confirm, т.е. его ещё надо воспроизвести у себя на стороне. И отдельный тэг — client_reported. Что примечательно, всем багам, которые нашли внутри компании, на которые могут наткнуться клиенты (но пока не наткнулись!), также ставится тэг client_reported.
- Саппорт ведёт двойной мониторинг багов (“внешний” — то есть своевременно уведомляя клиентыа, и “внутренний” — своевременно пиная программистов).
- Отличная находка — статья для клиентов “как у нас правятся баги”, где объясняется, почему то, что с клиентской точки зрения выглядит как “да там одно минорное изменение внести, это за час можно сделать” может занимать время. И ещё любопытно, что ребята не отправляют копи-паст доводов из этой статьи клиентам (соглашусь с выступающим, клиенты всегда чуют готовые шаблоны объяснений за версту).
- Главная цель bug manager как роли— быть адвокатом клиентских проблем в продукте и “продавать” правки багов программистам и product owner’ам.
- Эталонная, хоть сейчас бери и пользуйся, таблица расстановки приоритетов саппортом:
В общем, очень и очень классная презентация, всё очень по делу, очень жизненно и полезно, а главное — успех налицо :)
