Запишіть рішення, яке можна переглянути пізніше

Збережіть міркування

Зустріч щодо рішення дає вибір. Запис рішення зберігає пояснення, чому цей вибір мав сенс.

Без міркувань наступна команда може сприйняти тимчасове обмеження як постійний принцип. Вона також може повторити оцінювання, яке організація вже завершила.

AWS описує архітектурні записи рішень як спосіб документувати рішення та їхній контекст. Та сама стисла структура може допомогти з операційною моделлю розробки з ШІ. Зберігайте запис достатньо коротким, щоб відповідальні люди його прочитали.

Порівнюйте реалістичні альтернативи

Вигаданій компанії потрібно підтримувати застосунок договорів. Вона розглядає три варіанти:

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

Поєднання також може бути доречним. Наявна платформа може надавати середовища та розгортання, а фабрика програмного забезпечення — координувати розробку. Поясніть інтерфейс і відповідальність замість того, щоб нав’язувати штучний вибір «усе або нічого».

Напишіть шість частин

1. Контекст. Зазначте проблему та наслідок збереження поточного стану.
2. Вимоги. Перелічіть умови, яким має відповідати варіант.
3. Альтернативи. Запишіть реальні варіанти та їхні основні компроміси.
4. Докази. Додайте посилання на оцінювання, припущення витрат і невирішені питання.
5. Рішення. Назвіть вибраний варіант, обсяг, відповідального та прийняті межі.
6. Перегляд. Визначте дату або спостережувану подію, що потребує повторного оцінювання.

Відокремлюйте спостережуване від очікуваного. «Під час оцінювання завершено цю зміну в межах обслуговування» — спостереження. «Сервіс удвічі зменшить річні витрати на обслуговування» — прогноз, що потребує доказів і явних припущень.

Включіть найсильніше заперечення

Для застосунку договорів придбаний сервіс може зменшити інтеграційну роботу, але створити залежність від зовнішнього постачальника. Запишіть це заперечення та вправу експорту, що частково його розглядає. Не вилучайте заперечення через те, що команда віддає перевагу цьому варіанту.

Зазначте, які невирішені питання блокують активацію. Решту призначте відповідальним із датами. Рішення продовжити не перетворює питання контролю без відповіді на перевірений результат.

Переглядайте запис зі зміною вимог або доказів. Додавайте нове рішення, коли вибір змінюється, і зберігайте попередні міркування. Перейдіть до практичних сценаріїв Taiga, щоб застосувати ці принципи до робочих процесів продукту.