Портал долгосрочной аренды квартир — от объявления до передачи

Отрасль и клиент

Рынок и граница продукта

Арендатор находит подходящую квартиру, пишет владельцу и покидает портал. Дальше начинается отдельный процесс: вопросы в мессенджере, просмотр по телефону, фотографии документов в переписке, условия в голосовых сообщениях и акт передачи, который каждая сторона понимает по-своему.

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

Для демонстрационного кейса рассматривается портал долгосрочной аренды квартир в Минске. Это не универсальная система управления недвижимостью и не кабинет управляющей организации. Граница продукта проходит от подготовки объявления до подтверждённой передачи квартиры арендатору.

Единица работы — целая квартира, а не комната. Соседний сценарий — проект заселения в комнату с уже проживающими соседями: там центр — бытовые правила и состав жильцов, здесь — условия найма и передача жилья целиком. Посуточный календарь и channel manager в этот контур не входят.

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

Модельный контекст

Цифры описывают модельную нагрузку первой версии, а не когортную конверсию рынка.

Что именно пытаются решить пользователи

Запрос «найти квартиру» слишком общий для проектирования. Внутри него находятся несколько разных задач.

Задачи арендатора

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

Задачи владельца

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

Задачи модератора

• не проверять вручную каждое стандартное действие;
• быстро понимать причину попадания объекта в очередь;
• видеть историю публикации, жалобы и связанные решения;
• отделять ошибку заполнения от намеренного введения в заблуждение;
• ограничивать доступ или скрывать материал без уничтожения доказательной истории;
• возвращать карточку на исправление с конкретной причиной.

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

Баланс интересов и роли

Один аккаунт может совмещать роли. Полномочия владельца и представителя проверяются отдельно: право разместить фотографию не означает право менять цену или подтверждать передачу.

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

Принципы проектирования доверия

1. Показывать источник, а не обещать достоверность. Пользователь должен понимать, кем внесено значение и проходило ли оно проверку.
2. Не смешивать отсутствие данных с положительным ответом. «Не указано» — самостоятельное состояние.
3. Хранить версии значимых условий. Подтверждение относится к конкретной формулировке, а не к названию поля вообще.
4. Разделять личное и совместное. Личная заметка никогда не должна случайно стать общей договорённостью.
5. Объяснять автоматический сигнал. Вместо скрытого балла показывается конкретная причина: пропущено поле, найдено совпадение, истёк срок ответа.
6. Оставлять спор человеку. Система хранит последовательность действий, но не выносит правовую или моральную оценку.

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

Как было

Один вечер, три версии одной квартиры

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

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

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

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

Семь мест, где теряется контекст

Типовой путь выглядит связанным только снаружи:

1. Владелец размещает краткое объявление и отвечает на повторяющиеся вопросы вручную.
2. Арендатор сохраняет несколько вариантов скриншотами или пересылает их себе в мессенджер.
3. Существенные ограничения — домашние животные, срок проживания, состав жильцов, регистрация, порядок визитов — выясняются уже в переписке.
4. Время просмотра обсуждается сообщениями и не связано с актуальной доступностью квартиры.
5. После просмотра каждая сторона хранит свои заметки, а устные договорённости нигде не подтверждаются.
6. Документы, перечень имущества и замечания о состоянии квартиры появляются в последний момент.
7. После передачи ключей трудно восстановить, какие дефекты существовали заранее и какие условия действительно были согласованы.

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

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

Детальная карта процесса «до»

Последствия разрывов

Разрывы проявляются не только в потере времени. Они меняют качество решений:

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

Почему чат, календарь и ещё одна форма не решают проблему

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

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

Расширенная форма объявления повышает полноту карточки, но после отклика не отвечает на вопрос, какие сведения изменились, какие условия подтвердили обе стороны и что блокирует передачу.

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

Концепция продукта

Портал должен продолжать работу после отклика и создавать общее пространство, в котором объект постепенно превращается из объявления в подготовленную аренду.

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

