Что такое release notes
Как описать обновление приложения — инструкция от контент-директора Slack
Контент-директор Slack Анна Пикард написала для корпоративного блога заметку о том, как создаются описания каждого обновления сервиса. Она убеждена, что эти тексты надо писать так, чтобы их чтение приносило пользу и удовольствие.
Люди пишут о содержании обновлений программного обеспечения с тех пор, как программное обеспечение появилось и начало обновляться. Большую часть времени аудитория этих сообщений была маленькой и состояла из ИТ-менеджеров. Теперь у каждого в кармане есть компьютер, и все следят за установленным софтом и его обновлениями.
Когда мы начинали работать над Slack и постоянно обновляли сервис, мы думали — что можно сделать, чтобы сообщения об обновлениях были более полезными, чем стандартное: «23 марта: v2.0.8. Исправлены ошибки и добавлены улучшения». Зачем так писать, если сообщения об обновлениях могут содержать по-настоящему ценную информацию, и формировать связи между людьми, которые пользуются сервисом?
Забавно, что такие сообщения предназначены для разового использования. Их необязательно читать, чтобы пользоваться приложением. Их вообще читать необязательно: можно их пролистать или настроить автоматическое обновление и жить в счастливом неведении об их существовании, зная, что приложение будет становиться лучше и лучше.
Но можно их и читать. И если вы даёте себе этот труд, то должны, по крайней мере, извлекать какую-то пользу. Поэтому мы стараемся делать эти сообщения ценными. Описание обновлений играет существенную роль в:
Мы стараемся делать всё перечисленное с долей обаяния. Мы много рассуждали о том, как должны выглядеть описания обновлений и пришли к следующей формуле: взять факты, убрать профессиональную терминологию, описать их понятными словами. Слова могут быть слегка поэтичными и немного несуразными, но обязательно информативными. Вот как мы действуем.
Составьте список
Когда команды работают над очередным релизом, они составляют список вещей, которые в него входят. Его редактируют и делят на две колонки: «Что нового» и «Что исправлено».
«Что нового»: Любые новые функции, перечисленные по значимости.
«Что исправлено»: «Что-то, с чем кто-то столкнулся в какой-то ситуации и сообщил об ошибке или что-то, трудно обнаруживаемое и откровенно нелепое, но достаточно интересное, чтобы этим поделиться».
Проверьте дважды
Некоторые команды (особенно разработчики мобильных сервисов, которые обновляются быстро и заметно) предпочитают составить скупой список и заняться работой над следующим обновлением. Есть другие разработчики, которые более словоохотливы и с гордостью составляют хорошо продуманные списки.
В любом случае, нельзя ничего публиковать, не проверив, не приведя в порядок и не посыпав волшебной редакторской пыльцой. Придётся немного пободаться с разработчиками и прояснить детали, которые выглядят неочевидными. Редактор должен задать несколько глупых вопросов и попросить показать примеры, чтоб сделать описание понятным обычному пользователю. В этом смысле может помочь отсутствие у редактора технического бэкграунда.
Разберитесь, что было плохо, и когда будет хорошо
Мы гордимся тем, что умеем признавать ошибки и работаем над тем, чтобы продукт становился лучше. Это значит, что мы не прибегаем к прибауткам и красивым словам, чтобы скрыть проблемы — большие или маленькие. Мы приносим извинения, благодарим людей за терпение и сообщаем, что усердно трудимся над улучшениями.
Мы «перемешиваем» текст так, чтобы в нем не оказалось слишком много смешных мыслей подряд (и чтобы их в целом не было слишком много). Текст должен иметь ритм, который сделает чтение проще; предложения должны звучать в голове читателя так же хорошо, как если прочитать их вслух.
Знайте, когда остановиться
Если вы хотите сочинить что-то такое, что люди будут охотно читать, то сделать текст приятным для чтения — это вопрос приличия. Поэтому в описании обновлений — как и во всём остальное — имеют большое значение любовь к языку и немного юмора. Порой возникает соблазн с этим переборщить, но мы сохраняем бдительность и не позволяем себе слишком увлекаться.
«С солью еда вкуснее, но если пересолить, то можно вообще не ощутить вкус. Всем нравятся хорошие гитарные проигрыши, но если песня только из них и состоит, то большинство людей просто не сможет её слушать», — сказал однажды кто-то мудрый и знающий, как испортить веселье.
Стоит отметить, что количество соли — это всегда вопрос вкуса, и даже у нас в Slack постоянно ведутся споры о том, сколько её добавить. И это единственно верный способ создания текстов. Мы принимаем это близко к сердцу и вместе становимся лучше.
Смысл в том, что содержание — всегда важнейшая из вещей. Да, у нас есть форма, мы же Slack. Но если форма начинает преобладать над содержанием, то это конец. Но пока можно сказать вот что. Люди читают описания обновлений. И чем больше людей их читают, тем больше мы вкладываем в их написание. А чем больше мы вкладываем, тем больше люди получают от их прочтения. По крайней мере, мы на это надеемся.
Управлять релизом просто: правила и этапы release management
Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?
Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.
Часто релиз состоит из ряда решений по устранению проблем и улучшений предоставляемых услуг, может включать изменения в ПО. На самом деле, это довольно значимое событие как для внутренних команд, так и для целевой аудитории.
Управление релизами помогает командам планировать свою работу и видеть конечный результат, а для клиентов это, своего рода, гарантия качества и получения новой ценности.
Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.
Релизы должны включать все дополнительные задачи и активности, такие, например, как обновления на официальном сайте и в социальных сетях, обучение команды поддержки, обновление всех маркетинговых материалов и т. д.
Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.
Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.
Что включает процесс управления релизом?
Понимание процесса управления выпуском продукта может отличаться у разработчиков и нетехнических специалистов. Важно учитывать все аспекты релиза и прислушиваться к мнению каждого члена команды.
Процесс управления релизом может включать следующие этапы:
В управлении релизом продукта могут участвовать практически все члены команды.
Product manager и Project Manager
Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.
Разбработчики
Команда разработки — это ключевые игроки в управлении релизом, поскольку они участвуют в большинстве процессов в жизненном цикле продукта. Они оценивают изначальные затраты и время, определяют основные требования, создают документацию и разрабатывают функциональность. Они принимают главные решения о том, что можно сделать и что не нужно, а также сколько времени это займет.
Маркетинг
Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.
Тестировщики
Тестировщики работают вместе с разработчиками. Их задача — тестировать результаты исследований и разработки, основываясь на установленных критериях. Продукт не придет к релизу, пока не будут учтены все замечания и критерии прохождения тестирований.
Служба поддержки
Support-команда или отдельный специалист поддержки первыми получают сообщения, елси что-то пошло не так. Они должны понимать и знать все о релизе и должны быть должным образом подготовлены на всех уровнях еще на стадии планирования.
Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.
Почему нужно внедрять процесса управления релизам?
Что такое Release Notes в процессе управления релизом?
Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.
Когда используются примечания к релизу?
Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).
Вы можете найти различные варианты написания Release Notes, поскольку для этого документа нет единого стандарта или формата. В разных компаниях менеджеры продуктов, тестировщики и разработчики, которые обычно ответственны за написание примечаний, обычно используют свои собственные шаблоны.
Вот как выглядит страница с примечаниями к релизу у Firefox:
Как писать примечания к релизу?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
Заключение
Управление релизом во многих компаниях становится отдельным самостоятельным процессом, который сообщает заказчику дату выпуска продукта и основные этапы его развития. Заказчик участвует в приоритизации и вовлечен в определение содержания релиза.
Процесс позволяет менеджерам продуктов и команде своевременно оценить загрузку и управлять объемом работ, доставлять изменения в срок. Управление релизами позволяет собирать собственную статистику, с которой удобнее в дальнейшем обосновывать запросы на дополнительные ресурсы.
Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)
Как организовать релиз
Как готовиться к релизу?
Выбрать ответственного человека
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить календарь
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Сделать таблицу в вики
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
Release notes
Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.
Внутренний анонс
Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.
Во время релиза
Создать релизный бранч
Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.
Отправить уведомление
Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.
Сделать тэг
Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.
Сделать сам релиз
В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.
Релиз одной кнопкой
Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.
Если все пошло не так, как планировалось
Конечно же в случае какой-либо ошибки нельзя друг друга обвинять, а нужно решить проблему вместе и придумать план по предотвращению подобных инцидентов в будущем.
После релиза
Мониторить
Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.
Сообщить об успехах и неудачах
Намного лучше если о проблеме узнают от разработчиков, а не от пользователей. И конечно же, если вы решили какие-то проблемы, то этим можно смело похвалиться.
Провести ретроспективу
Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.
Заказать пиццу и отпраздновать
Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.
Начать подготовку к следующему релизу
Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.
Release Notes: Пользу или юмор вперёд?
Вот, как это выглядит для меня: «Мы месяц занимались неведомой хренью, поэтому выкатили обновление, но там ничего полезного нет. Чтобы хоть что-то написать, мы сейчас пошутим. Шутим. Шутим. Пошутили».
Редактор и маркетолог Ника Троицкая в блоге «Биодинамической редакции» рассказала, что ничего хорошего в смешных Release notes на самом деле нет, и что прежде всего от них должна быть польза.
Некоторые люди находят уместными шутки в App Store — там, где разработчики по идее пишут, что нового появилось в приложении.
Вот, как это выглядит для меня: «Мы месяц занимались неведомой хренью, поэтому выкатили обновление, но там ничего полезного нет. Чтобы хоть что-то написать, мы сейчас пошутим. Шутим. Шутим. Пошутили». Такие шутейки я встречала у Рокетбанка и 2ГИСа.
Аналогично бесполезен в таких описаниях рассказ о том, как «нам важно ваше мнение, спасибо что делитесь впечатлениями, мы стараемся для вас, бла-бла-бла». Пустословие. Например, этим страдает Facebook.
Мне нравится, когда компании пишут, что реального они исправили, даже если это небольшое изменение. Так делает Модульбанк, Twitter, Тинькофф-банк. Я считаю, описание «Что нового» решает две задачи:
Если бы S7 сразу писал нормально, вместо бесполезного заигрывания с читателями, о его новых фичах и о том, какие они там молодцы, то об этом узнало бы гораздо больше людей.
В комментариях к посту Ники на Facebook встретилось и несколько противоположных мнений.
У этих комментов Рокета главная цель — чтобы люди это обсуждали. Они, в общем, этого добились 🙂 Круче всех конечно были Альфа.
Эти апдейты никто никогда не читает, даже если какую-то багу пофиксили и об этом написали, полезно это будет только гикам, которые за этим следят и для них такие вещи важны.
Ты смотришь на задачу, как по самую макушечку инфостильнй редактор, что тоже хорошо. А взгляни на кейс с точки зрения маркетинга:
То, что надо делать обновления пореже, чтобы делать РН поинтереснее — это вообще булшит на 146%. Если баги есть — надо править. Если в App Store их нужно заливать через мучительный процесс с написанием РН — пусть пишут и шутят, блин! В мире и так **** (очень много) унылого говна, а ребятам весело.
И, да, фидбек на эту шутейку был так хорош, что даже до инстастори моих знакомых долетело 🙂 Как сммщица я в восторге.
Правила написания Release Notes
Release Notes – это документ, описывающий изменения между выпускаемой и предыдущей версиями программного продукта. Адресатом данного документа в первую очередь являются технические специалисты клиента, которые занимаются обслуживанием продукта, интеграторы и команды внедрения. Поэтому документ в первую очередь должен содержать полезную техническую информацию, а не маркетинговые лозунги.
Состав документа
В некоторых конторах в качестве Release notes наружу выдают маркетинговый булшит, а реальное техническое содержание оставляют только для внутреннего читателя. Это косвенно указывает на то, что в продукте много проблем, а производитель ПО вместо их исправления скрывает их. В обратной ситуации, когда принята политика открытости перед пользователем, и его честно информируют о всех косяках в софте, то пользователь будет более лоялен к производителю ПО. В качестве дополнительного бонуса прозрачность мотивирует делать качественные продукты. Стыдно ведь публично писать о своей криворукости.
Сам документ состоит из следующих разделов:
Краткое описание продукта
Несколько предложений или пара абзацев о продукте. Служит для того, чтобы человек, которому в руки попал документ, мог погрузиться в контекст. Иначе без введения на него сразу будет вывален список нового функционала и багов. Не нужно сразу пугать людей.
Что нового
Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.
Исправленные ошибки
Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях. Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.
Включать в этот список все содержимое баг трекера не нужно:
Удобно указывать ID проблемы, для удобства истории ошибки.
Список известных проблем или known issues
Если у вас нет known issues – значит никто не тестировал продукт.
Приводим список известных проблем (багов). Идеально, если в нем содержатся все актуальные баги для данной версии. Если их слишком много, то выбираем наиболее критичные для пользователя. Для каждого бага нужно указывать:
Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.
Не стоит забывать и про мотивационную составляющую. Если люди работают в условиях прозрачности, то они склонны делать свою работу более качественно, краснеть никто не любит.
Технические ограничения
Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.
Системные требования
В данном разделе все понятно: минимальные и рекомендуемые требования по железу, поддерживаемые операционные системы, требуемый сторонний софт.
Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.
Особенности обновления с прошлой версии.
Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.
Кто пишет документ
Все новости сайта в телеграм канале: @pmlife_ru