Привет Хабр!

Меня зовут Дмитрий Константинов. Я продакт менеджер и больше всего в своей работе люблю развивать мобильные приложения. Верю, что мобильные приложения могут быть более удобными для решения некоторых кейсов, чем десктоп или веб. Недавно я опубликовал свою первую статью на хабре (на английском, зацените её!) и мне захотелось поделиться более комплексным опытом. Я подумал, какой опыт, который я пережил как продакт менеджер мне запомнился больше всего и почему. Ответ без сомнения будет — "тот самый стартап, который нельзя называть". Во вступительной части будет много “Я”, потому что эта секция персонально обо мне. Но структура всей статьи и заголовок содержат слово “Мы”, потому что я переживал этот опыт не один, а с потрясающей командой. Эта статья является переводом моей же статьи, которую я опубликовал в англоязычном фиде Хабра чуть ранее. 

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

Команда

В стартапе, с правильным менеджментом, вы можете выстроить атмосферу близкой дружбы, когда вы заказываете пиццу с пивом по пятницам после работы и играете вместе в “Broforce” (не все любят “FIFA”) на PlayStation.

Один из вопросов на интервью, когда я проходил собеседование в компанию, был: “Почему в твоем резюме именно эта цифра в строке ожидаемой зарплаты?”. На что я честно ответил, что “Когда сумма была на 20% меньше - мне никто не звонил.” После этого вопроса мы посмеялись (интервью вообще было очень весёлое), чуть позже я принял оффер. Надеюсь, что я получил его не только из-за этой шутки. 

Бывший СТО из этого стартапа сейчас хост одного из крупнейших русскоязычных IT подкастов и развивает маркетинг главного языка Android разработки. Бывший iOS разработчик написал известную, в кругах мобильных разработчиков, статью о двух работах и частенько рефлексирует о “том самом стартапе”. Бывший Android разработчик работает в самом быстрорастущем финтех стартапе Великобритании и т.д. Наша команда была достаточно талантливой. 

План А - Приложение для клиентов (или “Бьюти Убер”)

“Стартап” - это компания, которая не понимает:

1. Каков её продукт.

2. Кто её клиенты.

3. Как заработать деньги.

– Dave McClure, 500Startups co-founder (вольный перевод моего авторства)

Первая идея стартапа была в создании двух мобильных приложений (“Mobile first” подход!). Одно приложение для клиентов, которые покупают услуги, и одно для бьюти мастеров, которые эти услуги предоставляют.

Весь фокус был на первом приложении. Приложение было главным, состояло из намного большего количества экранов, чем другое приложение, и было создано как главный и единственный способ органичного взаимодействия клиента с нашим сервисом. "Органичный клиент" - внешний пользователь, который увидел нашу рекламу в знаменитой запрещенной в РФ социальной сети. Приложение содержало каталог услуг и список салонов и мастеров. Сразу после оформления заказа, клиент мог задать уточняющие вопросы мастеру в чате. Также была возможность вызова мастера к себе на дом (да, “Uber” в заголовке статьи не был кликбейтом). У нас был небольшой отдел, модерировавший мастеров, которые хотели стать частью нашего сервиса. Поначалу регистрация в приложении для мастеров была закрытой, и запросы шли через заявку на простеньком лендинге, позже мы добавили возможность регистрации и в приложение. Одно из преимуществ модерации мастеров было в том, что мы делали профессиональное фото каждого из них и они выглядели очень органично и аккуратно на экране выбора мастеров в клиентском приложении (да, я говорю про тебя, мастер, которая сделала селфи за рулем и поставила на аватар, когда мы ненадолго открыли возможность поставить персональную фотографию). 

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

У клиента было 3 опции во время оформления заказа:

• Прийти в наш фирменный, дорогой и роскошный салон, который наш фаундер свежо назвал “Спот”

• Прийти к мастеру в салон. Некоторые из мастеров начали оформлять такие салоны у себя дома с нашего разрешения. Что могло пойти не так при выборе этой опции? Например однажды я пришёл к мастеру домой, меня встретил её муж в трусах, а потом сел передо мной смотреть мультик на большой громкости (поэтому эту опцию я не рекомендую)

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

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