Публикация отвечает на вопрос «подходит ли мне этот вариант для знакомства». Проект аренды отвечает на вопрос «готовы ли стороны к передаче квартиры и что ещё осталось сделать».

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

Публикация

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

Подбор

Арендатор фильтрует предложения не только по характеристикам жилья, но и по совместимости условий. Карточки с неизвестным параметром не исчезают из выдачи: портал показывает «не указано» и позволяет запросить уточнение. Пользователь собирает короткий список и сравнивает объекты в одинаковой структуре. Система отдельно выделяет различия и пропуски, чтобы решение не зависело от памяти.

Отклик

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

Просмотр

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

Согласование

Стороны проходят структурированный список условий. Каждое условие имеет состояние: не обсуждалось; предложено; требует уточнения; подтверждено обеими сторонами; изменено после подтверждения. Изменение уже подтверждённого пункта возвращает его на согласование и создаёт событие в истории. Голосовая или устная договорённость может быть внесена одной стороной, но считается общей только после подтверждения второй.

Передача квартиры

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

Семь сквозных пользовательских сценариев

Сценарий 1. Владелец готовит публикацию без помощи модератора

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

Если обязательное поле пропущено, пользователь видит не абстрактную ошибку, а объяснение влияния: «Арендатор не сможет отфильтровать возможность проживания с животным». При отправке выполняются автоматические проверки. Если критических отклонений нет, карточка попадает в короткую очередь подтверждения. Результат сценария — опубликованный объект с достаточной структурой для подбора и сравнения.

Сценарий 2. Модератор разбирает вероятный дубль

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

Сценарий 3. Арендатор собирает короткий список

Пользователь задаёт район, количество комнат, срок и существенные бытовые условия. В выдаче отображаются подходящие и частично заполненные варианты. Объекты с конфликтующим обязательным условием можно скрыть, а карточки с неизвестным значением — оставить для уточнения. Арендатор выбирает четыре объекта и открывает сравнение. Строки с одинаковыми значениями сворачиваются, различия остаются видимыми. Для пропущенного значения можно сразу создать вопрос владельцу. После ответа строка сравнения обновляется, а рядом появляется источник значения. Результат — короткий список, построенный по фактам и явно обозначенным неизвестным параметрам.

Сценарий 4. Стороны назначают и переносят просмотр

Владелец публикует несколько интервалов. Арендатор выбирает время и получает статус «Ожидает подтверждения» либо сразу «Подтверждено», если владелец разрешил автоматическую запись. При переносе старое событие не исчезает. В истории остаётся инициатор и причина, а обе стороны подтверждают новый интервал. Если квартира становится недоступна, будущие просмотры отменяются одним действием, но активные проекты сохраняются. Результат — однозначно определённое время встречи, связанное с объектом и участниками.

Сценарий 5. Арендатор фиксирует результат просмотра

После запланированного времени портал предлагает короткую форму. Пользователь оценивает соответствие описанию, отмечает важные наблюдения, добавляет личные фотографии и формулирует вопросы. Личные материалы сохраняются только в его кабинете. В общий контур передаются лишь вопросы и выбранный итог. Если результат «нужно уточнение», система просит определить конкретный следующий шаг. Результат — зафиксированное решение, которое можно сопоставить с другими просмотренными объектами.

Сценарий 6. Стороны согласуют изменившееся условие

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

Сценарий 7. Передача выявляет разногласие

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

Карточка квартиры как рабочая точка решения

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

Верхняя часть содержит фотографии, адресную часть, характеристики, доступность для просмотра и действия «Сохранить», «Сравнить», «Задать вопрос», «Откликнуться». Ниже информация разделена на пять зон:

1. Квартира и дом — планировка, состояние, этаж, лифт, хранение вещей и другие характеристики.
2. Условия проживания — срок, состав жильцов, животные, курение, гости, регистрация.
3. Что входит в квартиру — мебель, техника и принадлежности.
4. Просмотр и заселение — доступные интервалы и ориентировочная готовность к передаче.
5. История и подтверждения — дата обновления, источник сведений, существенные изменения и вопросы без ответа.

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

