Релиз ноты что это

Правила написания Release Notes

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

Состав документа

В некоторых конторах в качестве Release notes наружу выдают маркетинговый булшит, а реальное техническое содержание оставляют только для внутреннего читателя. Это косвенно указывает на то, что в продукте много проблем, а производитель ПО вместо их исправления скрывает их. В обратной ситуации, когда принята политика открытости перед пользователем, и его честно информируют о всех косяках в софте, то пользователь будет более лоялен к производителю ПО. В качестве дополнительного бонуса прозрачность мотивирует делать качественные продукты. Стыдно ведь публично писать о своей криворукости.

Сам документ состоит из следующих разделов:

Краткое описание продукта

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

Что нового

Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.

Исправленные ошибки

Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях. Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.

Включать в этот список все содержимое баг трекера не нужно:

• Если баг был сделан, найден и исправлен в процессе разработки текущей версии, то пользователь его видеть не мог, а значит и писать о нем смысла нет.
• Если баг был в прошлой версии, но пользователь его с ним не мог столкнуться. Например, проблема была прикрыта заплаткой в стиле «программа падает при вводе имени пользователя длинной более 10 символов, поэтому мы сделали ограничение на ввод в 9 символов».

Удобно указывать ID проблемы, для удобства истории ошибки.

Список известных проблем или known issues

Если у вас нет known issues – значит никто не тестировал продукт.

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

• ID по которому дальше можно отслеживать его судьбу.
• Workaround. Что делать пользователю, если он встретился с данной проблемой? Если workaround’а нет для критичного бага, значит продукт содержит критическую проблему и не готов к релизу.

Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.

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

Технические ограничения

Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.

Системные требования

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

Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.

Особенности обновления с прошлой версии.

Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.

Кто пишет документ

Документ должен писать технический писатель, как обладатель грамотного письма. А вот информацию для документа: системные требования, описания workaround’ов, исправленные баги и т.п., должны готовить технические специалисты, руководитель разработки, product manager. Если повесить все на человека, у которого основной навык знание языка, то получиться плохо.

Все новости сайта в телеграм канале: @pmlife_ru

Источник

Автоматизируем подготовку 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 на самом деле нет, и что прежде всего от них должна быть польза.

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

Вот, как это выглядит для меня: «Мы месяц занимались неведомой хренью, поэтому выкатили обновление, но там ничего полезного нет. Чтобы хоть что-то написать, мы сейчас пошутим. Шутим. Шутим. Пошутили». Такие шутейки я встречала у Рокетбанка и 2ГИСа.

Аналогично бесполезен в таких описаниях рассказ о том, как «нам важно ваше мнение, спасибо что делитесь впечатлениями, мы стараемся для вас, бла-бла-бла». Пустословие. Например, этим страдает Facebook.

Мне нравится, когда компании пишут, что реального они исправили, даже если это небольшое изменение. Так делает Модульбанк, Twitter, Тинькофф-банк. Я считаю, описание «Что нового» решает две задачи:

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

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

В комментариях к посту Ники на Facebook встретилось и несколько противоположных мнений.

У этих комментов Рокета главная цель — чтобы люди это обсуждали. Они, в общем, этого добились 🙂 Круче всех конечно были Альфа.

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

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

• Есть минорное обновление, которое надо выпустить (грубо говоря, исправлена пара багов, это нужно релизнуть, практически никто ничего не заметит);
• Не хочется отписываться в стиле «БАГ ФИКСЕС», «НЕЗНАЧИТЕЛЬНЫЕ УЛУЧШЕНИЯ»;
• Ребята пишут, что так и так, ничего нового и значительного для юзера, и вполне, кстати, по канонам инфостиля, все честно, как есть 🙂
• В итоге РН расходится вирусно по Пикабу и всяким пабликам. Это хорошо? Это *** (очень хорошо), потому что вирусный охват нахаляву.

То, что надо делать обновления пореже, чтобы делать РН поинтереснее — это вообще булшит на 146%. Если баги есть — надо править. Если в App Store их нужно заливать через мучительный процесс с написанием РН — пусть пишут и шутят, блин! В мире и так **** (очень много) унылого говна, а ребятам весело.

И, да, фидбек на эту шутейку был так хорош, что даже до инстастори моих знакомых долетело 🙂 Как сммщица я в восторге.

Источник

Жизнь — это движение! А тестирование — это жизнь 🙂

понедельник, 24 июля 2017 г.

Как писать Release Notes, чтобы их читали (ВИДЕО)

Пашин доклад

Ссылка на доклад — ЛАФ, Vimeo

Мой коллега Павел Абдюшев выступил на ЛАФ 2017 с докладом о том, как у нас пишутся Release Notes. И с чего они начинались ツ

А начинались они довольно уныло. Мы осмотрелись — где что пишут? И стали писать также:

Что вы поняли из такого описания? Скорее всего — ничего. Что это? О чем речь? А главное — зачем это мне? Никто не понимал, зачем им читать этот унылый набор букв, да никто и не читал. А мы сильно удивлялись потом: как это вы не знаете, что у нас есть такая фича? Мы же писали о ней в Release Notes!

В итоге поняли, что писали заметки мы для себя. Ссылки давали на задачи — те, которые у Заказчика даже не откроются. Кратенько формулировали мысль. Нам то понятно, спору нет. А вот Заказчику эти фразы ни о чем не говорят.

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

Сейчас, пару лет спустя, наши Release Notes кажутся очевидным решением. Словно так всегда и было. Но ведь не было и мы даже не видели в этом проблемы. А ведь Release Notes — это такая же документация, как и все остальное. И мы, как тестировщики, должны их тестировать. В том числе и на понятность клиенту.

Если уж взялись писать, пишите интересно:

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

Источник

Release notes

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

Содержание

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

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

Содержание и формат

Единого стандарта написания замечаний к версии ПО не существует, у каждой компании есть свои соглашения по формату. Содержание и форма замечаний могут сильно отличаться даже в одной компании в зависимости от изменений в выпускаемой версии ПО.

Разделы замечания

• Заголовок — «Замечания к релизу», название продукта, название версии, дата выпуска и т.д.
• Обзорная часть — Резюме изменений в версии
• Цель — Краткое описание цели выпуска версии со списком изменений, исправлений ошибок, добавленной функциональности
• Описание ошибок — список ошибок (для каждой ошибки: в чем ошибка, где и как воспроизводится), описание исправлений этих ошибок
• Перечень требуемых обновлений — для обновления аппаратной и программной части, документации
• Юридическая информация — лицензии, гарантии, отказ от ответственности и т.д.
• Контактная информация

Формат

Обычно замечания к версии пишутся в текстовом формате, где для изменений перед описанием ставятся соответствующие знаки:

• «+» добавленная функциональность;
• «*» изменения, не влияющие на конечного пользователя;
• «-» исправления ошибок.

Источник