Я не добавляю в SaaS новую роль, пока не понимаю, что изменится для старой

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

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

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

Роль появляется не потому, что у должности есть название

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

Один и тот же руководитель может согласовывать расходы, смотреть сводку и настраивать правила. Но эти действия нужны ему не всегда и не в каждом продукте. Иногда все три разумно оставить в одной роли. Иногда настройка правил должна быть отделена даже от просмотра денег. Решение зависит не от оргструктуры, а от того, где меняется ответственность.

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

Я сначала рисую не доступы, а рабочий день

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

Поэтому я начинаю с короткого сценария. Например: менеджер подготовил заказ, специалист проверил нестандартное условие, руководитель подтвердил исключение, бухгалтер увидел обязательство. Здесь важны не экраны, а переходы. Кто получает работу? Что он меняет? Кто узнает, что решение принято? Что будет, если он ничего не сделает до конца дня?

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

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

Когда отдельная роль действительно оправданна

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

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

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

Каждая новая роль меняет путь тех, кто уже работает

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

Если таких ответов нет, пользователи воспринимают изменение как поломку. Они не знают, что процесс стал безопаснее; они просто видят, что привычная кнопка исчезла. И тут возникает соблазн вернуть старое право «временно, чтобы не мешать работе». Через месяц временное исключение становится обычным способом жить в системе.

Я проверяю четыре изменения для каждой старой роли:

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

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

Нельзя выпускать роль без понятного возврата

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

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

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

Не путать роль, разрешение и правило

Эти вещи часто смешивают, а потом продукт становится трудно объяснить даже команде. Роль отвечает на вопрос «в каком качестве человек участвует в сценарии». Разрешение — «что технически ему можно сделать». Правило — «при каких условиях это действие допускается».

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

В статье о настройках и ответственности в SaaS я разбирал похожую границу: гибкость полезна, пока у каждого правила есть владелец и понятный смысл. Новая роль не должна становиться способом спрятать неоформленное правило.

Проверка на один реальный сценарий лучше длинного списка пожеланий

Когда роль придумана, её хочется сразу отдать в разработку: экран, фильтр, уведомление, экспорт, настройка. Но до этого полезно пройти один сценарий от начала до конца вместе с теми, кто будет в нём участвовать.

Не обязательно строить прототип со всеми деталями. Достаточно показать последовательность: вот заявка, вот момент передачи, вот решение, вот результат для автора. Попросите каждого участника проговорить, что он увидит и что сделает. Если кто-то произносит «а я бы тогда написал коллегам», это не мелочь. Это место, где в продукте нет нужного перехода или нет понятного владельца.

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

Что стоит зафиксировать до разработки

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

• какую работу начинает эта роль и какой результат передаёт дальше;
• какой один сценарий для неё главный;
• какие действия остаются у существующих ролей;
• какие правила ограничивают её решение;
• кто отвечает за исключения и за изменение правил;
• по какому признаку будет видно, что новая роль действительно используется, а не обходится.

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

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

Если не совпала, лучше исправить маршрут и объяснение, чем заставлять людей «привыкать». Привычка к неудобному обходу не делает продукт лучше; она просто скрывает проблему до следующего масштабирования.

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

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

Роль — это часть продукта, а не опция в меню

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

Я отношусь к новой роли как к изменению маршрута, а не как к новому пункту меню. Тогда разговор сдвигается с «какие права поставить» на более полезное «какое решение станет яснее и безопаснее». Именно с этого начинается функция, которая не просто присутствует в релизе, а помогает компании работать.

А если идея появилась после изучения чужого продукта, не стоит превращать увиденное в список экранов. Сначала полезно разобраться, какую задачу решает чужое решение и какую задачу должен решать ваш продукт. Роль будет удачной только во втором случае.