Как составить релизный план

Всë, что вам нужно знать об управлении релизами

В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.

---

Что это такое управление релизом?

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

1. Планирование релиза
2. Сборка релиза
3. Приемочное пользовательское тестирование
4. Подготовка релиза
5. Развертывание релиза.

Планирование релиза

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

При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.

Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:

1. Отсечение: начинается 1-й день.
2. Внутреннее тестирование версий альфа/UAT: Три дня.
3. Поэтапное развертывание [1%] Представление на ревью.
4. Продолжительность ревью: 3 дня.
5. Один день при 20% пользователей.
6. Один день при 50% пользователей, в тот же день рост до 100% пользователей.

В соответствии с приведенным выше примером в общей сложности потребуется 10 дней, пока новая версия приложения не будет общедоступна.

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

Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:

• Сроки
• Сроки поставки
• Требования
• Общий масштаб проекта

После разработки плана мы представляем его на рассмотрение всех заинтересованных сторон (релиз-группы, продакт-менеджера и руководителей высокого уровня). Затем получаем их отзывы о любых пробелах или проблемах, которые они видят в требованиях или в сфере применения.

Как только план утверждается и окончательно оформляется, начинается самое интересное!

Важные аспекты планирования релизов

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

• Релиз-менеджер управляет релизом и координирует его.
• Мы принимаем только код с проведенным ревью и протестированный код.
• В процессе есть этап внедрения.
• Мы мониторим выпущенную версию приложения.

Построение релиза

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

В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.

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

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

Релиз веток и контроль версий

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

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

Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.

Пользовательское приемочное тестирование

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

Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:

• Могут ли пользователи работать с приложением?
• Соответствует ли поведение приложения ожиданиям?
• Решает ли приложение проблему пользователей?

Без эффективного UAT (User Acceptance Testing) шансы на успех разрабатываемого проекта значительно снижаются. Именно поэтому пользовательское является такой важной частью процесса поставки. Как отмечалось ранее, UAT — часть итеративного процесса. По мере выявления ошибок команда возвращается, чтобы исправить их. Ошибка исправляется в ветке релиза, а затем мержится обратно в ветку разработки. Сборка должна пройти стадию UAT, чтобы её можно было изучить на предмет окончательного внедрения и выпуска.

Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!

Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.

Подготовка и релиз

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

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

Развертывание релиза

Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:

• Создание окончательной сборки [с указанием ветки и названия версии].
• Добавление «What’s New» в релизе.
• Добавление процента развертывания.
• У каждого этапа есть ручной ввод сигналов (красный/зеленый) от каждой из команд [UAT, бенчмарк, производительность, автоматизация].

Как только сигналы разрешают сборку, сборка автоматически загружается в Play Store с определенным процентом развертывания. Внутренние шаги коммита и прописывания тега версии, сохранение сборок в Dropbox, публикация и обновление в соответствующем канале Slack также выполняются через тот же конвейер.

В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.

Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.

Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.

Анализ после релиза

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

Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.

Подведем итоги

Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:

• Повысили нашу производительность за счёт улучшения коммуникации и координации.
• Доставка наших релизов происходит быстрее, что также снижает риски. В этих изменениях участвует команда, которая может регулярно предоставлять качественные релизы с высокой скоростью.
• Управление релизами также поддерживает систематизацию и оптимизацию метода разработки и эксплуатации.

Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.

• Курс по DevOps
• Обучение профессии Data Science
• Обучение профессии Data Analyst
• Курс «Python для веб-разработки»

Почему планирование релизов продукта 🌬 – один из самых важных этапов проекта

Планирование релиза – это метод управления продуктом, при котором вы разрабатываете стратегию его поэтапного выпуска.

Миша Ряженка

Founder, Executive Partner

Что такое планирование релиза?

Планирование релиза – это метод управления продуктом, при котором вы разрабатываете стратегию его поэтапного выпуска.

Миша Ряженка

Founder, Executive Partner

