🧭 Рубрикатор-навигатор
Выражение "И чтец, и жнец, и на дуде игрец,и всем капец" идеально описывает идеального продакта. Потому что выбрав для себя путь Product Manager придется быть скилловым товарищем и иметь высокий уровень экспертности во многих областях.
Сегодня мы перечислим те составляющие, без которых, на наш взгляд, не может быть хорошего продуктового менеджера, и заодно превратим их в удобный (как мы надеемся) рубрикатор для последующих публикаций и поиска нужных вам тем.
1. Идея
- #JTBD_AGIMA
- #value_prop_AGIMA
- #custdev_AGIMA
- #marketing_reseach_AGIMA
- #design_thinking_AGIMA
2. План
- #roadmap_AGIMA
- #business_model_canvas_AGIMA
- #lean_canvas_model_AGIMA
- #cashflow_AGIMA
- #frameworks_AGIMA
3. Разработка продукта
- #development_methodologies_AGIMA
- #MVP_AGIMA
- #agile_AGIMA
- #lean_startup_AGIMA
- #user_stories_AGIMA
- #managing_team_AGIMA
- #user_interviews_AGIMA
- #release_notes_AGIMA
4. Качество
- #user_testing_AGIMA
- #dogfooding_AGIMA
- #demo_AGIMA
5. Запуск
- #user_guides_AGIMA
- #monetisation_AGIMA
- #community_management_AGIMA
- #cx_ux_AGIMA
6. Улучшение продукта
- #cx_ux_research_AGIMA
- #ab_testing_AGIMA
7. Общее для всех этапов
- #product_analysis_AGIMA
- #product_metrics_AGIMA
- #product_marketing_AGIMA
- #product_design_AGIMA
- #PM_reading_AGIMA
- #case_AGIMA
- #video_AGIMA
- #conference_AGIMA
- #knowledge_AGIMA
Это оглавление будет дополняться новыми рубриками и хэштегами для них — во имя развития этого канала и вашей профессиональной насмотренности 💪
Выражение "И чтец, и жнец, и на дуде игрец,
Сегодня мы перечислим те составляющие, без которых, на наш взгляд, не может быть хорошего продуктового менеджера, и заодно превратим их в удобный (как мы надеемся) рубрикатор для последующих публикаций и поиска нужных вам тем.
1. Идея
- #JTBD_AGIMA
- #value_prop_AGIMA
- #custdev_AGIMA
- #marketing_reseach_AGIMA
- #design_thinking_AGIMA
2. План
- #roadmap_AGIMA
- #business_model_canvas_AGIMA
- #lean_canvas_model_AGIMA
- #cashflow_AGIMA
- #frameworks_AGIMA
3. Разработка продукта
- #development_methodologies_AGIMA
- #MVP_AGIMA
- #agile_AGIMA
- #lean_startup_AGIMA
- #user_stories_AGIMA
- #managing_team_AGIMA
- #user_interviews_AGIMA
- #release_notes_AGIMA
4. Качество
- #user_testing_AGIMA
- #dogfooding_AGIMA
- #demo_AGIMA
5. Запуск
- #user_guides_AGIMA
- #monetisation_AGIMA
- #community_management_AGIMA
- #cx_ux_AGIMA
6. Улучшение продукта
- #cx_ux_research_AGIMA
- #ab_testing_AGIMA
7. Общее для всех этапов
- #product_analysis_AGIMA
- #product_metrics_AGIMA
- #product_marketing_AGIMA
- #product_design_AGIMA
- #PM_reading_AGIMA
- #case_AGIMA
- #video_AGIMA
- #conference_AGIMA
- #knowledge_AGIMA
Это оглавление будет дополняться новыми рубриками и хэштегами для них — во имя развития этого канала и вашей профессиональной насмотренности 💪
🙅🏻♀️ Roadmap: как не надо делать. Pt.1
Хотели в один пост все ошибки составления/использования roadmap'а запилить, но что-то в один никак не помещаются. Поэтому сериал будет. Вероятно, остросюжетный. Серии будут выходить не каждый день — завтра про другое поговорим (да-да, анонсируем открытие комментов — а то как будто нам с вами обсудить нечего 😅).
Итак. Первая серия "Что написано пером..."
🎥 Заброненная переговорка. За столом сидят продакт- и проджект- менеджеры, лид направления, маркетолог и аналитик. Все зловеще молчат и переглядываются. (Фон — гнетущее адажио, струнные-смычковые). По их лицам и музыке мы понимаем, что должно случиться что-то плохое.
Продакт (раздраженно): Я, всё-таки, настаиваю на смене приоритетов. Сейчас важнее реализовать...
Лид (еще более раздраженно, привставая на стуле): Мы это уже слышали! Есть сроки, они утверждены, с твоей стороны тоже был коммитмент!
Маркетолог вздрагивает. Проджект закатывает глаза. Аналитик смотрит прямо перед собой невидящим взглядом.
Продакт (вскакивает со стула): Но потребности клиента меняются! Его боли эволюционируют! Он динамичен!
Лид (тоже вскакивает, хватает пульт от проектора): На Q1 были другие планы!
Камера фокусируется на стене. Там мы видим огромный roadmap с кучей подробностей, указанием хронологии проекта, конкретных шагов и т.п. Слышим звуки борьбы, чей-то сдавленный стон и визг. Фокус всё еще на roadmap'е.
Звук падения тела. Затемнение...
Резюмируем: когда roadmap обрастает излишними деталями и перестает быть динамичным, могут произойти страшные вещи ☝️
#roadmap_AGIMA
Хотели в один пост все ошибки составления/использования roadmap'а запилить, но что-то в один никак не помещаются. Поэтому сериал будет. Вероятно, остросюжетный. Серии будут выходить не каждый день — завтра про другое поговорим (да-да, анонсируем открытие комментов — а то как будто нам с вами обсудить нечего 😅).
Итак. Первая серия "Что написано пером..."
🎥 Заброненная переговорка. За столом сидят продакт- и проджект- менеджеры, лид направления, маркетолог и аналитик. Все зловеще молчат и переглядываются. (Фон — гнетущее адажио, струнные-смычковые). По их лицам и музыке мы понимаем, что должно случиться что-то плохое.
Продакт (раздраженно): Я, всё-таки, настаиваю на смене приоритетов. Сейчас важнее реализовать...
Лид (еще более раздраженно, привставая на стуле): Мы это уже слышали! Есть сроки, они утверждены, с твоей стороны тоже был коммитмент!
Маркетолог вздрагивает. Проджект закатывает глаза. Аналитик смотрит прямо перед собой невидящим взглядом.
Продакт (вскакивает со стула): Но потребности клиента меняются! Его боли эволюционируют! Он динамичен!
Лид (тоже вскакивает, хватает пульт от проектора): На Q1 были другие планы!
Камера фокусируется на стене. Там мы видим огромный roadmap с кучей подробностей, указанием хронологии проекта, конкретных шагов и т.п. Слышим звуки борьбы, чей-то сдавленный стон и визг. Фокус всё еще на roadmap'е.
Звук падения тела. Затемнение...
Резюмируем: когда roadmap обрастает излишними деталями и перестает быть динамичным, могут произойти страшные вещи ☝️
#roadmap_AGIMA
🙅🏻♀️ Roadmap: как не надо делать. Pt.2
Продолжаем серию постов про ошибки составления и использования roadmap. Сегодня через призму мышления Колобка. (Да, у нас тут прям как «Черное зеркало» — серии не делят общий сюжет, но друг с другом как-то связаны).
Вторая серия «Тесты теста».
🎥 Новоиспечённый Колобок остывает на подоконнике. За окном пасторальный пейзаж, пение птиц. Безмятежность. Колобок очень любознателен и просит Деда с Бабкой показать ему roadmap его самого, как продукта. Дед с Бабкой многозначительно переглядываются и отказывают Колобку.
Колобок, желающий взять от жизни всё, отправляется в непредсказуемое путешествие. Камера отъезжает, нам видно, что тропинка от домика с подоконником ведёт в лес. Следующий кадр — Колобок врезается в Зайца.
Заяц: Я тебя съем!
Колобок: Не съешь!
Колобок с пробуксовкой укатывается от Зайца.
Далее наблюдаем аналогичные встречи Колобка с Волком и Медведем.
По мере продвижения Колобка вглубь леса картинка становится всё более мрачной. Пение птиц сменилось на карканье вороны, деревья черные и кривые, звуки, которые слышны помимо вороны, по-лавкрафтовски неописуемы. Колобок замедляет скорость движения, с опаской оглядывается по сторонам и замечает Лису.
Лиса: Я тебя съем!
Колобок (радостно, т.к. знакомый поведенческий паттерн): Нет, не съешь!
Лиса: Спорим, не сможешь залезть мне на нос?
Колобок (заинтересованно, мы помним, что он, всё же, открыт новому): Да легко!
Мгновенное затемнение. Абсолютная тишина.
Мы слышим приглушенный предсмертный хрип Колобка и последнюю в его жизни, полную отчаяния фразу: «Ну почему дед с бабкой отказались показать мне roadmap?!»
Резюмируем: roadmap должен быть легкодоступным всем членам команды и заинтересованным в продукте лицам.
#roadmap_AGIMA
Продолжаем серию постов про ошибки составления и использования roadmap. Сегодня через призму мышления Колобка. (Да, у нас тут прям как «Черное зеркало» — серии не делят общий сюжет, но друг с другом как-то связаны).
Вторая серия «Тесты теста».
🎥 Новоиспечённый Колобок остывает на подоконнике. За окном пасторальный пейзаж, пение птиц. Безмятежность. Колобок очень любознателен и просит Деда с Бабкой показать ему roadmap его самого, как продукта. Дед с Бабкой многозначительно переглядываются и отказывают Колобку.
Колобок, желающий взять от жизни всё, отправляется в непредсказуемое путешествие. Камера отъезжает, нам видно, что тропинка от домика с подоконником ведёт в лес. Следующий кадр — Колобок врезается в Зайца.
Заяц: Я тебя съем!
Колобок: Не съешь!
Колобок с пробуксовкой укатывается от Зайца.
Далее наблюдаем аналогичные встречи Колобка с Волком и Медведем.
По мере продвижения Колобка вглубь леса картинка становится всё более мрачной. Пение птиц сменилось на карканье вороны, деревья черные и кривые, звуки, которые слышны помимо вороны, по-лавкрафтовски неописуемы. Колобок замедляет скорость движения, с опаской оглядывается по сторонам и замечает Лису.
Лиса: Я тебя съем!
Колобок (радостно, т.к. знакомый поведенческий паттерн): Нет, не съешь!
Лиса: Спорим, не сможешь залезть мне на нос?
Колобок (заинтересованно, мы помним, что он, всё же, открыт новому): Да легко!
Мгновенное затемнение. Абсолютная тишина.
Мы слышим приглушенный предсмертный хрип Колобка и последнюю в его жизни, полную отчаяния фразу: «Ну почему дед с бабкой отказались показать мне roadmap?!»
Резюмируем: roadmap должен быть легкодоступным всем членам команды и заинтересованным в продукте лицам.
#roadmap_AGIMA
🤫 Когда не нужен roadmap?
Roadmap — очень полезная штука. Но нужен он не всем и не всегда. Про ошибки составления роадмэпа уже было (можно найти в канале по тэгу), а вот про ситуации, когда нужно сконцентрироваться на других задачах и не упарываться в роадмэп (или таки стоит упороться), расскажем сейчас.
Роадмэп не обязателен, когда:
◼️продукт на стадии концепта, прототипа, альфа/бета-версии, MVP.
Потому что роадмэп в этом случае будет давать нам ложное чувство уверенности, тогда как нам нужно сконцентрироваться на learning loop, быстрых исправлениях и валидациях.
◼️компания на аналогичных ранних стадиях.
Только когда уже есть продукт, который приносит деньги, стоит задуматься о дорожной карте. Потому что к этому моменту у нас есть достаточно информации, чтобы эту самую карту создать.
Роадмэп обязателен, когда:
◼️ в компании над продуктом трудится более одной команды.
И чем больше команд/участников, тем выше ценность дорожной карты.
◼️нужно рассказать о вашем продукте за пределами продуктовой команды (маркетинг/продажи/стейкхолдеры/инвесторы и т.п).
В этом случае роадмэп должен быть, хотя бы очень верхнеуровневый.
◼️мы в ситуациях, противоположных тем, что указаны в предыдущем абзаце (продукт/компания не на ранних стадиях).
Высшие ценности роадмэп — план, история и показатели успеха. Поэтому составление дорожной карты до того, как мы понимаем направление измерений успеха продукта или компании, дело достаточно сомнительное.
#roadmap_AGIMA
Roadmap — очень полезная штука. Но нужен он не всем и не всегда. Про ошибки составления роадмэпа уже было (можно найти в канале по тэгу), а вот про ситуации, когда нужно сконцентрироваться на других задачах и не упарываться в роадмэп (или таки стоит упороться), расскажем сейчас.
Роадмэп не обязателен, когда:
◼️продукт на стадии концепта, прототипа, альфа/бета-версии, MVP.
Потому что роадмэп в этом случае будет давать нам ложное чувство уверенности, тогда как нам нужно сконцентрироваться на learning loop, быстрых исправлениях и валидациях.
◼️компания на аналогичных ранних стадиях.
Только когда уже есть продукт, который приносит деньги, стоит задуматься о дорожной карте. Потому что к этому моменту у нас есть достаточно информации, чтобы эту самую карту создать.
Роадмэп обязателен, когда:
◼️ в компании над продуктом трудится более одной команды.
И чем больше команд/участников, тем выше ценность дорожной карты.
◼️нужно рассказать о вашем продукте за пределами продуктовой команды (маркетинг/продажи/стейкхолдеры/инвесторы и т.п).
В этом случае роадмэп должен быть, хотя бы очень верхнеуровневый.
◼️мы в ситуациях, противоположных тем, что указаны в предыдущем абзаце (продукт/компания не на ранних стадиях).
Высшие ценности роадмэп — план, история и показатели успеха. Поэтому составление дорожной карты до того, как мы понимаем направление измерений успеха продукта или компании, дело достаточно сомнительное.
#roadmap_AGIMA
🤓 Что на ранних этапах важнее, чем roadmap?
Вчера мы подсветили те ситуации, когда roadmap не так важен, как кажется. Но это не означает, что нужно забыть про планирование и целеполагание вообще. На ранних этапах стоит озаботиться следующим:
🔘 NSM в качестве ориентира. Важно помнить, что для выбранной вами метрики всевластия обязательно должна быть контрольная метрика (подробнее об этом — здесь).
🔘Концепция продукта. Что мы собираемся запускать? Определяем концепт продукта и начальные возможности/функции (описываем MVP).
🔘 ЦА. На какой рынок мы планируем запускаться? Кто наши целевые пользователи? Каковы их потребности и боли?
🔘 OKR — как мы будем измерять успех каждой итерации и понимать, как она связана с общей целью? Подробнее про OKR — тут.
🔘 Бриф продукта. В таком брифе должны быть:
- проблемы, которые вы пытаетесь решить
- требования к продукту
- контекст продукта
- таймлайн
- название продукта (хотя бы рабочее).
Это обязательный минимум. Лучше сосредоточиться на прототипе, альфа-, бета-версии или MVP 💪
#roadmap_AGIMA
Вчера мы подсветили те ситуации, когда roadmap не так важен, как кажется. Но это не означает, что нужно забыть про планирование и целеполагание вообще. На ранних этапах стоит озаботиться следующим:
🔘 NSM в качестве ориентира. Важно помнить, что для выбранной вами метрики всевластия обязательно должна быть контрольная метрика (подробнее об этом — здесь).
🔘Концепция продукта. Что мы собираемся запускать? Определяем концепт продукта и начальные возможности/функции (описываем MVP).
🔘 ЦА. На какой рынок мы планируем запускаться? Кто наши целевые пользователи? Каковы их потребности и боли?
🔘 OKR — как мы будем измерять успех каждой итерации и понимать, как она связана с общей целью? Подробнее про OKR — тут.
🔘 Бриф продукта. В таком брифе должны быть:
- проблемы, которые вы пытаетесь решить
- требования к продукту
- контекст продукта
- таймлайн
- название продукта (хотя бы рабочее).
Это обязательный минимум. Лучше сосредоточиться на прототипе, альфа-, бета-версии или MVP 💪
#roadmap_AGIMA
Telegram
Продуктовый подход. By AGIMA
💍NSM. Метрика Всевластия
North Star Metric (NSM), или метрика Всевластия — это такая невозможно крутая метрика, отслеживая и влияя на которую успеха не избежать. Звучит как что-то на волшебном, так что давайте разбираться, утопия это или нет.
Получить корону…
North Star Metric (NSM), или метрика Всевластия — это такая невозможно крутая метрика, отслеживая и влияя на которую успеха не избежать. Звучит как что-то на волшебном, так что давайте разбираться, утопия это или нет.
Получить корону…
⚠️ ППО: что это и почему оно нужно
Прежде, чем мы беремся за новый продукт или развитие уже имеющегося, мы настаиваем на проведении ППО. ППО — это предпроектное обследование, которое помогает:
◾️ выявить целевую аудиторию продукта и «работы», на которые она готова наш продукт «нанять»
◾️ избавиться от неопределенности и получить формализацию процессов «as is»
◾️ определить функции, необходимые для MVP
◾️ сопоставить эти функции с реальными бизнес-процессами
◾️ разработать стратегию развития продукта
◾️ планировать ресурсы
◾️ подсветить потенциальные риски для всех участников.
ППО актуально не только для агентств — для запуска продукта самой компанией оно тоже необходимо. Знаем, что многие коллеги активно используют этот инструмент, и если вдруг вы не из их числа — настоятельно рекомендуем присмотреться. А чтобы это «присматривание» было более предметным, предлагаем познакомиться с нашим видением ☺️
Что включает в себя ППО в AGIMA:
1️⃣ Проведение серии интервью со стейкхолдерами, участниками связанных процессов, текущими/потенциальными пользователями
2️⃣ Анализ имеющихся регламентов, систем и любой документации, затрагивающей связанные процессы
3️⃣ Подготовка отчетного концепт-документа:
- цели и задачи
- схемы бизнес-процессов с их описанием
- реестр функциональных требований
- роли пользователей продукта
- ограничения
- среда функционирования
- предметная область
- требования к UI и UX
- взаимодействие между компонентами продукта и другими продуктами (опционально).
- etc. (список не закрыт, т.к. может видоизменяться в зависимости от целей и задач заказчика).
Думаем, важность ППО после того, что вы прочитали выше, очевидна. Так что пользуйтесь. Если будут вопросы — ждем в комментах, без знаний не оставим. Data-driven всем! ♥️
#roadmap_AGIMA
#managing_team_AGIMA
#JTBD_AGIMA
#frameworks_AGIMA
Прежде, чем мы беремся за новый продукт или развитие уже имеющегося, мы настаиваем на проведении ППО. ППО — это предпроектное обследование, которое помогает:
◾️ выявить целевую аудиторию продукта и «работы», на которые она готова наш продукт «нанять»
◾️ избавиться от неопределенности и получить формализацию процессов «as is»
◾️ определить функции, необходимые для MVP
◾️ сопоставить эти функции с реальными бизнес-процессами
◾️ разработать стратегию развития продукта
◾️ планировать ресурсы
◾️ подсветить потенциальные риски для всех участников.
ППО актуально не только для агентств — для запуска продукта самой компанией оно тоже необходимо. Знаем, что многие коллеги активно используют этот инструмент, и если вдруг вы не из их числа — настоятельно рекомендуем присмотреться. А чтобы это «присматривание» было более предметным, предлагаем познакомиться с нашим видением ☺️
Что включает в себя ППО в AGIMA:
1️⃣ Проведение серии интервью со стейкхолдерами, участниками связанных процессов, текущими/потенциальными пользователями
2️⃣ Анализ имеющихся регламентов, систем и любой документации, затрагивающей связанные процессы
3️⃣ Подготовка отчетного концепт-документа:
- цели и задачи
- схемы бизнес-процессов с их описанием
- реестр функциональных требований
- роли пользователей продукта
- ограничения
- среда функционирования
- предметная область
- требования к UI и UX
- взаимодействие между компонентами продукта и другими продуктами (опционально).
- etc. (список не закрыт, т.к. может видоизменяться в зависимости от целей и задач заказчика).
Думаем, важность ППО после того, что вы прочитали выше, очевидна. Так что пользуйтесь. Если будут вопросы — ждем в комментах, без знаний не оставим. Data-driven всем! ♥️
#roadmap_AGIMA
#managing_team_AGIMA
#JTBD_AGIMA
#frameworks_AGIMA
Прототипирование — процесс создания начальной модели продукта для демонстрации его функциональности и дизайна. Это не окончательная версия продукта, но она позволяет проверить идеи и концепции на ранней стадии разработки.
Почему это важно (особенно для продактов)?
1️⃣ Тестирование идеи
Прежде чем инвестировать время и ресурсы в полноценное развитие продукта, лучше проверить основную идею с помощью прототипа.
2️⃣Обратная связь
Прототипы позволяют получать обратную связь от пользователей и команды, что помогает улучшить продукт.
3️⃣Экономия ресурсов
Избегая ранних ошибок, вы экономите время и деньги на дальнейших стадиях разработки (очень много времени и денег).
🔧 Инструменты для создания прототипов
То, что любим мы
👍 Figma. Мощный инструмент для дизайна и прототипирования, позволяющий командам совместно работать над проектами.
👍 Adobe XD. Интегрированный инструмент для дизайна интерфейсов и прототипирования.
👍 Sketch. Популярное решение для дизайна UI с большим количеством плагинов и интеграций.
Что есть еще
✔ InVision. Один из самых известных инструментов для прототипирования, позволяющий создавать интерактивные прототипы и совместно работать над ними.
✔ Balsamiq. Инструмент, который идеально подходит для создания «быстрых» макетов и прототипов.
✔ Axure RP. Мощное решение для создания высокофункциональных прототипов с возможностью добавления логики и переменных.
✔ Marvel. Платформа для дизайна, прототипирования и тестирования, которая также предлагает интеграцию с другими популярными инструментами.
✔ Proto.io. Облачное решение для создания полностью интерактивных прототипов без необходимости кодирования.
✔ Framer. Инструмент, который подходит для создания более динамичных и анимированных прототипов.
✔ Webflow. Платформа, которая позволяет дизайнерам создавать «отзывчивые» прототипы без написания кода, а также превращать их в готовые веб-сайты.
✔ Moqups. Онлайн-приложение для макетирования и прототипирования, которое также предлагает наборы элементов и шаблонов для ускорения процесса дизайна.
А что по тенденциям?
▪️ 3D и AR прототипирование
С развитием технологий, прототипирование становится более динамичным и интерактивным.
▪️ Микровзаимодействия
Больше внимания уделяется деталям и анимациям, чтобы сделать пользовательский опыт более плавным.
▪️ Совместное прототипирование
Инструменты становятся более интегрированными, позволяя командам работать над прототипами в реальном времени.
Прототипирование — это ключевой этап в разработке продукта, который помогает сформировать правильное видение и донести его до команды и пользователей
#cx_ux_AGIMA
#MVP_AGIMA
#roadmap_AGIMA
#lean_startup_AGIMA
Please open Telegram to view this post
VIEW IN TELEGRAM
Каждый запуск и даже принятие незначительного, на первый взгляд, решения несет в себе потенциальные угрозы и возможности, поэтому тему управления рисками избежать сложно.
Да и зачем избегать, если можно превратить риск-менеджмент из необходимости в мощный инструмент на пути к успеху продукта?
1️⃣ Идентификация рисков
Первый шаг к эффективному управлению рисками — их распознавание. Что может пойти не так? Это могут быть технические проблемы, изменения в настроениях аудитории или новые регуляторные ограничения. Составляем список всего, что может помешать достижению наших целей.
2️⃣ Анализ рисков
Оцениваем каждый риск по двум параметрам: вероятность возникновения и потенциальный ущерб. Для этого используем матрицу рисков для визуализации и приоритизации (про нее — дальше).
3️⃣ Планирование реагирования
Для каждого существенного риска разрабатываем план действий. Он может включать смягчение, принятие, перенос или избегание риска. И не забываем, что некоторые риски могут превратиться в возможности (нет, это не мотивирующая цитата, это реальность).
4️⃣ Реализация решений
Начинаем с рисков, которые имеют наибольшее сочетание вероятности и потенциального ущерба. Работаем с командой, мозгоштурмя пути минимизации рисков и используя нашу продуктовую стратегию.
5️⃣ Мониторинг и контроль
Управление рисками — это не разовая активность. Необходимо постоянно наблюдать за изменениями и адаптироваться к ним. Держим руку на пульсе, используя KPI и метрики, чтобы своевременно реагировать.
Теперь про матрицу
Это визуальный инструмент управления рисками, который помогает идентифицировать и приоритизировать риски на основе их вероятности возникновения и степени воздействия на проект/продукт/бизнес.
Матрица рисков — таблица с двумя осями:
- X — вероятность возникновения риска, от низкой до высокой;
- Y — величина воздействия риска, также от низкого до высокого.
Пересечение этих двух параметров определяет приоритет риска. Каждый риск размещается в соответствующей ячейке матрицы в зависимости от оцененной вероятности и воздействия.
Матрица как правило делится на четыре квадранта (все стандартно, похоже на популярные фреймворки приоритизации):
🟢 Низкая вероятность/низкое воздействие
Риски считаются «допустимыми» и обычно не требуют пристального внимания.
🔵 Низкая вероятность/высокое воздействие
Риски здесь не часто случаются, но могут быть разрушительными; стратегии управления рисками могут включать мониторинг или разработку планов на случай реализации риска.
🟡 Высокая вероятность/низкое воздействие
Риски в этой области могут часто возникать, но их воздействие управляемо; часто используются регулярные операционные процедуры для их обработки.
🔴 Высокая вероятность/высокое воздействие
Это риски, требующие максимального внимания. Становятся ключевыми точками для разработки стратегии управления рисками.
Матрицу рисков создали — го к третьему шагу.
Одна из ключевых задач data driven — это превращение неопределенности в ясность, и решения, принятые на основании данных, уже заставляют наши риски сбрасывать вес.
#roadmap_AGIMA
#frameworks_AGIMA
Please open Telegram to view this post
VIEW IN TELEGRAM