Привет! Я Оля Коршунова, лид первой редакции технических писателей в Т-Банке. Боль технических писателей — как определить влияние текста? Как оцифровать его в бизнес-результат?

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

В статье расскажу, с чего команда начинала работу и как пришла к метрикам документации.

Кто мы и где сейчас

Наша редакция работает на бизнес-платформе TWork, которая разрабатывает продукты для сотрудников компании. Платформа состоит из большого количества инструментов, похожих на кубики «Лего». Благодаря им сотрудники обучаются, следят за графиком работы и обслуживают клиентов. Например, используют процедуры для консультаций. Подробно о них писала моя коллега Даша.

Ежедневно продуктами платформы пользуются ≈90 000 сотрудников.

Сейчас в нашей команде три человека. Помимо того что все умеют писать доку, кто-то шарит за UX, а кто-то — за маркетинг. Поэтому кроме документации мы занимаемся продвижением и коммуникациями нашей платформы. А еще улучшаем интерфейсы продуктов во время работы над документацией. В общем, смотрим широко и далеко. Но так было не всегда.

Стадия Australopithecus. Австралопитеки: писали, потому что надо

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

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

Пришло время что-то менять. Так на платформе появился первый технический писатель. 

Стадия Homo Habilis. Человек умелый: работаем лучше, потому что появились инструменты и процессы

Первый техпис платформы дал будущей команде знания о технической документации. Положил начало эре работы в среде разработки и внедрил docs-as-code. 

Команд много, все хотели документацию, но ничего не знали ни про техписов, ни про совместную работу с ними. Инструкций не было. Границ ответственности не было. Только вера в большое и светлое будущее, где все пользователи счастливы.

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

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

Стадия Homo Erectus. Человек прямоходящий: пишем лучше, потому что ведем диалог с пользователями

Пришла пора наладить работу с пользователями. У меня появилась идея UX-тестирования документации. Она родилась из аксиомы Curse of knowledge — «проклятие знания»: продукт видит проблемы пользователей искаженно. Командам такой подход пришелся по душе ☺️

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

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

Стадия Homo Heidelbergensis. Человек гейдельбергский: улучшаем процессы и коммуникацию с продуктами

Мы какое-то время думали, что готовая документация продукта — это успех! Первый проект закончен, появился процесс взаимодействия с продуктовой командой, документация на проде, пользователи ее читают, отзывы тоже классные.

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

Мы вписались в целеполагание, чтобы делиться планами со всеми командами. В конце каждого квартала платформа планирует OKR. Это упражнение помогло:

• понимать, как влияем на цели платформы;

• планировать ресурсы на квартал;

• фокусироваться на главном, не сбиваясь с пути.

Фреймворк OKR прижился в команде, и мы работаем по нему до сих пор. 

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

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

Стадия Homo Neanderthalensis. Неандертальцы: делаем контент, опираясь на данные

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

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

Начали строить на этом измерение полезности доки — совершили «прыжок веры», потому что в компании пока не измеряли пользу документации. 

Мы изучили рынок. Посмотрели, как работают с метриками в других компаниях, — информации оказалось мало. Решили пойти своим путем. Наши разработчики создали шаблон документации на Docusaurus, в который зашили метрики качества доки:

• полезная статья или не очень;

• сколько времени люди тратят на прочтение статьи;

• какие статьи самые популярные по просмотрам;

• каково количество пользователей.

Мы начали промотировать работу с отчетом продактам. У платформы появилось понимание о популярности той или иной доки. Позже накопилась обратная связь пользователей. Ее разбираем на регулярных синках с командами и правим доку. Появилась историчность данных и метрики. 

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

Стадия Homo Sapiens. Человек разумный: думаем стратегически, считаем метрики, влияем на бизнес и продукты

В начале за ключевую метрику работы по качеству документации мы с продуктовыми командами брали КСАТы. Для нас они были неинформативными: либо количество отвечающих мало, либо про доку ничего сказать не могут.

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

В каждой продуктовой команде есть хелп-канал, куда приходят пользователи с разными вопросами. Им отвечают инженеры, они же следят за тем, чтобы системы работали как часы 24/7.

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

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

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

Наш путь показал:

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

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

• Технический писатель — не только автор, но и исследователь, аналитик и партнер.

Мы больше не пишем просто инструкции. Мы измеряем их пользу, влияем на развитие продуктов и экономим ресурсы компании.

Причем здесь эволюция

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

Мы не стали идеальными техписами. Мы стали релевантными. 

Прошли логичные этапы:

• от реактивного письма «потому что надо» к инструментам;

• от инструментов к диалогу с пользователями;

• от диалога к системе приоритетов;

• от системы к измерению влияния.

Следующий шаг — не просто реагировать, а предсказывать:

• где пользователи застрянут до того, как они спросят;

• какие статьи устареют до релиза;

• как автоматизировать измерение полезности;

• как сделать документацию активным элементом продукта, который учится и адаптируется.

Может, скоро мы сядем в ракету. А может, построим ее сами.