Как писать об изменениях, если вам не всё равно

Ведь если история изменений пишется, значит, это кому-нибудь нужно!

Привет! Я Арина, работаю техническим писателем в IT больше 7 лет и люблю заниматься текстами, которые, кажется, мало кому нравятся: текстами об изменениях в продукте (Историями изменений, What's New, Release Notes и подобными ченджлогами). И я твёрдо убеждена, что такие тексты, во-первых, читают, а во-вторых, через них можно и нужно нести реальную пользу. Эта статья о том, как писать для тех, кто вас реально читает.

Заметка перед началом

Здесь я буду писать в основном о документации для B2B: для тех, кто использует ваши продукты (API, SDK, инструменты аналитики и т.д.) для разработки своих решений.

Да кто вообще читает об изменениях?

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

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

• Вышла новая фича, которую они ждали (может быть, даже просили) и которую применят у себя, чтобы сделать своё решение ещё круче. И смогут заработать много денег.

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

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

Кто должен за это отвечать?

Ответственность за описание изменений — вопрос спорный. Где-то этим занимаются аналитики, где-то продакты, где-то тестировщики или маркетологи. Лично мне, как техническому писателю, отвечать за такие тексты нравится и кажется логичным по нескольким причинам:

• Это не даёт шанса не быть в курсе событий.

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

• Это здорово развивает навык техписателя «быть мостом между разработчиками и клиентами».‎

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

• Часть описываемых изменений обычно находит отражение в других документах, которыми точно владеет техписатель (руководства пользователя и т.д.), и выстроить связи между всеми документами может именно он.

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

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

Как писать, чтобы читали?

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

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

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

Чтобы «обработать» эту формулировку и сделать её максимально полезной для пользователя, зададим себе и команде следующие вопросы:

• Можно ли об этом изменении писать публично или для читателей конкретной истории изменений?

  Лучше лишний раз переспросить (или подкрутить процесс сбора), чем случайно опубликовать что-то, не предназначенное для глаз пользователей.

• Все ли детали относятся непосредственно к читателю истории изменений?

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

• Какая новая возможность появилась именно для читателя?

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

  Теперь вы можете задавать язык приложения по умолчанию через новую переменную LOCALE.

• Достаточно ли пользователю информации, чтобы воспользоваться новой возможностью?

  В истории изменений сложно (да и не нужно) описывать все детали и давать инструкции по новым возможностям. Но нельзя ставить пользователя в тупик: дайте подсказку, где посмотреть детали, куда обратиться за доступом, к какой уже известной функциональности относится это изменение. Иначе после прочтения у читателя может возникнуть логичный вопрос: «И что?».

  Добавим подсказку к нашему примеру:

  Теперь вы можете задавать язык приложения по умолчанию через новую переменную LOCALE. Список доступных значений переменной см. [по ссылке].

• Поймёт ли нас читатель остальной документации по продукту?

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

• Не заслоняет ли форма смысл?

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

  Пример двух формулировок, которые в обоих вариантах звучат неплохо:

  Добавлен учёт сезонных ограничений при поиске маршрута на общественном транспорте.

  При поиске маршрута на общественном транспорте теперь учитываются сезонные ограничения.

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

  Папки с фотографиями заменены на альбомы с встроенным слайд-шоу.

  Заменены папки...? Изменена форма папок...? Добавлены альбомы вместо папок...?

Заключение

Хорошая история изменений — это ещё один способ позаботиться о пользователе вашего продукта. А пользователи чувствуют, когда вам не всё равно ;)