Разработка портала: роли, доступы и интеграции

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

Бизнес-контекст выбора архитектуры

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

Trade-offs: скорость vs гибкость

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

Когда хватает простого контура

Ключевой вопрос при проектировании интеграций — где сейчас находится «источник правды» о клиенте, заказе или документе. Если это CRM или ERP, портал должен читать (а иногда и писать) данные туда, а не дублировать их в своей базе — иначе быстро возникает рассинхронизация и портал начинает врать. Для компаний с 1С типична синхронизация остатков, документов и статусов без повторного ручного ввода. Для внутренних порталов сотрудников — интеграция с Active Directory для единого списка пользователей и SSO, чтобы не заводить отдельный пароль. Уведомления часто дублируют в мессенджеры вроде Telegram, чтобы пользователь не проверял портал вручную. Список необходимых интеграций определяется на этапе discovery, а не додумывается по ходу разработки.

Когда нужна более сложная схема

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

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

Как мигрировать без простоя

На странице услуги «Порталы» процесс включает: погружение и фиксацию задачи (1–2 недели), проектирование структуры разделов, прав доступа и интеграционного контура (1–3 недели), дизайн интерфейса с проверкой сценариев в прототипе (2–4 недели), разработку спринтами с еженедельными демо рабочих разделов (3–16 недель), запуск с тестированием доступов и переносом документов (1–2 недели), развитие после запуска по обратной связи от пользователей.

Практический вывод

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

Ошибки при выборе подрядчика

1. Карту ролей и прав рисуют уже в процессе разработки, а не до старта — это ведёт к переделке архитектуры доступа
2. Список интеграций с CRM, 1С или Active Directory согласовывают «по ходу», хотя именно от него зависит львиная доля бюджета
3. Требования информационной безопасности не собраны на discovery, а всплывают на приёмке
4. Подрядчик закладывает одну общую роль «пользователь» вместо честной модели прав для разных аудиторий
5. Нет обсуждения, кто развивает портал после сдачи и как передаются код и доступы

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