0rsk.com: Cause + Risk + Effect

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Работа менеджера проекта не должна сосредотачиваться на решении проблем; она должна быть направлена на их предотвращение, - так начинает Рита Малкахи главу о управлении рисками в своей замечательной книге “Подготовка к экзамену PMP”. Звучит умно, но как менеджер проекта узнает о проблемах, которые должны быть предотвращены? Об этом и посвящены эта глава и книга “Секреты управления рисками для менеджеров проектов”, также написанная этой же автором. Из этих книг, а также из своего многолетнего опыта выявления, анализа и решения рисков, я узнал, что лучший формат для их описания состоит из трех частей: причина, риск и эффект.

Давайте начнем с простого примера. Я разработал Sibit, простой Ruby гем, всего несколько недель назад, который является командной строкой клиентом Bitcoin. Вы можете проверить баланс своего адреса Bitcoin с его помощью и отправить платеж на другой адрес всего лишь одним вызовом командной строки. Он работает нормально, но выполняет все операции через Blockchain API по протоколу HTTP.

Это означает, что если однажды API изменится, гем перестанет работать. Это риск. Пока это не проблема, так как на данный момент API работает так, как гем ожидает, но это проблема, которую мы ожидаем. Когда это произойдет, гем прекратит работу, его пользователи не будут понимать, почему и просто перестанут использовать его. Они также будут считать меня создателем некачественного и неработающего “мусора”. Это не очень хорошо для моей репутации, верно?

Точно так же, как предложила Рита Малкахи выше, я не должен просто ждать, пока разочарованный пользователь отправит мне электронное письмо. Я должен активно как-то справиться с этим риском. Как? Я могу сделать несколько интеграционных тестов, чтобы проверить, поддерживает ли API протокол, который я ожидаю, и убедиться, что моя система непрерывной интеграции запускает сборку, скажем, один раз в день. Когда сборка становится неработоспособной, я должен получить электронное письмо и соответствующим образом отреагировать, исправив проблему в программном модуле до того, как пользователи заметят проблему. Во-вторых, я могу вручную проверять репозиторий каждую неделю, например, чтобы убедиться, что он все еще в хорошем состоянии и работает с API.

Теперь превратим эту историю в формальное управление рисками. Я взял названия подразделов ниже из главы “Управление рисками” PMBOK.

Identify Risks

Сначала мы определяем риск. Он будет состоять из трех частей:

Cause #1: Sibit works by using the Blockchain API
Risk #1: The API may be changed without notice
Effect #1: Users will be disappointed

Причина - это то, что у нас есть и что является фактом. Риск - это предполагаемое событие, которое может произойти или не произойти. Эффект - это то, что произойдет, если риск реализуется. Зачем нам нужно разбивать это на три составляющих? Технически, если мы объединим их вместе, это будет звучать так: “Поскольку Sibit использует API блокчейна и API может быть изменен без предупреждения, пользователи будут разочарованы.” Но лучше явно определить составляющие - причину/риск/эффект, потому что, догадайтесь … у нас может быть различные комбинации рисков, эффектов и причин. Например, что насчет определения дополнительного риска для существующей причины:

Risk #2: The API may go out of the market

Этот риск отличается от предыдущего. API не изменится, но полностью исчезнет с рынка. Возможно ли это? Очень вероятно. Каков будет эффект этого риска? Тот же самый - пользователи будут разочарованы, так как моя Ruby-библиотека Sibit перестанет работать. Может быть, будут и другие эффекты? Хм, давайте подумаем. Если весь API будет закрыт, мне придется потратить значительное количество времени на поиск нового, изучение его, понимание принципов его работы и внесение множества изменений в мою библиотеку, чтобы она могла работать с новым API. Я даже могу не справиться с этой задачей, если новый API будет иметь значительно отличающуюся структуру. Иными словами, эффект от риска №2 будет примерно таким:

Effect #2: It will take time to connect to a new API

С другой стороны, когда API выходит с рынка, на рынке появляется возможность для появления аналогичного API. Если мы узнаем об этом вовремя, мы сможем воспользоваться этой возможностью и создать аналогичное API для других пользователей, верно? Таким образом, риск №2 имеет дополнительный эффект:

Effect #3: There will be an opportunity to create a similar API

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

В итоге, вот что у нас есть сейчас:

C1 → R1 → E1
   → R2 → E2
        → E3

Понятна диаграмма? Причина C1 приводит к рискам R1 и R2, у каждого из которых есть несколько последствий: E1, E2 и E3. Чтобы можно было определить такую многоуровневую диаграмму и избежать дублирования текста, мы должны разделить каждое предполагаемое событие на три части.

У меня есть некоторые правила, которые я выработал для себя относительно этих трех частей:

