Журнал изменений — самый дешёвый маркетинговый канал, который большинство SaaS-компаний игнорирует. Вы и так выпускаете обновления, а журнал просто делает их видимыми: пользователям, которые решают, жив ли продукт, потенциальным клиентам, которые сравнивают вас с конкурентами, и вашей команде, когда она оглядывается на сделанное. Вот как вести журнал, который читают.
1. Пишите для пользователей, а не для git
Самая частая ошибка — публиковать сообщения коммитов. «Отрефакторили middleware авторизации» клиенту ни о чём не говорит. Каждая запись должна отвечать на единственный вопрос пользователя: что я теперь могу сделать, чего не мог раньше?
Слабо: «Добавлен эндпоинт массового экспорта в API v2». Лучше: «Теперь все счета можно выгрузить разом: выберите сколько угодно счетов и нажмите „Экспорт“».
Сначала результат, потом механика. Если у изменения нет результата, который увидит пользователь, ему, скорее всего, место во внутреннем логе, а не в журнале изменений.
2. Присваивайте каждой записи категорию
Журнал изменений редко читают подряд, его просматривают. Небольшой постоянный набор меток — Новое, Улучшено, Исправлено — помогает читателю за секунды найти то, что его касается. Не поддавайтесь соблазну придумать классификацию из двенадцати категорий: трёх-четырёх меток хватает почти на всё, а постоянство важнее точности. Большинство инструментов для журналов изменений хранят это как поле типа у каждой записи (в Kookee эти категории есть из коробки), и по этому же полю фронтенд фильтрует записи.
3. Держите ритм, который сможете выдержать
Журнал, где последняя запись вышла четыре месяца назад, хуже, чем никакого: он выглядит заброшенным. Выберите ритм, который сможете держать: раз в неделю, если выпускаете изменения постоянно, или на каждый релиз, если версии у вас выходят по плану. Помогает группировка: три мелких исправления складываются в приличную еженедельную запись, а большая функция заслуживает своей.
Секрет дисциплины — сделать запись в журнал частью процесса релиза, а не делом на потом. Если функции нет в журнале изменений, она не выпущена.
4. Дайте записям постоянные адреса и версии
У каждой записи должен быть свой slug и постоянный адрес. Тогда на запись можно сослаться в ответе поддержки, посте в соцсетях или письме отдела продаж, а именно так журнал изменений по большей части и читают. Если у продукта есть версии, укажите версию в записи; если нет, хватит даты.
5. Показывайте журнал там, где пользователи и так бывают
Публичная страница журнала изменений — это архив, а работает журнал благодаря распространению. Что себя окупает:
Объявление в приложении: небольшой баннер или значок, когда выходит что-то заметное. Отсюда приходит большая часть прочтений.
RSS-фид: отдавать его дёшево, а опытные пользователи и агрегаторы им пользуются.
Email-дайджесты только для крупных релизов: не чаще раза в месяц, иначе об этом вам расскажут отписки.
Если журнал отдаётся через API контента, показывать его в нескольких местах несложно: одни и те же записи попадают на публичную страницу, в панель внутри приложения и в фид, и ничего не приходится писать дважды.
6. Дайте читателям реагировать
Журнал изменений — ещё и инструмент обратной связи. Простые реакции на записях показывают, какие релизы зашли, а читателю почти ничего не стоят. Комментарии дают больше: пользователи расскажут, если «улучшение» сломало им привычный процесс, и гораздо лучше услышать это под записью в журнале, чем в опросе ушедших клиентов. Если открываете комментарии, отвечайте на них.
7. Замыкайте цикл через доску обратной связи
Больше всего даёт запись, которая называет свой источник: «Вы просили — 47 голосов на нашей доске обратной связи — и это уже работает». Когда выпущенная запись ссылается на запросы, из-за которых её сделали, пользователи видят, что обратная связь работает по-настоящему, и пишут более толковые запросы. Если доска обратной связи и журнал изменений живут в одной системе, это ссылка между двумя записями, а не ритуал с копированием и вставкой.
8. Переводите журнал, если переведён продукт
Если вы продаёте на нескольких языках, журнал только на английском молча говорит остальным клиентам, что они второго сорта. Записи журнала короткие и по делу — это самый дешёвый контент, который вам придётся переводить. В бэкенде контента, где язык задаётся у каждой записи, переводы привязываются к той же записи, и каждый читатель получает свой. Параллельные журналы вести не нужно.
9. Не удаляйте историю
Старый журнал изменений — это доказательство: скорости, долголетия, того, как вы справлялись с прошлыми инцидентами. Храните всё, оставляйте доступным для поиска и не меняйте адреса. Потенциальные клиенты, которые проверяют вас перед покупкой, листают историю глубже, чем вы думаете.
Чего избегать
Раздутый маркетинговый язык. «Революционно новый опыт» для переделанной страницы настроек подрывает доверие. Простой язык выигрывает.
Молчаливые ломающие изменения. Если поведение изменилось так, что может сломать чей-то процесс или интеграцию, журнал изменений — минимально допустимое уведомление: напишите, что изменилось, когда и что с этим делать.
Скриншоты текста. Пишите настоящий текст, а картинки используйте как дополнение: текст находится поиском, переводится и доступен скринридерам.
Журнал, который могут обновлять только разработчики. Если для публикации записи нужны pull request и деплой, записи будут отставать от релизов. Пишите записи в панели управления, отдавайте их через API и рендерьте в приложении: запись об обновлении должна занимать минуты, а не цикл релиза.
Минимальный шаблон
Для каждой записи:
Заголовок: результат для пользователя, одной строкой
Тип: Новое | Улучшено | Исправлено
Версия или дата
Текст: 2–6 предложений — что изменилось, почему это важно, где это найти
Ссылка: документация или сама функцияНачните с этого, продержите ритм квартал и посмотрите на цифры: посещаемость страницы журнала, число реакций, открытия объявлений в приложении. Хороший журнал изменений — не формальность для галочки. Это постоянное доказательство того, что ваш продукт выбрали правильно, и обновляется оно каждую неделю.