В конце весны 2018 года к нам поступил очень интересный заказ на разработку веб-сервиса для риэлторов. Тогда бриф от заказчика - Генерального директора агентства недвижимости "Остоженка", Салкина Сергея Сергеевича, был весьма скромным, и масштабы проекта не поражали воображения. Но, в дальнейшем мы смогли развить этот сервис от узконаправленного инструмента до полноценной платформы для сообщества профессиональных участников рынка недвижимости. Сегодня мы расскажем о вызовах, с которыми пришлось столкнуться нашей команде в процессе проектирования, разработки, тестирования и запуска этого проекта. Итак, «PUSH-KA: за кулисами».

К моменту, когда к нам обратились представители «Остоженки», мы уже реализовали множество проектов с похожим функционалом, включая и CRM, и специализированные системы управления бизнес-процессами для самых разных отраслей, от ритейла и банкинга до табачной промышленности. Поэтому для нас вполне знакомой была специфика таких продуктов – разворачивание таких систем, их настройка под потребности представителей конкретной отрасли, оперативная адаптация под особенности рынка. Поэтому приступить к разработке мы смогли максимально оперативно. С другой стороны, этот проект стал для нас ценным опытом в плане погружения в нюансы разработки для рынка недвижимости: работа с распространенными форматами фидов («ЦИАН», «Яндекс.Недвижимость» и т.д.), периодичность и особые настройки публикации объектов недвижимости, уникальные механики продаж объектов – разработка инструмента, позволяющего решать связанные с этим специализированные задачи, стала для нас отличным вызовом. И мы с ним справились!

В конце мая 2018 года мы согласовали с «Остоженкой» бизнес-описание требуемого сервиса. Уже тогда мы сошлись с заказчиком на максимальном воплощении итеративно-инкрементального подхода для данного проекте. Иначе говоря, мы решили максимально сократить путь от начала разработки до выхода результата на рынок и спланировали с заказчиком совсем минимальный MVP, необходимый для запуска проекта. Да, уже тогда у заказчика было стратегическое видение множества будущих улучшений и этапов развития, но нам удалось найти компромисс в плане того, что из этого может войти в MVP, а что стоит отодвинуть на более поздние этапы. Забегая вперед, не можем не упомянуть – нам очень комфортно было взаимодействовать с заказчиком по этому проекту! Со временем мы все больше подстраивались под особенности рынка недвижимости, а заказчик все больше адаптировался к ритму и нюансам веб-разработки. С уверенностью можем сказать, что и для заказчика, и для нас это стало мощным стимулом к развитию.

Изначально сервис планировался для решения двух ключевых задач. Во-первых, существенно упростить и оптимизировать бизнес-процессы для «Остоженки», позволяя быстро и без проблем управлять публикацией объектов недвижимости на ключевых площадках. Во-вторых, превратить этот инструмент в сервис-агрегатор, позволяющий различным участникам рынка недвижимости быстро и просто решать те же задачи.

MVP включал в себя только то, что нужно риэлтору для размещения объектов на внешних сервисах. По сути, мы должны были разработать функционал, позволяющий агенту создавать и сохранять в системе объекты недвижимости, размещать их на 6 крупных площадках-агрегаторах. При этом агент должен был получить возможность управлять настройками размещения (на какие площадки объект будет опубликован, на какие – нет), а у администратора должна была быть возможность управлять настройками публикации у конкретных пользователей. При этом предполагалось, что систему каталогов по географическим наименованиям, а также базу по жилым комплексам страны мы будем подтягивать из внешних источников (в первую очередь – из Яндекса).

На этом этапе в системе предполагалась очень простая ролевая модель: из ролей были только «гость» (обычный пользователь системы), «агент» и «администратор». «Агентами» должны были стать пользователи из «Остоженки», «гостями» - сторонние участники, «Администратор» - роль для управления сервисом. При этом тогда планировалось, что у гостей будут два «подтипа» - «брокер» и «собственник» (соответственно для риэлторов и для владельцев объектов недвижимости). Уже в дальнейшем, трансформируя ролевую модель, мы разделили эту роль на «Гость-брокер» и «Гость-собственник». Но об этом позднее.

Уже на этапе MVP, немного вникнув в обновленные потребности заказчика, мы реализовали несколько фич, которых не было в изначальном ТЗ. В том числе:

• Сделали функционал работы пользователей с клиентской базой. Теперь наш пользователь-риэлтор получил возможность добавлять в базу своих клиентов и увязывать их с объектами, которыми они интересуются.
• Добавили функционал подразделений. Узнав от заказчика особенности его бизнес-структуры, мы уже тогда внедрили возможность привязывать зарегистрированных пользователей к определенным подразделениям, а также завязывать определенные права и полномочия именно на подразделения. Какие-то права вязались на роль, какие-то – на подразделения; нам пришлось проделать изрядную работу, чтобы права для ролей и подразделений гармонично увязывались, не дублировали функционал и решали разные задачи с точки зрения своих бизнес-смыслов. Используя введенный нами функционал, заказчик смог создать ряд подразделений как для внешних пользователей, так и для своих сотрудников и привязать к ним доступы таким образом, чтобы максимально удобно решать свои бизнес-задачи.
• Добавили отдельный раздел для управления фидами
• Сделали возможность для сотрудников заказчика обновлять данные по жилым комплексам вручную
• Сделали справочный раздел, где в иерархическом порядке хранятся добавляемые заказчиком документы, необходимые агенту для работы

Всего работы по MVP заняли 3 месяца. За лето 2018 мы смогли пройти путь от обсуждения с заказчиком бизнес-потребностей до запуска первой версии продукта.

Первый этап развития сервиса можно отнести со старта до примерно конца 2018 – начала 2019 года. Тогда сервис в большей степени работал как удобный инструмент для сотрудников заказчика и только начинал позиционироваться как внешний продукт для участников рынка недвижимости.

Запустив MVP, мы тут же приступили к проработке разных качественных улучшений. Во-первых, добавили возможность публикации на разные площадки: в совокупности сервис получил возможность публикации на 21 различных площадках (включая 7 крупных и 15 поменьше).

Во-вторых, увеличили количество форматов загрузки фидов. Не секрет, что для рынка недвижимости существуют 3 наиболее распространенных формата XML-фидов. На ранней стадии работали только с «циановским», со временем удалось приспособиться ко всем форматам, имеющимся на рынке.

Публикация объектов недвижимости в фиде включает в себя массу нюансов. Объект недвижимости с точки зрения архитектуры данных – сущность, включающая до 50 атрибутов. Все эти атрибуты должны отображаться на форме размещения объекта в удобном для пользователя формате и после публикации не только сохраняться в БД проекта, но и добавляться во все фиды для различных площадок, в которых пользователь был размещен. При этом мало соответствовать требуемой XML-структуре и требованиям по обязательности полей – нужно, чтобы парсер требуемой площадки корректно считывал данные по объектам, чтобы не допускались дубли ранее размещенных объектов (с учетом того, что ID для публикации у них иногда меняются в силу специфики бизнес-процесса), чтобы фотографии размещались корректно (для этого пришлось доработать обработчик фото, ужимающий их до нужного площадкам формата). При этом у площадок различные требования – определенные поля обязательны для одних площадок, но не нужны для других. Нам пришлось проделать изрядную работу, оптимизируя форму размещения объекта и состав атрибутов, чтобы и на все площадки объекты размещались без ошибок, и пользователю было удобно.

На этом этапе, несмотря на предпринятые усилия по группировке атрибутов в user-friendly формате, форма размещения объекта у нас выглядела все еще громоздко и не во всем удобно. Во многом это объяснялось ограничениями в ресурсах и сроках. Уже потом, в профессе рефакторинга фронтенда, мы пересмотрели многие интерфейсы и переделали эту форму полностью, руководствуясь лучшими практиками в этой сфере (в конце концов, не мы первые придумываем удобную форму для размещения объектов недвижимости)..

Тогда же мы смогли состыковать с сервисом первую витрину, где в открытую публиковались объекты, размещаемые на сервисе. По сути, витрина была собственной альтернативой агрегатору, где внешний посетитель мог получить всю информацию о размещенных объектах недвижимости. Помимо этого, витрина сообщала и о команде «Остоженки», и о предлагаемых услугах и сервисах, и собственно о размещенных объектах. При этом все размещенные объекты подтягивались с базы основного сервиса PUSH-KA через REST API.

Примерно после начала 2019 года постепенно происходило изменение самого позиционирования бизнес-смыслов сервиса. Если в самом начале делался упор на решение более утилитарных задач для риэлтора («мы делаем сервис, позволяющий быстро и удобно закинуть объявления о ваших объектах на кучу внешних площадок»), то в дальнейшем смысл расширился до универсальной площадки для профессиональных участников рынка. Из «размещалки объектов» сервис все больше превращался в место, где риэлтор может, зайдя в систему, не только разместить объект, но и получить множество различных услуг – по юридическим консультациям, связанным со спецификой его работы; по проверке на риски, по заказу выписки из ЕГРН, по оценке стоимости объектов и по многим другим направлениям. Также на такой платформе агент получает возможность взаимодействовать с другими участниками рынка, смотреть данные по объектам и клиентам в единой базе сервиса, вести свою базу продавцов и покупателей, заключать сделки.

Согласовав с заказчиком такое целеполагание по проекту, на втором этапе развития проекта мы смогли разработать много новых механик.

В частности, мы не только интегрировали в сервис платежную систему, но и обновили структуру веб-сервиса под новую финансовую модель, транслируемую заказчиком. Теперь у нас кроме сущности «Тариф» (она же «Формат партнерства») появилась сущность «Услуга». У одного пользователя может быть только один активный тариф, но несколько разных услуг. При этом и тарифы, и услуги могут изменить как роль пользователя. Так и его привязку к подразделению. Мы проработали логику, которая позволяет без конфликтов проводить все эти изменения в нужном порядке, причем с учетом приоритетов (к примеру, изменения доступов, связанные с услугами, приоритетнее изменений, связанных с тарифами). Это была долгая, непростая работа по адаптации структуры сервиса к новым реалиям.

По некоторым услугам мы сделали интеграции со сторонними сервисами. Множество интеграций строились по схожему принципу: мы разрабатываем связанную с разделом услуг уникальную форму, увязываем его с REST API интегрируемого партнера и после заполнения формы заявка улетает к партнеру. В ряде случаев мы еще и реализовали обратную связь для клиента – с получением по тому же REST обновлений по статусу обработки его заявок.

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

Кстати, о новых ролях и механиках. Узнав от заказчика об уникальной механике аукционных продаж, мы смогли создать под неё не только новую услугу, но и новую роль, новый метод размещения и целый пакет изменений «под капотом» проекта, заточенных под этот ограниченный во времени метод продаж объектов недвижимости.

И, наконец, самое главное. Мы смогли реализовать для заказчика специальную механику, которая позволяет, анализируя базу размещенных объектов недвижимости и базу запросов клиентов, формировать потенциальные сделки, находя объекты, «похожие» на те, которыми клиент уже интересовался.

Работает это примерно так (см. схему):

1. Некий клиент-1 хочет продать объект недвижимости (например, квартиру). Он просит своего агента разместить этот объект в публикацию. Агент-1 размещает его на PUSH-KA.RU и заодно сохраняет клиента в базе клиентов на сервисе.
2. Некий клиент-2 хочет купить объект недвижимости. Он просит своего агента найти что-то, подходящее под его запросы. Агент-2 сохраняет этого клиента в базе клиентов на сервисе и начинает искать подходящий объект.
3. В процессе агент-2 находит некий объект-2, размещенный агентом-3 на сервисе. Агент-2 сообщает об этом клиенту-2. Клиент-2 и агент-2 проводят переговоры, интересуются объектом, но по каким-то причинам отказываются от сделки (все может быть – может, не договорились о цене, а может, и вовсе не дозвонились по контактному телефону).
4. Все это время на сервисе работает «робот-сводник». Он мониторит изменения в базе клиентов и базе объектов. И как только он узнает, что клиент-2 интересовался объектом-2 – он проверяет все объекты в базе на предмет того, являются ли они похожим на запрос клиента-2. «Похожесть» определяется множеством параметров, включая площадь объекта, тип объекта, его географическое расположение, близость к метро и многие другие факторы.
5. Как только «робот-сводник» узнает, что объект-1 «похож» на объект-2 – он фиксирует в базе «потенциальную сделку» клиента-1 по объекту-1. Это отражается и на странице клиента, и на странице объекта. Таким образом, агент-1 и агент-2 узнают, что между их клиентами может быть потенциальная сделка.
6. Агент-1 и агент-2 связываются друг с другом и со своими клиентами, договариваются о сделке и фиксируют на сервисе уже полноценную сделку, куда включаются все участники (в том числе агент-1, клиент-1, агент-2 и клиент-2)
7. PROFIT!