Давайте остановим обсуждение деталей бизнеса на секунду. Я обещал технические кейсы и испытания. Краткая история самого типичного кейса, который мы тогда решали. Когда мы проектировали табличку бьюти услуг в нашей базе данных, то не ожидали, что цена окрашивания должна быть не фиксированной, а дельтой. Причина динамичной цены в том, что ни клиент ни мастер не знают как много расходных материалов (краска, шампунь, кондиционер и т.д.) будет использовано во время заказа, поэтому клиент обычно берёт больше денег с собой, а мастер заранее говорит ему примерную дельту. Поэтому чуть позже мы добавили новый атрибут в API и костыльное условие в мобильные клиенты “сначала смотри на дельту, уже потом на цену услуги”.

Или другая история. Нам нужно было реализовать возможность общения между клиентом и мастером в мобильных приложениях. Написать SDK с нуля? Зачем, если можно взять готовое решение со знаменитого дейтинг аппа! Мобильные разработчики иногда мечтают о Вебсокетах. Мы тоже о них только мечтали. Как реализовать живой чат, который будет обновляться с каждым сообщением? Обновлять его с пуш-уведомлениями!

Провал

Пока всё хорошо, правда? Не совсем, мы не смогли ответить на третий вопрос из цитаты, которую я привёл выше. Сервис рос недостаточно быстро. В системе, которую мы построили, нам нужно было масштабироваться в 30-50 раз быстрее, чем мы масштабировались. Только на гигантском обороте средств мы бы начали приносить приемлемый профит. Это было абсолютно невозможно на рынке, на котором мы существовали. Поэтому было принято решение сделать пивот. 

План Б - Приложение для мастеров (или “Бьюти коворкинг”)

If Plan A doesn’t work, the alphabet has 25 more letters.”

– Claire Cook, Author (думаю перевод необязателен)

Время остановиться и спросить себя, что мы имеем на данный момент?

2 нативных мобильных приложения на iOS (для клиента и для мастера), 2 нативных мобильных приложения на Android (для клиента и для мастера), веб лендинг для клиентов, сервер, админская CRM панель (которая ещё не закончена) и последнее, но не по важности, два фирменных, дорогих и роскошных спота (опция для клиента номер 1, помните?).

Если бизнес не может масштабироваться, то вам нужно делать пивот! Определение пивота из вики гласит: “Пивот (от англ. pivot — «вращение») — резкое изменение направления стартапа с целью его дальнейшего развития и сохранения жизнеспособности”. Бизнесы могут изменить направление, чтобы лучше удовлетворить спросу пользователей, изменить свою целевую аудиторию для увеличения продаж или сочетать и то, и другое. 

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

Аудитория мастеров гораздо меньше. Если в случае с клиентами наш MAU (Monthly Active Users) измерялся тысячами, то с мастерами это были сотни. Другое дело, что у мастеров гораздо больше LTV (Lifetime Value) и с ними проще работать, потому что они приходят в салон и оказывают в нём все свои услуги. 

Давайте посмотрим детальнее, что у нас было на тот момент в приложении для мастеров. Календарь с расписанием заказов, чат, статистика (очень упрощённая) и возможность управлять своим списком услуг и портфолио. Мастер сам решал какой заказ принять, все принятые заказы отображались в календаре. Календарь тоже в первой версии приложения был упрощенный, в нём мастер мог выставлять свободное время в том или ином салоне и видеть заказы в расписании. 

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

Из приложения для клиентов были удалены следующие опции: посещение мастера в салоне (или на дому, ха-ха) и для мастера выезд к клиенту на дом (прощай “бьюти Uber”). 

Новые испытания

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

С какими техническими проблемами мы столкнулись? Самым неожиданным вызовом было то, что пришедшие ребята не могли масштабировать код, написанный до них. Поэтому было принято непростое решение написать методы с нуля (по сути весь сервер), но в той же структуре Json API, которая использовалась до этого, чтобы максимально сократить количество изменений в мобильных приложениях. Мы спланировали работу, я сделал диаграмму Ганта для мобильной разработки, которая основывалась на сроках, которые были на диаграмме Ганта для бэкенда.

В какой-то момент мы поняли, что API методы сильно изменились, и этот момент осознания совпал с моментом, когда нас покинул последний Android-разработчик.

Совет! Имейте хотя бы по два разработчика на каждой платформе, чтобы bus factor (фактор внезапного автобуса) не был максимально возможным (1.0). 

Что нам было делать? Один фронтенд разработчик проявил инициативу, но уже через месяц мы поняли, что у него ничего не получается и никакой волшебный “код ревью” эту проблему не решит, потому что у нас не осталось специалистов по Android. Параллельно мы писали виджет для веба, который повторял флоу мобильного приложения для клиентов.

