---

Многие стартапы B2B SaaS запускаются в бета-версии, и на то есть веские причины. Это часть традиционного девиза Кремниевой долины “двигайся быстро и ломай вещи”.

Наклеивание ярлыка “бета” на продукт снижает ожидания.

Что-то сломано? Ну и что, это же просто бета.

Система медленная? Ну и что, это же просто бета.

Документация отсутствует? Ну и что… вы поняли суть.

И это на самом деле хорошо. Рид Хоффман, основатель LinkedIN, однажды сказал:

Если вам не стыдно за первую версию вашего продукта, вы запустили слишком поздно.

И ярлык бета также полезен для клиентов. Он помогает им самостоятельно выбрать.

Клиенты, которые пробуют бета-продукты, находятся на ранних стадиях Жизненного цикла принятия технологий, также известного как Кривая принятия продукта.

Жизненный цикл принятия технологий обычно делится на пять основных сегментов:

1. Инноваторы
2. Ранние последователи
3. Раннее большинство
4. Позднее большинство
5. Отстающие

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

Или хотят?

Вот это вопрос, который мы задали себе.

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

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

И поскольку они использовали Blue с первых дней, эта команда всегда использовала Blue Beta!

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

И именно поэтому у нас нет выделенной команды тестирования.

Верно.

Никто в Blue не несет единоличной ответственности за то, чтобы наша платформа работала хорошо и стабильно.

На это есть несколько причин.

Первая — это более низкая базовая стоимость.

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

Чтобы это проиллюстрировать, мы предлагаем наборы функций на уровне предприятия, за которые наша конкуренция берет $30-$55/пользователь/месяц всего за $7/месяц.

Это не происходит случайно, это по замыслу.

Однако это не хорошая стратегия продавать более дешевый продукт, если он не работает.

Так что реальный вопрос заключается в том, как нам удается создать стабильную платформу, которую могут использовать тысячи клиентов без выделенной команды тестирования?

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

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

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

И это распространяется на тестирование функции, понимание случаев использования и запросов клиентов, а также на чтение и комментирование спецификаций.

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

Хорошо, давайте теперь поговорим о нашем открытом бета-тестировании.

Когда мы говорим, что оно “открытое” — мы имеем в виду это. Любой клиент может попробовать его, просто добавив “beta” перед URL нашего веб-приложения.

Таким образом, “app.blue.cc” становится “beta.app.blue.cc”.

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

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

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

И вот в чем дело: у нас есть несколько сотен тестировщиков!

Все эти клиенты будут пробовать функции в своих рабочих процессах и будут довольно откровенны, если что-то не так, потому что они уже внедряют эту функцию в своем бизнесе!

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

Мы оставляем новые функции в бета-версии на срок от 2 до 4 недель. Когда мы чувствуем, что они стабильны, мы выпускаем их в производственную версию.

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

Результат?

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

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

Однако, как и любой выбор, есть некоторые компромиссы.

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

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

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

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