Что такое дорожная карта продукта?

Дорожная карта продукта (Roadmap) – это достоверный источник информации, который описывает видение, направление и прогресс работы над продуктом с течением времени.

Миша Ряженка

Founder, Executive Partner

Когда лучше всего начинать планирование релизов?

Планирование релиза обычно происходит после того, как вы составили свое видение и дорожную карту проекта.

Миша Ряженка

Founder, Executive Partner

Цель планирования релиза

Только в идеальном мире все всегда идет по плану. Команда спокойно работает, а любая проблема решается по щелчку пальцев. Но, к сожалению, в реальном мире все не так.

Именно поэтому существует множество методик подготовки к реализации проекта. Одна из таких стратегий – это концепция планирования релизов, которая преимущественно используется в Agile совместно с построением дорожной карты проекта (Roadmap). Чаще всего понятие «планирование релиза» встречается в сфере IT и относится к разработке программных продуктов, поэтому сегодня мы тоже за основу возьмем именно эту сферу деятельности.

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

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

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

В индустрии программного обеспечения продукты обычно представляются клиентам в виде официального релиза.

Чтобы понять, что же такое планирование релизов, начать лучше всего с определения самого понятия «релиз».

Релиз – это вариант производимого продукта, предоставляемый для использования.

Планирование релиза – это метод управления продуктом, при котором вы разрабатываете стратегию его поэтапного выпуска.

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

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

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

Миша Ряженка

Founder, Executive Partner

Дорожная карта продукта vs план релиза

Менеджер продукта – это «навигационная система» компании. Представьте себе обычный GPS–навигатор: вы вводите адрес и получаете маршрут до точки назначения. По сути, менеджер продукта – это некий GPS–навигатор в рамках какой–либо компании. Он определяет курс (создает видение проекта) для команды, а затем организует фактическую работу, необходимую для воплощения этого видения в реальность.

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

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

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

Поэтому менеджер должен точно понимать различия между ними:

1. Цель

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

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

2. Компоненты

Дорожная карта продукта часто включает в себя следующие компоненты:

• цели продукта;
• стратегические инициативы;
• релизы и ожидаемые функции;
• основные эпики (эпик – это объем работы, который можно разбить на несколько отдельных заданий, так называемых «пользовательских историй», в зависимости от потребностей или запросов клиентов или конечных пользователей).
• общий график;
• статус.

А план релиза обычно включает в себя:

• функции продукта на каждый релиз;
• циклы, фазы и вехи процесса;
• риски (зависимости);
• даты релизов;
• статус.

3. Аудитория

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

Планирование релиза предназначено для внутренней группы участников кросс–функциональной работы. Наличие такого плана помогает команде продумывать и отслеживать детали предстоящей работы. Цель – избежать неожиданных ситуаций/проблем и нарушения дедлайнов.

4. Время

Roadmap обычно включает в себя даты, которые могут варьироваться от недель и до месяцев, кварталов, а иногда даже лет. Все зависит от типа дорожной карты и уровня детализации, необходимого команде. Конечно, такая карта не должна оставаться статичной, поскольку после реализа какой–то части продукта вам могут потребоваться правки.

План релиза обычно предусматривает более короткие сроки. В зависимости от того, как часто компания выпускает новые продукты или добавляет новые функции, план может составляться на 30, 60 или 90 дней.

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

Миша Ряженка

Founder, Executive Partner

Когда лучше всего начинать планирование релиза

Планирование релиза обычно происходит после того, как вы составили свое видение и дорожную карту проекта. То есть план релизов должен составляться и утверждаться как можно раньше. Практически все необходимые предпроектные работы (составление документации, распределение ресурсов, составление графика работ) должны исходить из пользовательского представления, так как только так можно будет составить список необходимых релизов и понять их последовательность. К тому же при составлении этого плана и его согласовании выясняется, какие решения неприемлемы для исполнителя и заказчика. Если возникшие разногласия окажутся неразрешимыми, это будет свидетельствовать о том, что вам стоит отказаться от такого заказа.

