Стадии запуска облачных продуктов на примере Cloud.ru Evolution: что и зачем мы изменили в процессе
Теперь наши клиенты тестируют сервисы и влияют на их функциональность
Привет, я Никита Бутримов, лидер продуктового направления в Cloud.ru. Отвечаю за эксплуатацию и стабильную работу платформы и поддержку клиентов. Хочу поделиться опытом, как моя команда внедрила новые стадии запуска продукта: открытое превью, закрытое превью и общую доступность. Расскажу, как мы работали раньше, как пришли к новому процессу, зачем это было нужно и что мы получили на выходе. Процесс разберем на примере запуска новой облачной платформы Cloud.ru Evolution.
Как было до и что поменялось
В любой производственной компании есть процесс разработки нового продукта. Если смотреть верхнеуровнево, то у всех он построен плюс-минус одинаково. У облачных провайдеров процесс разработки выглядит примерно так: у внешних или внутренних пользователей появляются идеи, эти идеи проходят этап согласования и «выжившие» попадают в бэклог разработки. После команда разработки приносит уже готовый продукт или сервис, который затем оказывается в проде. Раньше у нас было так же.
По обновленному алгоритму мы как бы встраиваемся в разработку и дополняем ее новыми стадиями. При этом не нарушаем уже сложившийся продуктовый процесс и не мешаем другим командам.
Зачем нам это нужно? Теперь мы выпускаем продукты быстрее и получаем обратную связь от пользователей еще до того, как выпустим их на рынок в общий доступ.
Что внутри стадий превью и общей доступности
Что на практике означают эти стадии? Как определить, на какой из них находится продукт? Для удобства мы сделали таблицу и выделили конкретные атрибуты, характерные для каждой стадии.
Доступ к продукту, количество участников и функциональность
Продукты в закрытом превью не отображаются в личном кабинете, доступ к ним можно получить только по приглашению менеджера. Функциональность на этой стадии ограничена. Наша задача — собрать первую обратную связь, посмотреть на реакцию пользователей и валидировать их сценарии.
На стадии открытого превью тестировать продукты могут все: мы активно анонсируем запуск и зовем всех желающих. В личном кабинете рядом с продуктами в открытом превью отображается шильдик с надписью preview. Функциональность такая же, как в закрытом превью, или чуть шире. Главное отличие в том, что продукт теперь доступен неограниченному кругу пользователей.
Ну, и у продукта в общей доступности полный уровень функциональности, он в проде, и мы берем за него деньги.
Продуктовые метрики
Когда мы запускаем продукт, у нас всегда есть какие-то ожидания: сколько пользователей должно прийти, сколько пользователей мы сможем принять, что пользователи буду делать с продуктом и так далее. Это супер важная информация для дальнейшего развития, поэтому мы начинаем снимать метрики сразу на стадии открытого превью: емкость, число уникальных пользователей, нагрузка на продукты. И, конечно, продолжаем анализировать в общей доступности, только собираем уже немного другие метрики.
Мониторинг доступности — это обязательный атрибут, который есть на каждой стадии.
Документация
Наши технические писатели готовят документацию еще до выхода продукта в закрытое превью. Мы считаем так: если что-то не прописано в документации, то для пользователя этого просто нет. Кроме того, у нас все продукты комплементарны, они друг друга дополняют — инструкция о конкретном продукте просто не может находиться в вакууме.
Биллинг
На стадии закрытого и открытого превью мы не выставляем счет, но при этом видим, сколько пользователей и в каких масштабах используют продукт: все метрики потребления в личном кабинете оцифрованы, в контроле затрат всё прозрачно и понятно. Мы уже можем спрогнозировать, какое потребление продукта будет в будущем. А пользователи могут оценить, сколько продукт будет стоить для решения их задачи.
Поддержка
Техническая поддержка есть на всех стадиях, но работает по-разному. В закрытом превью поддержка сильно ограничена. Обращения стандартно проходят через первую и вторую линию поддержки и в итоге падают на продуктовую команду, потому что на этом этапе развития только продуктовая команда знает, что происходит с продуктом.
В превью поддержка учится помогать, особенно если продукт сложный или просто новый. Ей нужно время, чтобы изучит его и понять, как с ним правильно работать и какие бывают типовые вопросы. Получается, работа с клиентом тюнится в закрытом превью, чтобы в открытом превью уверенно отрабатывать любой вопрос.
Цель стадий
Тут всё просто. В закрытом превью мы собираем обратную связь и оцениваем, к чему готов или не готов продукт, какой аудитории и сегменту он лучше подходит. Мы понимаем, когда будем готовы вывести продукт и на какое число пользователей. Например, если продукт для сегмента малого и среднего бизнеса, то он должен выдерживать много-много пользователей, а к такому еще нужно хорошо подготовиться.
В открытом превью мы уже вывели продукт на рынок и громко об этом говорим. Мы работаем с нашей базой клиентов и усиливаем бренд, анонсируем, что еще скоро можно будет подключить.
Ну, а в общей доступности наша цель — предложить готовый классный продукт и получать за него деньги.
Почему мы пошли новым путем: преимущества
Как я говорил, такой подход — не новшество для рынка. Spotify, Google, Microsoft, например, давно так делают, только каждый по-разному у себя эти стадии называет. А теперь и мы так делаем.
Снижаем риски и четче планируем
Запуская продукт, мы принимаем риски, которые с этим запуском могут быть связаны. Например, если просрочили SLA или просто не успели доделать что-то до конца. Но поскольку мы в превью, то официально можем иметь какие-то недоработки. Нам пользователи могут и будут про них писать, а нам как раз это и нужно. Благодаря такой обратной связи мы понимаем, что нужно доделать в первую очередь и на что в целом обратить внимание при доработке продукта.
В превью мы можем планировать рекламные кампании, обучение и еще много полезного и нужного для клиентов, чтобы в общей доступности продукт уже летел, а не только выходил на взлетную полосу. Возможность четко планировать — важное преимущество стадий превью.
Ускоряем time to market
Многие говорят про ускорение time to market и многие про это наслышаны, но тут не всё так просто. Чтобы выпустить продукт, нужно соблюдать юридические обязательства, учитывать оферту и многое другое. Чтобы выпускать продукты раньше, нужны специальные механизмы.
Стадии закрытого превью, открытого превью и общей доступности — это мировая практика, которая юридически позволяет выпускать продукты и сервисы на рынок быстрее. Поэтому в открытом превью мы можем прикинуть, какая у нас будет стратегия маркетинга: начинаем готовить страницы для сайта, баннеры и многое другое. И поэтому на стадии общей доступности у нас уже будет всё готово.
Делаем продукты ближе к клиенту
Главная ценность подхода с этапами превью — клиент, ведь мы работаем для него. И продукт делаем тоже для него. Поэтому в закрытом и открытом превью мы его буквально сопровождаем.
Вот пример: в марте мы запустили стадию закрытого превью продуктов Data Platform (Trino, Metastore, ArenaData DB) и DBaaS (PostgreSQL, DocumentDB и Pangolin) на платформе Cloud.ru Evolution. На тестирование позвали немного клиентов и на всех этапах буквально вели их за руку: объясняли, как работает продукт, что и как настраивать, что уже функционирует, а что пока нет. А еще спрашивали, какой у них сценарий использования продукта и как они планируют его реализовывать.
Обычно в больших компаниях клиенту сложно пробиться к продукт оунеру. У нас наоборот, мы сами предлагаем пообщаться. Мы делаем так и с юридическими, и с физическими лицами — нам важна любая информация и любой фидбэк. Мы стараемся сделать продукт еще лучше для любого клиента.
Усиливаем взаимодействие с клиентами
Все клиенты разные: их можно делить по индустриям, сегментам, чекам и подобным критериям. Но тут немного про другое.
Есть такой подход, когда ты смотришь, какие конкретно продукты используют твои клиенты. Например, есть те, кто использует только платформу данных или вообще не используют виртуалки. Есть клиенты, которые используют только serverless, и так далее. С каждым из этих клиентов стоит по-разному взаимодействовать. Это разная аудитория, им интересны разные каналы. С ними нужно работать по-разному: где-то через сейла, где-то через партнерскую структуру, где-то напрямую с продуктовой командой. Потому что разные клиенты требуют разного.
Сопровождая клиента на стадиях превью, мы как раз понимаем, почему и зачем они используют именно эти продукты, а также видим,что им важнее и нужнее. Мы делаем разные выводы и на их основе улучшаем продукт или раньше выводим его в релиз. А в каких-то случаях можем решить, что вообще не будем выводить продукт.
Повышаем прозрачность процессов
В нашем случае речь про Jira — систему отслеживания ошибок, предназначенную для организации взаимодействия с пользователями, а также совместной работы и управления проектами. Мы используем оба сценария. А еще настроили для всех задач чек-лист, чтобы структурировать процесс, и выложили его в общий доступ внутри компании.
Понимаем критерии передачи из change в run
Во многих компаниях есть разделение на change- и run-команды. Первые создают продукт, допиливают его и регулярно докручивают, а вторые — продают. По сути, это продакты и продавцы. И нередко между этими командами случается недопонимание.
У нас всё работает немного иначе. В Cloud.ru тоже есть разделение на change и run, но при этом мы — одна команда: change разрабатывает продукт, а run принимает его в эксплуатацию и запускает в прод. Быстро принимать продукты важно для обеих сторон, а новые стадии как раз помогают делать всё вовремя. Именно для этого мы ввели чек-лист с атрибутами, о котором я рассказываю ниже.
А еще теперь удобно давать обратную связь. Например, команда change сделала продукт и передала его run-команде. И становится понятно, что продукт пока не готов к общей доступности, а только к закрытому превью. Как мы это понимаем? Благодаря чек-листу сразу видим, что пока нет нужных атрибутов, которые соответствуют стадии общей доступности.
Чек-лист для передачи продукта из change в run: как это работает
Чек-лист передачи продукта из сhange в run — это отражение того, как стадии запуска ложатся на уже существующие процессы. В нем учтены все задачи на пути выхода нового продукта с подробным описанием, списком участников и принимающих. Мы не хотим мешать другим командам и диктовать: «С завтрашнего дня вы работаете по-другому!». Как я говорил, мы аккуратно встраиваемся в уже существующий процесс.
Чек-лист помогает с двух сторон:
- точно определить, на какой стадии сейчас находится продукт;
- структурировать проверку продукта перед запуском.
Важная часть чек-листа — атрибуты, именно они делают процесс прозрачным. Атрибуты помогают проверить, что:
- названия продукта соответствует правилам нейминга и Tone of voice;
- продукт одинаково называется во всех каналах коммуникации;
- у продукта в личном кабинете есть шильдик preview;
- описание продукта есть в личном кабинете и на сайте;
- есть разрешение от центра кибербезопасности и так далее.
Прозрачная коммуникация между командами change и run помогает нам сбиться в понимании того, что мы запускаем, зачем и когда именно. Всё те же вопросы нам потом будут задавать клиенты, поэтому мы хотим не только знать на них ответы, но и отвечать на них одинаково на всех уровнях.
Стадии превью есть у многих компаний, и у всех они работают по-разному, у всех свои внутренние механизмы и процессы. Поэтому у каждой компании будет свой чек-лист со своими атрибутами — универсального шаблона нет.
Итоги и планы
За три месяца мы смогли перейти от идей на листке А4 к полноценной концепции: реализовали всё в Jira, запустили большой и важный процесс. Еще месяц ушел на то, чтобы перестроиться под этот новый процесс.
Итог такой. Теперь, чтобы какой-то продукт вышел в полноценный релиз, он должен пройти три стадии:
- закрытое превью: когда продукт тестируется ограниченной группой из сотрудников вендора, целевых и стратегических клиентов. Чаще всего функциональность продукта на этой стадии ограничена;
- открытое превью: когда тестирование продукта доступно всем клиентам. На этой стадии функциональность продукта становится шире;
- общая доступность: на этой стадии у продукта работают все функции и он доступен всем пользователям.
При этом разработка продолжается на каждой стадии с учетом планов и отзывов от клиентов. Благодаря этому мы снижаем риски, собираем обратную связь и быстро реагируем на изменения рынка.
Так что не стесняйтесь, тестируйте наши продукты в открытом превью, оставляйте отзывы, а затем заказывайте их в общей доступности. И присоединяйтесь к реферальной программе — рекомендуйте продукты коллегам и знакомым и получайте вознаграждение 15% с каждого оплаченного счета.
Если интересно, вот еще статьи про платформу Cloud.ru Evolution: