Небольшие заметки о разработке CRM‑системы по продаже объектов недвижимости

По причине того что после 8-летнего хардкодинга рандомными людьми, код предыдущей CRM пришел в состояние квантовой запутанности, потребовалось срочно разработать новую CRM

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

И первое (Продукт), и второе (Процессы) накладывает фундаментальные требования к модели данных, формируя каркас бизнес‑логики

Даже продукт в таком казалось бы распространенном виде деятельности, как недвижимость, может иметь существенные отличия, не предусматриваемые типовыми CRM

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

Касательно стека, хотелось:

1. API‑driven, 2. Максимальную гибкость, 3. Минимальную стоимость, в общем все как у нормального заказчика.

Как оказалось, это возможно c headless CMS, что и позволило предложившему победить с более чем 2-кратным отрывом от ближайших конкурентов

Кратко об основных чертах предметной области

Определили следующие сущности и связи между ними:

Объекты: Город — Проект — Здание — Блок‑секция — Помещение
Тип помещения — библиотека из значений: Коммерция, Квартира, Паркинг, Кладовка
Лиды: Контакт — по типу (звонок, визит, заявка), направлению (входящий, исходящий) и др.
Клиент: «Клиент» и «Журнал клиента» с 6 этапами от обращения до продажи
Документы: Документ — Клиент — Помещение
Платежи: Помещения — Документ — Плательщик — Платеж

Исходя из этого, стала понятна модель данных. Сущности стали таблицами, связи определялись исходя из отношений — в основном «один ко многим» и «многие ко многим»

На этом этапе очень помогает Yandex Datalens для прототипирования

База данных — MySQL с репликацией

Отчеты — Yandex Datalens с подключением к БД. Был настроен ежедневный трансфер в кластер MySQL

Основные выводы:

1. Очень удобно использовать встроенный инструментарий Yandex WebSQL, который представляет собой DBeaver на минималках и позволяет:

быстро браузить существующие таблицы в поисках необходимых полей
создавать SQL запросы и получать отчеты для быстрого прототипирования
есть даже функционал CRON задач, позволяющий сразу автоматизировать работу БД, но лучше использовать более наглядные инструменты существующие в Yandex Cloud

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

3. Для подключения к Datalens создайте копию базы данных: это позволит избежать падения БД при сложных запросах. Некоторые SQL запросы приводили к росту потребления оперативной памяти кластера MySQL до предельного уровня и к крашу БД. Настраивать периодическое копирование базы целиком или отдельных таблиц позволяет Yandex Data Transfer

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

Позже отчеты Datalens были приватно встроены в CRM.

Надеюсь, тем кто в настоящее время стоит перед выбором, данный опыт позволит прояснить некоторые вопросы.

Заметки о разработке CRM‑системы