Как запускать сервисы эффективно: три стадии запуска на примере Cloud.ru Evolution

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

Иными словами: 

• сперва у внешних или внутренних пользователей рождается идея;

• затем эта идея согласуется с командой и добавляется в бэклог разработки; 

• в финале реализованная в виде готового сервиса идея попадает в прод.

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

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

• private preview (закрытое превью);

• public preview (открытое превью); 

• general availability (общая доступность). 

Что это дает? Значительное сокращение time to market и повышение уровня клиентского сервиса за счет своевременной обработки обратной связи от непосредственных пользователей сервисов. 

По какому принципу мы делим продуктовый процесс на стадии и в какой момент сервис переходит из одной стадии в другую? Продемонстрирую ключевые параметры в соответствии с каждым из трех этапов запуска в таблице: 

А теперь давайте подробнее поговорим про указанные параметры.

Доступность продукта, число участников и уровень функциональности

На стадии private preview у клиентов и партнеров нет доступа к сервисам в разработке. Их не увидеть в личном кабинете (ЛК) Cloud.ru, а возможность тестирования наши менеджеры предлагают лишь малой группе клиентов. Функциональность сервисов на этом этапе ограничена, а первая обратная связь помогает оценить реакцию будущих пользователей и утвердить основные сценарии использования. 

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

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

Продуктовые метрики, документация и мониторинг доступности

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

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

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

Мы оказываем поддержку пользователям на всех этапах, но только на финальной стадии general availability гарантируем выполнение Service Level Agreement (SLA) — соглашения об уровне обслуживания. А на стадиях preview помогаем нашим клиентам так: 

• По продуктам в private preview все обращения поступают к нам по стандартной схеме: сначала проходят через первую (L1) и вторую (L2) линию поддержки, а после попадают в руки коллег из продуктовой команды. На этой стадии только они и могут ответить на вопросы по новому сервису. 

• А на стадии public preview у поддержки уже есть некоторый багаж знаний, который помогает отвечать на вопросы пользователей. Однако команда поддержки все еще нередко обращается за консультацией к продуктовой команде. 

Думаю, вы уже уловили логику, но на всякий случай повторюсь: 

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

• В public preview начинается активная работа с клиентской базой — в это время мы активно рассказываем о преимуществах сервиса и возможных сценариях его использования. 

• А на финальной стадии general availability наша цель — предоставить максимально полезный и удобный сервис и получить за него деньги. 

Разделение продуктового процесса на стадии — не инновация. Такие компании, как Google, Microsoft, Spotify, уже давно используют такой подход в разработке. Но для нашей компании — это новшество, а потому я поделюсь теми преимуществами, которые мы наблюдаем от его внедрения в Cloud.ru. 

Минимизация рисков и качество планирования

При выпуске продуктов никто не застрахован от рисков: возможно, просрочился SLA или стали очевидны какие-то недоработки. Однако на стадии preview все это не так критично. Более того, в этот момент мы приветствуем активный поиск «огрехов» пользователями и за счет этого получаем возможность понять, что нужно доделать. 

А еще в preview мы планируем рекламные кампании, составляем программы обучения и создаем много другого полезного контента, который поможет сервису уверенно запуститься и быстро взлететь сразу после перехода в general availability. Проще говоря, планирование — наше все, а с новым подходом планировать удается более прицельно. 

Сокращение time to market

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

Такими механизмами как раз и выступают стадии private preview, public preview и general availability. Ведь в public preview уже можно прикинуть, какой будет маркетинговая стратегия для нового сервиса: мы заранее начинаем готовить для него страницу на сайте, баннеры и другие полезные материалы. А потому к моменту запуска в прод все уже готово. 

Понимание задач клиентов 

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

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

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

Улучшение клиентского сервиса (customer engagement)

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

Речь про подход, который подразумевает отслеживание того, в каких именно продуктах заинтересованы клиенты. Ведь некоторые из них используют только платформу данных, а другие — интересуются лишь serverless-вычислениями. В такой ситуации важно каждому предложить то, что нужно, а еще использовать для этого максимально удобные каналы: «дотянуться» через сейла или партнерскую структуру, наладить коммуникацию с продуктовой командой. 

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

Рост прозрачности процессов 

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

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

От создания до продажи: простая передача продукта из change в run

Во многих компаниях-разработчиках задачи для change- и run-команд делятся так: команды change создают продукт и вносят в него изменения и улучшения при необходимости, а run — продвигают его на рынке. У нас все несколько иначе. 

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

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

Чек-лист позволяет: 

• выяснить, на какой стадии разработки находится сервис;

• провести отлаженную проверку сервиса перед запуском — учесть задачи, которые осталось выполнить, а также всех участников процесса и ответственных. 

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

• проверить, что название нового сервиса соответствует правилам нейминга и Tone of Voice нашей компании — это важно для выстраивания корректной коммуникации с клиентами в дальнейшем; 

• убедиться, что шильдик preview есть у продукта и в личном кабинете, и на сайте; 

• удостовериться, что новый сервис представлен и в ЛК и на сайте; 

• увериться, что центр кибербезопасности (ЦКЗ) дал «добро» на размещение сервиса;

• и многое другое. 

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

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

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

Сегодня каждый наш сервис в обязательном порядке проходит три стадии развития:

• Private preview (закрытое превью): тестирование ограниченного по функциональности сервиса небольшой группой наших сотрудников, а также целевыми и стратегическими клиентами. 

• Public preview (открытое превью): тестирование ограниченного по функциональности сервиса продукта всеми заинтересованными клиентам. 

• General availability (общая доступность): на этой стадии сервис доступен всем пользователям и может быть полноценно использован для решения задач. При этом он доступен на коммерческой основе и обеспечивает выполнение SLA.

При этом на каждой стадии разработки команда Cloud.ru внимательно собирает обратную связь, чтобы создавать такие сервисы, которые будут максимально полезны и удобны для наших пользователей. Например, сейчас вы можете принять участие в тестировании аналитического SQL-движка Evolution Managed Trino, сервиса для хранения метаданных Evolution Managed Metastore и управления брокерами сообщений в облаке Evolution Managed Kafka, а также управляемой базы данных Evolution Managed Redis. Пробуйте наши сервисы и оставляйте отзывы, а мы постараемся учесть ваши пожелания и разработать такие инструменты, которыми вы захотите пользоваться и в general availability.