Миша Ряженка

Founder, Executive Partner

Как строится план релиза

Планирование релиза предполагает, что ваша компания уже знакома с принципами Agile и возможно даже внедрила его в рабочий уклад. В таком случае начать разрабатывать план релиза будет достаточно просто. Попробуем разложить весь этот процесс на отдельные шаги:

1. Определите свое видение проекта

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

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

2. Создание дорожной карты продукта и чернового варианта плана релизов

На этом этапе менеджер должен создать дорожную карту продукта и, уже основываясь на ней, наметить черновой вариант плана релизов.

3. Обсуждение готового плана с командой

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

Этот шаг гарантирует, что вся команда получит единое общее понимание стратегии, прежде чем погрузится в проект.

Само обсуждение планов должно сводиться к нескольким пунктам:

• Обзор дорожной карты

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

• Обзор технических деталей релиза

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

• Обзор скорости работы (Velocity) и графика итераций

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

• Определите критерии готовности для оценки какого–либо релиза

Т.е. определите критерии, согласно которым можно оценить, насколько готов какой–либо релиз.

4. Создайте календарь релизов

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

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

Миша Ряженка

Founder, Executive Partner

Что делать, если вы не успеваете с релизом

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

• Разбиение этапа

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

• Сдвиг работ

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

• Перераспределение работ

Это ускорение процесса работы за счет привлечения к проекту дополнительных ресурсов (обычно кадровых) с сохранением даты окончания итерации и запланированного объема работ. Такая методика применима, если ваш продукт можно разбить на части, допускающие раздельное выполнение. И, конечно, ей нельзя воспользоваться, если у вас просто нет дополнительных ресурсов.

Подведем итоги

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

Привет! Меня зовут Анджали и я выстраиваю стратегии продвижения для артистов. Я верю, что если к таланту добавить планирование, а также знание основ музыкального бизнеса и маркетинга, артист достигнет своих целей.

Начинающие артисты часто теряются, когда дело доходит до продвижения их музыки. Самый частый вопрос — с чего начать? Хоть я и не динозавр шоу-бизнеса, а маркетолог из индустрии развлечений, который последние 2 года работает с музыкантами, я все равно решила поделиться своим опытом. Надеюсь будет полезно!

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

Плохой релиз

Что я чаще всего вижу, когда провожу аудит релиза начинающих артистов:

Отсутствие системы

По моему наблюдению, такой подход приводит к демотивации. Ведь ожидание роста в этом случае направлено на вирусность контента. В этом случае артист делает ставку на переменную: «Взлетит – не взлетит.»

Эту переменную контролировать невозможно. Для этого способа роста, должно оставаться место, но ставку нужно делать на ежедневную системную работу.

С чего начать?

Сначала я предлагаю ответить на эти важные вопросы:

1. Какую музыку я делаю?

Вы мгновенно заинтересуете собеседника, если сможете ответить примерно: «Я как RHCP в 1984 году, только с элементами электронной музыки и вокал женский.»

2. Кто моя аудитория?

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

3. Мой план релизов?

Зная план на год вперед, можно выстроить эффективную стратегию развития вашего проекта. Важно понимать что делать между релизами. Как не терять время и создавать поддерживающий контент на этот период. Планирование поможет.

Кто вы как артист? Какую музыку вы делаете?

Это самые страшные вопросы для артиста. В этот момент, обычно, случается неловкая пауза. И далее в 99% случаев начинающий артист ответит:

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

Учитывая, что 99% артистов отвечают примерно одинаково, услышать осознанный ответ — это свежо. Это непременно поможет выделиться на общем фоне.

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

Подумайте, что повлияло на ваше творчество?

Как отразить свое креативное ДНК в био?

Акцент на творчестве, не автобиографии

Ответьте на эти вопросы в своих профилях:

Расскажите про музыку которая вас вдохновляет. Что вы хотите дать слушателю? Какие референсы для своего сингла или альбома вы использовали? Как вы совместили несовместимое и смогли создать что-то уникальное?

Дополните образ актуальной фотографией. Так вы сразу дадите понять о «чем вы».

Пример:

В одном коротком абзаце ooes собрано все, что нам надо знать о личности артистки и ее музыке. Есть небольшой перегруз по метафорам, но это дело её вкуса. Нарочитая небрежность в тексте и шумное фото помогают быстро «считать» её образ.

Ваша аудитория?

Что ваша аудитория слушает? Что в плейлистах ваших слушателей? На кого они подписаны? Какие каналы на YouTube смотрят? Какие чаты в Telegram читают и тд.

Хорошая тренировка – составить портрет слушателя, который сможет оценить ваше творчество. Понимая для кого вы делаете музыку, вам будет гораздо проще донести ее до своего слушателя.

Как понять аудиторию?

Начните с исследования 3-4 смежных артистов:

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

Ссылки на ресурсы для аналитики:

Идеальный план релиза

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

Как часто выпускать музыку?

Spotify рекомендует выпускать музыку раз в месяц. Это тяжело! Как финансово, так и с точки зрения продвижения. Вы просто не будете успевать проработать релиз.

Поэтому рассчитайте промежуток между релизами исходя из ваших возможностей. Промежуток 60 дней, пожалуй, самый удачный. Так вам будет проще словить волну и идти по нарастающей.

Что ещё публиковать в 2021 году?

— Live версии
— Акустические/электронные версии
— Ремиксы
— Ваши комментарии к альбому/синглу
— Хит-сингл отдельно от альбома
— Сингл вперёд альбома

Календарь релиза сингла

Это примерный план, и в нем не учтено время на съемки видео и ваших индивидуальных планов на релиз.

Общие рекомендации по старту работы с Медиа и партнерами – за 2-3 месяца до релиза.

Если вы чувствуете, что вам надо больше времени, вы можете разбить задачи на больший срок и дополнить план своими задачами.

Цель

От релиза к релизу надо возвращаться к своей цели и сверять координаты. Насколько вы продвинулись? Вы стали лучше за это время?

Цели только в цифрах — плохая мотивация.

Концентрация на цифрах очень сильно дает по нервам, увеличивается тревожность. Вы занимаетесь музыкой, чтобы получать кайф от того, что вы делаете. Цифры — побочный эффект.

Не останавливайтесь

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

Правило 15-ти секунд

Чаще получается так:

Сделали трек — потом думаем какую часть взять для сниппета, а какую для промо-видео.

Но, что если вы в этот раз сделаете чуть по-другому? Если вы заранее подумаете про правило 15-ти секунд? Какие 15 секунд, вы сможете прикрепить к видеоряду? Какие 15 секунд будут двигать ваш трек в таргете, TikTok, Reels, Shorts?

А если таких частей несколько – это невообразимая роскошь!

Пойти от обратного

Что если вы начнете писать свою музыку опираясь на плейлисты и чарты в которые хотите попасть?

Только не бросайте тапком в экран. Я могу понять, что это звучит ужасно. Но послушайте, ведь не обязательно смотреть на топ «Русский поп», «Русский хип-хоп» и тд. Есть еще куча других клевых, может чуть менее популярных плейлистов. Опирайтесь на свое направление и тестмейкеров вашей ниши.

Обложка альбома

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

Видео

Видео без преувеличения самая важная составляющая эффективной рекламной кампании.

Конечно можно использовать фрагменты из готового клипа. Но! Требования к рекламному ролику:

— длительность 15 секунд
— первые 3 секунды работают на захват внимания
— формат 9:16 (вертикальное) или 1:1 (квадрат)

Найти кусочки клипа, чтобы они хорошо смотрелись в вертикальном формате, да еще чтобы фрагмент совпал с нужными 15-ю секундами трека, а первые 3 секунды захватывали внимание – очень тяжело!