Тут к нам пришла ужасная идея, потому что другого выбора у нас не было. Я думаю, что вы уже догадались. Мы сделали приложение на Android, которое содержало из себя только вебвью с нашим веб-виджетом. 

I have a pen, I have a apple

Uh! Apple-Pen!

I have a pen, I have pineapple

Uh! Pineapple-Pen!

Piko-Taro, singer/songwriter (думаю и тут можно обойтись без перевода)

Customer development

Со сменой фокуса и целевой аудитории на другое приложение у нас появилась уникальная возможность пообщаться буквально со всеми мастерами, которые у нас были. Мы провели более 100 интервью, изучили почему они выбрали нас и что их отталкивало до того, как они пришли к нам. Мы увидели некоторые паттерны в интервью, и на основе этих паттернов сделали новый “Welcome” экран, где написали о преимуществах нашего сервиса исходя из опасений и потребностей пользователей. Экран состоит из видео мастеров в процессе работы и слайдера с нашими основными преимуществами. Да, я понимаю, видео на “Welcome” экране сейчас не в фаворе и выглядят грустно, но 2019 год был расцветом вертикальных видео и ТТ (тогда он был известен под другим названием). Диалог с мастерами на этом экране вёлся без заглавных букв, но зато с добавлением эмодзи - таков был брендбук компании. 

Какие страхи и потребности были у мастеров?

• Рабочие кресла в коворкинге будут неопрятными и грязными — на первом же экране мы говорим, что наш сервис про “чистоту” и “комфорт”

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

• Как и где встретить клиента? — Клиента встретит вежливый администратор и приведет к вам на рабочее место

• Будет ли звонок с подтверждением после бронирования места в мобильном приложении? — Нет, потому что мы “Mobile first” сервис. Бронируй, внеси предоплату за 24 часа до начала заказа в мобильном приложении и приходи на работу

У мастера было 2 опции во время создания заказа:

• Бронирование (флоу бронирования в скриншоте ниже)

• Заказ на клиента (с вводом номера телефона и имени). Заказ на клиента в мастерском приложении автоматически регистрировал клиента в системе, если он не был ранее зарегистрирован. За 24 часа до начала заказа мы отправляли клиенту СМС с напоминанием и ссылкой на мобильное приложение. Тут кстати нам помог “Mobile first” подход, потому что для клиента в мобильном приложении флоу регистрации и авторизации был одинаковый, он вводил номер телефона и код из смс. Никаких логинов и паролей - класс!

Далее мы реализовали онбординг флоу оформления первого бронирования/ заказа (на скриншоте ниже). 

У нашего фаундера была идея, чтобы мастер “тянул” интервал в календаре (как в календаре Google), чтобы выбрать желаемую продолжительность заказа. Лично мне нравилось как это работает в календаре Apple, где можно легко изменить начало интервала, двигая пальцем, в то время как в календаре Google палец "застревал" в первой точке, куда пользователь тапнул. Моя команда и я придумали классное, на мой взгляд, решение с прогресс баром, сочетающим в себе лучшее из календаря Apple и Google. Прогресс бар заполнялся чуть более, чем за одну секунду. Вы можете увидеть как это работает на скриншоте выше.

Резюме и заключение

Мы сделали и успешно выпустили сайт и приложения в срок. Нашим основным показателем успеха была общая занятость всех кресел, и этот показатель успешно рос. Всё было хорошо и многообещающе, пока не пришёл Covid. Почти вся IT команда была расформирована. Позже со мной связался CTO из IT аутсорса и поспрашивал о бизнес-части и архитектуре мобильных приложений. Скорее всего они планировали подхватить разработку, но, судя по отсутствию обновлений мобильных приложений, у них не срослось. 

Вот как сейчас выглядят изображения приложения для мастеров в App Store.

Сервис продолжает существовать и процветать. Вы можете видеть, что бьюти мастера все еще доступны для бронирования. Приложение WebView по-прежнему доступно в Google Play! (Google, у меня есть к тебе вопросы)

В заключении я хотел бы отметить, что стартап - это отличная возможность для вертикального роста в компании. Вы можете развивать свои хард и софт скиллы где угодно, но в стартапе вы можете повысить (или изменить) название своей должности. Я пришёл в качестве QA и очень быстро вырос до Head of Mobile и отчитывался про роадмап и сроки на недельных синкапах напрямую фаундеру. Если вы открыты и готовы жить своей работой 24/7, то идите в стартап, а не корпорацию. 

Спасибо всем, кто дочитал до конца! Оставьте комментарий ниже и поставьте лайк, мне будет приятно.