Система интерфейсов

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

Каталог и карта

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

Сравнение объектов

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

Редактор объявления

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

Управление откликами

Роль: владелец. Задача: обработать входящие обращения и назначить подходящие просмотры. Отклики группируются по состоянию: новый, нужно уточнение, просмотр предложен, подтверждён, закрыт. В строке отображаются только сведения профиля, которыми арендатор разрешил поделиться. Основное действие определяется состоянием: у нового отклика — «Открыть и ответить»; у согласованного — «Предложить время»; у прошедшего просмотр — «Подтвердить взаимный интерес» или «Закрыть с причиной».

Календарь просмотров

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

Очередь модератора

Роль: модератор. Задача: обработать риск или несоответствие, не перечитывая всю карточку. Вместо dashboard с общими числами первым экраном становится таблица заданий. Основные колонки: причина, объект, автор, возраст задания, предыдущее решение, приоритет. Быстрые фильтры позволяют выбрать дубли, жалобы, существенные изменения и публикации с запрещёнными материалами. Внутри задания сравниваются текущее и предыдущее состояния. Модератор обязан выбрать причину решения. Свободный комментарий дополняет её, но не заменяет структурированный результат.

История объекта

Роли: владелец, участник проекта, модератор в пределах доступа. Задача: восстановить изменение фактов и решений. Лента разделяет действия пользователя и автоматические события. Изменение условия раскрывается как сравнение «было / стало». Просмотр закрытого документа не отображается всем участникам, но остаётся в защищённом журнале безопасности.

Общие состояния интерфейса

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

Проект аренды: совместное пространство без смешивания личных данных

После взаимного выбора стороны переходят из публичной карточки в закрытый проект. Его главный экран — не переписка, а состояние подготовки к передаче. В верхней части показывается последовательность: взаимный интерес → условия согласуются → документы подготовлены → передача назначена → квартира передана.

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

Личные заметки арендатора остаются за пределами проекта. Владелец не получает историю других откликов пользователя. Модератор не открывает документы автоматически и получает доступ только при жалобе или предусмотренном процессе проверки.

Мобильная передача квартиры

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

Для каждого пункта доступны состояния: соответствует, есть замечание, не проверено. Нельзя завершить передачу, пока обязательный пункт остаётся непроверенным. Фотография получает время, автора и связь с конкретным пунктом. Портал не заявляет, что фотография доказывает причину повреждения. Он только сохраняет состояние, которое стороны совместно зафиксировали.

При нестабильной связи заполненный шаг временно сохраняется в браузере. Полноценный автономный режим не входит в MVP: перед финальным подтверждением устройство должно синхронизировать данные с сервером.

Автоматические правила и исключения

Карточка и публикация

• У публикации есть черновик, текущая версия и история существенных изменений.
• Адресная часть, фотографии, характеристики и обязательные условия проверяются до модерации.
• Изменение доступности квартиры автоматически закрывает новые отклики, но не удаляет активные проекты.
• Вероятный дубль не блокируется безусловно: он поступает модератору вместе с найденными совпадениями.

Совместимость

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

Согласование

• Подтверждение привязано к конкретной версии условия.
• Любое изменение подтверждённого текста отменяет прежнее подтверждение.
• У проекта всегда есть одно следующее действие, ответственный и срок.
• Просрочка создаёт уведомление, но не переводит проект на следующий этап автоматически.

Передача

• Обязательные пункты должны быть проверены обеими сторонами.
• Добавленное замечание требует повторного ознакомления второго участника.
• Если один участник отказывается подтверждать передачу, проект получает статус «Есть разногласие».
• Проект с разногласием не закрывается как завершённый.
• Модератор может помочь восстановить историю, но не принимает решение о правоте сторон.

Предметная модель продукта

Система строится не вокруг набора страниц, а вокруг связанных сущностей. Это важно для сохранения истории и однозначного определения доступа.

Объект недвижимости

