На связи снова Никита Бутримов — лидер продуктового направления в Cloud.ru. Недавно я рассказывал про облачный free tier, а сегодня хочу поделиться опытом нашей компании по внедрению новых стадий запуска продукта — рассказать, как мы работали раньше, как пришли к новому процессу, зачем это было нужно и что мы получили на выходе. Процесс разберем на примере запуска новой облачной платформы Cloud.ru Evolution. Поехали!
Как было до и что поменялось
В любой компании есть продуктовый процесс. Если смотреть верхнеуровнево, то у всех он построен плюс-минус одинаково: сначала у внешних или внутренних пользователей появляются идеи, потом эти идеи проходят этап согласования и «выжившие» попадают в бэклог разработки. После команда разработки приносит уже готовый продукт или сервис, который затем оказывается в проде.
Вот и у нас раньше было точно так же. Свимлайн product development на картинке ниже — это стандартный процесс разработки продукта. А то, что на картинке под чертой — как раз процесс, который мы недавно внедрили:
По обновленному алгоритму мы как бы «встраиваемся» в разработку и дополняем ее новыми стадиями. При этом не нарушаем уже сложившийся продуктовый процесс и не мешаем другим командам😊.
Теперь «большой» процесс разработки мы делим на три стадии:
private preview (закрытое превью),
public preview (открытое превью),
general availability (общая доступность).
Зачем нам это нужно? Теперь мы можем выпускать продукты намного раньше и быстрее и получать обратную связь от пользователей до того, как выпустим продукт на рынок в общий доступ. Подробнее о пользе и преимуществах этих стадий рассказываю дальше.
Что значит private preview, public preview, general availability
Что на практике означают все эти стадии? И как определить, на какой из них находится продукт? Для удобства мы сделали таблицу и выделили конкретные атрибуты:
Доступ к продукту, количество участников и функциональность
В private preview доступ к продуктам у всех клиентов и партнеров закрытый. В нашем личном кабинете вы его не увидите — менеджеры предлагают попробовать продукты небольшой выборке клиентов. На этой стадии функциональность ресурса ограничена. Наша задача — собрать первую обратную связь, посмотреть на реакцию пользователей и валидировать их сценарии.
В public preview возможность пробовать и тестировать продукты есть уже у всех — мы активно анонсируем запуск и зовем всех желающих на тест. В личном кабинете рядом с сервисом отображается шильдик preview. Функциональность такая же, как в private preview, либо чуть шире. Главное отличие в том, что продукт теперь доступен большему кругу пользователей.
Ну и в general availability продукт с полной функциональностью доступен всем: он в проде и мы берем за него деньги.
Продуктовые метрики
Когда мы запускаем продукт, у нас всегда есть какие-то ожидания: сколько пользователей должно прийти, сколько пользователей мы сможем принять, как продуктом будут пользоваться и так далее. Это супер важная информация для дальнейшего развития продукта (и не только), поэтому мы начинаем снимать все метрики уже на стадии public preview — capacity, количество уникальных пользователей, нагрузка на продукты. И, конечно, продолжаем в general availability, только собираем уже немного другие метрики.
Мониторинг доступности — это обязательный атрибут, который есть на каждой стадии.
Документация
Она есть каждой стадии. Для чего? Если что-то не прописано в документации, то для пользователя этого просто нет. Поэтому писать документацию важно заранее — уже на стадии private preview. Кроме того, у нас все продукты комплементарны, они друг друга дополняют — инструкция о конкретном продукте просто не может находиться «в вакууме».
Биллинг
На стадии private и public preview мы не берем денег, но при этом видим, сколько пользователей и в каких масштабах используют продукт. Мы уже можем спрогнозировать, какой usage (потребление) будет в будущем у продукта.
Хорошо, если в личном кабинете уже оцифрованы все метрики потребления, в контроле затрат всё прозрачно и понятно — уже на стадии public preview клиенту важно понимать, сколько он будет платить, когда перейдет в general availability.
Поддержка
Она у нас есть на всех стадиях, но работает по-разному. Нам всегда много пишут с вопросами, в том числе в preview.
Однако в private preview поддержка сильно ограничена. Хоть все обращения и идут стандартным путем через первую (L1) и вторую (L2) линию поддержки, все они в итоге «падают» на продуктовую команду: на этом этапе «развития» только продуктовая команда знает, что с продуктом происходит.
В preview поддержка только «учится» помогать, особенно если продукт сложный (например, как serverless) или просто новый (например, Evolution Managed Kubernetes или Evolution Object Storage). Ей тоже нужно время, чтобы познакомиться с продуктом и понять, как с ним правильно работать и какие бывают типовые вопросы. Получается, работа с клиентом «тюнится» в private preview, чтобы в public preview уже уверенно любой вопрос отрабатывать.
Цель стадий
Тут всё просто. В private preview мы собираем обратную связь и понимаем, к чему готов или не готов продукт, для какой аудитории он лучше подходит и для какого сегмента. Мы продумываем, когда продукт выводить (когда мы будем к этому готовы) и на какое количество пользователей. Например, если продукт для сегмента малого и среднего бизнеса, то он должен выдерживать много-много пользователей, а к такому еще нужно хорошенько подготовиться.
В public preview мы уже вывели продукт на рынок и об этом «громко говорим». Мы работаем с нашей базой клиентов и усиливаем бренд, анонсируем, какие еще продукты вскоре можно будет подключить.
Ну а в general availability наша цель — предложить готовый классный продукт и взять за него деньги.
Почему мы пошли новым путем: преимущества
Как я говорил, такой подход — не новшество для рынка. Многие крупные компании (например, Spotify, Google, Microsoft) уже так делают, только каждая по-разному у себя эти стадии называет.
А теперь и мы так делаем😊. Расскажу, какие преимущества дает этот подход.
Минимизируем риски и четче планируем
Выпуская продукт, мы принимаем риски, которые с этим запуском могут быть связаны, например, SLA просрочился или просто что-то не успели до конца доделать. Но поскольку мы в preview, то можем «официально» иметь какие-то недоработки. Нам пользователи могут (и будут) про них писать, а нам как раз это и нужно😉. Благодаря такой обратной связи мы понимаем, что нужно доделать в первую очередь и на что в целом обратить внимание при доработке сервиса.
В стадии preview мы можем планировать рекламные кампании, обучение и еще много полезного и нужного для клиента, чтобы на стадии general availability продукт уже взлетел, а не только начал это делать. Возможность четче планировать — важное преимущество нового подхода.
Ускорили time to market
Про ускорение time to market говорят многие и многие про это наслышаны, но тут не всё так просто. Чтобы выпустить продукт, нужно соблюсти юридические обязательства, учитывать оферту и многое другое. Чтобы выпускать продукты раньше, нужны специальные механизмы.
Стадии private preview, public preview и general availability — это мировая практика, которая юридически позволяет выпускать продукты и сервисы на рынок быстрее. Поэтому уже в public preview мы можем прикинуть, какая у нас будет стратегия маркетинга, мы начинаем готовить страницы для сайта, баннеры и многое другое. И поэтому на стадии general availability у нас уже будет всё готово.
Делаем продукты ближе к клиенту
Главная ценность нашего текущего подхода — клиент, ведь мы работаем для него. И продукт делаем тоже для него. Поэтому на стадиях private preview и public preview мы буквально сопровождаем клиента.
Вот пример: 21 марта мы запустили в private preview продукты Data Platform (Trino, Metastore, ArenaData DB) и DBaaS (PostgreSQL, DocumentDB и Pangolin). На тестирование позвали небольшое количество клиентов и на всех этапах их «вели за ручку»: объясняли, как работает продукт, что и как настраивать, что уже работает, а что пока нет. А еще спрашивали, какой у них сценарий использования продукта и как они планируют его реализовывать.
Обычно в больших компаниях клиенту сложно пробиться к продукт оунеру, а у нас наоборот — сами предлагаем пообщаться. Мы делаем так не только с юридическими лицами, но и с физическими — нам важна любая информация и любой фидбэк. Мы стараемся сделать продукт еще лучше для любого клиента.
Улучшаем взаимодействие с клиентами (customer engagement)
Очевидно, что все клиенты разные: их можно делить по индустриям, сегментам, чекам и подобным критериям. Но тут немного про другое😉.
Есть такой подход, когда ты смотришь, какие конкретно продукты используют твои клиенты. Например, есть те, кто использует только платформу данных или вообще не используют виртуалки. Есть клиенты, которые используют только serverless, и так далее. С каждым из этих клиентов стоит по-разному взаимодействовать. Это разная аудитория, им интересны разные каналы. С ними нужно работать по-разному: где-то через сейла, где-то через партнерскую структуру, где-то напрямую с продуктовой командой. Потому что разные клиенты требуют разного.
Сопровождая клиента на стадии preview мы как раз понимаем, почему и зачем они используют именно эти продукты, а также видим, какие вещи им важнее и нужнее. Мы делаем разные выводы и на их основе улучшаем продукт или выводим его раньше в коммерцию. А в каких-то случаях можем решить, что вообще не будем выводить продукт.
Повысили прозрачность процессов
В нашем случае речь про Jira — систему отслеживания ошибок, предназначенную для организации взаимодействия с пользователями, а также совместной работы и управления проектами.
Мы используем оба сценария😊. А еще настроили для всех задач чек-лист (о нем подробно рассказываю ниже), чтобы структурировать весь процесс, и выложили его в общий доступ внутри компании.
Четче понимаем критерии передачи из Exchange в Run
Во многих компаниях есть разделение на Change- и Run-команды. Первые создают продукт или услугу, допиливают их и регулярно докручивают, а вторые — продают. По сути это продакты и продавцы. И нередко между этими командами случается недопонимание.
У нас всё работает немного иначе. В Cloud.ru тоже есть разделение, но при этом мы одна команда: change разрабатывает продукт, а run принимает его в эксплуатацию и запускает в прод. Быстро принимать продукты важно для обеих сторон, а новые стадии как раз помогают делать всё вовремя. Именно для этого мы ввели чек-лист с атрибутами, о котором я рассказываю ниже.
А еще теперь удобно давать обратную связь. Например: сделали продукт в change, но в run становится понятно, что продукт пока не в general availability, а только в private preview. Как мы это понимаем? Благодаря чек-листу сразу видим, что пока нет нужных атрибутов, которые соответствуют стадии general availability.
Чек-лист передачи из Change в Run: как это работает
Чек-лист передачи продукта из Change в Run — это отражение того, как стадии запуска ложатся на уже существующие процессы в нашей компании. Мы не хотим мешать другим командам и диктовать: «С завтрашнего дня вы работаете по-другому!». Как я говорил, мы аккуратно встраиваемся в уже существующий процесс.
Чек-лист помогает:
точно определить, на какой стадии сейчас находится продукт — private preview, public preview или уже general availability;
структурировать проверку продукта перед запуском — в нем учтены все задачи на пути выхода нового продукта с подробным описанием, списком участников и принимающих.
Важная часть чек-листа — атрибуты, именно они делают процесс прозрачным. Атрибуты помогают проверить, что:
продукты соответствуют правилам нейминга и Tone of voice, правильно называются во всех каналах коммуникации с клиентом;
шильдик preview есть не только в личном кабинете, но и на сайте;
раздел с сервисом есть и в личном кабинете и на сайте;
есть разрешение от ЦКЗ (центра кибербезопасности) и так далее.
Прозрачная коммуникация помогает «сбиться» в понимании того, что мы запускаем, зачем запускаем и когда именно. Все те же вопросы нам потом будут задавать клиенты, поэтому мы хотим не только знать на них ответы, но и отвечать консистентно😉.
Стадия preview есть у многих компаний, но все они по-разному работают, у всех свои внутренние механизмы и процессы. Поэтому у каждой компании будет свой чек-лист со своими атрибутами — универсального шаблона нет.
Итоги и наши планы
За квартал мы смогли от листочка А4 перейти к полноценной концепции — реализовать всё в Jira и запустить большой и важный процесс🎉. А затем за месяц перестроиться под этот новый процесс💪.
Подытожу. Теперь, чтобы какой-то продукт вышел в полноценный релиз, на этапе разработки он должен пройти три стадии:
Private preview (закрытое превью): когда продукт тестируется закрытой группой из сотрудников вендора, целевых и стратегических клиентов. Чаще всего функциональность продукта на этой стадии ограничена.
Public preview (открытое превью): когда тестирование продукта доступно всем клиентам. На этой стадии функциональность продукта становится шире.
General availability (общая доступность): на этой стадии продукт имеет полную функциональность и доступен всем пользователям.
При этом разработка продолжается на каждой стадии с учетом планов и отзывов от клиентов. Благодаря этому мы снижаем риски, собираем обратную связь и быстро реагируем на изменения рынка.
Так что не стесняйтесь — пробуйте наши сервисы в public preview, оставляйте отзывы, а затем заказывайте в general availability😉. И присоединяйтесь к реферальной программе — рекомендуйте сервисы коллегам и знакомым, а затем получайте вознаграждение 15%.
Полезные материалы в блоге:
Что такое free tier и какие облачные ресурсы вы можете бесплатно использовать прямо сейчас
Накатить ось на 500+ серверов и настроить всё за 10 минут: наш опыт использования Foreman
Запускаем кластер OpenSearch для централизованного хранения логов