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

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

Разберём, какими бывают личные кабинеты, из чего они состоят, как идёт разработка и от чего на самом деле зависит цена. Чтобы к разговору с подрядчиком вы пришли с пониманием, что именно заказываете.

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

• Кабинет клиента. Покупатель или заказчик видит свои заказы, статусы, счета и документы, может задать вопрос или оставить заявку. Главная задача — чтобы клиенту не приходилось звонить и писать, чтобы узнать, что происходит.
• Кабинет партнёра. Для дилеров, агентов и поставщиков: остатки и цены, заказы и отгрузки, взаиморасчёты. Часто это самый «интеграционный» тип — данные почти всегда живут в 1С или учётной системе.
• Кабинет сотрудника. По сути внутренний портал компании: задачи, процессы, табели, документы, отчёты. Здесь главное — роли и права доступа.

В реальных проектах эти типы часто совмещаются: у одной системы есть и клиентская часть, и внутренняя для команды.

И ещё один вопрос, который стоит задать себе до разработки: а нужен ли именно веб-кабинет? Если пользователи работают «в полях» и им важны быстрые действия и уведомления, иногда удобнее Telegram-бот. Мы подробно разбирали это в статье «Telegram-бот или веб-портал: как выбрать и не пожалеть».

Почти в любом кабинете есть базовый набор:

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

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

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

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

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

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

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

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

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

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

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

MVP часто путают с двумя вещами: с прототипом и с готовой системой. Это ни то, ни другое, и разницу лучше понимать заранее.

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

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

Ориентиры по MVP:

• веб-портал или личный кабинет — от 2–3 месяцев, 350–800 тыс. ₽;
• Telegram-бот — от месяца, от 30 тыс. ₽.

Дальше MVP дорабатывают до рабочей системы. Сколько это займёт, зависит от того же «сколько»: интеграций, ролей, отчётов, настроек и сценариев. Иногда система и вовсе растёт годами вместе с бизнесом — как в нашем кейсе Telegram-ботов для логистики из Китая, где всё началось с одного бота для клиентов.

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

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

Забыть про интеграции. Кабинет без связи с 1С или CRM быстро превращается в ещё одно место, куда данные переносят руками. Если данные уже где-то живут, кабинет должен брать их оттуда.

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

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

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

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

Поэтому лучший способ узнать цену — не искать среднюю по рынку, а описать свою задачу. Чем точнее вы понимаете, кто будет работать в кабинете и что он должен делать, тем точнее будет оценка и тем меньше сюрпризов в процессе.