Казалось бы, простая схема поиска «похожих» объектов и информирования о потенциальных сделках агентов существенно улучшает процессы для риэлторов, экономя им массу времени на поиск подходящих объектов вручную. Согласовав эту схему с заказчиком, мы реализовали эту механику в максимально дружественном для пользователя формате – теперь агенты, оплатившие доступ к «своднику», смогли увидеть «потенциальные» сделки и на странице объекта, и на странице клиента, и на странице каталога объектов (в виде счетчиков новых потенциальных сделок).

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

Третий этап развития сервиса, занявший 2020-2021 годы, вкратце можно охарактеризовать следующими ключевыми чертами:

1. Снова существенно меняется бизнес-модель – и мы снова гибко к ней адаптируемся
2. Решаем те вопросы, до которых ранее не доходили руки из-за приоритетов

Пройдемся по ключевым пунктам:

Опять меняется модель – меняются и механики

По мере развития сервиса эволюционировала и его бизнес-модель. Если на ранних этапах пользователи сервиса делились в основном на сотрудников заказчика и на новых внешних пользователей-одиночек, то теперь картина изменилась. Само сообщество пользователей, работающее на сервисе, стало включать в себя крупные группы профессионалов со своей спецификой ведения бизнеса. Адаптация сервиса под их нужды потребовала трансформировать работу с подразделениями внутри сервиса – фактически, создавая для каждого из них «сервисы внутри сервиса». Настроек подразделения стало больше, появилась возможность более гибко задавать настройки публикации под различные подразделения. Сами тарифные опции стали адаптироваться под целые группы пользователей, оплачивающие своё пространство под свои нужды.

Существенно изменилась и ролевая модель на сервисе. Если когда-то, на ранних этапах, у нас, по сути, были всего 3 роли (под администраторов, сотрудников заказчика и внешних пользователей), то теперь у нас появились 2 роли под новых клиентов (под собственников и под брокеров соответственно), отдельная триал-роль для ознакомительного доступа и целое многообразие платных ролей с разными возможностями. В целом поток пользователей и объектов в этот период настолько возрос, что нам пришлось заметно доумощниться в плане серверного пространства.

С учетом возрастающей роли новых подразделений изменилась и структура витрин сервиса. Если в самом начале у сервиса была лишь одна витрина (по сути, заменяющая собой старый сайт агентства заказчика), то теперь появилось как минимум пять витрин, часть которых уже была заточена под потребности отдельных автономных подразделений, созданных под агентства, оплатившие «групповые» тарифы взаимодействия с сервисом.

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

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

