что такое ранний релиз
Ранний релиз или выдержанный?
Все эти программы имеют одну особенность — относительно длинный и непредсказуемый цикл разработки и релиза. Между тем все более популярным становится предсказуемый и относительно короткий цикл релиза, строго по графику. Какая стратегия разработки более выигрышная и каковы условия добиться перехода на оптимальную стратегию? Об этом мы поговорим в данной статье.
Релизы почаще, да пораньше
Меня потрясло, что этот базарный стиль работает и работает хорошо. Я не только участвовал в разработке индивидуальных проектов, но также пытался понять, почему в мире Linux’a не только не возникает беспорядка, но напротив он движется вперед со скоростью, которой строители собора могут только позавидовать.
Эта философия отлично характеризует разработку самого ядра Linux, однако многие проекты с открытым кодом не вполне оценили ее по достоинству и придерживаются стратегии ad-hoc релизов. Так мы будем называть стратегию развития проекта, при которой новую версию выкатывают по готовности, когда определенный набор фич воплощен в коде и стабилизирован.
Этот подход обладает существенными недостатками, часто ad-hoc становится долгостроем, как первая стабильная версия Mplayer-a.
Популярная платформа для верстки Scribus недавно выпустила версию 1.4.6, в то время как 1.4.0. вышла еще в самом начале 2012-го. Когда выйдет 1.5.0 вообще неизвестно. Почтовик mutt — основной рабочий инструмент мейнтейнера стабильной ветки Linux ядра GKH, пробыл в версии 1.5.X сколько другие за особо тяжкие получают. И даже gzip протянул 13 лет, с 1993 по 2006, между версиями 1.2.X и 1.3.X.
В то же время более крупные проекты давно уже перешли на временной график, и как правило, интервал между релизами не превышает полгода. Вот список некоторых крупных проектов, временные интервалы и время выбора новой стратегии развития проекта.
Дебиан стоит особняком и является некоторым гибридным сочетанием двух стратегий. Как видим, дебиановцы таки-придерживаются графика, но цикл разработки слишком долгий, для того, чтобы воспользоваться преимуществами стратегии с предсказуемым циклом производства. Довольно часто сроки выпуска новой версии откладываются.
Рассмотрим теперь причины долгостроя приверженцев ad-hoc стратегии, преимущества предсказуемого короткого цикла производства и возможность поменять первое на второе.
Дисциплина имеет значение
Когда команда ждет включения в код и стабилизации определенного набора фич, для того чтобы выпустить новую версию, чаще всего происходит следующее. В какой-то момент они осознают, что добавить все желаемые нововведения не получится, так как многие энтузиасты проекта работают недавно и раньше не сталкивались с новыми концепциями. Тогда волевым усилием объявляют предполагаемую дату релиза, которая для всех становится шоком. Далее следует шквал патчей и суета-сует, ведь многие релиза уже лет дцать как не видели и не знают, как это делается.
То ли дело GitLab, разработчики выкатывают новую версию каждый месяц 22-го числа — как швейцарские часы. По словам основателя и руководителя проекта Дмитрия Запорожца, не надо ждать, пока все будет идеально.
At GitLab we believe you shouldn’t wait for something to be perfect: Release what you have and do it on a schedule
Особенно благоприятно переход с ad-hoc стратегии на график повлиял на GNOME. Тут бы следовало добавить фотожабу, то есть Gimp-обработку, картины Васи Ложкина «Жизнь с бородой», но к сожалению, не могу красиво написать нужные слова аркой.
Невероятно масштабный и сложный комплекс проектов с открытым кодом OpenStack имеет полугодовой цикл выпуска, однако изначально новые версии выпускались каждые три месяца.
Давайте посмотрим вкратце, что такое OpenStack в цифрах.
Представим себе на минуточку, как мог бы развиваться данный проект, полагаясь на длинный цикл разработки и релиза. Что если бы, выход очередной версии происходил по мере готовности набора новых фич, вместо того, чтобы придерживаться предсказуемых и четких графиков времени? Думаю, в таком случае участники элементарно не смогли бы ни о чем договориться, и проект бы заглох на ранней стадии.
Qui bono?
Означает ли все вышесказанное, что для всех проектов без исключения переход со стратегии ad-hoc релизов на предсказуемый график является благом?
Точно так же, нет причин перехода с ad-hoc релизов на предсказуемые, если коммитов было всего ничего. Должна накопиться критическая масса изменений.
Нет никакой линейной зависимости между упомянутыми двумя стратегиями и качеством кода, что было показано на примере FireFox. Согласно проведенному исследованию, до и после перехода на предсказуемый короткий цикл производства количество багов после выхода стабильной версии было практически одинаково.
Резюмируя все вышесказанное. График предпочтительнее чем ad-hoc в тех случаях когда:
Управлять релизом просто: правила и этапы release management
Релиз является одним из самых важных и ожидаемых событий в жизненном цикле продукта. Приготовления к релизу могут занимать много усилий и времени, участия всей команды и заинтересованных сторон. Хорошо, если выпуск продукта или его версии проходит гладко и становится настоящим праздником. Но бывает иначе. Что из себя представляет эффективный релиз-менеджмент и как менеджерам продукта научиться его секретам?
Релиз связан с запуском нового продукта/сервиса/услуги или набором новых функций, изменений, которые становятся доступны клиентам или пользователям и обеспечивают новую продуктовую ценность.
Часто релиз состоит из ряда решений по устранению проблем и улучшений предоставляемых услуг, может включать изменения в ПО. На самом деле, это довольно значимое событие как для внутренних команд, так и для целевой аудитории.
Управление релизами помогает командам планировать свою работу и видеть конечный результат, а для клиентов это, своего рода, гарантия качества и получения новой ценности.
Хорошо подготовленный релиз — это не только предоставление доступа к новым техническим возможностям продукта. Это конечная дата, когда ваша команда может предоставить новый пользовательский опыт, поддержать и развить взаимодействие с ним.
Релизы должны включать все дополнительные задачи и активности, такие, например, как обновления на официальном сайте и в социальных сетях, обучение команды поддержки, обновление всех маркетинговых материалов и т. д.
Основная цель управления релизом — создавать, тестировать и доставлять новые возможности, которые будут удовлетворять все продуктовые требования и намеченные цели.
Продуктовым командам стоит тщательно планировать релизы, поскольку они являются новым предложением, которое ожидают клиенты.
Что включает процесс управления релизом?
Понимание процесса управления выпуском продукта может отличаться у разработчиков и нетехнических специалистов. Важно учитывать все аспекты релиза и прислушиваться к мнению каждого члена команды.
Процесс управления релизом может включать следующие этапы:
В управлении релизом продукта могут участвовать практически все члены команды.
Product manager и Project Manager
Менеджеры продуктов и менеджеры проектов несут основную ответственность за релиз. Функционал product manager project и manager отличается, но миссия у них одна — выпустить продукт и представить его клиентам в идеальном виде.
Разбработчики
Команда разработки — это ключевые игроки в управлении релизом, поскольку они участвуют в большинстве процессов в жизненном цикле продукта. Они оценивают изначальные затраты и время, определяют основные требования, создают документацию и разрабатывают функциональность. Они принимают главные решения о том, что можно сделать и что не нужно, а также сколько времени это займет.
Маркетинг
Маркетологи всегда должны “держать руку на пульсе” и быть в курсе того, чем живут конкуренты. В управлении релизом им важно тесно отрудничать с sales-менеджерами для получения новых и удержания существующих клиентов.
Тестировщики
Тестировщики работают вместе с разработчиками. Их задача — тестировать результаты исследований и разработки, основываясь на установленных критериях. Продукт не придет к релизу, пока не будут учтены все замечания и критерии прохождения тестирований.
Служба поддержки
Support-команда или отдельный специалист поддержки первыми получают сообщения, елси что-то пошло не так. Они должны понимать и знать все о релизе и должны быть должным образом подготовлены на всех уровнях еще на стадии планирования.
Помимо этих основных ролей, к управлению релизом могут привлекаться и другие специалисты: отдела закупок, финансисты, sales, биллинг, system engineering и др.
Почему нужно внедрять процесса управления релизам?
Что такое Release Notes в процессе управления релизом?
Release Notes — это примечания к версии продукта, в которых описываются изменения между выпускаемой и предыдущей версиями этого продукта. Такой документ может составляться для пользователей и для внутренних команд: тестировщиков, маркетологов, службы поддержки.
Когда используются примечания к релизу?
Примечания к релизу распространяются вместе с продуктами. Иногда — когда продукты все еще находятся в разработке или тестировании. Документ может быть доставлен клиентам при выпуске обновления (для продуктов, которые уже были использованы клиентами).
Вы можете найти различные варианты написания Release Notes, поскольку для этого документа нет единого стандарта или формата. В разных компаниях менеджеры продуктов, тестировщики и разработчики, которые обычно ответственны за написание примечаний, обычно используют свои собственные шаблоны.
Вот как выглядит страница с примечаниями к релизу у Firefox:
Как писать примечания к релизу?
Содержание документа зависит от типа релиза. Вот пример основных пунктов:
Заключение
Управление релизом во многих компаниях становится отдельным самостоятельным процессом, который сообщает заказчику дату выпуска продукта и основные этапы его развития. Заказчик участвует в приоритизации и вовлечен в определение содержания релиза.
Процесс позволяет менеджерам продуктов и команде своевременно оценить загрузку и управлять объемом работ, доставлять изменения в срок. Управление релизами позволяет собирать собственную статистику, с которой удобнее в дальнейшем обосновывать запросы на дополнительные ресурсы.
Если вы хотите детальнее разобраться в теме release management и отыскать интересные инсайты разных компаний, следующие книги будут полезными: (на английском языке)
Всë, что вам нужно знать об управлении релизами
В постоянно меняющемся, эволюционирующем мире приложений отдавать полусырые релизы пользователям — не вариант. Именно здесь на первый план выходит управление релизом. Данный материал от одного из менеджеров компании Hike, рассказывает о трейн-релизах и о стратегии ветвления, вводя в курс дела тех, кто хочет расширить свою зону компетенции и получить представление об управлении проектом.
Что это такое управление релизом?
Управление релизами охватывает все этапы выпуска программного обеспечения, от разработки и тестирования до развертывания. Управление релизом требуется каждый раз, когда запрашивается новый продукт, или даже изменения в продукт существующий. Есть пять основных шагов по управления релизом, которые мы делаем в этой ситуации:
Планирование релиза
Этап планирования в большинстве случаев интенсивен, так как именно на этом этапе весь наш релиз организуется от начала до конца. Надёжный план релиза помогает придерживаться верного пути и обеспечивать надлежащее соблюдение стандартов и требований.
При планировании релизов мы считаем, что разработанные несколькими командами приложения нуждаются в согласованном подходе, который должен быть выпущен заранее. Именно здесь в игру вступает концепция «трейн-релиза». Следуя подходу трейн-релиза, команды могут планировать изменения на основе релизов и отправлять их в Play Store.
Самым первым шагом, ещё до того, как мы начнём реализовывать трейн-релиз, является определение временных интервалов каждого этапа. В нашем случае этап разработки — это две недели. Затем нужно определить, сколько времени вы хотите потратить на интеграционное тестирование и этапы развёртывания. Ниже наш пример интервалов:
Следующий шаг на пути к релизам — создание рабочего процесса, к которому на протяжении всего релиза могут обращаться как наши команды, так и ключевые заинтересованные стороны.
Рабочий процесс сразу объясняет, как устроен весь релиз и какую роль играет каждый член команды. Мы используем инструмент «Асана» для отображения этих деталей, перечисленных ниже:
Как только план утверждается и окончательно оформляется, начинается самое интересное!
Важные аспекты планирования релизов
Создание и использование трейн-релиза звучит здорово, но поддерживать процесс в рабочем состоянии во время планирования трейн-релиза может быть непростым. Вот некоторые детали этого процесса:
Построение релиза
После того как план выпуска готов, можно приступать к тестированию продукта для релиза. Это будет фактическое «тестирование уровня пользователя» продукта на основе изложенных в плане выпуска требований.
В определённый день и время (скажем, в понедельник, в 15:00) происходит замораживание/отсечение кода. До этого момента команды успевают посмотреть, протестировать и смержить фичи в ветку разработки, которая должна быть частью трейн-релиза. В 15:00 релиз-менеджер создаст из ветки разработки ветку релиза. Этот шаг автоматизирован с помощью Jenkins.
Автоматизируя переход ветки, мы проверяем все пороговые значения производительности, бенчмарк и автоматизации из предыдущих релизов в маркет устанавливаются на текущий как основание сравнения, а трейн-релиз блокируется от дальнейших изменений.
Как только код замораживается, начинается новый цикл разработки, и все участвующие команды начинают новый спринт и продолжают разработку. Самое замечательное в трейн-релизе: все знают о следующем, запланированном релизе, и это помогает людям соответствующим образом планировать свою работу.
Релиз веток и контроль версий
Разработка продукта обычно не останавливается, когда заканчивается разработка для релиза, поэтому первое, о чем мы думаем, это как заморозить тестируемую сборку и в то же время поработать над новыми возможностями для следующего релиза. Что случится, если в сборке релизов появится ошибка? Как исправить ошибку, если вы уже добавили кучу новых вещей до того, как эта ошибка нашлась?
Именно здесь на помощь приходит хитрая стратегия ветвления, в которой есть концепция разветвления. Как следует из названия, ветвление кода означает, что точно так же, как у веток дерева, код веток до определенной точки совпадает, а затем разбивается на две копии.
Каждая ветвь может развиваться независимо от другой. В этом случае одна копия — ветка релиза — остаётся замороженной на том месте, где вы завершили разработку. Это то, что мы называем отсечённой веткой. Другая ветка (ветка разработки) может быть изменена новым кодом и исправлениями ошибок, не затрагивая ветку релиза вообще. Если ошибка найдена в релиз-кандидате, исправление может быть разработано и добавлено в ветку релиза. Таким образом, следующая сборка, которую вы снова соберёте из ветки выпуска, может быть идентична первой, за исключением исправления одной ошибки. Таким образом, вы можете минимизировать риск появления новых ошибок в выпуске и изолировать баги от нового кода. Исправление также применяется к ветке разработки, чтобы гарантировать, что та же самая ошибка не попадёт в следующий релиз. Другое преимущество релиз-ветвления состоит в том, что как только вы действительно публикуете код, у вас есть «замороженная» ветка, которая представляет собой точную копию опубликованной кодовой базы. Вы можете вернуться к этому коду в любое время для справки.
Пользовательское приемочное тестирование
Пользовательское приемочное тестирование является наиболее важным шагом для управления релизом из-за объема собранных данных и исправлений, необходимых для того, чтобы сделать сборку именно такой, какой она должна быть для официального запуска.
Как следует из названия, когда речь идёт об этом виде тестирования, ключевая фигура — пользователь. Пользователи — это именно те люди, которые будут пользоваться приложением. Поэтому крайне важно сделать пользователей частью всей стратегии обеспечения качества в процессе разработки программного обеспечения. Вот где пригодится UAT. Этот тип тестирования, как никакой другой, ставит потребности пользователей в центр работы над продуктом. Вот некоторые из вопросов, на которые такое тестирование пытается ответить:
Pro Tip: всегда включайте внутреннее тестирование в планирование UAT!
Одним из способов ускорить UAT релиза для нас было использование внутренних тестовых треков, предоставляемых Google. Это помогает нам быстрее распространять тикеты среди коллег и фиксировать их отзывы посредством автоматического создания тикетов JIRA. Перед отправкой финального теста команда также следит за тем, чтобы отзывы были учтены.
Подготовка и релиз
Этот шаг заключается в том, чтобы внести последние штрихи в продукт, учитывая все, что было понято при UAT. Подготовка релиза также включает в себя заключительную проверку качества командой по контролю качества. В ходе проверки группа по контролю качества проводит окончательные проверки, чтобы убедиться, что сборка соответствует минимальным стандартам приемки и бизнес-требованиям из плана релиза.
После завершения ревью релиз-группа завершит релиз для начала развертывания. Перед тем, как сборка может быть развернуто в живой среде, она должно быть утверждена соответствующими ответственными командами, такими как команда дизайна. UAT гарантирует, что результат утверждается до передачи на следующий этап.
Развертывание релиза
Наконец-то настал важный день, когда окупилась вся тяжелая работа нашей команды. Пришло время выпустить наш продукт в дикую природу продакшна. Помимо простой отправки сборки в производственную среду, стадия внедрения также содержит обучение работе с продуктом как конечного пользователя, так и компании в целом. Например, пользователи должны быть уведомлены об изменениях в релизе, и именно здесь на появляется в поле зрения «What’s New» (Что нового). У нас есть автоматизированный процесс на Jenkins, содержащий такие шаги:
В данном случае мы начинаем с развертывания для 1%. На каждом этапе необходимо следить за ревью, а также за инструментами мониторинга падений релиза, чтобы выявить возможные проблемы.
Если ошибка становится заметной в 1%, у команды есть шанс отреагировать на проблему и решить, нужно ли исправлять ее быстро. Если это так, то трейн-релиз не должен достигнуть следующего шага развертывания в 5%. Вместо этого проблема решается для 1% пользователей. Как только проблема устраняется и решение проверено, трейн-релиз может перейти на стадию 5%.
Как и в простой версии трейн-релиза, только релиз-инженер или команда релиза заботится о процессе релиза после замораживания кода. Все остальные команды продолжают «нормальную» разработку.
Анализ после релиза
Работа по управлению релизом не заканчивается, когда публикуется код, продолжаясь до тех пор, пока вы не будете готовы выпустить релиз снова. Если вы хотите, чтобы ваше приложение было успешным, ему нужно хорошее ревью, вам также нужно следить за релизом в производственной среде, чтобы исправлять ошибки, внедрять функции, которые нужны людям, и решать проблемы пользователей. Для этого мы используем Firebase Crashlytics, где отслеживаем любые сбои, требующие немедленного исправления.
Кроме того, ревью приложения дают представление о вашем продукте, которое гораздо труднее получить при других подходах. И Google Play, и App Store предоставляют разработчикам приложений возможность отвечать на отзывы, что может быть невероятно полезным инструментом для получения дополнительной информации о проблемах с приложением от пользователей. Отзывы могут выявить проблемы, с которыми сталкиваются пользователи при работе с вашим приложением, и проинформировать о будущих изменениях.
Подведем итоги
Управление релизами наблюдает за чрезвычайно динамичным процессом. Каждый релиз — это возможность уточнить всё — от нашего рабочего процесса до нашего контрольного списка, поскольку мы вместе с ним обнаруживаем области улучшения. Вот некоторые преимущества, которые мы получили:
Мы также увидели, что наш процесс управления релизами облегчил сотрудникам по всем направлениям — от разработчиков и владельцев продуктов до руководителей — просмотр плана высокого уровня и получение краткой информации о своём прогрессе, работа синхронизирована.
Зачем игры выпускают в раннем доступе?
Разбираемся, как разработчики вместе с игроками доводят игры от раннего доступа до релиза.
Какие преимущества у релиза в раннем доступе? Казалось бы, выпуская ещё не готовый проект, можно распугать аудиторию недоделанными фичами и багами. И тем не менее игры в раннем доступе — одна из самых популярных позиций на площадках цифровой дистрибуции, особенно на ПК. Разобраться, как так вышло, нам помогли геймдизайнер Wargaming Дарья Моргунова и Леонид Горбачёв, глава студии Moon Moose.
Какие игры выпускают в раннем доступе?
Формат раннего доступа популярен у инди-студий: для независимых разработчиков это возможность заявить о себе. Например, основанная на физике головоломка-конструктор Besiege вышла в раннем доступе Steam в 2015 году. Полноценный релиз состоялся в 2020 году, сейчас у Besiege 95% положительных обзоров.
Broforce — двухмерный платформер про отряд коммандос, борющихся с террористами. Концепция приключений Бро, пародирующих героев боевиков, ураганный геймплей и атмосфера боевиков 1980-х годов зародились на геймджеме Ludum Dare 23. Студия Free Lives Games выиграла в категории Fun. До релиза игра находилась в раннем доступе полтора года.
«Для небольших инди-команд очевидное преимущество раннего доступа — бесплатное тестирование. Кроме того, с его помощью студии проверяют гипотезы и баланс. Если игра на очень ранней стадии имеет хоть какие-то весёлые и понятные для игрока элементы, то есть возможность протестировать все свои механики и понять, какие заходят лучше. Однако если вы выложили наполовину доделанный кор-геймплей, в котором основные активности работают со скрипом, такой эксперимент будет бесполезен».
Дарья Моргунова,
геймдизайнер Wargaming
Другой пример — подводный симулятор выживания Subnautica. Инди-студия Unknown Worlds Entertainment выпустила свой проект в ранний доступ в 2014 году, а релиз состоялся в январе 2018 года. Игроки, впрочем, до сих пор могут отправить разработчикам отчёт об ошибке в Subnautica, будто игра и по сей день находится в стадии активной разработки.
Игра Unknown Worlds победила в номинации «Компьютерная игра года» премии Golden Joystick Awards 2018. Разработчики Subnautica продолжают придерживаться подобной стратегии: так, недавно они выпустили продолжение, Below Zero, которое тоже вышло в раннем доступе.
«Если игра делится на главы, уровни и какие-то совершенно отдельные игровые единицы, ранний доступ может быть наиболее удачным форматом релиза. Вы получаете деньги, фидбэк и новые возможности после каждого завершённого этапа. А вместе с этим потихоньку совершенствуете предыдущие, чтобы в итоге добраться до полноценного релиза».
Дарья Моргунова,
геймдизайнер Wargaming
К формату раннего доступа прибегают не только инди-студии. Например, Crytek выпустила таким образом Hunt: Showdown. Игрок там переносится в Луизиану конца XIX века, где вместе с другими игроками охотится на чудовищ. Жанр сессионной мультиплеерной игры тоже подходит для запуска в раннем доступе.
«Для новых тайтлов это способ быть увиденными и услышанными, известные IP так не делают именно по причине багов и недоделанных механик. Для игр с уникальными фичами ранний доступ — способ проверить свои идеи. Примут ли их игроки? Сама разработка превращается в шоу, интересный диалог с преданными фанатами. По сути, это альтернативный способ разработки со своими нюансами».
Леонид Горбачёв,
глава студии Moon Moose
Санкт-петербургская студия Moon Moose выпустила в раннем доступе Cartel Tycoon в марте 2021 года. Действие бизнес-симулятора с элементами выживания разворачивается в Латинской Америке 1980-х годов. Больше о процессе разработки этой игры вы можете узнать из нашего интервью с командой.
Game Gods — разработчики партийной RPG от первого лица Age of Silence — размышляют, будут ли делать ранний доступ. Игра разрабатывается уже около трёх лет, и студии понадобится примерно такой же срок до полноценного релиза.
«Мы готовим демо Age of Silence, которое выпустим в открытый доступ. Все, в том числе инвесторы, смогут сыграть, оценить. После этого выход беты или какой-то другой версии будет зависеть от финансирования. На этом этапе невозможно сказать, как будет лучше. Вероятно, что раннего доступа не будет, поскольку игра сложная, багов может быть много, а мы не хотим распугать аудиторию. Мы ненавидим баги. Может быть, потому наша разработка так растянута по времени. Печальны многочисленные кейсы, когда выходит проект, в котором изначально много багов. Ориентируемся на игры вроде Hitman — я люблю приводить этот пример, там мало багов на момент релиза».
Олег Кондрашов,
основатель студии Game Gods
Rust была запущена в раннем доступе в декабре 2013 года и сразу же стала хитом с миллионом проданных за два месяца копий. Глава студии Facepunch, Гарри Ньюмэн, в сообщении к релизу писал, что ранний доступ для каждого проекта отличается. Создатели Rust определились с точным направлением своей игры только после её изучения активной базой игроков. Например, во время запуска в Steam в ней были зомби. Получив первый фидбэк, разработчики их убрали.
«Для условно-бесплатных игр ранний доступ тоже может быть полезен. Фактически закрытый бета-тест и софт-лонч — формы раннего доступа, где происходит то же самое — тестирование, проверка гипотез, монетизации, баланса».
Дарья Моргунова,
геймдизайнер Wargaming
Fortnite — пример удачной работы с ранним доступом. Команда регулярно выпускала подробные отчёты об исправленных ошибках и обновлениях. Одна из причин популярности игры Epic Games — постоянное общение с комьюнити.
Сценарист и копирайтер. Утверждает, что видел все фильмы и прошёл все игры, но редакция отказывается ему верить.
Обратная связь от игроков
В раннем доступе выходят не только инди-, но и ААА-проекты. Например, бельгийская студия Larian выпускает в раннем доступе все свои последние ролевые игры: две части Original Sin и Baldur’s Gate III.
«Я действительно люблю модель раннего доступа, хотя трудности, безусловно, есть. Опытное сообщество знает, что ему нужно, очень трудно изменить выбранный курс. Вы можете пообещать игрокам сделать фичу, а позже узнать, что она не работает. С другой стороны, стало проще собирать статистику и презентовать идеи. Мы показываем новую сборку и сразу же получаем фидбэк. Конечно, чтобы получить такую обратную связь, у вас должно быть огромное сообщество игроков».
Разработчики изучают свои форумы, RPG Codex, RPG Watch — там игроки описывают проблемы и баги, предлагая методы их решения. В Larian даже есть отдельный сотрудник, каждый день составляющий отчёты на базе отзывов со всех площадок.
Для Divinity: Original Sin бельгийская студия проводила кампании на Kickstarter. Для краудфандинга, как и для раннего доступа, важно, чтобы разработка была открытой и игроки регулярно получали обратную связь в виде дневников разработчиков.
«Для успешной разработки нужно активно поддерживать ранний доступ апдейтами и общаться с игроками, иначе потеряется и смысл, и аудитория. Многие игроки боятся раннего доступа, потому что некоторые команды забрасывают проект. Если студия открыта для общения, то ранний доступ будет довольно комфортным. К тому же он не равен багам, при удачном планировании можно и без серьёзных ошибок обойтись».
Леонид Горбачёв, глава студии Moon Moose
Недавний удачный пример — симулятор выживания Valheim. Команда всего из пяти человек сделала игру в раннем доступе практически без багов. Как говорили разработчики, шведская студия Iron Gate, сообщество сильно повлияло на развитие игры: авторы изменили и доработали большинство функций на основе отзывов.
«Ранний доступ помогает сформировать комьюнити. Игроки чувствуют свою значимость, если их советы помогли проекту развиться. Они склонны оставаться в такой игре дольше и прощать ей многие косяки. Более того, люди, которым понравилась игра в раннем доступе, могут стать ядром будущего комьюнити для уже полностью доделанной игры».
Дарья Моргунова, геймдизайнер Wargaming
Прежде, до сегодняшней формулы открытого раннего доступа, игроки нередко могли выиграть или купить доступ к бета-версиям некоторых игр. Например, приглашение в бета-версию многопользовательской части Halo 3 было включено в комплект игры Crackdown. Считается, что именно из-за этого у последней высокие продажи.
«Ранний доступ помогает некоторым играм обрасти „легендами“ о вседозволенности, бесконечных ресурсах или особых пасхалках. Это что-то вроде эксклюзивного и ограниченного по времени клуба для ценителей. Однако, чтобы такие легенды были полезны как маркетинговый инструмент, игра всё-таки должна пройти через полноценный релиз и стать популярной».
Дарья Моргунова, геймдизайнер Wargaming
Чешская студия Bohemia Interactive часто применяет модель раннего доступа — так, её ArmA 3 входила в список первых игр Steam Early Access. Игра, которая началась как модификация ко второй ArmA — DayZ, пять лет провела в раннем доступе. У игры фактически нет сюжета, игроки сами придумывали истории, когда находили в окружении подсказки и намёки от разработчиков. Последний релиз Bohemia Interactive — постапокалиптический условно-бесплатный экшен Vigor — также вышел в раннем доступе.
Советы по раннему доступу от Steam
Представители Steam разместили список советов и рекомендаций для разработчиков, планирующих выпуск игры в раннем доступе. Например, необходимо учитывать, что подобная форма релиза — не платформа для краудфандинга. Разработчики не могут использовать ранний доступ исключительно для финансирования проекта.
Другие формы инвестиций можно искать на площадках для краудфандинга, как сделали уже упомянутые Larian или, скажем, создатели Wasteland 2: половина финансирования постапокалиптической RPG была собрана с помощью Kickstarter.
Valve советует для запуска игры в магазине убедиться в её готовности. До раннего доступа можно давать ключи избранным игрокам и собирать небольшую фокусную группу. Выпущенная в магазине версия должна быть играбельна, у разработчиков должен быть трейлер с геймплеем. Лучше не делать ставку на будущее проекта, ведь пользователи покупают игру, исходя из её текущего состояния.
Ранний доступ — этап разработки, на котором игроки могут повлиять на окончательную версию проекта. Если игровой процесс уже определён, то лишь для финального тестирования и поиска багов ранний доступ не подходит. По мнению Valve, его основная цель — это возможность «заглянуть за кулисы» и оценить процесс разработки игры на разных этапах.