Як написати меморандум про прийняття ризику англійською мовою

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

Ключовий словник

** Залишковий ризик ** — ризик, який залишається після того, як було застосовано заходи зменшення ризику, на відміну від початкового, не зменшеного ризику, який є конкретною мірою прийняття ризику. *“Після додавання обмеження швидкості, залишковий ризик полягає в тому, що достатньо розподілена атака все ще може виснажити басейн з’єднань - це ризик, який ми просим керівництво формально прийняти, а не початковий необмежений ризик запиту.” *

Компенсаційний контроль — вторинна захисна дія, яка зменшує ймовірність або вплив ризику без усунення основної проблеми, включена спеціально для того, щоб показати, що ризик не приймається з нульовим зменшенням. “Ми не виправляємо причину цього кварталу, але ми додали компенсаційний контроль: попередження, що сторінки на виклику протягом двох хвилин після виникнення режиму аварії, тому радіус вибуху залишається малим.”

** Власник ризику ** — особа, а не команда або роль, яка відповідає за прийняття рішення щодо ризику і перегляд цього рішення, що перетворює неясну угоду на щось, що може бути виконано. “Власником ризику для цієї записки є наш віце-президент з інженерії, а не «команда платформи» — це відмінність має значення, якщо це рішення коли-небудь буде поставлено під сумнів під час аудиту.”

** Перегляд тригера ** — специфічна, заздалегідь визначена умова, за якої прийнятий ризик повинен бути переоцінений, а не залишати прийняття відкритим на неопределенный час. “Тригер перегляду тут явний: якщо обсяг даних цієї служби перевищить 500 запитів за секунду, або якщо ми додамо третій зовнішній клієнт, ця записка закінчиться і ризик слід переоцінити.”

Звичайні фрази

• «Ця записка документує наше рішення офіційно прийняти наступний залишковий ризик, а не розглядати його в дорожній карті цього кварталу»
• «Компенсаційні заходи контролю, що в даний час застосовуються, зменшують ймовірність / вплив цього ризику, але не виключають його»
• “Власником ризику для цього рішення є [ім’я/назва], який відповідає за перегляд його за умовами нижче.”
• “Це прийняття є чинним до тих пір, поки не буде виконано наступний тригер перегляду: [особлива умова].”
• «Ми розглядали [альтернативне зменшення] і вирішили не слідувати за ним в цей час через [спеціальну, чесну причину]»

Приклади висловлювань

Заявляти про ризик, не розмиваючи його до нечіткості:

• “Якщо первинна область стане недоступною під час вікна розгортання, можливо, буде втрачено запис у чергу. Ми оцінили, що це впливає менше ніж на 50 запитів на інцидент, на основі поточної частоти розгортання. ”*

Назвати те, що було розглянуто і відхилено, щоб рішення не виглядало неінформованим:

• “Ми оцінили додавання синхронної репліки, щоб повністю виключити цей ризик, і оцінили, що це коштувало б три інженерні тижні і додало б 40 мс затримки запису. Враховуючи нинішню низьку ймовірність і невеликий радіус вибуху, ми приймаємо залишковий ризик замість цього. ”*

Створення однозначної умови закінчення терміну дії: “Це прийняття ризику пов’язане з переглядом тригера: якщо ми втратимо другого інженера на виїзді, який покриває цю службу, або якщо частота інцидентів перевищує один на місяць, це рішення має бути переглянуто протягом двох тижнів.”

Професійні поради

• Зазначте ** залишковий ризик ** точно, з числом або конкретним сценарієм, де це можливо - “це може викликати проблеми іноді” не те, що аудитор або майбутній читач може діяти, в той час як “вплине менше ніж на 50 запитів на інцидент”.
• Список всіх ** компенсаційних засобів контролю **, які вже встановлено, навіть невеликих, оскільки записка, яка показує * деяке * зменшення, буде виглядати зовсім по- іншому, ніж записка, яка не показує жодного — це сигналізує про те, що ризик було розроблено, а не проігноровано.
• Ніколи не залишайте поле ** власник ризику ** у вигляді назви команди — записка, у якій вказано відповідальну особу, буде сприйматися набагато серйозніше як особою, яка її підписує, так і будь- ким, хто переглядатиме рішення пізніше.
• Напишіть явний ** перегляд тригер **, а не “ми переглянемо це періодично” - нечіткі ритми перегляду є однією з найпоширеніших причин, чому записки про прийняття ризиків позначаються в аудитах як недостатні.
• Записайте дату запису і зберігайте його у зручному місці, оскільки його цінність залежить від того, чи зможе хтось знайти його під час наступного відповідного випадку, а не лише у момент його написання.