Содержит устойчивые характеристики квартиры: адресную часть, параметры дома, планировку, связь с владельцем. Объект может иметь несколько публикаций во времени, но не должен дублироваться как новая квартира при каждом повторном размещении.

Публикация

Представляет публичное состояние объекта в конкретный период. У неё есть черновик, версия, статус модерации, доступность и история изменений. Снятие публикации не удаляет сам объект и связанные завершённые проекты.

Профиль арендатора

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

Отклик

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

Просмотр

Хранит предложенные интервалы, подтверждённое время, переносы, отмены и независимые результаты сторон. Сам факт проведённой встречи не означает взаимного интереса.

Проект аренды

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

Передача квартиры

Содержит версию чек-листа, пункты имущества, показания, замечания, фотографии и подтверждения. После завершения запись становится неизменяемой. Исправление оформляется отдельным дополнением с новой датой и подтверждением сторон.

Жизненные циклы и статусы

Публикация: Черновик → На проверке → Требует исправления → Опубликована → Приостановлена → Снята. Публикацию нельзя перевести из «Требует исправления» в «Опубликована», не создав новую версию и не устранив блокирующую причину.

Отклик: Новый → Просмотр предложен → Просмотр подтверждён → Результат ожидается → Взаимный интерес или Закрыт. Состояние «Закрыт» всегда требует причины: несовместимость условий, недоступность объекта, отсутствие ответа, выбор другого кандидата, отказ самого арендатора.

Проект аренды: Создан → Условия согласуются → Документы готовятся → Передача назначена → Есть разногласие или Передача подтверждена → Закрыт. Этап рассчитывается из состояния вложенных сущностей. Пользователь не может вручную объявить документы готовыми, если обязательный пункт не имеет соответствующего статуса.

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

Матрица доступа

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

Модули одного процесса

MVP

Первая версия замыкает процесс от создания объявления до подтверждённой передачи квартиры.

В первой версии

1. Регистрация и три роли.
2. Пошаговое создание объявления и история изменений.
3. Модерация по отклонениям и жалобам.
4. Каталог, карта, фильтры, короткий список и сравнение.
5. Профиль арендатора, отклик и предупреждения о несовместимости.
6. Интервалы просмотра, подтверждения и результат встречи.
7. Проект аренды с условиями, документами, действиями и историей.
8. Адаптивный сценарий передачи квартиры с фотографиями и подтверждениями.
9. Уведомления внутри портала и по электронной почте.

Осознанно отложено

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

Модерация и работа с нарушениями

Модерация разделяется на предварительные проверки и реакцию на события.

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

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

Уровни реакции: предупреждение без скрытия публикации; запрос исправления с ограничением части действий; временная приостановка; скрытие конкретного материала; снятие публикации; ограничение учётной записи с сохранением активных обязательств по проектам.

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

Нефункциональные требования MVP

Производительность. Каталог должен открывать первую содержательную выдачу без загрузки всей карты и всех фотографий. Фильтр изменяет результаты без полной перезагрузки страницы. Изображения получают несколько размеров и загружаются по мере появления на экране. Тяжёлая обработка фотографий выполняется в очереди. Сравнение четырёх объектов формируется из нормализованных данных, а не из произвольного текста.

Надёжность. Подтверждение условия и передачи выполняется в транзакции. Повторный запрос не создаёт два одинаковых подтверждения. Каждая фоновая задача допускает безопасный повтор. Резервное копирование охватывает базу данных и закрытые файлы. Восстановление проверяется на тестовой копии по расписанию.

Доступность интерфейса. Статус передаётся текстом и цветом, а не только цветом. Формы поддерживают клавиатурную навигацию. Ошибки связаны с конкретными полями. Фотографии имеют описания там, где они несут смысл. Мобильный чек-лист использует крупные зоны нажатия. Критическое действие подтверждается отдельным экраном с итоговой сводкой.

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

Защита данных

Портал разделяет четыре области видимости: публичная карточка квартиры; профиль арендатора, открываемый только выбранному владельцу; личные заметки пользователя; общие материалы проекта аренды.

