Сервис начинается с документации

Когда говорят про качество сервиса, обычно обсуждают отказоустойчивость, поддержку, интерфейсы, SLA. Но очень редко — документацию. Хотя именно она часто становится первой точкой контакта клиента с сервисом.

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

Признаюсь честно: раньше я относилась к документации примерно как к чему-то, что просто должно существовать. Где-то написано, ссылка есть — и ладно.

Пока не пришел клиент с вопросом, ответ на который в инструкции был. Формально. Однако разобраться по ней не смог ни он сам, ни первая линия поддержки, ни клиентский сервис. Тогда стало понятно, что плохая документация — это не только неудобство, но и полноценная дыра в продукте.

Кто пишет документацию в Облакотеке?

Если честно — все, кто причастен к сервису. Во-первых, инженер, который знает все технические детали. Во-вторых, product owner, который знает, как это должно работать для клиента и какие сценарии самые частые. Наконец, поддержка, которая знает, где клиенты спотыкаются чаще всего.

Но здесь есть важный нюанс: инженер почти всегда пишет для инженера. Ему кажется очевидным, что прежде чем что-то залить в бакет, нужно этот бакет создать, потом нужно получить ключи доступа, а потом уже подключаться и загружать объекты. Для него это базовая последовательность действий, а вот для клиента — далеко не всегда.

Поэтому у нас документацию финально «причесывает» тот, кто смотрит на нее глазами пользователя, а не админа или разработчика. Задача — убрать все, что требует специальных знаний для понимания, и добавить все, что автор пропустил, потому что сам знает это наизусть.

Как тестируем?

Самый простой и безжалостный тест: дать инструкцию человеку, который впервые видит сервис, и попросить выполнить задачу без подсказок. Места, где он останавливается и переспрашивает — это и есть проблемные точки документации.

Также мы смотрим на тикеты поддержки. Если один и тот же вопрос приходит снова и снова — значит, ответ на него в документации либо отсутствует, либо написан так, что его не находят или не понимают. Это прямой сигнал к правке.

Кстати, именно так появился целый раздел с пошаговыми инструкциями по работе с нашими ВМ. Не потому что мы такие предусмотрительные, а потому что поддержка несколько раз объясняла одно и то же разным людям.

Зачем улучшать документацию?

Представьте: клиент хочет разобраться сам. Заходит в документацию, читает и не понимает, с чего начать или же получает ошибку, которая в инструкции не описана. В лучшем случае он пишет в техподдержку, и мы тратим время на объяснение того, что должно быть написано. В худшем — решает, что сервис сложный и непонятный, и уходит.

Кроме того, плохая документация влияет и на поддержку. Когда первая линия не может дать клиенту ссылку на понятную инструкцию, ей приходится каждый раз объяснять заново, своими словами, с нуля. Это трата времени и энергии.

Что нам помогло?

Завели привычку периодически обновлять документацию. Особенно с запуском новых фишек. Новая фича без обновленной инструкции не готова к выходу.

Перестали писать «технически правильно», взамен стараемся писать понятно. «Выполните инициализацию соединения через API-endpoint» и «введите адрес сервера в поле подключения» — это одно и то же, но второй вариант поймет живой человек без словаря.

Готовим видеоинструкции для самых частых сценариев. Часть аудитории читает текст, а часть — смотрит.

Поддержка стала соавтором документации. Если первая линия видит, что клиенты регулярно спотыкаются на одном и том же месте — это сигнал для нас, и мы его обрабатываем.

Документация — это не приложение к продукту, а его часть. Если клиент не может разобраться сам — значит, сервис еще не готов .

#Оксана_объясни