Сочи · работаем по РФ и СНГ Пн–Пт 10–19 · Сб 11–16 (МСК)
Текст этой страницы без разметки — markdown-версия. Полный список страниц сайта — llms.txt, тексты всех страниц целиком — llms-full.txt.
Веб-сервис · кабинет со своей моделью данных от 200 000 ₽ роли проектируются

Личный кабинет клиента: экран, в котором работают

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

  • Роли различаются не видимостью, а сценарием: кто создаёт, кто согласует, кто отменит
  • Журнал действий появляется вместе с правом действовать: кто, что и когда
  • Экран недоступен — встала работа у клиента, поэтому окно обслуживания оговаривается письменно
от 200 000 ₽, срок 7–10 недель кабинет внутри сайта — от 280 000 ₽ разбор бесплатный 9 лет в разработке
Разбираемся

Роли — это модель, а не галочки в настройках

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

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

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

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

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

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

Что именно придётся проектировать

Четыре предмета работы, которых у витринного кабинета нет вовсе. Они появляются не по очереди, а сразу: как только человек получает право что-то создать, всё четыре включаются одновременно.

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

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

Шесть частей, и экраны среди них самые дешёвые

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

Своя модель данных

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

Роли со своими сценариями

Не уровни доступа к одному экрану, а разные пути: один создаёт, второй согласует, третий забирает документы. Описываются действиями, а не галочками.

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

Администратор компании-клиента заводит и отключает своих сотрудников сам. Иначе отзыв доступа после увольнения проходит через вашу почту и опаздывает.

Журнал действий

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

Обмен в обе стороны

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

Поведение при отказе

Что человек видит, когда учётная система недоступна: сохраняется ли черновик, можно ли продолжить и куда писать. Решается до запуска, а не в момент аварии.

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

Спросить про свои роли

Не уверены, что у вас именно система?Напишите, что клиент будет делать в кабинете и кто на вашей стороне это принимает. Скажем, хватит ли раздела на сайте, справится ли экран в мессенджере или задача действительно про отдельную систему. Без счёта и без созвона.

Спросить в Telegram Сравнить с кабинетом на сайте

Шесть признаков, что это уже система

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

Отметьте то, что про вас

Вердикт появится после первой отметки. Ничего никуда не уходит: это проверка для вас, а не заявка.

Совпало 0 из 6

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

Как идёт работа

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

  1. 01

    Перепись ролей и действий

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

  2. 02

    Модель данных и правила переходов

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

  3. 03

    Прототип одного сквозного сценария

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

  4. 04

    Разработка и обмен на тестовых данных

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

  5. 05

    Запуск на одной компании-клиенте

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

Доступность: что обещаем и чего не обещаем

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

Что мы делаем и обещаем
  • Мониторинг и резервные копии с первого дня. Не «когда понадобится»: понадобятся они ровно один раз, и это будет плохой день
  • Реакция на аварию — 15 минут, в любой день, включая выходные. Это общее условие студии, одинаковое для всех работ
  • Работа кабинета не зависит от учётной системы напрямую. Если учёт молчит, человек всё равно оформит заявку: она уйдёт в очередь и доедет, когда связь вернётся
  • Окно обслуживания согласуется заранее и приходится на время, когда ваши клиенты не работают. Оно объявляется, а не случается
Чего не обещаем
  • Круглосуточного дежурства. У студии его нет ни на одном направлении, и придумывать его для одной страницы мы не станем. Ночные условия — отдельный пункт договора
  • Процента доступности в год. Такого числа у нас нет, а названное наугад вы проверите первым же инцидентом. Что обещаем, написано слева и проверяется
  • Работы при отказе вашего хостинга или вашей 1С. Чужую недоступность мы переживаем аккуратно и без потери данных, но починить её не можем
  • Бесплатного сопровождения после сдачи. Кабинет живёт дальше: обновления, правки по поведению людей, чужие изменения. Это поддержка, и считается она часами

Час доработок стоит 3 000 ₽ по факту и 2 000 ₽ в абонементе; абонемент начинается от 60 000 ₽ в месяц и включает 30 часов. Проценты «на поддержку в год» мы не называем: такого числа у студии нет.

