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.
Сначала мы определяем риск. Он будет состоять из трех частей:
cause - причина - это то, что у нас есть и что является фактом. risk - это предполагаемое событие, которое может произойти или может не произойти. effect - это то, что произойдет, если риск сбудется. Зачем нам нужно разделить это на три части? Технически, если мы объединим их, звучит это будет так: “Поскольку Sibit использует Blockchain API, и API может быть изменен без предупреждения, пользователи будут разочарованы.” Но лучше явно определить компоненты причины/риска/эффекта, потому что, догадайтесь … у нас может быть разные комбинации рисков, эффектов и причин. Например, что если мы выявим дополнительный риск для существующей причины:
Это другой риск, нежели тот, с которым мы сталкивались ранее. API не изменится, но полностью исчезнет с рынка. Это возможно? Вполне. Каков будет эффект от этого риска? Тот же — пользователи будут разочарованы, так как моя Ruby-библиотека Sibit перестанет работать. Может быть, будут и другие последствия? Ну, давайте подумаем. Если весь API будет закрыт, мне придется потратить приличное количество времени на поиск нового, изучение его, понимание его работы и внесение множества изменений в мою библиотеку, чтобы она понимала новый API. Я даже могу не справиться с этим, если новый API будет иметь значительно отличный дизайн. Другими словами, эффект риска #2 будет что-то вроде:
С другой стороны, когда API выходит с рынка, появляется возможность на рынке для похожего API. Если мы узнаем об этом в нужный момент, мы сможем воспользоваться этой возможностью и создать похожее API для других пользователей, верно? Таким образом, риск №2 имеет дополнительный эффект:
Это положительный эффект, в то время как ранее у нас были отрицательные эффекты. Задача менеджера проекта заключается не только в выявлении отрицательных эффектов, но и в поиске подобного количества положительных эффектов для большинства рисков и причин.
В заключение, вот что у нас есть сейчас:
Поняли диаграмму? Причина C1 приводит к рискам R1 и R2, каждый из которых имеет несколько последствий: E1, E2 и E3. Чтобы иметь возможность определить такую многоуровневую диаграмму и избежать дублирования текста, нам необходимо разделить каждое предполагаемое событие на три части.
Есть несколько правил, которые я выработал для себя относительно этих трех частей:
Май. В утверждении Risk следует использовать слово “может”, поскольку это то, что еще не произошло, но только предполагается, например: “мы можем потерять клиента”, “архитектор может уйти”, “Apple Store может задержать рассмотрение нашего приложения”, “инвестор может отказаться”, и т.д.
Will. Эффект должен быть в будущем времени, явно указывающем на результат, который мы испытаем в будущем, если риск произойдет, например, “мы обанкротимся,” “нам придется переписать весь модуль,” “мы потратим еще $10,000 на оборудование” и так далее.
Как следует известно, чем короче утверждения, тем лучше. Правильно определенная причина, риск и эффект должны содержать не более 20 слов каждое. Длинные высказывания означают только одно: автор не ясно представляет себе, что происходит, и нужно потратить больше времени на изучение ситуации.
Не все риски и эффекты одинаково вероятны, как вы видите. Очень маловероятно, что вся блокчейн-API умрет, но очень вероятно, что он может изменить свой протокол HTTP. Было бы глупо уделять одинаковое внимание всем рискам, так как некоторые из них являются первичными, а другие - вторичными. Как мы узнаем, какой риск является каким? Мы назначаем числа. Вот как.
Сначала мы проанализируем все риски и назначим вероятность каждого из них, где 1 означает, что риск, скорее всего, никогда не произойдет, а 9 означает, что риск, безусловно, случится:
Я присвоил рискам выше значения 7 и 2. Это было мое экспертное мнение. Здесь нет математики. Я просто взглянул на риски и принял личное решение как владелец/менеджер проекта.
Затем мы присваиваем влияние каждому эффекту, снова в диапазоне [1..9]. Здесь 1 означает, что ожидаемые последствия не причинят вреда никому и не принесут реальной пользы, в то время как 9 означает, что эффект критически важен (как в отрицательном, так и в положительном смысле):
Снова я выбрал числа в соответствии с моим профессиональным мнением. Изменение камня в соответствии с немного измененным API - одно дело (воздействие равно 3), в то время как переписывание его для совершенно нового API - совершенно другой объем работы (отсюда воздействие равно 8).
Последний шаг - умножить их: вероятность × воздействие. Мы получим этот список рисков:
Вы теперь можете увидеть, что есть что в нашем списке. Несмотря на то, что последствия второй строки в списке более серьезны, вероятность ниже, и в общей карте рисков эта строка менее важна.
То, что мы только что сделали, называется качественным анализом рисков: мы определили, какие риски более важны и требуют немедленного решения, а какие менее важны и могут быть просто проигнорированы на некоторое время.
Я пропущу этот раздел. Я не считаю его важным или осуществимым для небольшого программного проекта. Согласно Рите Малкахи: “Как менеджер проекта, вы всегда должны проводить качественный анализ рисков, но количественный анализ рисков не требуется для всех проектов или всех рисков и может быть пропущен в пользу перехода к планированию реагирования на риски”.
Теперь пришло время воплотить в жизнь мои планы реагирования. В каждой положительной строке моего списка рисков у меня в основном есть два варианта.
- Смягчение. Вторая возможная стратегия реагирования на риск - смягчение воздействия. Взгляните на воздействие
E1. Как уже обсуждалось выше, будет разумно сделать две вещи. Во-первых, создать интеграционные тесты и настроить CI на отправку мне электронного письма при изменении API. Во-вторых, регулярно проверять репозиторий на согласованность и минимизировать время, в течение которого репозиторий будет несогласован с API, сразу после изменения API.
Ну, есть и другие варианты, такие как принятие (ничего не делать и просто ждать) или передача (найти козла отпущения, чтобы обвинить, когда дела пойдут плохо), но они менее практичны.
Также есть два варианта для хорошего риска (E1/R2/E3):
- Усилить. Я могу предпринять действия, чтобы увеличить положительное влияние эффекта
E3. Например, я могу подготовить аналогичное API и сделать его готовым для рынка. Когда умирает Blockchain API, я сразу запускаю своё и начинаю его продвигать с помощью фразы “Эй, эти ребята умерли, переходите сюда прямо сейчас!” Шучу, но вы понимаете идею.
Итак, просто говоря, у нас может быть план, прикрепленный либо к риску, либо к эффекту. Мы можем что-то сделать с вероятностью или с воздействием. Что ж, мы также можем сделать что-то с причиной. Например, я могу устранить весь список рисков, просто удалив свою драгоценность и прекратив проект, верно? Больше не будет никаких проблем. Нет разочарованных пользователей, нет рисков, нет возможностей. Это также может быть решением в некоторых случаях (хотя не в этом).
Главное, что план может быть связан либо с причиной, либо с риском, либо с эффектом. Я бы определил три плана, все смягчающие воздействие E1:
Первые два — это одноразовые действия, которые мне нужно выполнить как можно скорее. После их завершения они снизят воздействие E1. План P3 должен выполняться каждую неделю, чтобы также снизить воздействие E1. Вот как выглядит мой Список рисков вместе с планами:
Понятно? Надеюсь, что да. Я определенно рекомендую вам прочитать Risk Management Tricks of the Trade for Project Managers. В нем все подробно объясняется и его интересно читать.
Я создал простой веб-проект, который позволяет записать именно такую структуру рисков: 0rsk.com (он относится к семейству продуктов Zerocracy, поэтому его название начинается с нуля). Просто войдите туда, создайте новый проект и “добавьте” свои риски. Попробуйте. Затем, когда риски зарегистрированы, вы можете прикрепить к ним планы реагирования. Интерфейс довольно интуитивно понятный, поэтому у вас не должно возникнуть проблем. Если возникнут трудности, не стесняйтесь сообщить о проблеме.
Пришло время реализовывать запланированные действия. 0rsk превращает планы в задачи, когда приходит время. Задачи представляют явные инструкции для вас, менеджера проекта. Затем вы можете выполнить их самостоятельно или делегировать своим участникам проекта.
В ближайшем будущем 0rsk будет интегрироваться с GitHub и другими системами отслеживания задач, чтобы размещать новые задачи там и контролировать их выполнение. Следите за обновлениями, вскоре появятся ещё больше функций.
Также имеется интеграция с Telegram. Каждый раз, когда необходимо выполнить новый план, 0rsk напоминает мне в Telegram о том, что пришло время приступить к работе. Попробуйте, бот доступен по адресу: @zerorsk_bot.
Честно говоря, я считаю, что такой риск-ориентированный подход к управлению моим объемом работы очень продуктивен и направлен на результаты. Сначала я определяю самые важные ситуации в моем проекте (к которым могут относиться люди, ресурсы, банковские счета, программные продукты, активы и т.д.), затем я задумываюсь о рисках и делаю это регулярно, создавая несколько новых рисков каждый день вместе с их последствиями. Затем я планирую, что я могу сделать, чтобы минимизировать их вероятность и реагировать на их влияние. Наконец, Telegram-бот начинает говорить мне, что мне нужно делать каждый день.
Благодаря всему этому, я не упускаю общую цель - она определяется структурой причина-риск-последствие-план в моем проекте 0rsk, и я сосредоточен на том, что имеет значение, каждый день.
Теперь я не реагирую на проблемы, я предотвращаю их, как советовала Рита Малкахи.
И вы можете это сделать, 0rsk бесплатен для всех.
P.S. Есть отобранный список причин, рисков и последствий, где вы можете выбрать наиболее релевантный для вашего случая: yegor256/awesome-risks. Вы даже можете добавить свои идеи туда.
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-15 at 06:57
