Исходная ситуация
Заказчик пришёл с идеей сервиса для аукционов недвижимости. Пользователи должны были иметь возможность выставлять объект на торги, участвовать в аукционе, выигрывать его и связываться с владельцем недвижимости для дальнейшей сделки.
Проект уже был частично разработан другой подрядной организацией, но прежняя команда прекратила взаимодействие с заказчиком и не выполнила свои обещания. Поэтому клиенту нужно было быстро найти команду, которая сможет подхватить проект, разобраться в уже сделанной части и продолжить разработку.
Для заказчика были критичны сроки и бюджет. Он хотел быстрее вывести продукт на рынок, получить первые продажи и выполнить обязательства перед инвесторами.
Основная бизнес-боль заключалась не только в разработке приложения, а в необходимости вернуть проект в управляемое состояние: собрать команду, синхронизировать разные направления разработки и довести продукт до релиза.
Задачи проекта
Подхватить частично разработанный сервис после предыдущей подрядной команды.
Разобраться в текущем состоянии продукта и продолжить разработку без полной остановки проекта.
Разработать мобильное приложение для iOS.
Разработать мобильное приложение для Android.
Разработать веб-сайт и веб-сервис для работы с аукционами недвижимости.
Реализовать механику выставления объектов недвижимости на аукцион.
Реализовать участие пользователей в торгах и выбор победителя аукциона.
Проработать платежную механику и удержание сервисной комиссии.
Организовать параллельную работу веб-, мобильной и backend-разработки.
Довести MVP до релиза в рамках согласованных требований, сроков и бюджета.
Решение
Что мы предложили
Мы предложили не начинать проект заново, а подхватить уже частично разработанный сервис, привести работу в управляемый процесс и сфокусироваться на запуске MVP.
Для заказчика это было важно: ему нужно было не просто «получить код», а быстро вернуть проект в движение, контролировать бюджет и показывать инвесторам прогресс. Поэтому команда выстроила разработку вокруг практичного результата: мобильные приложения, веб-сервис и базовая логика аукциона, достаточная для выхода продукта в релиз.
Что было сделано
Команда закрыла техническую часть проекта и организовала параллельную разработку по нескольким направлениям:
iOS-приложение;
Android-приложение;
веб-сайт;
веб-сервис;
backend-часть;
DevOps-поддержка;
аналитика и проектное управление.
В продукте была реализована логика аукционов недвижимости: пользователь мог выставить объект, другие участники могли участвовать в торгах, а после завершения аукциона победителю открывались контактные данные владельца.
Также была проработана платежная логика с сервисной комиссией. По задумке, комиссия должна была снижать риск недобросовестного поведения участников сделки и работать как компенсационный механизм в случае попытки обмана.
Как был организован процесс
Проект вёлся через спринты. Так как заказчик выступал product owner и часто менял требования, команда заранее обсуждала с ним пожелания, фиксировала критерии приёмки и ожидания от результата.
Это помогало не превращать разработку в хаотичный поток изменений. Команда регулярно проводила приёмку, показывала заказчику результат и корректировала приоритеты бэклога, чтобы наиболее важные функции быстрее попадали в релиз.
Отдельное внимание уделялось синхронизации команд. Веб, iOS, Android и backend-разработка шли параллельно, поэтому часть специалистов могла двигаться быстрее, а часть — отставать. Руководитель проекта перераспределял задачи так, чтобы команда сохраняла общий темп и возвращалась в план.
Какие инструменты, технологии или подходы использовались
Из транскрибации указаны следующие направления и подходы:
iOS-разработка;
Android-разработка;
frontend-разработка;
backend-разработка;
DevOps;
работа спринтами;
сбор требований;
критерии приёмки;
управление бэклогом;
приоритизация задач;
параллельная разработка нескольких продуктовых частей.
Конкретные технологии, языки программирования, фреймворки и инфраструктурные решения в транскрибации не указаны. В интервью отдельно отмечено, что технологии лучше уточнить у CTO.
Ход проекта
Подхватили проект после предыдущей команды
Проект Winbi начался для нас не с чистого листа. До этого заказчик уже работал с другой подрядной организацией, но команда прекратила взаимодействие и не довела сервис до результата.
В такой ситуации важно было не просто продолжить писать код, а быстро понять, что уже сделано, где находятся риски и как вернуть проект в нормальный рабочий ритм.
Что было особенно важно: заказчику нужно было сохранить темп разработки, потому что за проектом стояли инвестиции, ожидания по срокам и желание быстрее выйти на рынок.
Сфокусировались на MVP, а не на бесконечной разработке
Идея продукта была понятной: создать площадку, где недвижимость можно продавать через аукцион. Для одних пользователей это способ быстрее продать объект, для других — возможность поучаствовать в торгах и попробовать купить недвижимость на выгодных условиях.
Также продукт был интересен не только физическим лицам, но и застройщикам. Они могли выставлять построенные объекты на аукцион и быстрее привлекать деньги клиентов к своей недвижимости.
Команда сфокусировалась на том, чтобы довести продукт до работающего MVP: реализовать ключевые сценарии, запустить приложения и веб-сервис, а не распылять бюджет на второстепенные функции.
Собрали команду под разные части продукта
Для проекта была сформирована команда, которая закрывала сразу несколько направлений:
iOS-разработку;
Android-разработку;
frontend;
backend;
DevOps;
аналитику;
дизайн;
проектное управление.
Со стороны заказчика в проекте участвовал маркетолог, а сам заказчик выступал product owner. Он отвечал за продуктовую стратегию и продвижение, а наша команда закрывала техническую реализацию.
Важно: для заказчика это снижало нагрузку: ему не нужно было самостоятельно собирать техническую команду и управлять разными направлениями разработки.
Настроили работу с меняющимися требованиями
Одной из главных сложностей было то, что заказчик часто менял требования. Это нормальная ситуация для MVP и стартап-проекта, но без понятного процесса она быстро приводит к срыву сроков и росту бюджета.
Чтобы удерживать проект в управляемом состоянии, команда работала спринтами, заранее обсуждала пожелания заказчика и фиксировала критерии приёмки. Это помогало отделять важные изменения от второстепенных и быстрее принимать решения по бэклогу.
Сложность проекта: требования менялись по ходу работы.
Решение: команда использовала спринты, критерии приёмки и регулярную приоритизацию задач.
Синхронизировали параллельную разработку
Проект включал сразу несколько частей: iOS, Android, веб и backend. Такие направления редко движутся с одинаковой скоростью: одни специалисты могут закрывать задачи быстрее, другие — сталкиваться с зависимостями или задержками.
Чтобы не терять общий темп, руководитель проекта перераспределял задачи между участниками. Если одна часть команды была впереди, её работа корректировалась так, чтобы помочь остальным направлениям и вернуть проект в общий план.
Проработали платежную и юридически чувствительную часть
В продукте планировалась платежная логика и сервисная комиссия. Эта часть была важна не только технически, но и юридически: сервис должен был работать с деньгами и пользовательскими данными.
Юридические вопросы решал сам заказчик, но команда помогала рекомендациями по специалистам, которые могли закрыть такие задачи. Это позволило не смешивать зоны ответственности и при этом поддерживать заказчика в важной части проекта.
Довели MVP до релиза
Разработка заняла около 9 месяцев. В результате были реализованы мобильные приложения для iOS и Android, веб-сайт и отдельный веб-сервис. Приложения были выложены в RuStore, Google Play и App Store.
Заказчик получил рабочий MVP в рамках согласованных требований. По ходу проекта проводились регулярные приёмки, на которых заказчик подтверждал, что результат его устраивает.
Результат: продукт вышел в релиз, а заказчик получил реализованное приложение и веб-сервис в рамках оплаченного объёма работ.
Сложности и ограничения
Сложность: Проект нужно было подхватить после другой подрядной команды, которая не выполнила обязательства и прекратила работу. Как решили: Команда разобралась в частично разработанном сервисе, собрала техническую команду и продолжила разработку, не начиная проект полностью заново.
Сложность: Заказчик часто менял требования, так как сам выступал product owner. Как решили: Работали спринтами, заранее обсуждали пожелания, фиксировали критерии приёмки и ожидания от результата.
Сложность: Разработка шла параллельно по нескольким направлениям: iOS, Android, веб и backend. Как решили: Руководитель проекта синхронизировал команды, перераспределял задачи и помогал возвращать отстающие направления в общий план.
Сложность: В проекте были юридические вопросы, связанные с комиссией, деньгами и пользовательскими данными. Как решили: Юридическую часть закрывал заказчик, а команда помогала рекомендациями специалистов, которые могли решить эти вопросы.
Сложность: Финансирование зависело от инвестора и поступало постепенно, из-за чего возникали задержки оплат. Как решили: Команда не останавливала работу сразу, а позже договорилась с заказчиком о предоплате и юридически зафиксировала сроки оплаты.
Сложность: Ближе к концу инвестор свернул проект и перестал выделять средства. Как решили: Команда завершила работы в рамках оплаченного и согласованного объёма. Не все желаемые функции были реализованы, но ключевой MVP был доведён до релиза.
Результат
В результате заказчик получил рабочий MVP продукта Winbi: мобильное приложение для iOS, мобильное приложение для Android, веб-сайт и отдельный веб-сервис.
Были реализованы ключевые сценарии продукта:
размещение объекта недвижимости на аукцион;
участие пользователей в торгах;
выбор победителя;
передача контактных данных владельца недвижимости победителю;
проработка платежной логики и сервисной комиссии;
запуск приложений в RuStore, Google Play и App Store.
Разработка заняла около 9 месяцев. За это время команда довела проект от частично разработанного сервиса до MVP, который вышел в релиз.
Заказчик получил реализованное решение в рамках согласованных требований и оплаченного объёма работ. По ходу проекта проводились регулярные приёмки, и, согласно транскрибации, клиенту результат нравился.
Важно отметить: не все желаемые функции были реализованы, потому что финансирование проекта завершилось. При этом команда выполнила согласованный объём и довела ключевой продукт до рабочего состояния.
Почему этот кейс важен для похожих клиентов
Этот кейс будет близок компаниям и предпринимателям, которые уже начали digital-продукт, но столкнулись с хаосом в разработке, сменой подрядчика, ограниченным бюджетом или необходимостью быстро выйти на MVP.
Мы умеем подхватывать проекты не только «с нуля», но и из сложной точки: когда часть продукта уже сделана, требования меняются, сроки давят, а заказчику нужно не утонуть в технических деталях. В таких проектах важна не только разработка, но и управление процессом, синхронизация команды и фокус на том, что действительно нужно для запуска.
