Организация - верхний контейнер над командами: одно место, где заданы общая идентичность, администрирование и настройки уровня всей компании. Команды при этом остаются самостоятельными единицами: у каждой свой состав, свои роли, свой взгляд на расход, свои настройки приватности и свои ограничения. Организация не отменяет команду, она забирает у неё то, что не должно решаться внутри отдела: вход, каталог сотрудников, договор и правила, общие для всех.
Наивное представление естественно, потому что структура растёт снизу. Сначала появляется одна команда, потом вторая, потом отдельная команда для подрядчиков, и каждая заводит себе вход, свой список людей и свои лимиты. Пока команд две или три, это дешевле любой централизации: настройка занимает полчаса, согласовывать не с кем, а разница между командами выглядит как полезная гибкость, а не как расхождение.
Ломается это на арифметике. Настройка не одна, их десяток, и каждая новая команда умножает их на себя; человек состоит сразу в нескольких командах и в каждой имеет свою роль, а где-то не состоит вовсе; увольнение приходится закрывать в трёх местах, и достаточно забыть одно; расход считается по каждой команде отдельно, хотя договор один. Ни одна из этих проблем не выглядит аварией по отдельности, и все вместе они дают состояние, которое никто не может описать целиком.
Профессиональный механизм начинается с того, что вход настраивается один раз наверху, а не повторяется в каждой команде. У организации есть команда по умолчанию - устойчивый дом для входа и маршрутизации. Единый вход организации через поставщика идентичности - рекомендуемый способ входа в масштабах компании, при этом вход на уровне отдельной команды остаётся поддержанным для случаев со своими требованиями к идентичности. Подготовка учётных записей на уровне организации делает группы каталога видимыми для системы, а администратор выбирает, какие из них синхронизировать. Организация умеет опираться на несколько каталогов, если у присоединённых команд были разные поставщики; свести их в один можно, но на время слияния настройки блокируются, а обратной операции нет.
Второй опорой служат организационные группы - когорты поперёк команд: инженеры, подрядчики, пилотная группа. Синхронизированная группа зеркалит каталог, её состав в консоли доступен только для чтения и меняется у поставщика идентичности. Ручная группа ведётся администратором через консоль, импорт списком или программный интерфейс организации и позже может быть подключена к каталогу. Группа, отображённая на команду, управляет её составом целиком: вступление в группу добавляет человека в команду, выход убирает, если он не попадает туда через другую отображённую группу, а ручное редактирование состава на такой команде выключается. Создают и ведут группы администраторы организации; администратору команды это недоступно.
Отсюда вырастает главный вопрос эксплуатации. Одно и то же значение может быть задано на четырёх слоях: команда, человек в команде, группа каталога и организационная группа. Общее правило разрешения конфликтов знать надо наизусть: выигрывает более разрешающее. Из него есть важное исключение - персональное значение на человеке в команде перебивает и командные значения по умолчанию, и настройки групп каталога. Ниже такая карта: настройка, правило слияния и следствие, ради которого это правило стоит помнить.
Разворачивается правило по-разному. Лимит расхода берётся наибольший из применимых. Доступ к моделям объединяется: модель доступна, если её разрешает команда или любая из групп. Управление автоматическим запуском сливается по каждому полю отдельно, и в каждом побеждает более свободное значение, так что выключенная песочница перебивает включённую. Инструкции автоматического ревью не сливаются, а замещают: групповые заменяют командные для затронутых людей. Роли в командах в слиянии не участвуют вовсе, они определяются отображением групп. Практическое следствие одно: забытая широкая группа снимает ограничение у всех, кто в неё попал, и на экране настроек команды этого не видно.
| Настройка | Правило слияния | Следствие |
|---|---|---|
| Лимит расхода | Берётся наибольший из применимых | Широкая группа поднимает планку всем, кто в неё попал |
| Доступ к моделям | Объединение: хватает разрешения от команды или любой группы | Запрет держится, только если запрещают все слои |
| Автоматический запуск | Слияние по полям, в каждом побеждает более свободное значение | Выключенная песочница в одной группе отменяет включённую |
| Инструкции автоматического ревью | Групповые замещают командные | Для затронутых людей командный текст не действует |
| Роли в командах | Определяются отображением групп на команды | Слияния нет, ручная правка состава выключена |
| Состав команды | Объединение составов всех отображённых групп | Выход из одной группы не выводит из команды, если есть вторая |
| Расход и отчётность | Считается по командам, средства берутся из общего пула | Группы выставления счетов задают атрибуцию, а не ограничение |
Вторую половину задачи решает общий бюджет. Вместо фиксированной доли на человека организация получает единый пул на срок договора, из которого берёт тот, кому сейчас нужнее; неизрасходованная доля тихого месяца не сгорает у одного, а достаётся другому, разбирающему тяжёлую задачу. Учёт ведётся нарастающим итогом за срок договора, а не обнуляется каждый месяц. Контроль при этом не исчезает: оповещения о расходе по настраиваемым порогам уходят администраторам почтой, а лимиты на команду умеют пересчитываться при росте и сокращении состава, и менять эти настройки может только администратор. Повседневная отчётность собирается по командам, а группы выставления счетов - отдельная сущность: они отвечают за то, на кого записан расход, а не за то, что человеку разрешено.
Цена верхнего слоя - необратимость и неочевидность. Слияние поставщиков идентичности назад не отыгрывается, а эффективная настройка человека перестаёт читаться из одного экрана: она складывается из команды, персонального значения и всех групп, в которые он входит. Оправдан этот слой там, где команд больше двух, каталог один и договор общий; одной команде он добавляет работу, не давая ничего взамен. Проверяют результат не по экрану настроек, а по поведению: завести человека в каталоге и посмотреть, в каких командах он появился; убрать его из группы и убедиться, что он действительно вышел из команды; дать одному человеку членство в двух группах с разными лимитами и посмотреть, какой лимит действует - должен остаться больший, а не заданный последним.
Типичные провалы предсказуемы. Считать, что настройка команды перебивает групповую. Оставить пилотной группе широкие разрешения после окончания пилота. Свести поставщиков идентичности, не выписав заранее, что при этом теряется. Отобразить на одну команду несколько групп и удивиться, что состав получился их объединением. Принять группу выставления счетов за инструмент ограничения. И перевести компанию на общий бюджет, не задав пороги оповещения, а потом узнавать о расходе из счёта.