1. Куратор отдельно взятой амбассадорской программы делает так, чтобы к потенциальному амбассадору попала реферальная ссылка. Он может разместить её на своем сайте / странице в соцсетях или иным способом распространять её среди своей аудитории. Кураторов может быть несколько, они могут быть связаны с отдельными организациями, которые, помимо прочего, позволяют своим участникам (или связанным с ними лицами) зарабатывать таким образом.
2. Амбассадор регистрируется на сервисе. При этом в механику реферальной программы уже зашита автоматическая привязка амбассадора к куратору после регистрации.
3. Амбассадор находит потенциального клиента и рассказывает ему, насколько некий риэлтор в плане своих услуг подойдет для решения его задач. Клиент соглашается с его доводами.
4. Амбассадор создает в базе лидов новый лид, для которого указывает контактные данные этого потенциального клиента. При этом лид автоматически привязывается и к куратору, и к самому амбассадору.
5. После подтверждения готовности лида взаимодействовать с указанным клиентом куратор на основе лида создает в БД клиентов нового клиента, после чего привязывает его вручную к агенту. В процессе взаимодействия лида с амбассадором могут быть изменения в плане привязки услуг конкретного агента (к примеру, амбассадор может рассказывать об услугах не конкретного агента, а определенного агентства, имеющего свое подразделение на PUSH-KA), поэтому привязка клиента к агенту осуществляется только на этом этапе.
6. При этом клиент также привязывается и к амбассадору, который привел лид, на основе которого появился этот клиент.
7. Агент видит, что у него появился новый клиент, связывается с ним и заключает с ним сделку. Сделку он также заводит на сервисе, и она отображается не только у агента, но и у амбассадора, который привел ему этого клиента.
8. Амбассадор получает возможность мониторить сделку, созданную на основе приведенного им клиента, и отслеживать её статус. Как только он видит, что сделка доведена до завершения, он получает право запросить у агента своё вознаграждение.

Всю описанную модель мы реализовывали в привязке к сложной структуре подразделений и партнёров. Под механику кураторов, ведущих амбассадоров, были созданы специальные партнёрские роли, и появились целые отдельные разделы в админпанели сервиса, позволяющие мониторить работу с амбассадорами.

Улучшение визуалики

Как известно любому PO, в случае наличия сжатых сроков планирования всегда приходится чем-то жертвовать в угоду приоритетным целям. Иногда это какие-то некритичные элементы функционала, иногда – целые блоки возможностей. В нашем случае довольно долго приходилось жертвовать визуальными «красивостями» интерфейса в угоду его практичности и функциональности.

Когда все основные бизнес-механики на сервисе были доведены до ума, мы вплотную занялись переделкой визуальной составляющей. Обновили страницы просмотра объекта, клиента, существенно обновили форму размещения объекта, сделав её более близкой к тому, как подобные формы выглядят на крупных агрегаторах недвижимости.

Помимо прочего, мы также сделали крупный и динамически изменяемый по ряду параметров раздел FAQ с инструкциями для пользователей, дав возможность заказчику самостоятельно изменять его структуру и состав (включая, в том числе, видеоинструкции).

По механикам сводника и управлению сделками мы также провели изрядную работу, сделав удобный механизм перехода от потенциальных сделок к реальным.

Пока мы менялись – менялись и ключевые площадки-агрегаторы объектов недвижимости. За все время существования проекта практически не прекращались с нашей стороны активности по адаптации механик размещения объектов к постоянно изменяющимся правилам площадок. С учетом того, что площадки зачастую берут деньги с сервиса за каждый выход (если объект недвижимости один день провисел на площадке как объявление – это считается выходом), нам приходилось адаптировать собственную финансово-техническую модель, чтобы учитывать выходы объявлений с учетом того, как это делают площадки (особенно – с учетом того, что площадка может проверять наш фид 2-3 раза в день, а мы его можем обновлять много раз в течение суток с учетом обновлений, вносимых пользователями).

Для нас в Аксиоматике важнее всего было правильно выстроить работу с заказчиком, адаптируясь к его отраслевым особенностям. Очень часто самые интересные идеи рождались в процессе совместных с заказчиком брейнштормов, когда в результате долгих и интересных дискуссий рождались замысловатые и красивые механики на стыке бизнес-логики и технических решений. Мы смогли не просто погрузиться в специфику работы рынка недвижимости – с его массовыми выгрузками объектов, XML-фидами и уникальными риэлторскими активностями – но и заметно поучаствовать в улучшении практик для профессионалов рынка недвижимости, в изменении самого их ритма и технических подходов.

Сегодня сервис продолжает развиваться, привлекая новых клиентов, развивая новые услуги и механики. А мы продолжаем развивать свою методологию развития проектов с учетом отраслевых специфик в самых различных областях.