#осторожноАнглицизмы #осторожноСексизм
Целевая аудитория для этой статьи — представители ИТ сферы, которым волею судьбы выпала задача управлять рисками в их проекте и/или команде, которые не имеют входных знаний по теме статьи или имеют, но так и не уловили ответа на вопрос — И чё?
Матёрым менеджерам здесь будет скучно, но если вы таки знаете пана Мазоха, тоже заходите!
К делу. Риски — это всё, что потенциально может произойти с вашим проектом (команду опустим для упрощения фигуры речи, но всё ещё актуально).
Всё, что уже произошло, либо точно не произойдёт (ну ок… скорее всего не произойдёт) — не риск.
Пример первого: заказчик вас кинул и увёл свой бизнес к конкурентам. Это не риск, это факт.
Пример второго: у кастрированного кота родились котята (да, я в курсе, что коты не могут окотиться).
Пример рисков для первого и второго:
Заказчик может уйти к конкурентам, потому что что-то он часто говорит, что соотношение цена-качество в соседней конторе лучше.
Самочка кастрированного кота (ну мало ли) может привести котят, потому что коты не в курсе про институт брака и живут они, к тому же, в частном секторе.
Итак. Откуда берутсякотята риски:
Часто их кто-то приносит. Пример: ваш брат заметил уже второй раз у вас во дворе соседского кота Ваську. И как бы заподозрил измену в котячих рядах.
У кого-то сработала интуиция, или по процессам положено: провели брейн-сторм по рискам. Примера здесь не будет, брейн-сторм говорит сам за себя.
На данном этапе мы имеем:
а) риск
б) его источник
в) дату, когда мы о нём узнали
Не будем дураками и запишем в ексель табличку, чего добру пропадать…
Важная оговорка. Риски бывают не только негативными. Может ваш кот таки порадуется котятам как своим. Ну ок, забыли про котов. Пример: вы думали, что у вас нишевый рынок и подняли приложение на домашней тачке, а тут произошёл бум и на 107м пользователе ваш магазин машет всемлапкой 503й.
г) можно ещё одну колоночку, а можно и пропустить. Ибо это judgment.
У риска есть вероятность его наступления (probability of occurrence) и тяжесть последствий (severity of impact). Эти величины лучше прикидывать небольшим, качественно подобранным коллективом. Привлеките к этому процессу SME, к примеру.
Есть разные подходы, как их указывать, я люблю цифрами и процентами, ибо они умножаются друг на друга.
д) probability: 0.1 — 0.9 (если возникает вопрос, где 0 и 1, перечитайте параграф “К делу”.
е) severity: 1 — 10.
Шкалы выберите так чтоб вам нравилось, think out of borders!
Теперь ответ на вопрос — а зачем же умножать probability на severity.
ё) rate = probability * severity.
Ранжируем риски по rate, выделяем крайние квантили соответственно красным и зелёным, остальное — жёлтым. Если не знакомы с математикой, пропустите вторую часть предыдущего предложения (не нужно страдать, такой цели у меня не было).
Предпосылки для Ж (пункта, а не того, о чём вы подумали).
Можно посоветоваться с каким-нибудь менеджером в вашей компании, СЕО или ещё с кем, либо рискнуть и придумать свою систему классификации рисков. Мне здесь снова нравится red — amber — green. То есть вам нужно систему — как по рейту определить цвет.
ж) эта колонка,которая пока без названия, условно, — будем ли мы что-то с этим риском делать. (Там я дальше статью писала, эта колонка упоминается, поэтому назовём её…) Action needed.
Самое время упомянуть стратегии работы с рисками:
Avoid — Transfer — Mitigate — Accept для негативных рисков
Exploit — Share — Enhance — Accept для положительных.
Если вы не судили риски или ищете что попроще, просто возьмите стратегии для негативных.
На выходе наш спредшит пополнился ещё одной колонкой. С названием мудрить не будем.
з) стратегия
Упс… Мы забыли о самом важном для трейса риска в будущем — ИД. Ну ничего, ексель добрый, позволяет вставить колонку левее первой (или нулевой… Это был краткий тест на то, разраб ли вы и если да, то какой ЯП юзаете).
Я же пишу лонгрид, поэтому моя колонка с ИД будет под буквой И, что символично!
и) ИД.
Далее по всему списку рисков составляем RACI матрицу по таким правилам:
1 каждый риск должен иметь минимум один I.
2 каждый риск (кроме зеленого Action needed) должен иметь минимум по одному A и R
3 С по желанию
4 не более одного А на каждый риск
Далее нам нужно по стратегиям (кроме Accept) написать список Action Items.
Это уже не удобно делать в той же табличке, поэтому заводим отдельную под каждый риск (ИД в помощь). Не забываем про дедлайны.
Там перечисляем те самые нужные действия.
Сводим все AI в одну RACI матрицу.
Самый важный пункт: КОММУНИЦИРУЕМ это всё. Это очень важный этап. Если вы не заручитесь поддержкой коллег касательно вашей стратегии управления рисками, можете сильно попасть в будущем, когда окажется, что просчитались.
Следующий важный пункт. Это вам не DoD, нельзя раз написать и на весь жизненный цикл проекта забыть. Регулярно возвращаемся, смотрим, выполняются ли Action Items, не меняются ли probability и severity.
Советуемся, валидируем, контролируем, управляем.
Вносим новые риски.
Золотое правило: никогда ничего не удаляем из этого документа. Только добавляем и обновляем!!!
Бонус. Самый крутой риск менеджмент, который я видела воочию: “Вы что??? Тьфу-тьфу-тьфу”. (с) При этих словах, директор небольшой ИТ компании постучала по своей голове.
1 правильно постучала (по верному месту, если вы понимаете, о чём я)
2 не будьте как эта директор, документируйте и обсуждайте риски!
Резюмируя: Риск нужно идентифицировать, классифицировать, принять решение, по какой стратегии с ним работать, постоянно его обсуждать и пересматривать.
И не забывать что-то делать, если вы таки не готовы его принять!
Всем проектов с рисками в грин зоне!
Целевая аудитория для этой статьи — представители ИТ сферы, которым волею судьбы выпала задача управлять рисками в их проекте и/или команде, которые не имеют входных знаний по теме статьи или имеют, но так и не уловили ответа на вопрос — И чё?
Матёрым менеджерам здесь будет скучно, но если вы таки знаете пана Мазоха, тоже заходите!
К делу. Риски — это всё, что потенциально может произойти с вашим проектом (команду опустим для упрощения фигуры речи, но всё ещё актуально).
Всё, что уже произошло, либо точно не произойдёт (ну ок… скорее всего не произойдёт) — не риск.
Пример первого: заказчик вас кинул и увёл свой бизнес к конкурентам. Это не риск, это факт.
Пример второго: у кастрированного кота родились котята (да, я в курсе, что коты не могут окотиться).
Пример рисков для первого и второго:
Заказчик может уйти к конкурентам, потому что что-то он часто говорит, что соотношение цена-качество в соседней конторе лучше.
Самочка кастрированного кота (ну мало ли) может привести котят, потому что коты не в курсе про институт брака и живут они, к тому же, в частном секторе.
Итак. Откуда берутся
Часто их кто-то приносит. Пример: ваш брат заметил уже второй раз у вас во дворе соседского кота Ваську. И как бы заподозрил измену в котячих рядах.
У кого-то сработала интуиция, или по процессам положено: провели брейн-сторм по рискам. Примера здесь не будет, брейн-сторм говорит сам за себя.
На данном этапе мы имеем:
а) риск
б) его источник
в) дату, когда мы о нём узнали
Не будем дураками и запишем в ексель табличку, чего добру пропадать…
Важная оговорка. Риски бывают не только негативными. Может ваш кот таки порадуется котятам как своим. Ну ок, забыли про котов. Пример: вы думали, что у вас нишевый рынок и подняли приложение на домашней тачке, а тут произошёл бум и на 107м пользователе ваш магазин машет всем
г) можно ещё одну колоночку, а можно и пропустить. Ибо это judgment.
У риска есть вероятность его наступления (probability of occurrence) и тяжесть последствий (severity of impact). Эти величины лучше прикидывать небольшим, качественно подобранным коллективом. Привлеките к этому процессу SME, к примеру.
Есть разные подходы, как их указывать, я люблю цифрами и процентами, ибо они умножаются друг на друга.
д) probability: 0.1 — 0.9 (если возникает вопрос, где 0 и 1, перечитайте параграф “К делу”.
е) severity: 1 — 10.
Шкалы выберите так чтоб вам нравилось, think out of borders!
Теперь ответ на вопрос — а зачем же умножать probability на severity.
ё) rate = probability * severity.
Ранжируем риски по rate, выделяем крайние квантили соответственно красным и зелёным, остальное — жёлтым. Если не знакомы с математикой, пропустите вторую часть предыдущего предложения (не нужно страдать, такой цели у меня не было).
Предпосылки для Ж (пункта, а не того, о чём вы подумали).
Можно посоветоваться с каким-нибудь менеджером в вашей компании, СЕО или ещё с кем, либо рискнуть и придумать свою систему классификации рисков. Мне здесь снова нравится red — amber — green. То есть вам нужно систему — как по рейту определить цвет.
ж) эта колонка,
Самое время упомянуть стратегии работы с рисками:
Avoid — Transfer — Mitigate — Accept для негативных рисков
Exploit — Share — Enhance — Accept для положительных.
Если вы не судили риски или ищете что попроще, просто возьмите стратегии для негативных.
На выходе наш спредшит пополнился ещё одной колонкой. С названием мудрить не будем.
з) стратегия
Упс… Мы забыли о самом важном для трейса риска в будущем — ИД. Ну ничего, ексель добрый, позволяет вставить колонку левее первой (или нулевой… Это был краткий тест на то, разраб ли вы и если да, то какой ЯП юзаете).
Я же пишу лонгрид, поэтому моя колонка с ИД будет под буквой И, что символично!
и) ИД.
Далее по всему списку рисков составляем RACI матрицу по таким правилам:
1 каждый риск должен иметь минимум один I.
2 каждый риск (кроме зеленого Action needed) должен иметь минимум по одному A и R
3 С по желанию
4 не более одного А на каждый риск
Далее нам нужно по стратегиям (кроме Accept) написать список Action Items.
Это уже не удобно делать в той же табличке, поэтому заводим отдельную под каждый риск (ИД в помощь). Не забываем про дедлайны.
Там перечисляем те самые нужные действия.
Сводим все AI в одну RACI матрицу.
Самый важный пункт: КОММУНИЦИРУЕМ это всё. Это очень важный этап. Если вы не заручитесь поддержкой коллег касательно вашей стратегии управления рисками, можете сильно попасть в будущем, когда окажется, что просчитались.
Следующий важный пункт. Это вам не DoD, нельзя раз написать и на весь жизненный цикл проекта забыть. Регулярно возвращаемся, смотрим, выполняются ли Action Items, не меняются ли probability и severity.
Советуемся, валидируем, контролируем, управляем.
Вносим новые риски.
Золотое правило: никогда ничего не удаляем из этого документа. Только добавляем и обновляем!!!
Бонус. Самый крутой риск менеджмент, который я видела воочию: “Вы что??? Тьфу-тьфу-тьфу”. (с) При этих словах, директор небольшой ИТ компании постучала по своей голове.
1 правильно постучала (по верному месту, если вы понимаете, о чём я)
2 не будьте как эта директор, документируйте и обсуждайте риски!
Резюмируя: Риск нужно идентифицировать, классифицировать, принять решение, по какой стратегии с ним работать, постоянно его обсуждать и пересматривать.
И не забывать что-то делать, если вы таки не готовы его принять!
Всем проектов с рисками в грин зоне!