[Управление проектами, Развитие стартапа, Управление продуктом] Три проблемы быстрой проверки гипотез

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
11-Фев-2021 14:32

Цитировать

Меня зовут Иван Кесель, я владелец продукта сделок с недвижимостью в ДомКлик, а раньше был владельцем продукта мобильного приложения «Спасибо от Сбербанка». В Sbergile работаю уже три года. Выручка от продажи сервисов нашей команды измеряется сотнями миллионов рублей, а количество сделок с недвижимостью — десятками тысяч в год. Я расскажу о том, как запустить продукт при ограниченном количестве ресурсов и времени. Но сразу предупрежу: если необходимых ресурсов нет, то и продукт вы не запустите. Волшебной пилюли не существует. Хватит верить в сказки. Но если вам нужны практические советы, то читайте дальше. Мы рассмотрим три основные проблемы, которые могут возникать при быстрой проверке гипотез. Рассказывать буду на примерах конкретных запусков продуктов нашей командой. ДомКлик — это не только сделки с ипотечными кредитами, но и продажа недвижимости без кредита, когда покупатель и продавец уже нашли друг друга и им нужна помощь в обмене объекта недвижимости на деньги. На момент старта продукта и проверки гипотезы, о которой я расскажу, у нас уже было несколько отдельных сервисов:

сервис безопасных расчетов;
сервис электронной регистрации права собственности;
сервис проверки юридической чистоты квартир.

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

Почему средний ряд не относится к MVP? Казалось бы, функциональность постепенно нарастает, почему нет-то? Конечно, этот ряд подойдёт, например, если вы доставляете заказы, их вполне можно сначала развозить на самокате, а потом дорасти до грузовика. Но для многих ИТ-продуктов такая схема не годится. Первая проблемаВы придумали большую гипотезу, хотите запустить большой продукт, но у вас мало ресурсов. Идея кажется необъятной и вы не знаете, с чего начать. Здесь под «нет ресурсов для запуска продукта» может подразумеваться что угодно. В такой ситуации чётко сформулируйте свою гипотезу. Ответьте себе, что именно вы хотите проверить? Можно ли упростить гипотезу, а вместе с ней и продукт? Все ли его составляющие действительно необходимы для ответа на гипотезу? Отсеките всё лишнее.

Вы придумали большую идею, которая, кажется, взорвет рынок. Она представляется большим грузовиком, который невозможно запустить в эксплуатацию. А нужна ли MVP мигалка автопоезда на крыше? Нужен ли для такой большой кузов? Да и нужен ли кузов вообще? А теперь то же самое на примере нашей гипотезы «Сделка под ключ». Мы начали представлять, что должно быть в этом продукте, чтобы его купили. Естественно, личный кабинет, в котором клиент может посмотреть всю информацию. Должна быть интеграция со всеми сервисами, чтобы автоматически подтягивались данные и отправлялись заявки. Должен быть менеджер, какая-то богатая витрина с объектами для подключения.

Для запуска такого продукта потребовалось бы огромное количество ресурсов. Но если нет возможности их выбить или затягивать запуск MVP, то необходимо обратить внимание на функциональность. Важное правило: нельзя просто отказываться от каких-то частей. Если вы что-то убираете, то обязательно сверяйтесь с текстом гипотезы. Например, мы хотим проверить, что есть люди, готовые оформить и автоматически подключить услугу именно в личном кабинете, или нам достаточно просто подтвердить, что найдутся желающие услугу? Пока вы задаете такие вопросы, у вас постепенно может отпадать какая-нибудь функциональность. Может оказаться, что для проверки единого пакета можно обойтись не только без личного кабинета, но и без автоматической интеграции с сервисами — менеджер сам может подключить и оформить все необходимые заявки. Мы пришли к выводу, что для запуска нашего MVP достаточно одного менеджера. Он может по телефону передавать всю информацию, которую мы хотели отобразить в личном кабинете.

Вторая проблемаМы придумали большую гипотезу, потом сократили её, но оказалось, что нет необходимой команды для быстрого запуска и проверки такого продукта. Например, разработчики отсутствуют, а есть только менеджеры или дизайнеры, или наоборот, вся команда состоит из разработчиков и совершенно нет людей, кто бы нарисовал интерфейсы и прототипы. В нашем проекте на момент запуска не было менеджеров для работы с клиентами. Если вы работали в крупной компании, то можете себе представить, каково это — выбивать нужные ресурсы. Могут потребоваться месяцы на согласования и подтверждения эффективности. Этого времени у нас не было. В команду входили только бэкенд- и фронтенд-разработчики, и ничего хорошего не вышло бы, попытайся мы привлечь их к обзвону клиентов. Как же быть, если вы считаете, что у вас или вашей команды лапки?

