Что дальше¶
Здесь — куда движемся, без конкретных дат. Я сознательно не ставлю календарные сроки. В творческой работе они всегда сдвигаются, и обещать «к такому-то числу» — значит ставить себе ловушку. Лучше — по этапам и в правильном порядке.
Ближайшие шаги¶
Это то, что я делаю прямо сейчас или в самой ближайшей перспективе. Их порядок зафиксирован.
1. Обновить продуктовое техзадание до версии 2.1¶
Старая версия 2.0 не описывает второй уровень (рыночную аналитику для банков), потому что она писалась до этого решения. Версия 2.1 это исправит:
- В позиционирование добавится: «двухуровневая платформа».
- Появятся новые роли: банк-партнёр (аналитика), оценщик, инвестор.
- Появится новый раздел про аналитический слой: цели, объём первой фазы, этажи аналитики (дескриптивная / диагностическая / предиктивная), правила обезличивания, право собственников отказаться от участия, источники данных.
- В дорожной карте появятся фазы открытия аналитических этажей по мере накопления данных.
- В версии 2.1 появится новый раздел «Принятые ключевые решения» — по сути, то, что ты сейчас читаешь на странице «Решения», но в формальном виде в самом ТЗ. Чтобы любой будущий читатель сразу видел логику, не лазая по архитектурным записям.
После этого можно показывать ТЗ 2.1 потенциальным партнёрам — у тебя в руках полное описание продукта, без устаревших мест.
2. Юридический документ про использование данных¶
Это короткая, но важная работа. Создать черновик оферты на использование данных собственников в обезличенной аналитике. Туда войдёт:
- Что именно используется (ставки, вакансия, платёжная дисциплина и т.д.).
- Как обезличивается (правила, к которым мы пришли в архитектурных решениях).
- Кто получает доступ (собственники, банки-партнёры, банки-кредиторы по своему заёмщику).
- Как отказаться от участия (один клик в кабинете).
- Что собственник теряет при отказе (доступ к рыночным бенчмаркам).
Этот документ будет черновиком для юриста — не финальная оферта, а основа, по которой юрист сделает юридически выверенный текст для подписания собственниками при регистрации.
3. Раздел про договоры в модели данных¶
Это самый крупный раздел, который ждёт своей очереди после двух предыдущих шагов. Пять основных сущностей: договор, стороны договора, статьи договора, связь договора с юнитами, отдельная сущность для сделок выкупа арендатором.
Раздел отложен сознательно: пока не зафиксирована рамка (продуктовое ТЗ 2.1) и не оформлены юридические аспекты (оферта), писать про договоры было бы преждевременно — пришлось бы переписывать.
Среднесрочные шаги¶
Это то, что идёт после ближайших в осмысленном порядке. Каждый шаг опирается на предыдущий — нельзя их менять местами.
4. Биллинг и счета¶
Раздел модели данных про деньги: тарифные планы, начисления, счета, платежи, дебиторка. Опирается на договоры — без них не имеет смысла, потому что начисление всегда привязано к договору.
5. Эксплуатация и операционные задачи¶
Заявки от арендаторов, обходы зданий управляющими, инциденты, плановые работы. Это то, что наполняет мобильное приложение управляющего, и то, что видит арендатор в своём кабинете.
6. Матрица прав доступа¶
Самая педантичная часть. Точная таблица: одиннадцать с лишним ролей, несколько десятков сущностей, четыре типа действий (читать / создавать / изменять / закрывать) — на пересечении каждое право либо есть, либо нет. Эту матрицу потом просто превращают в код, без интерпретаций.
7. Налоговая модель¶
Как считается налог на имущество, как привязаны кадастровые стоимости, как работает разделение по налоговым режимам собственников (общая система, упрощённая, патент). Опирается на уже сделанные части про объекты ЕГРН и контрагентов.
8. Аналитический слой в модели данных¶
Подробное описание сущностей второго уровня: сегменты рынка, обезличенные наблюдения, рассчитанные бенчмарки, согласия собственников, журнал запросов к аналитике, иерархия локаций. Это уже техническая часть, которая закроет пять документов про второй уровень, написанных в архитектурных решениях.
После этого пункта модель данных Этапа 1 закрыта. Можно начинать код.
Долгосрочные ориентиры¶
Это уже за горизонтом этой партнёрской страницы. Здесь нет пошаговости, а есть направления, в которых пойдём после закрытия модели данных.
Прототип¶
Когда модель данных закрыта — можно писать первую версию системы. Это уже не документация, а реальный код. Сейчас кода нет вообще, и я сознательно не начинаю — слишком велик риск переделывать, если в модели найдётся ошибка.
Прототип будет работать на четырёх объектах нашего портфеля (Кластер 73, Пяловская, Нововатутинская, Черёмушки) — это идеальная пилотная база, где есть все типичные сложности: мультивладение, композитные юниты, разные типы юнитов, реальные арендаторы.
Подключение первых внешних собственников¶
После того как прототип работает на наших объектах — приглашение первых внешних собственников. Это критичный момент: с этого начинается сетевой эффект. Маленькая ошибка на этом этапе — и собственники не идут, аналитика остаётся пустой, банкам показать нечего.
Первая аналитика¶
Когда наберётся минимум данных (точная цифра зависит от вопроса про порог обезличивания, который обсуждаем) — открывается первый этаж аналитики (дескриптивный): бенчмарки ставок, вакансии, платёжной дисциплины. Это уже монетизируемый продукт для банков-партнёров.
Второй этаж аналитики¶
Когда данных существенно больше — открывается диагностический этаж: «ваш объект отстаёт от рынка на N процентов», «здесь аномально высокая вакансия», «сравнение фактической стоимости с расчётной». Это уже не просто справочник, а активный совет собственнику.
Третий этаж — предиктивная аналитика¶
Открывается только когда наберётся критическая масса данных (порядка ста объектов в одном регионе с историей не меньше года). До этого порога прогнозы делать математически некорректно — на малых данных любая модель даст слишком много шума.
Этот этаж сознательно убран из планов первой и второй фаз. Если кто-то захочет «прогноз доходности на год» через полгода после старта — придётся объяснять, что это не работает на маленьких данных. Лучше не обещать, чем обещать и не дать.
Что может затормозить¶
Честно — точки, где работа может встать не из-за моей лени, а потому что нужен внешний ввод.
Юрист¶
Оферта про использование данных и сама модель согласия — это юридическая территория. Без юриста финальный текст не сделать. Я могу написать содержательный черновик, но довести его до подписываемого вида — работа специалиста. Если юриста нет под рукой — это блокер для запуска внешних собственников (без оферты их подключать нельзя).
Банковская обратная связь¶
Шесть открытых вопросов для тебя — именно про это. Часть из них (особенно про пороги обезличивания, про сегментацию бизнеса арендатора, про роли) влияет на дизайн системы. Я могу принимать решения по своей гипотезе, но если потом окажется, что банковская практика требует другого — придётся переделывать. Лучше уточнить заранее.
Разработчики¶
Когда модель данных закроется и начнётся код — нужны будут люди, которые этот код пишут. Один я этого не сделаю. Это не блокер для текущей стадии (мы ещё в техзадании), но это блокер для перехода к прототипу. Я подумаю над командой ближе к концу Этапа 1, и обсудим с тобой как именно — нанимать, искать соинвестора, как-то иначе.
Реальные данные четырёх объектов¶
Для тестирования прототипа нужны кадастровые номера, фактические договоры, история ставок, движения денег. Доступ к этим данным у меня есть. Это не блокер.
Зачем эта страница вообще существует¶
Чтобы у тебя в любой момент была картина «куда движется проект», а не только «что сделано». Это разные вещи. Сделано — это вчера. Что дальше — это про завтра, про моё понимание траектории.
Если ты видишь, что какой-то шаг должен идти раньше или, наоборот, его вообще быть не должно — пиши. Порядок шагов — это тоже решение, которое можно обсудить.
— Рома