Подумайте о рекламном ролике заранее.

Типы видео-контента

— Музыкальное видео (клип)
— Behind the scenes (бэкстейдж, история создания)
— Live-видео (запись выступления)
— Кавер-видео (короткое или полная версия)
— Lyric-видео ( видеоряд с текстом)
— Короткое видео (TikTok, Reels, Shorts)
— Анимационное видео
— Визуализатор
— Сниппет (15-30 секунд)
— Видео-приглашение
— Canvas (верт. видео для Spotify)

Не ограничивайте себя.

Такие современные артисты как Lil Nas X создают уникальные видео-экспириенсы, которые раскрывают идею, или юмор еще глубже.

На один клип выпущено 4 видео.

(Статья была написана до MTV VMA 2021)

Фото

Рекомендую поучиться у фотографов самым удачным ракурсам, а также поставить себе на телефон Lightroom для быстрой и качественной обработки фото.

2 в 1

Если вы снимаете клип, хорошо бы совместить съемки с фотосессией и сделать классные снимки. Используйте площадку по максимуму, постарайтесь организовать фотосъемку прямо на месте.

Режим «супер-эконом»?

Камера телефона при хорошем свете прекрасно справится с задачей.

План релиза

Частью планирования релиза является определение, какой объем работы можно выполнить и к какой дате. В одних случаях мы начинаем с даты и смотрим, какой объем работы можно завершить. В других случаях мы начинаем с набора пользовательских историй и смотрим, сколько времени потребуется для их реализации. В обоих случаях, как только команда получает первоначальный ответ, он оценивается относительно целей организации в проекте: принесет ли разработанный продукт желаемое количество денег? Поможет ли он сэкономить достаточно денег? Позволит ли продукт получить целевую долю рынка? Если нет, то, может быть, более продолжительный или короткий проект позволит достичь приемлемой комбинации целей.

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

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

Конечно, если ваш проект, организация и условия работы требуют этого, вы можете включить в план релиза дополнительную информацию. Например, вы можете изложить ключевые допущения, лежащие в основе плана. Прежде всего это касается допущений в отношении того, кто войдет в состав команды, какой будет продолжительность итерации, даты начала первой итерации и даты завершения последней итерации. В главе 21 «Информирование о плане» приводится дополнительная полезная информация, которую можно использовать при доведении плана релиза до окружающих.

Основные этапы планирования релиза показаны на рис. 13.1. Каждый из этих этапов описывается в следующих разделах.

 vlada_maestro / shutterstock

Пишет про управление в Skillbox Media. Работала координатором проектов в Русском музее, писала для блога агентства CRM-маркетинга Out of Cloud.

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

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

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

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

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

Чтобы проверить даже мелкие расхождения, такие как размеры элементов и отступы, тестировщики накладывают макет на готовую верстку прямо в браузере с помощью специальных плагинов, например, PerfectPixel.

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

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

Проверяйте код по плану, который готовили заранее. Если работаете короткими итерациями, — после каждой из них, если спринтами, — после каждого спринта.

---

Чем раньше вы найдете баг в коде, тем дешевле и проще будет его исправить.

---

Если у вас маленький проект, можно проводить тестирование дважды — когда будет готова вёрстка и потом проект целиком — либо вообще один раз, в финале разработки.

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

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

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

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

Но один из параметров, прямо влияющий на доступность сайта пользователям, можно измерить просто. Речь идёт о скорости загрузки — как быстро загружаются ваши страницы у пользователя в браузере. Скорость загрузки сайта можно проверить автоматически, например, с помощью PageSpeed Insights от Google.

Ещё на этом этапе сайт проверяется на различные уязвимости. Для этого также есть разные сервисы, например, Metascan, которые делают это автоматически.

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

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

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

Научитесь: Excel + Google Таблицы с нуля до PRO
Узнать больше