Настройка ролей и доступов
Проблема
Сейчас роли и доступы для сотрудников нельзя настроить. Почему это плохо? Потому что мы не можем обозначить, какие ресурсы каждый сотрудник может просматривать, редактировать, удалять и далее по списку. Это может привести к утечке данных компании.
Поэтому настройка прав доступа — действий, которые сотрудники могут выполнять с папками и файлами — важна для эффективного и безопасного управления информацией.
Задача
Как владелец бизнеса, который пользуется Яндекс 360, я хочу иметь возможность
быстро и удобно настраивать доступы и ограничения для своих сотрудников;
одновременно настраивать роли для нескольких сотрудников.
Так я смогу контролировать безопасность процессов в своей компании и не допустить утечек данных со стороны сотрудника.
Текущий интерфейс
Первым делом я стала исследовать, что такое Яндекс 360 для бизнеса, и как он работает.
У меня не было доступа к сервису, поэтому вариант «потыкать» самой отпал. Я искала информацию на официальных сайтах Яндекса и его ютуб-канале, а также смотрела подробные видео с демонстрацией интерфейса на каналах компаний-дистрибьюторов MONT и Syssoft. Это помогло мне понять суть сервиса, его особенности и структуру.
Бенчмаркинг
Я проанализировала 5 сервисов и выделила ряд общих паттернов, а также почерпнула несколько идей из сервисов по отдельности.
Общие паттерны
Есть фильтрация по ролям или доступам (4/5)
Содержат только административные роли (4/5)
Можно вручную настроить доступ (3/5)
Можно выбрать роль при создании пользователя (2/5)
Есть статусы (2/5)
Есть мультиселект (2/5)
Avito
Доступы распределены по категориям
Настройки доступа раскрываются иерархично
Google Workspace
У каждой роли свой экран со списком доступов и назначенными пользователями
Роли можно копировать
Выводы
Суммарно на основе бенчмаркинга мне удалось сгенерировать 10 гипотез, которые я развивала впоследствии.
Почему я отказалась от шаблонов ролей
Сначала я подумала так: нужно максимально упростить работу пользователя. Я хотела избавить его от необходимости настраивать доступы, создав шаблонные роли разных категорий.
Но и эта гипотеза, и все её производные быстро отвалились по многим причинам. Поэтому я отказалась от обилия предопределённых ролей и приоритизировала создание ролей пользователями.
Дорого
Разработка и поддержание предопределённых ролей финансово невыгодны.
Долго
Администраторам быстрее самим создать необходимые компании роли, чем ждать обновления.
Сложно
Обилие вариантов выбора повышает когнитивную нагрузку.
Избыточно
Предопределённые роли усложнят интерфейс и могут попросту не подойти кейсам конкретного бизнеса.
Гипотеза 1
Все роли должны находиться в отдельном разделе
Как проверить
Не требует проверки, так делают все.
Гипотеза 2
Изначально у роли нет никаких доступов. Настройки доступа иерархичны и раскрываются последовательно
Зачем
Так мы применяем принцип прогрессивного раскрытия информации и упрощаем интерфейс. Предотвращаем ошибки. Возвращаясь к задаче — повышаем безопасность хранения данных.
Как проверить
Провести исследование-наблюдение по сценарию создания кастомной роли, чтобы отследить возможные барьеры.
Гипотеза 3
Роль — это дублируемый шаблон
Зачем
Число приложений, которые входят в Яндекс 360 для бизнеса, будет только расти. Как и число доступов, которые необходимо настроить. Кроме того, роли могут отличаться друг от друга незначительно. Поэтому важно предусмотреть дублирование ролей.
Как проверить
Провести исследование-наблюдение по сценарию создания роли, чтобы отследить возможные барьеры и проверить понимание концепции, что роли можно дублировать.
Сценарий создания роли
Гипотеза
Необходима история настроек ролей: кто кому когда назначил или изменил роль
Зачем
С её помощью можно будет отслеживать изменения и потенциальные утечки данных, вовремя выявлять любые подозрительные действия.
Как проверить
Историю доступов можно выкатить после самих ролей и провести АБ-тест, чтобы выяснить, упадет ли у экспериментальной группы количество вопросов в поддержку, связанных с историей доступов сотрудников.
Гипотеза 1
Сразу выбрать роль при создании сотрудника
Зачем
Чтобы сократить число кликов.
Как проверить
Проверить полноту вводимых данных и статистику по ней.
Сценарий создания пользователя
Гипотеза 2
Добавить графу «Роль» в шаблон CSV-файла с сотрудниками
Зачем
Чтобы сократить число кликов.
Как проверить
Аналогично первой гипотезе — проверить полноту вводимых данных и статистику по ней.
Гипотеза
Мультиселект в разы ускорит применение массовых действий
Как проверить
Замерить адопшн нажатия на кнопку «Изменить роль» при условии, что выделено не менее 2 пользователей.
Сценарий массового изменения прав
Гипотеза 1
Фильтрация поможет быстрее находить нужных сотрудников и совершать действия в отношении них
Как проверить
Замерить адопшн.
Гипотеза 2
Разделить список пользователей и список администраторов
Как проверить
Провести интервью-наблюдение с администраторами. Попросить их найти администраторов или сказать их число.
Пример 1
Если сотрудники с ролью Аналитик
Находятся в статусе На больничном
То изменить их роль на Гость
Пример 2
Если сотрудники с ролью Менеджер по продажам
Изменили свою роль на Топ-менеджер
То предоставить права на Удаление, Создание
Ресурса Годовой отчет
Гипотеза 1
Создание правил и условий для ролей повысит безопасность процессов в компании и снизит время, затрачиваемое на изменение ролей.
Во время бенчмаркинга я заметила, что у 2 из 5 сервисов сотрудники имеют статусы.
А в одном из видео компаний-дистрибьюторов узнала, что в Яндекс 360 для бизнеса есть раздел «Правила для писем». В нём можно автоматизировать обработку писем с помощью условий.
Я подумала, что два этих факта можно объединить в одну гипотезу.
Гипотеза 2
