Разработка личного кабинета: что закладывать сразу

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

Я в IT с 2014 года и кабинеты делал и как отдельные продукты, и как надстройку над CRM. Ниже — список того, что стоит заложить сразу. Не потому что «так правильно», а потому что каждый пункт я однажды доделывал постфактум и знаю, во сколько это обходится.

Кабинет — это не страница «профиль»

Разграничим, потому что путаница здесь стоит денег.

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

Два живых примера, на которые я буду ссылаться дальше.

Кабинет клиента в B2B. Владелец компании пришёл с прямым запросом: чтобы клиенты видели свои сделки, могли быстро общаться с менеджерами и обмениваться документами — всё в одном экране. Сделали на Flutter за 24 дня: авторизация, загрузка сделок, просмотр PDF, WebSocket-чат, пуши, интеграция с Битрикс24. Результат за первый месяц — минус 30 % входящих звонков: люди перестали звонить, чтобы спросить «а что там у нас».

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

Что закладывать сразу: семь пунктов

1. Роли и права — до первого экрана

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

В панели застройщика роли были заложены с самого начала: риэлтор, руководитель отдела, администратор. Права доступа — отдельный, заранее описанный слой. Вопрос «а можно добавить куратора, который видит три ЖК из десяти?» решается настройкой, а не переписыванием.

Сформулируйте на старте матрицу: строки — роли, столбцы — сущности, в клетках «видит / создаёт / меняет / удаляет». Час работы на берегу.

2. Один источник истины

Кабинет почти никогда не живёт сам: рядом CRM, склад, 1С, платёжка. Нужно решить до разработки: где данные рождаются, а где только отображаются.

В B2B-кабинете источником была CRM, поэтому чат мы завели напрямую в неё, а не в мессенджеры. Менеджер работает там, где привык, клиент — в приложении, переписка одна. В панели застройщика наоборот: цены и планировки живут в панели, а наружу уходят в CRM и мессенджеры.

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

3. Защита от дублей и конкурентных действий

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

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

4. Уведомления туда, где человек живёт

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

В приложении это были push-уведомления на все изменения. В панели — уведомления в тот канал, который удобен конкретной команде. Заложите заранее хотя бы два: почта и мессенджер, плюс отдельный канал для админов на ошибки.

5. История изменений

Кто поменял цену, когда снял бронь, почему у сделки другой статус. Без истории любой спор превращается в «я этого не делал», а любая ошибка — в детективное расследование по логам, если они вообще есть.

Дописать историю потом можно — но у вас не будет истории за прошлые месяцы, а именно она понадобится в первом же разбирательстве.

6. Экспорт и отчёты

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

7. Безопасность как часть сметы

Здесь кратко и без компромиссов: HTTPS, нормальная авторизация (в B2B-проекте — OAuth 2.0), проверка прав на каждом запросе к данным, а не только в интерфейсе. Скрытая кнопка — не защита. Если запрос к серверу отдаёт чужую сделку тому, кто её попросил, кабинет вас однажды подставит.

Что можно смело отложить

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

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

Где в смете прячется цена

По моему опыту пропорции в таком проекте выглядят так — привожу разбивку того самого B2B-приложения:

• интерфейс, переходы, логика — 25 %;
• интеграции с CRM и внешними API — 40 %;
• чат, пуши, документооборот — 25 %;
• тесты и релиз — 10 %.

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

По срокам: кабинет с одной ролью и одной интеграцией — 3-5 недель. Кабинет с несколькими ролями, документами и чатом — от полутора месяцев; в тот проект мы уложились в 24 дня, но там был готовый прототип и заказчик, отвечавший в течение дня.

Как проверить своё ТЗ за пять минут

Прогоните его по четырём вопросам. Сколько у вас ролей и что каждая видит? Где рождаются данные — в кабинете или в CRM? Что происходит, если два человека делают одно действие одновременно? Как пользователь узнаёт, что у него что-то изменилось?

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

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