Должно быть. Причина всегда должна звучать как утверждение в настоящем времени, так как она утверждает факт, который существует прямо сейчас, например: “мы используем Hibernate”, “Java 6 больше не поддерживается”, “70% наших пользователей используют Android”, “платежи отправляются через PayPal”, “GitHub является единственным обслуживающим наш репозиторий” и так далее.
Май. Утверждение о риске должно использовать слово “может”, так как это то, что еще не произошло, но только предполагается, например, “мы можем потерять клиента”, “архитектор может уйти”, “Apple Store может задержаться с проверкой нашего приложения”, “инвестор может отказаться”, и т.д.
Будущее время. Эффект должен быть выражен в будущем времени и четко указывать на результат, который мы испытаем в будущем, если риск произойдет, например: «мы обанкротимся», «нам придется переписать весь модуль», «нам придется потратить еще $10,000 на оборудование» и так далее.

Как несложно догадаться, чем короче утверждения, тем лучше. Правильно определенная причина, риск и эффект должны содержать не более 20 слов каждый. Более длинные высказывания означают только одно: автор не ясно представляет, что происходит и должен потратить больше времени на изучение ситуации.

Qualitative Analysis

Не все риски и эффекты одинаково вероятны, как видите. Очень маловероятно, что весь Blockchain API прекратит работу, но очень вероятно, что он может изменить свой протокол HTTP. Было бы глупо уделять одинаковое внимание всем рискам, поскольку некоторые из них являются первичными, тогда как другие - вторичными. Как мы узнаем, какой из них является каким? Мы присваиваем числа. Вот как.

Сначала мы анализируем все риски и присваиваем вероятность каждому из них, где 1 означает, что риск, скорее всего, никогда не произойдет, а 9 означает, что риск неизбежно произойдет.

C1 → R1:7 → E1
   → R2:2 → E2
          → E3

Я присвоил рискам выше значения 7 и 2. Это было моим экспертным мнением. Здесь нет математики. Я просто взглянул на риски и принял личное решение в качестве владельца/менеджера проекта.

Затем мы присваиваем воздействие каждому эффекту в пределах диапазона [1..9]. Здесь 1 означает, что ожидаемые последствия не причинят вреда никому и не окажут реальной пользы никому, в то время как 9 означает, что эффект является ключевым (как в отрицательном, так и в положительном смысле).

C1 → R1:7 → E1↓:3
   → R2:2 → E2↓:8
          → E3↑:3

Снова я выбрал числа в соответствии с моим профессиональным мнением. Изменение камня в соответствии с незначительно измененным API - это одно (влияние равно 3), а полная переработка для совершенно нового API - это совершенно другой объем работы (поэтому влияние равно 8).

Финальным шагом является их умножение: вероятность × воздействие. Мы получим следующий список рисков:

C1 → R1:7 → E1↓:3 ⇢ 7×3 = 21
C1 → R2:2 → E2↓:8 ⇢ 2×8 = 16
C1 → R2:2 → E3↑:3 ⇢ 2×3 =  6

Теперь вы можете видеть, что есть что в нашем списке. Несмотря на то, что последствия второй строки в списке более серьезные, вероятность ниже и, в общей карте рисков, эта строка менее значима.

То, что мы только что сделали, называется качественным анализом рисков: мы определили, какие риски являются более важными и требуют немедленного решения, а какие менее важны и могут быть просто проигнорированы на некоторое время.

Quantitative Analysis

Я пропущу этот раздел. Я не считаю его важным или выполнимым для небольшого программного проекта. Согласно Рите Малкахи: “В качестве менеджера проекта вы всегда должны проводить качественный анализ рисков, но количественный анализ рисков не требуется для всех проектов или для всех рисков и может быть пропущен в пользу перехода к планированию реагирования на риски”.

Plan Risk Responses

Теперь пришло время внедрить мои планы реагирования. В каждой положительной строке моего Списка рисков у меня есть в основном два варианта.

Избегайте. Я могу сделать что-то, чтобы снизить вероятность риска. Возьмем риск R2 - могу ли я сделать что-то, чтобы убедиться, что API Блокчейна останется на рынке дольше и не исчезнет? Ну, я могу написать о нем в твиттере, продвигать его или даже пожертвовать некоторую сумму денег. Но я сомневаюсь, что это действительно поможет. Так что избегание здесь не является правильной стратегией. Я просто не могу снизить вероятность, независимо от того, что делаю. Если риск R2 должен произойти, он произойдет. То же самое верно и для риска R1.
Смягчение. Вторая возможная стратегия реагирования на риск - смягчение воздействия эффекта. Взгляните на эффект E1. Как уже обсуждалось выше, будет разумно сделать две вещи. Во-первых, создать интеграционные тесты и настроить CI на отправку мне электронной почты при изменении API. Во-вторых, регулярно проверять репозиторий на согласованность и минимизировать время, в течение которого репозиторий будет несогласованным с API, сразу после изменения API.

