Перейти к содержанию

Что сделано

Здесь — без жаргона, по сути. Что лежит на столе на сегодня.


Этапы по порядку

Этап 0 — техзадание верхнего уровня (закрыт)

То, что ты последний раз смотрел в версии 1.9 — это и есть Этап 0. Описание продукта целиком: зачем, для кого, какие модули, какие роли. Сейчас на руках версия 2.0.

В ближайшие пару недель выйдет версия 2.1 — это будет та же 2.0, но дополненная описанием второго уровня (рыночная аналитика для банков). Когда выйдет — здесь появится ссылка на свежий PDF.

Этап 1 — модель данных (идёт, ~60%)

Подробное описание того, из чего технически состоит система. Какие сущности, какие у них поля, как они связаны, по каким правилам обновляются.

Это не код. Это документ, по которому потом можно будет писать код. Объём — около 40 тысяч слов в финале (для сравнения, Этап 0 — около 12 тысяч).

Что готово на сегодня:

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

Структурное ядро (топология). Описаны базовые сущности: здания, объекты в ЕГРН, зоны, юниты (то, что сдаётся в аренду как самостоятельная единица), портфели. Особое внимание уделено двойной иерархии — в реальности юнит может быть собран из частей нескольких ЕГРН, и при этом части могут принадлежать разным собственникам и быть на разных правовых основаниях (часть в собственности, часть в аренде у соседа). Старые ERP такой случай не покрывают, у нас он покрыт. Прошёл валидацию на четырёх реальных объектах из нашего портфеля.

Владение. Кто чем владеет, какие доли, как доли меняются при сделках. Включая сложные кейсы: продажа части помещения с одновременным «отрезанием» куска от старого ЕГРН и созданием нового, выкуп арендатором его помещения, наследование долей. Каждая операция атомарна: либо изменения зафиксированы целиком, либо никак — никаких промежуточных «полусохранённых» состояний.

Что осталось по Этапу 1:

  • Договоры (самый крупный раздел — пять основных сущностей, плюс жизненный цикл сделок выкупа).
  • Биллинг и счета.
  • Задачи эксплуатации.
  • Права доступа (одиннадцать с лишним ролей × сущности × действия).
  • Налоговая модель.
  • Аналитический слой (тот самый второй уровень платформы).

Сейчас перед началом договоров пауза — нужно дописать пару продуктовых документов и оформить юридическую часть про использование данных в аналитике.

Этап 2 — прототип

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


Что лежит в архитектурных решениях

В проекте формализован журнал ключевых развилок. На сегодня — восемь записей. Пять закрытых, три ещё в работе (по ним финальное решение зависит от того, как сложатся другие части модели).

Подробно — на странице Какие решения приняли и почему. Там у каждого решения видно:

  • В чём был вопрос.
  • Какие варианты рассматривал.
  • Что выбрал.
  • Какие альтернативы отверг и почему.

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


Зачем мы храним всю историю целиком

Внутри проекта нет «черновиков, которые потом стёрли, и финальной версии, которую показываем». Всё лежит вместе: первоначальные предположения, отвергнутые варианты, причины отказа, дискуссии, комментарии, правки.

Это сделано осознанно — с расчётом на будущее.

Когда придёт момент показывать продукт серьёзному инвестору или покупателю, у нас на руках будет не просто «вот техзадание, всё хорошо». Будет полная хроника:

  • Какие развилки были на каждом шаге.
  • Почему выбрали именно этот вариант.
  • Какие альтернативы взвешивали и почему отвергли.
  • Кто и когда повлиял на решение (включая твои комментарии — они тоже остаются в хронике с датой).
  • Где менялся курс и в ответ на что.

Это повышает доверие и оценку. Покупатель смотрит и видит: проект не на коленке писали по последнему вдохновению, а системно строили. Каждое решение защитимо, ничего не подгоняли задним числом.

Технически это работает так: проект живёт в хранилище версий (Git), где каждое изменение фиксируется отдельной записью с автором и датой. Удалить что-то задним числом нельзя — переписывание истории видно сразу.

Сейчас это только наша внутренняя страховка. Через год-два, когда речь зайдёт о финансировании или продаже, — это будет один из наших главных активов. Не код, не техзадание сами по себе, а доказуемая логика, по которой они построены.


Откуда взялась идея двухуровневой платформы

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

Я сначала слушал просто как разговор. Через какое-то время сел писать раздел про договоры — и понял, что то, что ты тогда описывал, это не «фича внутри ERP», а отдельный продукт, который растёт из тех же данных, что собирает операционка, но даёт совсем другую ценность другим людям.

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

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


Несколько цифр для масштаба

  • Этапы: 0 закрыт, 1 идёт, 2 не начат.
  • Объём документации: около 25 тысяч слов написано, ещё столько же остаётся по Этапу 1.
  • Архитектурных решений зафиксировано: 8 (5 закрытых, 3 открытых).
  • Открытых вопросов: около 20 — по каждому есть варианты, по нескольким нужен взгляд со стороны (банковской или юридической).
  • Реальных объектов для валидации: 4 (Кластер 73, Пяловская, Нововатутинская, Черёмушки). Каждое решение прогоняется через них.
  • Время от начала работы: около месяца активной фазы.
  • По документам и технике: один человек.

Что реально означает «60% Этапа 1»

Не процент написанных файлов. Это субъективная оценка того, что самые сложные структурные решения уже сделаны (двойная иерархия, единая модель контрагента, журнал событий, обезличивание аналитики). Дальше — больше про объём, чем про головоломки. Договоры будут крупными по тексту, но идейно они проще, чем то, что уже сделано.


— Рома