Роли и права
Кто что видит и что может менять — решаем до интерфейса, иначе переделывать придётся всё.
Бюросложных систем
Услуги / веб-сервисы и кабинеты
Личный кабинет,
в котором видно,
кто что сделал.
Система, где у клиента, менеджера и руководителя разные права, разные экраны и разные вопросы к данным. Проектируем роли и сценарии, а потом уже пишем код.
Описать свой кабинет ↘
Первый прототип — 0 ₽
Для нового кабинета покажем логику на экране до оценки проекта.
РОЛИ И СЦЕНАРИИ
Кто заходит
и зачем.
Клиент
Смотрит статус заказа, историю и документы. Не звонит, чтобы узнать, что происходит.
Менеджер
Ведёт сделки и заявки, видит только свои. Не держит параллельную таблицу «для себя».
Руководитель
Видит актуальные цифры по всем — без сводки, которую вручную собирают к понедельнику.
Внешняя система
Забирает и отдаёт данные по API: учётная система, сайт, телефония.
Роли у вас, скорее всего, другие. Это и есть первое, что мы выясняем: список ролей определяет всё остальное — от прав до экранов.
ПРИЗНАКИ
Похоже на ваш случай,
если хотя бы одно — правда.
- Клиенты звонят, чтобы узнать статус, потому что посмотреть его негде.
- Менеджеры ведут работу в таблице, потому что в системе неудобно.
- Права устроены по принципу «видно всё» или «не видно ничего».
- Отчёт руководителю собирается руками и к понедельнику устаревает.
- Каждое новое исключение из правил требует программиста.
ОБЪЁМ РАБОТ
Что входит в работу.
Сценарии работы
Путь заявки или сделки от появления до закрытия, включая исключения — их всегда больше, чем кажется.
Интерфейс под роль
Делаем разные экраны для разных ролей вместо одного универсального, в котором неудобно всем.
Данные и отчёты
Что система хранит, что считает сама и что отдаёт наружу без ручной сборки.
Интеграции
Настраиваем обмен с учётной системой, сайтом, телефонией, чтобы данные не вводились дважды.
Запуск и сопровождение
Разворачиваем, переносим существующие данные, остаёмся на связи после запуска.
ГРАНИЦЫ
Что в услугу не входит.
- Не делаем мобильные приложения для магазинов приложений.
- Не берёмся за проект, где список ролей не готов и выяснять его никто не хочет.
- Не внедряем коробочные CRM: это другая работа и другие люди.
- Не рисуем дизайн-концепции без последующей разработки.
СТОИМОСТЬ
Сколько это стоит.
Для нового кабинета первый шаг — бесплатный прототип одного согласованного сценария. Это ещё не система: он показывает логику и экраны, чтобы дальше говорить предметно. Если кабинет уже есть, начинаем с разбора того, что мешает им пользоваться. Потом — этапы; где кончается каждый, договариваемся заранее.
Цену называем после прототипа: объём кабинета задают роли и исключения, число экранов тут почти ни при чём.
ВОПРОСЫ
Что обычно
спрашивают.
У нас уже есть кабинет, но им не пользуются.+
Частая история, и причина обычно в том, что роли и права заданы не так, как устроена работа, — дело редко в самом интерфейсе. С этого и начнём.
Можно перенести данные из таблиц?+
Да, это штатная часть запуска. Сложность зависит не от объёма, а от того, насколько данные в таблицах согласованы между собой.
Сколько ролей — это много?+
Четыре-пять ролей покрывают почти всё. Если их выходит больше десяти, обычно это признак, что роли перепутаны с должностями.
Что, если сценарии изменятся?+
Изменятся обязательно. Поэтому сначала запускаем ядро и смотрим, как им пользуются, а дальше расширяем по фактам, не по предположениям.
ЗАЯВКА
Опишите,
кто будет заходить.
Достаточно перечислить роли своими словами: кто, что делает, что должен видеть. Схем и документов не нужно.