Каждый документ и фотография получают владельца, область видимости, срок хранения и историю доступа. Закрытые материалы отдаются через временные разрешения. Действия модератора с личными данными журналируются. При закрытии проекта стороны видят, какие данные останутся в истории и когда будут удалены. Удаление публичной публикации не уничтожает подтверждённый акт передачи у участников завершённого проекта.

Интеграции первой версии

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

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

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

Стратегия тестирования

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

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

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

Проверка прав доступа. Отдельная группа тестов пытается открыть чужой проект, личную заметку, закрытый документ и фотографию передачи. Проверяются не только страницы, но и прямые запросы к действиям и файлам. Бизнес-правила версий, доступов и подтверждений покрываются тестами Pest.

UX, стек и план

Рабочие экраны

Для арендатора стартовый экран — каталог, затем короткий список и сравнение. Для владельца — редактор объявления с панелью готовности, входящие отклики и календарь просмотров. Для модератора первым экраном становится таблица заданий, а не дашборд с общими числами.

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

Архитектура без лишнего разделения

Для MVP используется одно Laravel-приложение. Публичный каталог, личные кабинеты и проект аренды находятся в одном репозитории и развёртываются как единая система.

Blade и Livewire выбраны потому, что продукт состоит преимущественно из форм, карточек, списков, статусов и последовательных чек-листов. Отдельная SPA не даёт достаточного преимущества, но потребовала бы публичного API, отдельной аутентификации и второго процесса сборки.

PostgreSQL обеспечивает поиск и работу со связанными данными. PostGIS не добавляется: в MVP нужны точки на карте и фильтрация по видимой прямоугольной области, а не радиусы, маршруты и сложные полигоны. S3-совместимое хранилище оправдано большим количеством фотографий и необходимостью раздельно управлять публичными и закрытыми материалами. Доступ к закрытым файлам выдаётся только после проверки роли и участия в проекте.

Ключевые технические решения

• Версии объявления и условий хранятся отдельно от текущего состояния.
• Личные заметки арендатора физически и логически отделены от общего проекта.
• Статус проекта вычисляется из действий, подтверждений и блокирующих причин.
• Финальное подтверждение передачи выполняется только после синхронизации с сервером.
• Публичные и закрытые файлы используют разные правила доступа и сроки хранения.

Что сознательно не добавлено

• React или Vue — интерфейс не требует сложного редактора или совместной доски.
• Redis и Horizon — database queue достаточно для модельной нагрузки MVP.
• Отдельный поисковый движок — поиск и индексы PostgreSQL покрывают каталог из примерно 1 800 публикаций.
• WebSocket — мгновенный чат не является критическим сценарием.
• Микросервисы и Kubernetes — единый жизненный цикл и небольшая команда лучше поддерживаются модульным монолитом.

Потоки данных

От объявления к каталогу. Владелец сохраняет черновик → Laravel проверяет поля → фотографии отправляются на обработку → модератор принимает решение → опубликованная версия становится доступна каталогу → изменение индексируемого поля обновляет поисковые данные. Публичная выдача всегда использует только одобренную версию. Изменения черновика не появляются частично и не создают состояние, когда разные пользователи видят разные наборы характеристик.

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

От согласования к передаче. Стороны подтверждают условия → система проверяет обязательные пункты → назначается дата → из проекта формируется черновик передачи → участники проверяют имущество и состояние → сервер валидирует полноту → стороны последовательно подтверждают итоговую версию → проект закрывается как завершённый. Любое изменение между двумя подтверждениями создаёт новую версию и отменяет первое подтверждение. Это правило реализуется на сервере и покрывается отдельным тестом конкурентных запросов.

План создания и запуска

Модельный срок разработки и ограниченного пилота — 12 календарных недель. Пилот ограничивается одним районом, группой подготовленных владельцев и заранее проверенными объявлениями. Некачественные старые публикации не импортируются автоматически.

Команда наблюдает пять критических маршрутов: публикация и модерация; поиск и отклик; согласование просмотра; подтверждение условий; передача квартиры и закрытие проекта. Отдельный нагрузочный контур на этом масштабе не нужен; проверяется одновременная работа каталога и фоновая обработка фотографий.

