Автоматизируем подготовку 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.
Релиз ноут что это
Откройте возможности нейронного машинного перевода PROMT
PROMT.One (www.translate.ru) – бесплатный онлайн-переводчик на основе нейронных сетей (NMT) для азербайджанского, английского, арабского, греческого, иврита, испанского, итальянского, казахского, китайского, корейского, немецкого, португальского, русского, татарского, турецкого, туркменского, узбекского, украинского, финского, французского, эстонского и японского языков.
Изучайте времена и формы глаголов в английском, немецком, испанском, французском и русском языках в разделе Спряжение и склонение. Учите употребление слов и выражений в разных Контекстах. Мы собрали для вас миллионы примеров перевода на разные языки, которые помогут вам в изучении иностранных языков и подготовке домашних заданий.
Переводите в любом месте и в любое время с помощью мобильного переводчика PROMT.One для iOS и Android. Попробуйте голосовой и фотоперевод, скачайте языковые пакеты для офлайн-перевода.
Поделиться переводом
Но сейчас вы можете переводить только 999 символов за один раз.
Пожалуйста, войдите или зарегистрируйтесь, чтобы переводить до 5 000 символов единовременно. войти / зарегистрироваться
Добавить в избранное
Для добавления в Избранное необходимо авторизоваться
Правила написания Release Notes
Release Notes – это документ, описывающий изменения между выпускаемой и предыдущей версиями программного продукта. Адресатом данного документа в первую очередь являются технические специалисты клиента, которые занимаются обслуживанием продукта, интеграторы и команды внедрения. Поэтому документ в первую очередь должен содержать полезную техническую информацию, а не маркетинговые лозунги.
Состав документа
В некоторых конторах в качестве Release notes наружу выдают маркетинговый булшит, а реальное техническое содержание оставляют только для внутреннего читателя. Это косвенно указывает на то, что в продукте много проблем, а производитель ПО вместо их исправления скрывает их. В обратной ситуации, когда принята политика открытости перед пользователем, и его честно информируют о всех косяках в софте, то пользователь будет более лоялен к производителю ПО. В качестве дополнительного бонуса прозрачность мотивирует делать качественные продукты. Стыдно ведь публично писать о своей криворукости.
Сам документ состоит из следующих разделов:
Краткое описание продукта
Несколько предложений или пара абзацев о продукте. Служит для того, чтобы человек, которому в руки попал документ, мог погрузиться в контекст. Иначе без введения на него сразу будет вывален список нового функционала и багов. Не нужно сразу пугать людей.
Что нового
Изменение функциональности относительно прошлой версии. Перечисление основных изменений с их кратким описанием. Цель раздела — объяснить пользователю зачем ему тратить своё время и переходить на новую версию.
Исправленные ошибки
Список исправленных ошибок относительно предыдущей версии. Как и предыдущий раздел, этот тоже стимулирует пользователя на апгрейд. Обязательно описать исправленные проблемы, на которые жаловались клиенты и которые были заявлены как known issues в прошлых версиях. Крайне желательно описать те серьезные проблемы, с которыми пользователь мог столкнуться в прошлых версиях, но жалоб на них не поступало. Отсутствие жалоб вовсе не означает, что с ними никто сталкивался. Возможно люди мучились, но у них не хватило сил пробиться через поддержку.
Включать в этот список все содержимое баг трекера не нужно:
Удобно указывать ID проблемы, для удобства истории ошибки.
Список известных проблем или known issues
Если у вас нет known issues – значит никто не тестировал продукт.
Приводим список известных проблем (багов). Идеально, если в нем содержатся все актуальные баги для данной версии. Если их слишком много, то выбираем наиболее критичные для пользователя. Для каждого бага нужно указывать:
Есть соблазн написать в этот раздел поменьше, чтобы не пугать клиентов. Всех, кто так считает, можно отправить к рассказу Драгунского «Тайное становится явным». Если клиенты действительно используют продукт, то все равно они найдут все эти баги, в дополнение у них еще появятся вопросы к качеству тестирования продукта производителем. А так вы честно демонстрируете открытость клиентам и сразу выдаете список woraround’ов, снижая затраты на поддержку.
Не стоит забывать и про мотивационную составляющую. Если люди работают в условиях прозрачности, то они склонны делать свою работу более качественно, краснеть никто не любит.
Технические ограничения
Любое ПО имеет технические ограничения. Ваш сервер позволяет работать одновременно 10 пользователям? В базу можно сделать только 10000 записей? UI рассчитан только на Full HD? Напишите об этом.
Системные требования
В данном разделе все понятно: минимальные и рекомендуемые требования по железу, поддерживаемые операционные системы, требуемый сторонний софт.
Если параметры железа зависят от сценариев использования продукта, например, от количества пользователей, сложности вычислений, количества данных в базе, то хорошо сделать sizing guide. Это таблица в стиле: если ожидается такая нагрузка, то рекомендуется такое железо.
Особенности обновления с прошлой версии.
Апдейт не всегда проходит гладко. А потеря данных пользователя вообще караул. Лучше сразу предупредить о возможных проблемах.
Кто пишет документ
Все новости сайта в телеграм канале: @pmlife_ru
Как описать обновление приложения — инструкция от контент-директора 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 и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)