Выделите текст, чтобы комментировать.
Раздел «Роли пользователей» не заменяет договорённость о том, кто вправе менять данные. До выбора CRM или заказа собственной системы стоит описать конкретные действия сотрудников: какие карточки они видят, какие поля редактируют и какие изменения требуют согласования. Такая запись даёт бизнесу и разработчику предмет для проверки.
Начать с действий, а не должностей
Формулировка «менеджеру нужен доступ к клиентам» слишком широка. В ней не определено, можно ли видеть всю базу, выгружать её, менять ответственного или удалять карточки. Каждое из этих действий следует обсудить отдельно. Название должности само по себе не отвечает на эти вопросы.
Для согласования удобно составить список операций: просмотр карточки, создание записи, изменение контактных данных, изменение цены, перенос ответственности, экспорт, удаление. Затем напротив каждой операции указать, кому она нужна для работы. Если ответ пока неизвестен, его нужно получить у владельца процесса, а не заменять предположением разработчика.
Это не предложение ограничить всех одинаково. Смысл в том, чтобы необходимое действие было доступно человеку, который за него отвечает, а лишнее разрешение не появлялось только потому, что оно входило в стандартную роль.
Определить границы данных
Следующий вопрос — с какими записями сотрудник может выполнять разрешённую операцию. «Редактирует свои сделки» и «редактирует все сделки отдела» — разные требования. Отдельно стоит записать правила для другого филиала, закрытых сделок и карточек, временно переданных на замену коллеге.
В техническом задании нужны одновременно действие и граница. Недостаточно поставить отметку «редактирование: да». Следует указать, каких данных она касается и от какого признака зависит доступ. Владелец карточки, подразделение, назначенный ответственный и состояние записи могут участвовать в решении по-разному. Выбирать условия следует по реальному процессу компании.
Если сотрудник работает сразу в нескольких подразделениях, для этого требуется отдельная договорённость. Нельзя считать, что совмещение автоматически даёт доступ ко всей организации. Необходимо определить, кто назначает такой доступ, на какой срок и кто проверяет его после окончания замещения.
Отделить изменение от согласования
Право изменить цену и право согласовать скидку лучше обсуждать как две самостоятельные операции. Также стоит разделять подготовку документа и его утверждение, создание заявки на возврат и проведение самого возврата. Какие именно действия требуют согласования, решает компания: универсальный набор для любого бизнеса здесь не подходит.
Для каждого выбранного действия зафиксируйте четыре пункта: кто начинает процесс, кто принимает решение, какое состояние считается окончательным и что делать при отказе. Если согласующий отсутствует, нужен предусмотренный порядок замены. Иначе требование «только с разрешения руководителя» останется пожеланием, которое нельзя проверить при приёмке.
Не следует обещать себе, что любая CRM уже поддерживает согласованный порядок. В готовом продукте нужно проверить доступные настройки. При заказной разработке — включить правило в требования и критерии приёмки. Описание процесса и наличие функции в конкретной системе — разные вещи.
Проверить интерфейс и серверное решение
Скрытая кнопка помогает пользователю ориентироваться в интерфейсе, но проверка доступа не должна ограничиваться её видимостью. В рекомендациях OWASP по авторизации отдельно описаны минимально необходимые права, отказ при отсутствии разрешения и проверка прав при каждом запросе. Поэтому приёмку нельзя свести к тому, что сотрудник не нашёл действие в меню.
Техническую проверку стоит поручить разработчику или специалисту по тестированию на согласованном тестовом стенде. Для каждого правила понадобятся две проверки: разрешённое действие выполняется, запрещённое отклоняется. При отказе защищённые данные не должны измениться. Проверять ограничения на чужих системах или на действующих клиентских данных для такой приёмки не требуется.
Один успешный вход в систему подтверждает работу входа, а не корректность всех прав. В приёмочном протоколе следует отдельно отметить, под какой учётной записью выполнена проверка, к какой карточке она относилась и какое правило проверялось. Без этих сведений результат трудно воспроизвести после обновления.
Записать порядок изменения прав
Права доступа меняются не только при найме и увольнении. Сотрудник может перейти в другой отдел, получить временное замещение или перестать выполнять часть обязанностей. Поэтому в требованиях нужен ответ на вопрос: кто обновляет доступ и на основании какого решения.
Полезно вести список временных разрешений с ответственным и сроком пересмотра. Сам факт окончания срока должен приводить к предусмотренному действию — автоматическому отзыву, если он реализован, либо проверке ответственным человеком. Наличие автоматического отзыва необходимо подтвердить в выбранной системе; календарное напоминание не означает, что права уже исчезли.
Отдельно согласуйте, какие сведения о значимых изменениях нужно сохранять. Для проверки конкретного изменения могут потребоваться исполнитель, время, изменённый объект и результат. Какие данные входят в журнал, кто его видит и как долго он хранится, нужно описать в проекте. Нельзя считать, что журналирование по умолчанию покрывает любую операцию и любую задачу бизнеса.
Собрать документ для приёмки
Итогом обсуждения может быть короткая таблица: действие, граница данных, разрешённая роль, необходимость согласования, ожидаемый результат проверки. Каждая строка должна соответствовать одному проверяемому правилу. Если в клетке написано «по ситуации», правило ещё не согласовано.
К таблице добавьте владельца документа, дату версии и порядок внесения изменений. Перед запуском пройдите согласованные строки на тестовых учётных записях. После изменения ролей или рабочего процесса пересмотрите затронутые проверки. Это способ связать настройку доступа с реальной ответственностью сотрудников, а не отдельная гарантия безопасности всей системы.
Какая операция в вашей компании сейчас описана только словами «доступно менеджеру», хотя требует более точного правила?
