Советы по запуску IT-продукта за рубежом
Приехав в Дубай, создатели проекта увидели, что онлайн-рынок услуг здесь на уровне России 90-х годов. У людей есть деньги, но нет большинства сервисов, к которым привык житель России или Америки. Экспатам, которые решили инвестировать в недвижимость в Дубае, сложно найти местных подрядчиков по обустройству, поскольку для этого нет единой онлайн-площадки.
Наши клиенты решили создать платформу, которая соединяет владельцев недвижимости и поставщиков услуг. Для этого им требовалось укомплектовать команду разработки. Создатели проекта искали специалистов, общаясь с людьми, к мнению которых прислушиваются. Так они вышли на нас — Haiku.dev — партнера по разработке и внедрению цифровых и коммуникационных продуктов для бизнеса.
Вместе с клиентом мы прошли 9 месяцев разработки и готовы поделиться опытом, что стоит учитывать при создании IT-продукта. Если кратко, вот несколько советов:
- Не изобретайте велосипед, а протестируйте обкатанную модель.
- Отдавайте выбор технического стека на откуп исполнителю.
- Разберите готовый дизайн продукта по косточкам.
- Тестируйте нагрузку, чтобы избежать хабраэффекта.
- Предусмотрите механику выхода на новые рынки.
- Fake it till you make it — притворяйтесь, пока не реализуете.
- Закладывайте на разработку продукта 9 месяцев.
- Учитывайте риски инвестиций в IT-стартапы.
- Помните, что разработка похожа на растение.
- Начните привлекать трафик, несмотря на страх показать проект миру.
- Сформируйте сбалансированную команду разработки.
Не изобретайте велосипед, а протестируйте обкатанную модель
Проект нашего клиента сфокусирован на услугах для собственников недвижимости. В Америке 10–20 подобных сервисов, а по миру еще больше. Поэтому при разработке продукта не требовалось изобретать что-то принципиально новое.
Чтобы снизить риски стартап-проектов, клиент выбрал надежную обкатанную модель с зарубежных рынков и тестирует гипотезу на растущем рынке недвижимости Дубая.
Отдавайте выбор технического стека на откуп исполнителю
На момент обращения к нам в команде клиента был специалист по UX/UI, frontend-разработчики и представление об архитектуре продукта. Также были покрыты UX/UI порядка 80% функциональности сервиса. Требовался бэкендер и DevOps-инженер.
Поскольку мы неоднократно реализовывали подобные проекты, мы понимали, какие кусочки бэкенда должны быть проработаны. Обычно есть 2 варианта, на чем они должны быть реализованы:
- Клиент сам выбирает подходящий стек. Например, Ruby. И мы предоставляем квалифицированного разработчика в команду.
- Клиент ставит задачу, а выбор технологии отдает на откуп нам.
Отдав выбор техстека на сторону подрядчика, клиент получает буст в скорости, поскольку исполнитель работает с инструментом, к которому привык, и на котором реализовал множество проектов.
Для этого клиента мы сами выбирали технологию. Для бэкенда требовался серьезный специалист с хорошим бэкграундом и высокой скоростью работы. Это было основное требование. Язык был вторичен, рассматривали Node.js, либо Python. Согласовали технологию с клиентом — в проекте использовался Python — и предложили надежного бэкендера.
Разберите готовый дизайн продукта по косточкам
Продукт клиента начался с проектирования и дизайна. Задумав реализовать идею платформы, инвестор проекта нанял дизайнера, с которым они год прорабатывали нюансы будущего сервиса в Figma. Когда стало понятно, как будет выглядеть сервис, инвестор решил перейти к разработке.
Для разработки важна первичная подготовка и проектирование. Наличие дизайна не обязательно. Но важно, чтобы он был создан с участием команды управления или разработки. А если дизайн уже готов, его нужно подробно разбирать, поскольку если за ним не стояла аналитическая работа, разработчикам будет сложно.
Все потому, что первое увиденное кажется лучшим решением из возможных. Сложно выбросить из головы готовый дизайн. Но проблема в том, что если ты сам не приложил руку к этому к проектированию, некоторые вещи станут понятны только спустя время.
Например, в этом проекте мы пять раз меняли логику авторизации без изменений в интерфейсе. Базово мы не проработали ее механику и не обнаружили подводных камней. Оказалось, что в арабском мире сложности с авторизацией через Apple и очень высокая стоимость SMS — порядка 10 центов за транзакционную SMS, в противовес 1 центу в США.
Тестируйте нагрузку, чтобы избежать хабраэффекта
DevOps-инженер подготовил масштабируемую платформу в AWS c учетом региональности и CDN-специфики. Были подняты dev- / test- / prod-окружения, а гео серверов выбиралась из подхода быть максимально близко к конечным пользователям продукта.
Он занимался тестированием нагрузки, помогал с настройкой инфраструктуры для предотвращения серьезных проблем при росте числа пользователей. Хотелось заранее подготовиться к хабраэффекту — лавинообразному наплыву числа пользователей, который потенциально может случиться после публикации пресс-релиза или маркетинговой активности.
Предусмотрите механику выхода на новые рынки
В разработке закладывали возможности и функции расширения и укрепления продукта, а также его локализацию в других странах.
Мы сохраняем единую кодовую базу с необходимыми доработками под каждый регион и изолированными базами данных под них. Это дешевле, чем поддержка нескольких копий с почти одинаковой функциональностью.
Fake it till you make it —притворяйтесь, пока не реализуете
Важной задачей проекта, которую мы решали с помощью искусственного интеллекта, было наполнение каталога. Здесь использовали простой подход fake it till you make it (притворяйся, пока не реализуешь). Чтобы привлекать на сервис исполнителей и клиентов, нужно самостоятельно добавить критическую массу данных.
Чем больше поставщиков будет на платформе, тем больше пользователей придет. Чем больше пользователей придет, тем легче будет привлекать поставщиков. Это замкнутый круг, похожий на работу маркетплейсов.
Мы спарсили базу подрядчиков из других каталогов, выделили около трех тысяч сервисных компаний для публикации. Но посчитали, что вручную только на проверку и публикацию этой информации нам потребовалось бы около полугода. Поэтому решили делегировать обработку и структурирование данных искусственному интеллекту.
Закладывайте на разработку продукта 9 месяцев
Наша работа над продуктом началась в феврале прошлого года. Первоначально договорились на полгода сотрудничества.
Подобные проекты очень похожи на детей: их разработка в среднем занимает около 9 месяцев. При этом затягивать с запуском тоже не нужно.
По завершении оговоренных шести месяцев клиент купил еще 3 месяца до искомых 9. После полугода мы вдвое сократили количество ресурсов, так как понимали, что этого будет достаточно для решения текущих задач. Провели технический запуск продукта, обнаружили все баги, требующие исправления. А в октябре — декабре занимались их устранением, чтобы продукт был готов к привлечению трафика.
Учитывайте риски инвестиций в IT-стартапы
Для нас заказчик стал примером идеального клиента. Понимание специфики разработки IT-продуктов и сопутствующих рисков — редкое явление за пределами IT-сообщества. Стартапы — это всегда капиталоемкая история. Риски высоки. Но соотношение риск-прибыль и относительно недорогое масштабирование через интернет-каналы привлекает предпринимателей в IT.
Инвестор, прошедший путь от идеи до готового продукта, уже потратил сотни тысяч долларов. Однако, пока не ясно, будет ли проект успешным. Это как экспедиция на Эверест. Вы с командой преодолеваете сложный путь к вершине. И так просто на середине пути обратно не повернешь.
Большинство инвесторов вкладывают деньги в более понятные и прибыльные сферы, такие как недвижимость или фондовый рынок.
Вложение средств в IT-проекты — всегда риск. Особенно для тех, кто не разбирается в этой сфере.
Например, те, кто не понимает специфики разработки, говорят: давайте совместим телегам с инстаграмом*, добавим гугл-карты, а сверху посыпем тиндером — получится суперприложение для Дубая.
Теоретически это возможно, но работать с такими идеями сложнее, так как люди не понимают, что происходит «под капотом», и с какими проблемами и расходами можно столкнуться в процессе разработки через полгода или год. Они не понимают, как продукт будет масштабироваться на стороне инфраструктуры при росте пользовательской базы. И главное — каким будет рост стоимости поддержки такой инфраструктуры.
Помните, что разработка похожа на растение
Обычно людям сложно объяснить, что такое разработка продукта. Они думают, что это как строительство дома. Дом построен, строители уезжают, открываются продажи и въезжают жильцы. Но на самом деле это не совсем так.
Разработка больше похожа на живое растение. На нем периодически возникают новые листья — новые гипотезы или кусочки продукта. Они могут «выстрелить», и из веточки вырастет дерево. А иногда разработка начинает реализовывать фичи, которые никакому не нужны и не будут восприняты рынком. Здесь важно вовремя их «отстричь», чтобы они не росли и не поглощали энергию, которую можно направить в другое русло.
В процессе разработки все постоянно меняется — требования, рынок, дизайн, интерфейс, backend. Все элементы продукта находятся в постоянном движении. И наша задача — чтобы этот хаотичный процесс выстроился в продуктовую историю. Важно следить за изменениями и адаптировать под них продукт.
Начните привлекать трафик, несмотря на страх показать проект миру
Любой проект рождается несовершенным, и у его создателей возникает страх начать привлекать клиентов и показать продукт миру. Особенно в Дубае, где недостаточно создать продукт, так как все строится на личных связях, и важен социальный капитал. Здесь важно выходить на поставщиков, рассказывать о проекте и привлекать их к сотрудничеству.
Трафик — это следующий этап в развитии проекта. Без него продукт не будет развиваться и умрет. С трафиком появляется обратная связь, и становление продукта проходит гораздо быстрее.
Наша следующая задача с этим клиентом состоит в привлечении трафика к продукту. В России большинство SEO-специалистов работают с «Яндексом». И среди маленькой прослойки работающих с Google сложно найти свободных специалистов, которые могут качественно выполнить работу. Несмотря на это у нас в команде появились ребята, которые занимаются SEO в Google, и могут решить эту задачу.
Сформируйте сбалансированную команду разработки
Команда разработки подобна клетке организма, жизнеспособность которой обеспечивают ядро, цитоплазма, митохондрии и другие элементы. Так, в команде разработчиков должны быть PM (project manager), аналитик, дизайнер, frontend, backend, DevOps и, желательно, кто-то, кто работает с базами данных. По мере роста проекта появляются support-специалисты, маркетологи, BizDevs и другие.
При реализации главное — понять, кого не хватает для сбалансированной работы, и нанять их.
Мы в Haiku.dev помогаем найти на рынке людей, обладающих нужными компетенциями, и сбалансировать их для организации максимально эффективной работы над IT-проектом. Если хотите укомплектовать команду, заказать разработку, интегрировать ПО или вам нужна другая помощь в создании цифрового продукта, оставьте заявку на сайте.
*Meta признана экстремистской организацией в России