Три ошибки, из-за которых кабинет потом переписывают

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

  1. Кабинет пишет прямо в чужую базу

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

  2. Права проверяются на экране, а не на действии

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

  3. Состояния записи не описаны, они «как-то сложились»

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

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

Условия, при которых мы сами предложим остановиться

Три строки. Первые две выясняются до счёта и уводят на более дешёвую работу, третья случается внутри проекта и губит кабинеты чаще всего.

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

Про деньги при остановке — общее для студии и написано на странице оплаты и гарантий. Остановка на разборе не стоит ничего: разбор бесплатный.

От чего зависит цена

Своей сметы у формата нет: первая версия кабинета — вход в направление, от 200 000 ₽; кабинет, которым пользуются каждый день, — вторая ступень, от 450 000 ₽. Разброс внутри задают четыре вещи, и число экранов среди них не значится.

  1. Сколько ролей и насколько разные у них пути

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

  2. Есть ли согласование и сколько в нём шагов

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

  3. Как устроен обмен с вашими системами

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

  4. Что должно происходить, когда что-то недоступно

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

Три сметы направления с составом и сроками — на странице веб-сервисов. Своей ступени у этой страницы нет намеренно: кабинет считается по тем же трём, что и остальные сервисы.

Эта страница — один из форматов направления

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

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

Когда такой кабинет вам не нужен

Четыре случая. Первые два уводят на соседние страницы сайта, где та же задача решается дешевле, третий — на другое направление, четвёртый означает, что начинать надо не с нас.

  1. Если человеку достаточно видеть своё

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

  2. Если ваши клиенты живут в мессенджере

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

  3. Если в кабинете будут работать только ваши сотрудники

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

  4. Если показывать пока нечего и создавать некуда

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

Куда идти, если задача другая

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

Если человек только смотрит своё Сайт с личным кабинетом Закрытый раздел внутри сайта: статусы, документы, история, повтор заказа. Дешевле, быстрее и входит в смету сайта целиком. Там же разобрано, где этот вариант упирается в потолок Если клиенты не выходят из мессенджера Личный кабинет в Telegram Вход без пароля, потому что мессенджер уже знает, кто открыл. Главная работа там — связать вошедшего с карточкой в вашем учёте, и разобрана она подробно Если кабинет должен жить рядом с 1С и CRM Интеграции между системами Обмен в обе стороны, очередь и повторы, журнал операций и поведение при расхождении. Для кабинета, в котором создают записи, это не дополнение, а часть конструкции Если карточки клиента ещё не существует Настройка CRM Кабинету нужно откуда-то брать клиентов, договоры и историю. Если этого места пока нет, первая работа не наша — и мы скажем это на разборе, даже когда речь о более дешёвом заказе

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

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

Как отличить кабинет-витрину от кабинета-системы

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

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

Почему доступность обсуждают до разработки

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

Сколько стоит разработка личного кабинета

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

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

Что подготовить до разбора

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

Вопросы про личный кабинет

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

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

Расширяется не интерфейс, а серверная часть. Если у приложения в мессенджере уже есть рабочий бэкенд с вашими данными и обменом, кабинет-система подключается к нему, а не строится рядом — переписывается интерфейс, а логика и интеграции остаются. Поэтому путь «сначала экран в мессенджере, потом отдельная система» дешевле обратного. Что именно умеет и чего не умеет экран в Telegram, написано на его странице

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

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

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

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

Опишите, что клиент будет делать в кабинете, — скажем, система это или раздел

  • Разбор 30 минут: роли, действия, согласования и где сейчас лежат данные
  • Скажем прямо, хватит ли раздела на сайте или экрана в мессенджере
  • Если начинать надо с порядка в учёте, услышите это первым и бесплатно
Николай Старостов, основатель Starostoff
Николай Старостов Основатель. Разбор веду лично, не передаю менеджеру
Куда прислать ответ

Ответ в течение рабочего дня

Заявка принята

Вернёмся в течение рабочего дня. Если срочно — напишите в Telegram.