Доброго дня й дякую за запитання. Ви слушно зазначили, що аналіз причин та наслідків не наводяться у цій статті, й так це поза межами.
Але я спробую відповісти й навести деякі спостереження-приклади.
Стосовно запитання «чи розглядали Ви Blocker, Major, Critical як ризики, щоб працювати з проблемами до того, як вони з’являються». Це окремий процес який повинен бути ретельно опрацьований, й не тільки на ретроспективі. За результатами дослідження причин та наслідків складається план запобігання.
Тут варто зазначити, що запобігання проблемі не завжди можливе з точки зору компанії, а також не завжди можливе з точки зору команди-розробників.
Наприклад, нехай в нас застосунок, на якому можна здійснювати якісь покупки й сплачувати за допомогою декількох сервісів. Й от саме сьогодні сервіс, якому надають перевагу 80% користувачів не працює. Чи в нас стався Blocker? На мою думку так. Чи можемо це виправити «негайно» — ні. Така ситуація може статися знову? — Так.
Тобто з точки зору команди-розробників ми безсилі. Ну максимум можемо звернутися до нашого постачальника платіжного сервісу й повідомити про проблему; можливо отримаємо якийсь прогноз про час виправлення. Але суттєво не впливаємо на вирішення проблеми.
З іншого боку можемо переглянути договір з цим платіжним сервісом, але це також не стосується активних дій розробників.
Якщо взяти цей самий приклад й уявити, що платіжний сервіс змінив API, про що нам було заздалегідь повідомлено, але команда вчасно не внесла зміни на своєму боці — то ту вже наша відповідальність.

Max, дякую за відгук. Рада, якщо стала у нагоді.

Valentine Barmak, дякую за коментар. Змінила лінку )
Гадаю визначення безпосередньо залежать від перекладу.
Ось тут, наприклад, ukraine.iiba.org/babok-glossary-ukraine, проєкт — це тимчасова діяльність, спрямована на створення унікального продукту, послуги або результату.
А за цим перекладом biconsult.ru/...​/PMBOK-6th-Edition-Ru.pdf визначають, як підприємство.

Дякую, що приділили час. :)

Алекс, а в чому полягає Ваше співчуття, поясніть будь-ласка?

Стосовно першого запитання, то не бачу перепонів для використання SLA для продукти, що знаходиться в стадії розробки та ще не мав жодного релізу у прод. У даному випадку команда при плануванні своїх робіт має чіткі критерії, які баги виправляємо в поточному спринті, які в наступному, а які класти в беклог. Наявність або відсутність проду тут не впливає.
Що ж до другого питання. Якщо уявити ситуацію при якій «існування продукту» на проді залежить від імплементації якоїсь критичної фічи, то звісно ми можемо сказати, що наступив блокер й все відкласти для розробки АСАП. Але це не схоже на системний підхід, скоріше на якусь екстренну ситуацію.

Алекс, для того, щоб відповісти на Ваші питання, мушу перепитати:
1. Що ви маєте на увазі під непродукційним оточенням?
2. Правильно я розумію, що Ви маєте на увазі ситуацію, коли під час поточної розробки поступає запит на зміни й команда вимушена переключитися на нову задачу вищого пріоритету?

Дякую за відгук, Євгене. :)