Тут помогут принципы T-shape развития навыков: откажитесь от стереотипных ролей в команде. Не стоит относиться к ролям в команде как к чему-то, высеченному в камне. Не важно, что написано в трудовой у человека, не бойтесь открыто обсуждать с командой возможности сотрудничества и пересечения ролей. Мы думали, что обидим senior- или middle-инженера, если попросим его сутки поразбирать клиентские обращения. Или полдня поотвечать на клиентские звонки, послушать людей, получить какую-то обратную связь. А на деле всё оказалось не так. Когда мы предложили нашим ребятам-разработчикам помочь нам разобрать клиентские обращения, то они оказались очень заинтересованы и воодушевлены. Для них это была радость — отвлечься от ежедневной работе в редактор и перейти в поле, пообщаться с клиентами и узнать об их переживаниях и потребностях. Смена ролей даёт очень хорошие результаты:

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

Третья проблемаВы определились с продуктом и договорились о смене ролей в команде. И теперь не знаете, куда идти, у вас нет плана действий по развитию и запуску гипотезы. В результате команда не знает, что делать, у неё нет единого списка задач. Все начинают ждать, что бизнес-сотрудники — менеджеры или специалисты по клиентскому пути — подготовят задачи, а пока разработчики могут сидеть без дела. Конечно, в самом начале проекта никто не может точно представить, как должна работать система. Все ожидают этого понимания от менеджера. И получается очень большой перекос между бизнес-сотрудниками и технарями. Менеджерам предстоит большая работа по описанию всех задач, а их ресурсы не бесконечны. Если бы мы работали по каскадной модели управления проектами, то столкнулись бы с так называемым аналитическим параличом, связанным с необходимостью разработки технических требований перед началом работ. Пришлось бы нарисовать диаграмму Ганта и следить за ростом графика аналитики. Мы вынуждены были бы пить ромашковый чай и расстраиваться. А при гибкой модели управления графики на диаграмме смешиваются в короткие спринты, постепенно чередуя анализ, программирование и релиз. Но я хочу предложить иное решение. Чтобы избежать аналитического паралича, необходимо, чтобы команда сама описывала и анализировала все предстоящие задачи. Даже если вы долго работаете по Agile, всё равно бывают команды, которые работают по гибкой методологии, в которой большая часть ресурсов владельца продукта посвящена описанию задач и формулировке целей. И он не только тратит свои ресурсы, так еще и перетягивает на себя одеяло ответственности за те или иные решения. Это неправильно. Важно доверять своей команде, сотрудничать по-настоящему, передавать ответственность команде полностью или частично, чтобы команда сама обсуждала, спорила, искала какие-то решения и анализировала. Во-первых, это приводит к неожиданным решениям. То, что не могло прийти в голову бизнес-разработчику, может внезапно и легко родиться у технического специалиста, потому что он сталкивался с таким раньше. Кроме того, будет меньше ошибок, потому что технари напрямую видят результат своей работы. Наконец, команда видит баги и поэтому заинтересована в том, чтобы как можно лучше писать код. Одно дело, когда ты работаешь в стол, пишешь никому не видные, незаметные задачи, и совсем другое дело, когда ты ясно видишь свой результат и общаешься с клиентами, твоя мотивация значительно вырастает. ВыводыОписанные три примера позволили нашей команде запустить и проверить нашу гипотезу в рекордные сроки: за 15 дней от идеи до первых денег в кассе. Не просто осуществили какую-то холодную или горячую продажу, получив согласие клиента по телефону, а именно заработали деньги — клиент оплатил услугу. Тем самым мы подтвердили свою гипотезу о том, что существуют такие храбрецы, которые нашли друг друга и готовы довериться стороннему сервису в интернете, а не общаться вживую с человеком. Важно не останавливаться после подтверждения гипотезы и не забывать о том, что вы обрезали часть функциональности. Для полноценной проверки и запуска продукта впереди еще много дел. Если сейчас вы добились успеха в виде запуска и быстрой проверки гипотезы, это не значит, что позже рынок не отвергнет ваш продукт. Не значит, что продукт выйдет на самоокупаемость. Вероятно, в дальнейшем вам понадобится смелость закрыть продукт на каком-то моменте. Если резюмировать весь наш опыт, то можно вывести 4 простых правила:

Четко формулируйте гипотезы.
Смело экспериментируйте в команде.
Описывайте не задачи, а потребности.
Делитесь результатами.

P.S. Большая благодарность всем участникам Dream Team, без которых ничего не получилось бы:Марии Мельниковой, Жене Долгому, Диме Олейнику, Полине Панченко, Мише Дроздову, Сереже Анасову, Тиграну Атояну, Кате Ларионовой, Максиму Гришаку, Саше Лобову, Алексу Лейпи, Николаю Васеву и всем смежным командам.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_proektami (Управление проектами), #_razvitie_startapa (Развитие стартапа), #_upravlenie_produktom (Управление продуктом), #_vladelets_produkta (Владелец продукта), #_mvp, #_proverka_gipotez (проверка гипотез), #_zapusk_novogo_produkta (запуск нового продукта), #_startap (стартап), #_blog_kompanii_domklik (
Блог компании ДомКлик
), #_upravlenie_proektami (
Управление проектами
), #_razvitie_startapa (
Развитие стартапа
), #_upravlenie_produktom (
Управление продуктом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 22-Ноя 12:13
Часовой пояс: UTC + 5