Подготовка данных к пилоту

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

Обучение модераторов

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

Поддержка владельцев

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

Наблюдение за поведением арендаторов

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

Параллельный процесс

На первой неделе пилота допускается резервная фиксация критических результатов старым способом, но она не должна продолжаться бессрочно. Команда назначает дату, после которой подтверждение условия и итог передачи считаются процессно завершёнными только внутри портала. Иначе пользователи будут выбирать более привычный канал, а продукт не получит достоверной проверки сквозного процесса.

Критерии перехода от пилота к расширению

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

Метрики

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

Как интерпретировать показатели

Полнота публикации измеряется только по обязательным структурированным полям. Большой объём произвольного описания не считается полнотой.

Повторное уточнение определяется по тематикам вопросов. Если арендатор спрашивает о животном после того, как условие уже указано и подтверждено, это повтор. Уточнение конкретной ситуации повтором не считается.

Зафиксированный результат просмотра должен содержать итог и следующее действие. Простое открытие формы не учитывается.

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

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

Дополнительные диагностические показатели

• среднее число версий одного условия;
• доля вопросов, созданных из поля «не указано»;
• доля отменённых и перенесённых просмотров;
• число проектов, закрытых из-за несовместимости;
• время ответа владельца на новый отклик;
• доля публикаций, возвращённых на исправление;
• причины повторного открытия модерационного задания;
• доля мобильных передач с временным сохранением черновика.

Если целевой показатель не достигнут, команда сначала ищет конкретный разрыв. Например, низкая доля результатов просмотра может быть вызвана неудобным мобильным экраном, поздним напоминанием или отсутствием понятного смысла для пользователя. Сам показатель не объясняет причину.

Риски и выводы

Основные риски

Развитие продукта

После подтверждения основного процесса возможны следующие направления. Они не входят в MVP.

Извлечение характеристик из документов. Владельцу приходится повторно переносить данные в форму. Модель извлекает отдельные характеристики из загруженного документа и ищет расхождения. Система предлагает заполнение полей и показывает источник каждого значения. Распознавание может ошибаться из-за качества файла или неоднозначной структуры. Владелец или модератор подтверждает каждое значимое значение.

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

Сводка изменений условий. Участнику сложно быстро понять, что изменилось в длинном проекте. Модель кратко излагает различия двух версий условий и событий между ними. Рядом всегда остаётся точное сравнение исходных текстов: сводка может потерять значимую деталь.

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

Отдельный контур после заселения. После подтверждённой передачи начинается другой жизненный цикл: обращения арендатора, согласование визитов, фиксация неисправностей, изменение состава имущества, подготовка обратной передачи. Этот контур рассматривается как самостоятельное расширение продукта.

Как меняется процесс

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

Система не пытается решить спор за людей или выдать автоматическую гарантию. Она делает видимым: кто внёс информацию; когда появилось изменение; какую версию подтвердили стороны; что осталось незавершённым; кто отвечает за следующий шаг; почему процесс не может перейти дальше. Именно это превращает каталог недвижимости в законченный цифровой продукт.

Выводы проекта

1. Ценность портала — в завершённом пути от выбора квартиры до подтверждённой передачи, а не в количестве фильтров каталога.
2. После «Связаться» нужна отдельная сущность: проект аренды хранит совместное состояние дольше публикации.
3. Подтверждение привязано к версии условия. Молчание и просмотр сообщения не считаются согласием.
4. Фотография передачи связана с пунктом проверки; система фиксирует разногласие, но не решает, кто прав.
5. MVP реализуем как Laravel-монолит на Blade, Livewire и Alpine.js, если ограничить город и не разрывать сквозной сценарий.
6. Контур после заселения — другой жизненный цикл, а не набор функций поверх передачи.
7. Система не выдаёт гарантию сделки: она делает видимым, кто внёс сведения, какую версию подтвердили стороны и что блокирует следующий шаг.