что такое релиз ноутс
Release Notes: Пользу или юмор вперёд?
Вот, как это выглядит для меня: «Мы месяц занимались неведомой хренью, поэтому выкатили обновление, но там ничего полезного нет. Чтобы хоть что-то написать, мы сейчас пошутим. Шутим. Шутим. Пошутили».
Редактор и маркетолог Ника Троицкая в блоге «Биодинамической редакции» рассказала, что ничего хорошего в смешных Release notes на самом деле нет, и что прежде всего от них должна быть польза.
Некоторые люди находят уместными шутки в App Store — там, где разработчики по идее пишут, что нового появилось в приложении.
Вот, как это выглядит для меня: «Мы месяц занимались неведомой хренью, поэтому выкатили обновление, но там ничего полезного нет. Чтобы хоть что-то написать, мы сейчас пошутим. Шутим. Шутим. Пошутили». Такие шутейки я встречала у Рокетбанка и 2ГИСа.
Аналогично бесполезен в таких описаниях рассказ о том, как «нам важно ваше мнение, спасибо что делитесь впечатлениями, мы стараемся для вас, бла-бла-бла». Пустословие. Например, этим страдает Facebook.
Мне нравится, когда компании пишут, что реального они исправили, даже если это небольшое изменение. Так делает Модульбанк, Twitter, Тинькофф-банк. Я считаю, описание «Что нового» решает две задачи:
Если бы S7 сразу писал нормально, вместо бесполезного заигрывания с читателями, о его новых фичах и о том, какие они там молодцы, то об этом узнало бы гораздо больше людей.
В комментариях к посту Ники на Facebook встретилось и несколько противоположных мнений.
У этих комментов Рокета главная цель — чтобы люди это обсуждали. Они, в общем, этого добились 🙂 Круче всех конечно были Альфа.
Эти апдейты никто никогда не читает, даже если какую-то багу пофиксили и об этом написали, полезно это будет только гикам, которые за этим следят и для них такие вещи важны.
Ты смотришь на задачу, как по самую макушечку инфостильнй редактор, что тоже хорошо. А взгляни на кейс с точки зрения маркетинга:
То, что надо делать обновления пореже, чтобы делать РН поинтереснее — это вообще булшит на 146%. Если баги есть — надо править. Если в App Store их нужно заливать через мучительный процесс с написанием РН — пусть пишут и шутят, блин! В мире и так **** (очень много) унылого говна, а ребятам весело.
И, да, фидбек на эту шутейку был так хорош, что даже до инстастори моих знакомых долетело 🙂 Как сммщица я в восторге.
Как организовать релиз
Как готовиться к релизу?
Выбрать ответственного человека
Можно дежурить по очереди, либо бросать игральные кости, либо тянуть спички —любой способ хорош. Важна ротация людей и обучение тех, кто не умеет делать релиз. Например, при броске костей можно ввести правила что тот, кто дежурил в прошлый раз, имеет право перебросить, а если дежурил два раза подряд, то автоматически не дежуришь. Дежурство не должно восприниматься как наказание или повинность, и обязательно должны быть люди, которые могут подстраховать.
Настроить календарь
Настроить дату в корпоративном календаре и убедится что все стейкхолдеры в курсе.
Сделать таблицу в вики
Укажите таблице версию, дату и человека, ответственного за релиз. Это больше нужно для ведения исторических данных. Можно и нужно тут же отметить, был ли релиз успешный и что именно вошло в релиз.
Release notes
Это то самое “что именно вошло в релиз”. В первую очередь, этими данными нужно поделится с аналитиками: любые изменения в KPI они могут сравнивать с тем, что вошло в релиз. На основании этих данных они могут делать выводы, какой функционал нужен пользователям, какие идеи хорошие, а какие нет, и что войдет в следующею итерацию.
Внутренний анонс
Другим отделам важно знать когда произошел релиз, чтобы, например, сделать посты в соц. сетях о новой версии продукта (создать инфоповод), следить за KPI (возможен рост или падение метрик) и т.д.
Во время релиза
Создать релизный бранч
Код, который подлежит выпуску не должен меняться, за исключением исправления критических багов. И в идеальном случае любой фикс должен пройти пул-реквест. Так же все тесты должны быть зеленые.
Отправить уведомление
Нужно уведомить всех по почте или в мессенджере о том, что создан релизный бранч и идет подготовка к релизу.
Сделать тэг
Обязательно сделать тэг, когда релиз финализирован, и затянуть фиксы в девелоп-ветку.
Сделать сам релиз
В идеальном варианте у вас должны быть механизмы, которые контролируют релиз: например, сделать релиз только на 10% пользователей или только на не платящих. Это необходимо для того. чтобы уменьшить урон от ошибок, которые возникли в процессе разработки и не были найдены во время тестирования.
Релиз одной кнопкой
Мифический. Безусловно, чем меньше человеческого фактора участвует в релизе, тем лучше. Но это нормально, если не все получается автоматизировать.
Если все пошло не так, как планировалось
Конечно же в случае какой-либо ошибки нельзя друг друга обвинять, а нужно решить проблему вместе и придумать план по предотвращению подобных инцидентов в будущем.
После релиза
Мониторить
Не забывайте мониторить ошибки, нагрузку на сервера. Также стоит обратить внимание на KPI: если вы сделали релиз и у вас упало DAU, то, возможно, что-то работает не так хорошо, как должно было, либо сломаны сами средства мониторинга. Любую подозрительную активность стоит проверить.
Сообщить об успехах и неудачах
Намного лучше если о проблеме узнают от разработчиков, а не от пользователей. И конечно же, если вы решили какие-то проблемы, то этим можно смело похвалиться.
Провести ретроспективу
Это, конечно же, частично зависит от методологии разработки, но если что-то в процессе релиза пошло не так — это стоит обсудить. Если что-то было хорошо, то это также стоит обсудить. В идеале на доске на каждый пункт неудачи должен быть пункт успеха либо благодарность коллеге. Это поможет не скатить ретроспективу в нытье и негатив.
Заказать пиццу и отпраздновать
Во время таких посиделок просто коллеги становятся друзьями и боевыми товарищами. А это значит, что в следующем бою друзья не подведут.
Начать подготовку к следующему релизу
Мне очень нравится идея Release train, когда каждый релиз проходит регулярно в четко обозначенные даты. Благодаря этому механизм релиза отлаживается командой. Как я писал выше, не обязательно делать релиз на 100% пользователей: можно выкатить на небольшую группу людей.
Как описать обновление приложения — инструкция от контент-директора Slack
Контент-директор Slack Анна Пикард написала для корпоративного блога заметку о том, как создаются описания каждого обновления сервиса. Она убеждена, что эти тексты надо писать так, чтобы их чтение приносило пользу и удовольствие.
Люди пишут о содержании обновлений программного обеспечения с тех пор, как программное обеспечение появилось и начало обновляться. Большую часть времени аудитория этих сообщений была маленькой и состояла из ИТ-менеджеров. Теперь у каждого в кармане есть компьютер, и все следят за установленным софтом и его обновлениями.
Когда мы начинали работать над Slack и постоянно обновляли сервис, мы думали — что можно сделать, чтобы сообщения об обновлениях были более полезными, чем стандартное: «23 марта: v2.0.8. Исправлены ошибки и добавлены улучшения». Зачем так писать, если сообщения об обновлениях могут содержать по-настоящему ценную информацию, и формировать связи между людьми, которые пользуются сервисом?
Забавно, что такие сообщения предназначены для разового использования. Их необязательно читать, чтобы пользоваться приложением. Их вообще читать необязательно: можно их пролистать или настроить автоматическое обновление и жить в счастливом неведении об их существовании, зная, что приложение будет становиться лучше и лучше.
Но можно их и читать. И если вы даёте себе этот труд, то должны, по крайней мере, извлекать какую-то пользу. Поэтому мы стараемся делать эти сообщения ценными. Описание обновлений играет существенную роль в:
Мы стараемся делать всё перечисленное с долей обаяния. Мы много рассуждали о том, как должны выглядеть описания обновлений и пришли к следующей формуле: взять факты, убрать профессиональную терминологию, описать их понятными словами. Слова могут быть слегка поэтичными и немного несуразными, но обязательно информативными. Вот как мы действуем.
Составьте список
Когда команды работают над очередным релизом, они составляют список вещей, которые в него входят. Его редактируют и делят на две колонки: «Что нового» и «Что исправлено».
«Что нового»: Любые новые функции, перечисленные по значимости.
«Что исправлено»: «Что-то, с чем кто-то столкнулся в какой-то ситуации и сообщил об ошибке или что-то, трудно обнаруживаемое и откровенно нелепое, но достаточно интересное, чтобы этим поделиться».
Проверьте дважды
Некоторые команды (особенно разработчики мобильных сервисов, которые обновляются быстро и заметно) предпочитают составить скупой список и заняться работой над следующим обновлением. Есть другие разработчики, которые более словоохотливы и с гордостью составляют хорошо продуманные списки.
В любом случае, нельзя ничего публиковать, не проверив, не приведя в порядок и не посыпав волшебной редакторской пыльцой. Придётся немного пободаться с разработчиками и прояснить детали, которые выглядят неочевидными. Редактор должен задать несколько глупых вопросов и попросить показать примеры, чтоб сделать описание понятным обычному пользователю. В этом смысле может помочь отсутствие у редактора технического бэкграунда.
Разберитесь, что было плохо, и когда будет хорошо
Мы гордимся тем, что умеем признавать ошибки и работаем над тем, чтобы продукт становился лучше. Это значит, что мы не прибегаем к прибауткам и красивым словам, чтобы скрыть проблемы — большие или маленькие. Мы приносим извинения, благодарим людей за терпение и сообщаем, что усердно трудимся над улучшениями.
Мы «перемешиваем» текст так, чтобы в нем не оказалось слишком много смешных мыслей подряд (и чтобы их в целом не было слишком много). Текст должен иметь ритм, который сделает чтение проще; предложения должны звучать в голове читателя так же хорошо, как если прочитать их вслух.
Знайте, когда остановиться
Если вы хотите сочинить что-то такое, что люди будут охотно читать, то сделать текст приятным для чтения — это вопрос приличия. Поэтому в описании обновлений — как и во всём остальное — имеют большое значение любовь к языку и немного юмора. Порой возникает соблазн с этим переборщить, но мы сохраняем бдительность и не позволяем себе слишком увлекаться.
«С солью еда вкуснее, но если пересолить, то можно вообще не ощутить вкус. Всем нравятся хорошие гитарные проигрыши, но если песня только из них и состоит, то большинство людей просто не сможет её слушать», — сказал однажды кто-то мудрый и знающий, как испортить веселье.
Стоит отметить, что количество соли — это всегда вопрос вкуса, и даже у нас в Slack постоянно ведутся споры о том, сколько её добавить. И это единственно верный способ создания текстов. Мы принимаем это близко к сердцу и вместе становимся лучше.
Смысл в том, что содержание — всегда важнейшая из вещей. Да, у нас есть форма, мы же Slack. Но если форма начинает преобладать над содержанием, то это конец. Но пока можно сказать вот что. Люди читают описания обновлений. И чем больше людей их читают, тем больше мы вкладываем в их написание. А чем больше мы вкладываем, тем больше люди получают от их прочтения. По крайней мере, мы на это надеемся.
Автоматизируем подготовку Release Notes в современной команде разработки
Делимся своим опытом о том, как мы в True Engineering собираем отчёты по релизам – быстро, корректно и без ручного труда.
Мы начали автоматизировать подготовку Release Notes несколько лет назад. Нашей целью было привести их к единому для всех команд стандарту, избавить тимлидов и PM-ов от ручной работы по подготовке материалов, застраховаться от возможных ошибок, которые обязательно возникают, если что-то делается вручную.
Мы сделали на нашем внутреннем портале веб-конструктор, который позволяет в несколько кликов собрать готовый отчет по релизу. Сервис интегрирован с таск-трекерами, откуда он автоматически подтягивает всю информацию по релизу. На выходе приложение генерирует красиво сверстанный e-mail отчет для заказчика. Вся информация разбита по категориям, у каждого пункта есть ссылка на соответствующую страницу в трекере.
Несколько лет инструмент работал в таком виде, но прогресс не стоит на месте. Когда мы стали внедрять Trunk Based Development (TBD), подход к Release Notes тоже пришлось поменять.
Концепция TBD предполагает, что разработка идёт непрерывно, а команда постоянно выпускает обновления микрорелизами. Это ускоряет развитие продукта, сокращает Time-to-Market (время от начала разработки до поставки продукта пользователям), обеспечивает разработчикам оперативную обратную связь от заказчика и пользователей.
Ещё один фактор – за последние годы большинство продуктов True Engineering переехали на микросервисы. Такая архитектура предполагает, что в командах используются несколько репозиториев для каждого участвующего микросервиса. Выпуск одной фичи включает несколько релизов для разных микросервисов, и отслеживать это довольно сложно.
Мы переосмыслили подготовку Release Notes, опираясь на автоматический анализ PBI (Product Backlog Item, условно – цельная задача в терминологии TFS). До этого мы уже наладили автоматическую маркировку задач тегами, чтобы QA-инженеры видели, какие фичи можно забирать на тест. Теперь эти же теги мы используем для Release Notes.
Специально созданный плагин TFS на базе TFS Aggregator ежедневно просматривает завершённые PBI и формирует письмо с итогами для менеджеров, директоров, отдела продаж. Aggregator позволяет автоматизировать многие ручные операции при работе с PBI – например, отслеживать, когда последняя задача в PBI получает статус Done, и помечать как готовую всю PBI. Причём` Aggregator умеет очень гибко работать с базой правил – разделять их по проектам, по типам задач и т.д.. В общем, он идеально выполняет рутинную работу, на которую у команды уходит много времени и сил.
Таким образом и получается автоматически готовить Release Notes. Пилот решения уже стартовал на двух наших проектах, скоро новая механика распространится на все команды True Engineering. Прелесть в том, что масштабировать этот опыт будет очень просто – достаточно письма в техподдержку, где будет указан тег, который должен ловить Aggregator, и список адресов, куда нужно отправлять Release Notes.
Правила написания Release Notes
Release Notes – это документ, описывающий изменения между выпускаемой и предыдущей версиями программного продукта. Адресатом данного документа в первую очередь являются технические специалисты клиента, которые занимаются обслуживанием продукта, интеграторы и команды внедрения. Поэтому документ в первую очередь должен содержать полезную техническую информацию, а не маркетинговые лозунги.
Состав документа
В некоторых конторах в качестве Release notes наружу выдают маркетинговый булшит, а реальное техническое содержание оставляют только для внутреннего читателя. Это косвенно указывает на то, что в продукте много проблем, а производитель ПО вместо их исправления скрывает их. В обратной ситуации, когда принята политика открытости перед пользователем, и его честно информируют о всех косяках в софте, то пользователь будет более лоялен к производителю ПО. В качестве дополнительного бонуса прозрачность мотивирует делать качественные продукты. Стыдно ведь публично писать о своей криворукости.
Сам документ состоит из следующих разделов:
Краткое описание продукта
Несколько предложений или пара абзацев о продукте. Служит для того, чтобы человек, которому в руки попал документ, мог погрузиться в контекст. Иначе без введения на него сразу будет вывален список нового функционала и багов. Не нужно сразу пугать людей.
Что нового
Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.
Исправленные ошибки
Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях. Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.
Включать в этот список все содержимое баг трекера не нужно:
Удобно указывать ID проблемы, для удобства истории ошибки.
Список известных проблем или known issues
Если у вас нет known issues – значит никто не тестировал продукт.
Приводим список известных проблем (багов). Идеально, если в нем содержатся все актуальные баги для данной версии. Если их слишком много, то выбираем наиболее критичные для пользователя. Для каждого бага нужно указывать:
Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.
Не стоит забывать и про мотивационную составляющую. Если люди работают в условиях прозрачности, то они склонны делать свою работу более качественно, краснеть никто не любит.
Технические ограничения
Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.
Системные требования
В данном разделе все понятно: минимальные и рекомендуемые требования по железу, поддерживаемые операционные системы, требуемый сторонний софт.
Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.
Особенности обновления с прошлой версии.
Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.
Кто пишет документ
Все новости сайта в телеграм канале: @pmlife_ru