Практичні вправи

1. Напишіть одне речення, в якому буде вказано залишковий ризик з конкретним, кількісно обчисленим сценарієм, а не нечітким описом.
2. Створити умову перегляду для гіпотетичного рішення щодо прийняття бази даних з одним регіоном як відомого ризику.
3. Напишіть речення, в якому вкажіть конкретного власника ризику і його відповідальність, уникаючи приписування назви команди.

Національний склад населення: Англійська мова — офіційна

Написання меморандуму про прийняття ризику ефективно не тільки про те, щоб заявляти * що * ризик існує; це про те, щоб сформулювати * чому * ви приймаєте його, демонструючи обдумане розглядання і забезпечення покупки. Це особливо важливо для не-рідних англомовних носіїв, які можуть бути звичні до різних рівнів формальності або деталей у своїх рідних мовах. Ключ полягає в прийнятті точного словника і фраз, очікуваних в професійному середовищі розробки програмного забезпечення - фрази, які передають впевненість, відповідальність і чітке розуміння потенційних наслідків.

Розглянемо сценарій: Ви переглядаєте запит на витяг, надісланий Sarah для нової функції в нашій платформі електронної комерції. Коментар старшого інженера Марка виглядає так: «Ризик: потенційне зниження продуктивності при високому рівні навантаження». Хоча це технічно вірно, але в ньому відсутній важливий контекст. Ефективнішою відповіддю - і однією, яку ви повинні намагатися використовувати самі - було б: “Сара, це розумне спостереження щодо потенційного впливу продуктивності під час пікової навантаження. Щоб офіційно визнати цей ризик, давайте документуємо, що ми оцінювали очікувані прогнози обсягу трафіку (на даний момент 500 одночасних користувачів) і визначили, що наша поточна архітектура має достатню вільну площу для 20% збільшення без необхідності негайного усунення. Ми будемо уважно стежити за продуктивністю під час початкового розгортання, використовуючи синтетичні тестування і дані користувачів реального світу; якщо пороги будуть перевищені, ми переглянемо це прийняття. “Зауважте використання фраз, таких як “формально підтверджують”, “оцінювали”, “спокій”, “синтетичні тестування” і “переглянути” - всі стандарти в комунікації управління ризиками.

Інша поширена ситуація пов’ язана з описом ризику у самому описі Запиту на завантаження. Замість того, щоб просто вказати « Ризик: Залежність X може перестати підтримуватися », ви можете написати: « Ми приймаємо на себе ризик, пов’ язаний з використанням Залежності X для її поточної версії [номер версії]. Хоча ми оцінили потенційну майбутню несумісність на основі обговорень плану постачальника і проактивно стежили за записами про випуск, ми визнаємо, що можливе припинення підтримки [Назва постачальника]. Ми будемо підтримувати план на випадок непередбачуваних обставин, що включає альтернативну оцінку залежності і стратегії міграції, задокументовані в Додатку А, якщо цей ризик матеріалізується. “Включення “природного ризику”, “активно моніториться”, і посилання на конкретну документацію додає шари професіоналізму і демонструє готовність.

Нарешті, пам’ятайте, що чіткість є найважливішою. Уникайте жаргонних або надто технічних термінів, якщо це не абсолютно необхідно, і завжди пояснюйте їх, якщо вам доведеться. Не бійтеся чітко вказати обґрунтування вашого рішення - наприклад: “Прийняття цього ризику дозволяє нам доставити функцію Y вчасно, відповідно до наших цілей спринту.” Добре розроблена записка про прийняття ризику - це не просто формальність; це критичний інструмент комунікації, який сприяє довірі і демонструє відповідальні практики розробки.