Organizational Decision Records (ODR)

Как это обычно бывает когда надо сделать реорг: составляются какие-то схемы в доске, что-то по факту отличается, непонятно кто видел и кто согласовал, где-то что-то разъехалось, непонятно с какой даты изменения вступают в силу. В лучшем случае все существует в голове автора, который может это объяснить на пальцах или прислать ссылку с названием вроде "Реорг 2026 v7 (draft)" — которая больше напоминает фиче-ветку, которая случайно уехала в прод, чем стабильный master.

Оказывается, все лучшее уже придумано — пару лет назад я подсмотрел у уважаемого Владимира Коноплева подход, который моментально захотел переиспользовать — Organizational Decision Records или ODR.

Да-да, это как TDR в Авито или ADR в Google при проектировании инженерных систем, только для проектирования и описания организационных изменений. И обладает теми же преимуществами, что и TDR / ADR — остается артефакт, а вместе с ним зеленые галочки от ревьюверов и аппруверов.

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

Получилось, что основные блоки примерно такие:
• as is и to be структура, прям схемой — для визуалов
• описание мотивации изменений — самое мясо и объяснение зачем
• альтернативы и компромиссы — мои любимые блоки, позаимствованные из TDR
• данные по зоне ответственности и ее изменению
• всякие данные по численности
• порядок и таймлайн вступления изменений в силу
• и сверху список авторов с датами, а также список согласующих, тоже с датами и с их визами о согласовании
• а, снизу еще есть чеклист на соответствие принципам орг дизайна, принятым в компании — как юнит-тесты для самопроверки

Итого получается вся важная информация, собранная на одной страничке и доступная всем заинтересованным — тот самый стабильный мастер, который можно смело катить в прод.

#структурируйэто