Меня зовут Иван Кесель, я владелец продукта сделок с недвижимостью в ДомКлик, а раньше был владельцем продукта мобильного приложения «Спасибо от Сбербанка». В Sbergile работаю уже три года. Выручка от продажи сервисов нашей команды измеряется сотнями миллионов рублей, а количество сделок с недвижимостью — десятками тысяч в год.
Я расскажу о том, как запустить продукт при ограниченном количестве ресурсов и времени. Но сразу предупрежу: если необходимых ресурсов нет, то и продукт вы не запустите. Волшебной пилюли не существует. Хватит верить в сказки. Но если вам нужны практические советы, то читайте дальше. Мы рассмотрим три основные проблемы, которые могут возникать при быстрой проверке гипотез. Рассказывать буду на примерах конкретных запусков продуктов нашей командой.
ДомКлик — это не только сделки с ипотечными кредитами, но и продажа недвижимости без кредита, когда покупатель и продавец уже нашли друг друга и им нужна помощь в обмене объекта недвижимости на деньги.
На момент старта продукта и проверки гипотезы, о которой я расскажу, у нас уже было несколько отдельных сервисов:
-
сервис безопасных расчетов;
-
сервис электронной регистрации права собственности;
-
сервис проверки юридической чистоты квартир.
У каждого из них был свой клиентский путь, своя стоимость, свои продающие посадочные страницы. Наша гипотеза заключалась вот в чём. Если покупатель и продавец где-то нашли друг друга и обо всём договорились, то им уже не нужны услуги сторонних специалистов. Им осталось лишь провести сделку. И мы верили, что найдутся клиенты, которые не захотят разбираться в каждом отдельном нашем продукте, и им понравится идея купить единый пакет услуг, не требующий что-либо изучать. Именно такой продукт и гипотезу мы проверяли.
Запуск продукта и проверка любой гипотезы начинается с MVP, минимального продукта.
Почему средний ряд не относится к MVP? Казалось бы, функциональность постепенно нарастает, почему нет-то? Конечно, этот ряд подойдёт, например, если вы доставляете заказы, их вполне можно сначала развозить на самокате, а потом дорасти до грузовика. Но для многих ИТ-продуктов такая схема не годится.
Первая проблема
Вы придумали большую гипотезу, хотите запустить большой продукт, но у вас мало ресурсов. Идея кажется необъятной и вы не знаете, с чего начать. Здесь под «нет ресурсов для запуска продукта» может подразумеваться что угодно.
В такой ситуации чётко сформулируйте свою гипотезу. Ответьте себе, что именно вы хотите проверить? Можно ли упростить гипотезу, а вместе с ней и продукт? Все ли его составляющие действительно необходимы для ответа на гипотезу? Отсеките всё лишнее.
Вы придумали большую идею, которая, кажется, взорвет рынок. Она представляется большим грузовиком, который невозможно запустить в эксплуатацию. А нужна ли MVP мигалка автопоезда на крыше? Нужен ли для такой большой кузов? Да и нужен ли кузов вообще?
А теперь то же самое на примере нашей гипотезы «Сделка под ключ». Мы начали представлять, что должно быть в этом продукте, чтобы его купили. Естественно, личный кабинет, в котором клиент может посмотреть всю информацию. Должна быть интеграция со всеми сервисами, чтобы автоматически подтягивались данные и отправлялись заявки. Должен быть менеджер, какая-то богатая витрина с объектами для подключения.
Для запуска такого продукта потребовалось бы огромное количество ресурсов. Но если нет возможности их выбить или затягивать запуск MVP, то необходимо обратить внимание на функциональность. Важное правило: нельзя просто отказываться от каких-то частей. Если вы что-то убираете, то обязательно сверяйтесь с текстом гипотезы. Например, мы хотим проверить, что есть люди, готовые оформить и автоматически подключить услугу именно в личном кабинете, или нам достаточно просто подтвердить, что найдутся желающие услугу? Пока вы задаете такие вопросы, у вас постепенно может отпадать какая-нибудь функциональность. Может оказаться, что для проверки единого пакета можно обойтись не только без личного кабинета, но и без автоматической интеграции с сервисами — менеджер сам может подключить и оформить все необходимые заявки. Мы пришли к выводу, что для запуска нашего MVP достаточно одного менеджера. Он может по телефону передавать всю информацию, которую мы хотели отобразить в личном кабинете.
Вторая проблема
Мы придумали большую гипотезу, потом сократили её, но оказалось, что нет необходимой команды для быстрого запуска и проверки такого продукта. Например, разработчики отсутствуют, а есть только менеджеры или дизайнеры, или наоборот, вся команда состоит из разработчиков и совершенно нет людей, кто бы нарисовал интерфейсы и прототипы.
В нашем проекте на момент запуска не было менеджеров для работы с клиентами. Если вы работали в крупной компании, то можете себе представить, каково это — выбивать нужные ресурсы. Могут потребоваться месяцы на согласования и подтверждения эффективности. Этого времени у нас не было. В команду входили только бэкенд- и фронтенд-разработчики, и ничего хорошего не вышло бы, попытайся мы привлечь их к обзвону клиентов.
Как же быть, если вы считаете, что у вас или вашей команды лапки?
Тут помогут принципы T-shape развития навыков: откажитесь от стереотипных ролей в команде. Не стоит относиться к ролям в команде как к чему-то, высеченному в камне. Не важно, что написано в трудовой у человека, не бойтесь открыто обсуждать с командой возможности сотрудничества и пересечения ролей. Мы думали, что обидим senior- или middle-инженера, если попросим его сутки поразбирать клиентские обращения. Или полдня поотвечать на клиентские звонки, послушать людей, получить какую-то обратную связь. А на деле всё оказалось не так. Когда мы предложили нашим ребятам-разработчикам помочь нам разобрать клиентские обращения, то они оказались очень заинтересованы и воодушевлены. Для них это была радость — отвлечься от ежедневной работы в редакторе и перейти в поле, пообщаться с клиентами и узнать об их переживаниях и потребностях.
Смена ролей даёт очень хорошие результаты:
-
мы быстрее поставляем продукты;
-
команда остается очень мотивированной, потому что каждый день видит, что она делает;
-
растёт ценность продукта, потому что мы не тратим время на формулирование задачи по получению обратной связи и передаче её туда-обратно;
-
сотрудники непосредственно участвуют в развитии продукта и эффектно определяют функции, которые повышают его ценность для клиентов.
Третья проблема
Вы определились с продуктом и договорились о смене ролей в команде. И теперь не знаете, куда идти, у вас нет плана действий по развитию и запуску гипотезы. В результате команда не знает, что делать, у неё нет единого списка задач. Все начинают ждать, что бизнес-сотрудники — менеджеры или специалисты по клиентскому пути — подготовят задачи, а пока разработчики могут сидеть без дела.
Конечно, в самом начале проекта никто не может точно представить, как должна работать система. Все ожидают этого понимания от менеджера. И получается очень большой перекос между бизнес-сотрудниками и технарями. Менеджерам предстоит большая работа по описанию всех задач, а их ресурсы не бесконечны. Если бы мы работали по каскадной модели управления проектами, то столкнулись бы с так называемым аналитическим параличом, связанным с необходимостью разработки технических требований перед началом работ. Пришлось бы нарисовать диаграмму Ганта и следить за ростом графика аналитики. Мы вынуждены были бы пить ромашковый чай и расстраиваться. А при гибкой модели управления графики на диаграмме смешиваются в короткие спринты, постепенно чередуя анализ, программирование и релиз.
Но я хочу предложить иное решение. Чтобы избежать аналитического паралича, необходимо, чтобы команда сама описывала и анализировала все предстоящие задачи. Даже если вы долго работаете по Agile, всё равно бывают команды, которые работают по гибкой методологии, в которой большая часть ресурсов владельца продукта посвящена описанию задач и формулировке целей. И он не только тратит свои ресурсы, так еще и перетягивает на себя одеяло ответственности за те или иные решения. Это неправильно.
Важно доверять своей команде, сотрудничать по-настоящему, передавать ответственность команде полностью или частично, чтобы команда сама обсуждала, спорила, искала какие-то решения и анализировала. Во-первых, это приводит к неожиданным решениям. То, что не могло прийти в голову бизнес-разработчику, может внезапно и легко родиться у технического специалиста, потому что он сталкивался с таким раньше.
Кроме того, будет меньше ошибок, потому что технари напрямую видят результат своей работы.
Наконец, команда видит баги и поэтому заинтересована в том, чтобы как можно лучше писать код. Одно дело, когда ты работаешь в стол, пишешь никому не видные, незаметные задачи, и совсем другое дело, когда ты ясно видишь свой результат и общаешься с клиентами, твоя мотивация значительно вырастает.
Выводы
Описанные три примера позволили нашей команде запустить и проверить нашу гипотезу в рекордные сроки: за 15 дней от идеи до первых денег в кассе. Не просто осуществили какую-то холодную или горячую продажу, получив согласие клиента по телефону, а именно заработали деньги — клиент оплатил услугу. Тем самым мы подтвердили свою гипотезу о том, что существуют такие храбрецы, которые нашли друг друга и готовы довериться стороннему сервису в интернете, а не общаться вживую с человеком.
Важно не останавливаться после подтверждения гипотезы и не забывать о том, что вы обрезали часть функциональности. Для полноценной проверки и запуска продукта впереди еще много дел. Если сейчас вы добились успеха в виде запуска и быстрой проверки гипотезы, это не значит, что позже рынок не отвергнет ваш продукт. Не значит, что продукт выйдет на самоокупаемость. Вероятно, в дальнейшем вам понадобится смелость закрыть продукт на каком-то моменте.
Если резюмировать весь наш опыт, то можно вывести 4 простых правила:
-
Четко формулируйте гипотезы.
-
Смело экспериментируйте в команде.
-
Описывайте не задачи, а потребности.
-
Делитесь результатами.
P.S. Большая благодарность всем участникам Dream Team, без которых ничего не получилось бы:
Марии Мельниковой, Жене Долгому, Диме Олейнику, Полине Панченко, Мише Дроздову, Сереже Анасову, Тиграну Атояну, Кате Ларионовой, Максиму Гришаку, Саше Лобову, Алексу Лейпи, Николаю Васеву и всем смежным командам.
Автор: Кесель Иван
