Небольшие заметки о разработке 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.
Надеюсь, тем кто в настоящее время стоит перед выбором, данный опыт позволит прояснить некоторые вопросы.