Есть и другие варианты, такие как принятие (ничего не делать и просто ждать) или перенос ответственности (искать козла отпущения, чтобы обвинить, когда дела пойдут наперекосяк), но они менее практичны.

Есть также два варианта для хорошего риска (E1/R2/E3):

Использование. Могу ли я сделать что-то, чтобы ускорить быстрое исчезновение Blockchain API, тем самым увеличив риск R2? Хорошо, это может показаться шуткой в данном случае, но очень часто мы можем выбрать продвигать вещи вперед с положительным риском. Эта стратегия называется использованием.
Улучшение. Я могу сделать что-то, чтобы увеличить положительное влияние эффекта E3. Например, я могу подготовить аналогичное API и сделать его готовым для рынка. Когда умирает Blockchain API, я немедленно запускаю свое и начинаю его продвигать с помощью фразы “Эй, эти ребята мертвы, переходите сюда сейчас!” Шучу, но вы понимаете идею.

Таким образом, просто говоря, у нас может быть план, привязанный либо к риску, либо к эффекту. Мы можем что-то делать с вероятностью или с воздействием. Что ж, мы также можем что-то сделать с причиной. Например, я могу удалить весь список рисков, если просто удалю свою драгоценность и прекратлю проект, верно? Больше не будет проблем. Нет разочарованных пользователей, нет рисков, нет возможностей. В некоторых случаях это также может быть решением (хотя не в этом).

В конечном итоге план может быть прикреплен к причине, риску или эффекту. Я бы определил три плана, которые все смягчают воздействие E1.

P1→E1: Create integration tests (once)
P2→E1: Configure CI (once)
P3→E1: Check the repo for compliance with API (weekly)

Первые два - это единоразовые действия, которые я должен выполнить как можно скорее. После их завершения они снизят воздействие E1. План P3 должен выполняться каждую неделю, чтобы также снизить воздействие E1. Вот как выглядит мой список рисков вместе с планами:

C1 → R1:7 → E1↓:3 ⇢ 7×3 = 21
  P1, P2, P3
C1 → R2:2 → E2↓:8 ⇢ 2×8 = 16
  No plans
C1 → R2:2 → E3↑:3 ⇢ 2×3 =  6
  No plans

Понятно? Я надеюсь, что да. Определенно рекомендую вам прочитать книгу Risk Management Tricks of the Trade for Project Managers. Она подробно объясняет все и при этом интересно читать.

Я создал простой веб-проект, который позволяет записывать именно такую структуру риска: 0rsk.com (он относится к семейству продуктов Zerocracy, поэтому имя начинается с нуля). Вы просто входите туда, создаете новый проект и “добавляете” свои риски. Попробуйте. Затем, когда риски зарегистрированы, прикрепляйте к ним планы реагирования. Интерфейс довольно интуитивно понятен, поэтому у вас не должно быть проблем. Если возникнут трудности, не стесняйтесь сообщать о проблемах.

Implement Risk Responses

Теперь пришло время сделать то, что было запланировано, реализовать планы. 0rsk превращает планы в задачи, когда наступает время. Задачи - это явные инструкции для вас, руководителя проекта. Затем вы сами выполняете их или делегируете своим участникам проекта.

В ближайшем будущем 0rsk будет интегрирован с GitHub и другими системами учета задач, чтобы добавлять новые задачи туда и отслеживать их выполнение. Следите за обновлениями, скоро появятся еще новые возможности.

Также имеется интеграция с Telegram. Каждый раз, когда необходимо выполнить новый план, 0rsk присылает мне напоминание в Telegram, что пора приступить к работе. Попробуйте это, бот находится здесь: @zerorsk_bot.

Honestly, I find this risk-driven way of managing my scope of work very productive and results focused. First, I identify what the most important situations are in my project (which could be people, resources, bank accounts, software products, assets, etc), then I think about risks and I do this regularly, creating a few new risks every day, together with effects. Then, I plan what I can do in order to minimize their probabilities and react to their impacts. Finally, the Telegram bot starts telling me what to do every day.

Благодаря всему этому, я не упускаю общую картину — она определяется структурой причина-риск-эффект-план в моем проекте 0rsk — и остаюсь сосредоточенным на том, что имеет значение, каждый день.

Теперь я не реагирую на проблемы, а предотвращаю их, как советовала Рита Малкахи.

Вы тоже можете, 0rsk бесплатен для всех.

P.S. Существует отобранный список причин, рисков и последствий, где вы можете выбрать наиболее подходящий для вашего случая: yegor256/awesome-risks. Вы также можете добавить свои идеи туда.

Do you have a formal Risk List in your project?
— Yegor Bugayenko (@yegor256) December 20, 2020

Translated by ChatGPT gpt-3.5-turbo/30 on 2023-08-29 at 05:49