Конструктор ADR (архитектурных решений)

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

Я сама узнала об ADR из книги "Проектирование архитектуры API" и поняла, что это действительно ценный инструмент для фиксации архитектурных решений. Мои розыски в документации проекта привели меня к существующему разделу ADR, который, к сожалению, давно не обновлялся и не использовался командой.

Как системному аналитику, мне хотелось, чтобы архитекторы не только вернули этот раздел к жизни, но и начали создавать новые ADR, фиксируя важные решения, которые мы принимаем в ходе обсуждений. Хотелось, чтобы эти решения не оставались на уровне мемо в электронной почте.

Однако быстро выяснилось, что в команде нет единого понимания того, как должны выглядеть ADR и какая структура для них оптимальна. Предыдущие ADR были избыточными и не имели чёткой структуры. Меня попросили прислать шаблон.

Я подумала, что будет полезно не просто дать шаблон, но и создать наглядное пособие. С помощью ИИ я структурировала материал и создала документ со следующими фичами:

🗺️ Структура 🚥 Статусы ✒️ Правила именования 🏗️ Конструктор для Confluence ✅ Чек-лист для проверки качества 📚 Примеры

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

Делитесь в комментариях — сталкивались ли вы, как системный/бизнес-аналитик, с ADR на проекте? Как вы их используете? 👇

Конструктор ADR (архитектурных решений) | Сетка — социальная сеть от hh.ru