Заказчик — команда с инвестором и владельцем продукта, у которого были собственные яхты и прямой доступ к рынку судовладельцев. Задача — создать сервис, который позволяет арендовать яхту для морских прогулок и сдавать её в аренду, управляя процессами удалённо.
На старте речи о разработке не шло: клиент пришёл только за предпроектной аналитикой. Нужно было проанализировать конкурентов и аудиторию, выяснить запросы владельцев яхт и арендаторов, определить функционал будущего продукта.
Ключевая особенность: у продукта две большие группы пользователей (судовладельцы и арендаторы) с принципиально разными сценариями — плюс в перспективе ещё две роли (капитан и агент). Это требовало продуманной архитектуры с самого начала.
Управленческие решения
1. Инициировал возврат клиента через демонстрацию экспертизы
Клиент пришёл только за аналитикой — о разработке речь не шла, и у него была знакомая команда в Лондоне, которая планировала заниматься реализацией. Мы как студия этого изначально не знали. Когда аналитика была готова, ситуация прояснилась.
Решение: я не стал принимать это как данность. Оценил ситуацию, описал арт-директору и предложил рискнуть — подготовить мудборд и дизайн-концепцию, чтобы показать уровень экспертизы и то, как мы видим продукт. Это была инициатива с моей стороны, а не запрос клиента.
Результат: клиент взял паузу, но вернулся и выбрал студию вместо своей знакомой команды. Проект был реализован у нас — от аналитики до запуска.
Это ключевое решение кейса: вместо того чтобы ограничиться оплаченным этапом аналитики, я увидел возможность для более крупного проекта и организовал её.
2. Согласовал смену формата с приложения на сайт
Изначально продукт задумывался как приложение. В процессе разработки стало понятно, что для своевременного запуска логичнее начать с сайта, а приложение сделать позже.
Решение: вынес это на обсуждение с заказчиком, обосновал с точки зрения сроков и приоритетов запуска. Формат был пересмотрен.
Результат: сервис запустился в срок в формате сайта, с возможностью бронирования и с компьютера, и с телефона — без необходимости скачивать приложение.
3. Согласовал с заказчиком переосмысление системы бронирования
Заказчик хотел систему бронирования, похожую на Booking.com. Это разумный ориентир, но переносить его один в один на продукт с другой спецификой (аренда яхты, а не номера) было неоптимально.
Решение: взял за основу саму идею и удачные решения, но предложил переосмыслить их под задачи продукта. Согласовал с заказчиком отход от прямого копирования.
Результат: система бронирования получилась под специфику аренды яхт — с гибкой длительностью (от часов до дней), привязкой к часовому поясу судна и сценариями отмены.
4. Управлял техническим риском по «тяжёлому» календарю
Самый сложный элемент разработки — календарь бронирования. У разных ролей он выглядит по-разному (арендатор видит доступность, владелец — брони), и одновременная проверка всех данных по одному судну могла приводить к низкой скорости загрузки.
Решение: согласовал с командой подход с денормализацией данных — разделение на более мелкие таблицы («день», «время», «бронирование»), чтобы поиск доступного времени не тянул весь массив. Также заложил в требования гибкую логику бронирования, учёт часовых поясов и сценарии отмены в зависимости от статуса оплаты.
Результат: календарь работает быстро и корректно при разных сценариях, без просадки по скорости.
5. Координировал работу с внешними специалистами на этапе SEO
На этапе SEO-оптимизации я как РП взял на себя координацию с внешними SEO-специалистами — это был отдельный трек, который требовал синхронизации с разработкой.
Решение: выстроил взаимодействие между внешней командой и внутренней разработкой, чтобы SEO-требования учитывались в продукте без ломки уже готовой логики.
Результат: SEO-этап прошёл без конфликтов с архитектурой продукта.
Результат проекта
- Сервис запущен: бронирование яхт доступно с компьютера и телефона, без установки приложения
- Для собственников и агентов сократились расходы на привлечение клиентов, появился доступ к более широкой аудитории
- Заложена архитектура под будущие роли — «капитан» и «агент»
- Клиент остался доволен сотрудничеством (см. отзыв)
Отзыв клиента
«Начиная любой бизнес, профессионализм и доверие к команде являются одним из главных критериев успеха. Сотрудничество с Pyrobyte ничем не отличалось от работы с инхаус-командой. Их заинтересованность в нашем успехе позволяла нам оперативно тестировать новые гипотезы, создавать новый функционал и анализировать результаты работ.»
— Олег, Yaves
Чему научился
- Если клиент пришёл за одним этапом — это не значит, что проект ограничивается этим этапом. Иногда стоит проявить инициативу и показать, что можешь больше. В Yaves именно так проект вырос из аналитики в полную разработку.
- Технические риски лучше снимать на этапе проектирования, а не в конце. «Тяжёлый» календарь бронирования мы разгрузили через денормализацию данных заранее — и получили быстрый поиск доступного времени без просадок по скорости.
- Прямое копирование чужого решения редко работает. Заказчик хотел систему бронирования как у Booking, но за успешным интерфейсом крупного сервиса стоит огромный пласт работы: UX-исследования, маркетинг, продуктовая разработка, сформированная аудитория. В социальных сервисах ключевую роль играет сетевой эффект, который складывается годами. Многие удачные решения появляются не на старте, а через UX-исследования, A/B-тесты, проверку гипотез и работу с метриками. Скопировать фасад без этой базы — значит получить внешне похожий продукт без работающей механики.
- Разница между проектом и продуктом. В Yaves я вёл проект: сроки, требования, релиз. Ближе к концу, после «Вдохновлённых» Марти Кагана, я начал видеть разницу. В проектном управлении, если требования выполнены в срок и в рамках бюджета, проект можно считать успешным. Но продукт живёт дольше: его судьба зависит от того, решает ли он реальную задачу пользователя. Работа с пользователями — та часть, которую я раньше недооценивал, а теперь считаю основой.