«Нам нужен личный кабинет на сайте» — фраза, после которой два подрядчика могут назвать совершенно разные суммы. И оба будут правы: они услышали разные задачи.
Потому что за этими словами скрываются два разных продукта. Первый — раздел сайта, доступный после входа. Второй — самостоятельная система, у которой сайт может не быть вовсе. Выглядят они для пользователя похоже: адрес, поле логина, страница с данными. Устроены по-разному, стоят по-разному и по-разному ведут себя через год.
Ниже — десять признаков, по которым видно, что подходит вам. Три из них решают больше остальных, и я скажу, какие именно.
В чём разница по существу
Личный кабинет в составе сайта — это продолжение сайта: часть того же продукта, связанная с его контентом и клиентскими сценариями. Человек заходит, чтобы посмотреть свои заказы, скачать документ, оплатить счёт, продлить подписку. Действий немного, каждое короткое.
Отдельное веб-приложение — это рабочий инструмент. У него свои пользователи, роли и рабочие сценарии; данные при этом могут храниться внутри системы, а могут приходить из уже существующих сервисов. Сайт может остаться витриной, а может не понадобиться вообще: сотрудники и партнёры на него не ходят.
Граница проходит не по количеству функций, а по тому, что происходит внутри. Как практическая граница для первичного выбора: если человек в основном смотрит на то, что уже произошло, — это кабинет. Если внутри рождается и меняется работа, — это система.
Что закрывает личный кабинет на сайте и где у него потолок
Чтобы таблица ниже читалась предметно, сначала — про верхнюю границу первого варианта.
Что в кабинет на сайте укладывается хорошо. История заказов и их статусы. Документы: счета, акты, договоры — посмотреть и скачать. Оплата и продление. Личные данные и адреса доставки. Обращения в поддержку. Всё это — короткие действия одного человека вокруг того, что уже произошло, и данные для них обычно уже есть на сайте или приезжают из вашей системы учёта.
Где начинается потолок. Он не технический, а практический. Чем больше внутри ролей, согласований и собственной логики, тем сильнее кабинет начинает жить своей жизнью внутри сайта: у него появляются свои справочники, свои права, свои правила — и всё это приходится поддерживать средствами, рассчитанными на другое. Сайт при этом продолжает работать, просто всё больше изменений начинают затрагивать не одну страницу, а права, данные и связанные сценарии.
Иногда ранний сигнал слышно даже в языке команды: вместо «страницы в кабинете» начинают говорить «раздел системы». Заметить это ничего не стоит, а сказать оно может больше, чем список пожеланий.
Таблица выбора: десять признаков
| № | Признак | Скорее кабинет на сайте | Скорее отдельная система |
|---|---|---|---|
| 1 | Кто пользователь | клиенты, которые и так приходят на сайт | сотрудники, партнёры, подрядчики |
| 2 | Сколько ролей | одна: клиент | несколько с разными правами |
| 3 | Что человек делает внутри | смотрит своё, скачивает, оплачивает | ведёт работу: создаёт, меняет, согласует |
| 4 | Откуда берутся данные | приходят снаружи, кабинет показывает | создаются и меняются внутри |
| 5 | Нужен ли контент сайта | да: каталог, цены, описания услуг | нет, система самодостаточна |
| 6 | Нужно ли продолжать с того места, где остановились | обычно нет: действие завершилось | да: есть незавершённые задачи и состояния |
| 7 | Что будет, если сайт недоступен | неприятно, но терпимо | работа встаёт |
| 8 | Как часто меняется логика | почти не меняется | меняется вместе с процессами |
| 9 | Чьи данные внутри | данные текущего пользователя | данные многих пользователей и общего процесса |
| 10 | Что планируется через год | то же самое | новые роли и сценарии |
Отмечайте по каждой строке ту сторону, которая ближе к вашей ситуации. Если отметки лягут в обе колонки — это нормально; вопрос в том, где именно проходит смесь.
Одно условие: отвечайте про конкретный процесс, а не про компанию вообще. «Кабинет для клиентов сервисного центра, где видно статус ремонта» и «система, в которой мастера ведут заказы» — это два разных заполнения таблицы, даже если речь об одной фирме. Смешав их в одно, вы получите ровно ту смесь, из-за которой подрядчики и называют разные суммы.
Три признака, которым я даю больший вес
Считать отметки — плохой способ принять это решение: признаки неравнозначны. Дальше — моя модель первичной оценки, а не универсальный закон.
Больший вес я даю строкам 2, 3 и 7 — числу ролей, характеру работы внутри и последствиям недоступности. Изменение любого из них затрагивает не отдельный экран, а роли, сценарии и структуру решения целиком.
Остальные семь я использую как уточняющие. Они помогают понять объём, нужные интеграции и запас на развитие, но сами по себе не дают такого же сильного сигнала.
Отсюда порядок действий: сначала посмотрите на строки 2, 3 и 7, потом — где больше остальных отметок. Если все три явно указывают в сторону отдельной системы, я бы не принимал решение только по большинству прочих отметок.
Три ошибки, которые я вижу в таких разговорах
Выбирают по цене входа. Кабинет в составе существующего сайта может оказаться меньшим по объёму решением на старте — и это нормальный аргумент в его пользу. Но по мере появления ролей, согласований и собственной логики первоначальная экономия перестаёт быть главным аргументом. Смотреть стоит на строку 10, а не только на первую смету.
Называют кабинетом то, что кабинетом не является. Знакомая формулировка: «нужен личный кабинет для клиентов, и чтобы менеджер тоже мог там работать, и бухгалтер видел оплаты». Это уже не просто клиентская страница: появляется отдельная задача по ролям и правам, и строка 2 начинает весить намного больше. Слово осталось прежним, а разговор пошёл про другое.
Делают систему там, где хватило бы страницы. Обратная ошибка — сделать отдельную систему там, где хватило бы страницы. Если клиенту нужно раз в месяц посмотреть статус заказа и скачать акт, отдельная система решает задачу, которой нет: она требует своей поддержки, своих доступов и своего сопровождения ради одного экрана.
Что если сейчас кабинет, а через год система
Такой путь тоже бывает разумным: начать с малого, посмотреть на использование и расширять по факту. Но у него есть цена, и её стоит знать заранее.
Что обычно проще сохранить: данные — заказы, клиенты, документы. Если они структурированы и у записей есть понятные идентификаторы, их можно выгрузить и загрузить. Если данные разъехались по форматам и дублям, лёгким переезд не будет и здесь.
Что может потребовать пересборки: интерфейсы и часть логики. Собранное средствами сайта на самостоятельной системе, скорее всего, придётся собирать заново — не потому, что кто-то схалтурил, а потому, что это другой инструмент.
Что нужно учитывать отдельно: смену привычного сценария. Люди уже привыкли к расположению разделов, и переезд — это работа по объяснению, а не только по разработке.
Практический вывод: начинать с кабинета имеет смысл, когда он закрывает текущую задачу без искусственных ограничений и вы понимаете цену возможного переезда. А если роли и сложные сценарии известны уже сейчас, разумнее учитывать их в основании сразу.
Куда смотреть дальше
Если по таблице получается кабинет в составе сайта — он считается как дополнение к сайту, отдельно от его базовой стоимости; состав и порядок цен корпоративного сайта — на его странице.
Если получается отдельная система — это веб-приложение, оно начинается от 450 000 ₽; что входит в эту цену и что оценивается отдельно, я разобрал подробно — в статье про состав и на странице услуги.
А если пока непонятно даже то, что именно у вас ломается и нужен ли вообще отдельный инструмент, — начинать стоит не с этой таблицы, а с диагностики.
Что подготовить, прежде чем спрашивать цену
Три вещи, и все формулируются без разработчика:
- Список ролей — кто будет заходить и что каждому можно.
- Один типичный сценарий — что человек делает от входа до результата.
- Ответ на строку 10 — что должно появиться через год.
По этим трём пунктам разговор о бюджете становится заметно предметнее: подрядчик сразу видит роли, основной сценарий и запас на развитие.