Ризик є основною причиною невизначеності в будь-якій організації. Компанії все частіше фокусуються на виявленні ризиків та управлінні ними, перш, ніж вони почнуть впливати на бізнес. На МК будемо вчитися ефективній роботі з ризиками. Здатність управляти ризиками допоможе компаніям впевненіше діяти в майбутніх бізнес-рішеннях.
Для кого корисний майстер-клас:
керівники проектів
тім-ліди
проектні менеджери
скарм-мастера
засновники стартапів
Які питання ми розглянемо?
Чи потрібен ризик-план, якщо ми працюємо за методологією Agile
Чи потрібні мені формули і матриці
Якщо я не можу вплинути на те, що ризик таки станеться, що тоді
Speaker - Anna Lavrova, SAFe Agilist
Риск является основной причиной неопределенности в любой организации и проекте. Компании все чаще фокусируются на выявлении рисков и управлении ими, прежде чем они даже повлияют на бизнес. На этом 3-х часовом воркшопе мы на практике будем учиться правильному риск-менеджменту.
Какие вопросы мы затронем?
✅ А нужен ли риск план, если мы работаем по аджайлу?
Манифест говорит, что работающий приносящий ценность продукт важнее документации - зачем риск план и это все?
✅ Нужны ли мне формулы и матрицы?
Во время мастер-класса мы поговорим о разных типах рисков и их источников, мы начнем с оценки вашего проекта и его окружения, вы, безусловно, поработаете с формулами и матрицами, и будете иметь несколько козырей в рукаве во времена шторма, а если формулы и матрицы вас пугают, не волнуйтесь, есть шаблоны ;)
✅ Если я не могу повлиять на то, что риск таки произойдет, то что?
Риск не может быть устранен. Однако он может:
- Быть передан другой стороне, которая готова рискнуть, скажем, путем покупки страхового полиса или заключения форвардного контракта;
- Уменьшен, благодаря хорошему внутреннему контролю;
- Его можно избежать, не вступая в рискованные предприятия;
Некоторые говорят, что риск - это неприятное слово, которое может испортить вам жизнь. Управление рисками - серьезный бизнес (кстати). Как отрасль, она включает более 30 000 компаний и генерирует годовой доход в размере 6 миллиардов долларов.
Ризик є основною причиною невизначеності в будь-якій організації. Компанії все частіше фокусуються на виявленні ризиків та управлінні ними, перш, ніж вони почнуть впливати на бізнес. На МК будемо вчитися ефективній роботі з ризиками. Здатність управляти ризиками допоможе компаніям впевненіше діяти в майбутніх бізнес-рішеннях.
Для кого корисний майстер-клас:
керівники проектів
тім-ліди
проектні менеджери
скарм-мастера
засновники стартапів
Які питання ми розглянемо?
Чи потрібен ризик-план, якщо ми працюємо за методологією Agile
Чи потрібні мені формули і матриці
Якщо я не можу вплинути на те, що ризик таки станеться, що тоді
Speaker - Anna Lavrova, SAFe Agilist
Риск является основной причиной неопределенности в любой организации и проекте. Компании все чаще фокусируются на выявлении рисков и управлении ими, прежде чем они даже повлияют на бизнес. На этом 3-х часовом воркшопе мы на практике будем учиться правильному риск-менеджменту.
Какие вопросы мы затронем?
✅ А нужен ли риск план, если мы работаем по аджайлу?
Манифест говорит, что работающий приносящий ценность продукт важнее документации - зачем риск план и это все?
✅ Нужны ли мне формулы и матрицы?
Во время мастер-класса мы поговорим о разных типах рисков и их источников, мы начнем с оценки вашего проекта и его окружения, вы, безусловно, поработаете с формулами и матрицами, и будете иметь несколько козырей в рукаве во времена шторма, а если формулы и матрицы вас пугают, не волнуйтесь, есть шаблоны ;)
✅ Если я не могу повлиять на то, что риск таки произойдет, то что?
Риск не может быть устранен. Однако он может:
- Быть передан другой стороне, которая готова рискнуть, скажем, путем покупки страхового полиса или заключения форвардного контракта;
- Уменьшен, благодаря хорошему внутреннему контролю;
- Его можно избежать, не вступая в рискованные предприятия;
Некоторые говорят, что риск - это неприятное слово, которое может испортить вам жизнь. Управление рисками - серьезный бизнес (кстати). Как отрасль, она включает более 30 000 компаний и генерирует годовой доход в размере 6 миллиардов долларов.
Андрей Вачегин, Начальник управления администрирования проектов, департамент развития мощностей, «КЭС», Член Совета Директоров «ТГК-9». Доклад "Управление рисками. Когда и как?"
Антон Грачев. В поисках мифического зверя. Новые подходы и инструменты для Ag...ScrumTrek
Вы, наверное, сталкивались с ситуацией когда в вашем Agile проекте срабатывали риски, которые приводили к тем или иным неприятным ситуациям, а затем на ретроспективе или во время аудита задавался вопрос: есть ли управление рисками на проекте? Очень часто ответ звучит положительный, но если рассмотреть детали, то хорошо отлаженного процесса почему-то не обнаруживается. Этакий мифический зверь, о котором все знают, но никто его не видел вживую. Я постараюсь ответить на вопрос «Почему не работают обычные инструменты управления рисками?» и предложу новые подходы и инструменты по управлению рисками как для Скрам, так и для Канбан команд. В частности, представлю свой авторский метод отслеживания рисков в проекте на основе Канбан-доски. Он позволяет упростить и очеловечить процесс отслеживания актуальности рисков, повысит прозрачность информации для всех участников проекта.
На этот раз мы решили показать общие принципы и особенности управления рисками в разных используемых подходах и методологиях:
PMBOK PMI - американская методология.
P2M - японская методология.
Agile - подход гибкой разработки программного обеспечения в ИТ- проектах.
MSF (Microsoft Solution Framework) - подход компании Microsoft по итерационной разработке программного обеспечения.
Avos - подход, часто при меняемый в российских компаниях. Его основной тезис выражается как poka grom ne gryanet. Сильно отличается от стратегии принятии рисков.
RiskGap - управление проектными рисками и Lessons LearnedRiskGap
RiskGap - веб-сервис для выявления и предотвращения проектных рисков. + Органично накапливаются Lessons Learned и идет обмен знаниями между командами.
Постановка задачи - Функционал - Как получить.
Получить бету 100% бесплатно - смотрите презентацию!
Доклад Александры Ковалевой, Test Lead в QA Service, Softengi, Украина.
В презентации представлен симбиоз теории планирования и практического опыта компании QA Service в оценке трудозатрат на тестирование.
Руководители отдела тестирования, ведущие тестировщики узнают:
Чем отличаются стратегические, тактические и оперативные планы? - Что такое планирование с точки зрения тестировщика?
Кто в отвечает за планирование трудозатрат на тестирование?
Какие существуют методы оценки?
Всегда ли имеет смысл детальное планирование и оценка?
Подводные камни планирование сроков тестирования и связь с другими активностями проекта.
Как начать внедрение системы планирования и оценки «снизу»?
Тестировщикам доклад поможет посмотреть на оценку сроков с точки зрения менеджмента и ответить на вопросы:
Как я оцениваю свои задачи? Как это делают другие? Можно ли что-то улучшить?
Как заставить лида перестать спрашивать о сроках?
Чем отличаются трудозатраты на выполнение задачи и сроки завершения задачи. Как сдавать задачи в срок?
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
Несколько вводных слайдов семинара для собственников, руководителей, финансовых директоров компаний.
Проблематика семинара: Как определить уязвимость компании к разнообразным рискам? Какие риски наиболее важны? Как они могут быть измерены? Каким есть оптимальный уровень инвестиций в снижение уязвимости к рискам? Как планировать, разрабатывать бюджеты и системы стимулирования в условиях высокой неопределенности? Как на практике ограничить влияние на компанию разнообразных рисков – валютных курсов, процентных ставок, рыночных цен? Какие системы контроля и управления рисками должны действовать в компании?
Андрей Вачегин, Начальник управления администрирования проектов, департамент развития мощностей, «КЭС», Член Совета Директоров «ТГК-9». Доклад "Управление рисками. Когда и как?"
Антон Грачев. В поисках мифического зверя. Новые подходы и инструменты для Ag...ScrumTrek
Вы, наверное, сталкивались с ситуацией когда в вашем Agile проекте срабатывали риски, которые приводили к тем или иным неприятным ситуациям, а затем на ретроспективе или во время аудита задавался вопрос: есть ли управление рисками на проекте? Очень часто ответ звучит положительный, но если рассмотреть детали, то хорошо отлаженного процесса почему-то не обнаруживается. Этакий мифический зверь, о котором все знают, но никто его не видел вживую. Я постараюсь ответить на вопрос «Почему не работают обычные инструменты управления рисками?» и предложу новые подходы и инструменты по управлению рисками как для Скрам, так и для Канбан команд. В частности, представлю свой авторский метод отслеживания рисков в проекте на основе Канбан-доски. Он позволяет упростить и очеловечить процесс отслеживания актуальности рисков, повысит прозрачность информации для всех участников проекта.
На этот раз мы решили показать общие принципы и особенности управления рисками в разных используемых подходах и методологиях:
PMBOK PMI - американская методология.
P2M - японская методология.
Agile - подход гибкой разработки программного обеспечения в ИТ- проектах.
MSF (Microsoft Solution Framework) - подход компании Microsoft по итерационной разработке программного обеспечения.
Avos - подход, часто при меняемый в российских компаниях. Его основной тезис выражается как poka grom ne gryanet. Сильно отличается от стратегии принятии рисков.
RiskGap - управление проектными рисками и Lessons LearnedRiskGap
RiskGap - веб-сервис для выявления и предотвращения проектных рисков. + Органично накапливаются Lessons Learned и идет обмен знаниями между командами.
Постановка задачи - Функционал - Как получить.
Получить бету 100% бесплатно - смотрите презентацию!
Доклад Александры Ковалевой, Test Lead в QA Service, Softengi, Украина.
В презентации представлен симбиоз теории планирования и практического опыта компании QA Service в оценке трудозатрат на тестирование.
Руководители отдела тестирования, ведущие тестировщики узнают:
Чем отличаются стратегические, тактические и оперативные планы? - Что такое планирование с точки зрения тестировщика?
Кто в отвечает за планирование трудозатрат на тестирование?
Какие существуют методы оценки?
Всегда ли имеет смысл детальное планирование и оценка?
Подводные камни планирование сроков тестирования и связь с другими активностями проекта.
Как начать внедрение системы планирования и оценки «снизу»?
Тестировщикам доклад поможет посмотреть на оценку сроков с точки зрения менеджмента и ответить на вопросы:
Как я оцениваю свои задачи? Как это делают другие? Можно ли что-то улучшить?
Как заставить лида перестать спрашивать о сроках?
Чем отличаются трудозатраты на выполнение задачи и сроки завершения задачи. Как сдавать задачи в срок?
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
Несколько вводных слайдов семинара для собственников, руководителей, финансовых директоров компаний.
Проблематика семинара: Как определить уязвимость компании к разнообразным рискам? Какие риски наиболее важны? Как они могут быть измерены? Каким есть оптимальный уровень инвестиций в снижение уязвимости к рискам? Как планировать, разрабатывать бюджеты и системы стимулирования в условиях высокой неопределенности? Как на практике ограничить влияние на компанию разнообразных рисков – валютных курсов, процентных ставок, рыночных цен? Какие системы контроля и управления рисками должны действовать в компании?
The presentation took place in Moscow at Whale Rider Conference (Internet Projects Management). A wider analytical look was taken at some slosely related to risks areas. What is risk and what is fact? What is behavioral pattern? How historical data can reduce risk impacts? How all these works together?
Зачем аналитику управлять рисками? (блиц-доклад на Analyst Days 2015)RiskGap
Наш доклад на конференции Analyst Days 2015.
Отвечает на вопрос зачем управлять рисками аналитикам и команде. Почему риски это не то, чем должен заниматься только PM.
Ссылки из презентации:
- https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/220647/orange_book.pdf
- http://www.sei.cmu.edu/reports/93tr006.pdf
- http://riskgap.ru/
- https://www.facebook.com/groups/RiskGap/
Управление компанией с использованием метода критического цепи (МКЦ)Евгений Пикулев
Частная презентация, рассказывающая о недостатках метода критического пути, и о достоинствах метода критической цепи. Полезна для собственников и руководителей компаний.
Webinar "Differences between Testing in Waterfall and Agile"
presentation by Maria Teryokhina
http://www.exigenservices.ru/webinars/testing-in-waterfall-and-agile
Презентация вебинара: Межкультурная коммуникация. Особенности взаимодействия с иностранными коллегами на примере работы с коллегами из Китая.
Автор: Екатерина Невзорова
2. Содержание тренинга
• Что такое риск
• Предмет управления рисками
• Идентификация и оценка рисков
• Стратегии управления рисками
• Процесс управления рисками
3. Что такое риск?
• Что такое риск?
• Почему и когда мы рискуем?
• Почему мы не рискуем?
• Почему мы пренебрегаем риском?
5. Что такое риск?
Риск – это событие, которое может произойти в ходе
проекта, и таким образом повлиять на исход проекта.
Риск связан с неопределенностью.
Риск имеет вероятность.
8. Идентификация рисков – примеры из Project Plans
• Wrong stored procedures, i.e. some procedure works incorrectly.
• Send bug report and wait for answer
• Requirements are defined vaguely and as clarified they become inconsistent (or contradictory)
• Provide to the customer our understanding of requirements wherever they seem to be unclear. Provide
interim versions of the application for customer evaluation
• Customer response to project related inquiries is too slow
• Ask customer beforehand to have enough time to get an answer
• The overall project estimates are wrong
• Review estimates on a regular basis and take corrective actions (find “shortcuts”, change priorities, add
resources, reduce functionality)
• Split the project in short iterations and update the estimates (as well as the requirements) before each
iteration
• The team will not be able to support the existing Oracle database due to the lack of knowledge.
• The team velocity can be low than expected.
• Increase the team size. Allocate 6 developers instead of 4 required and 3 testers instead of 2 required.
• The total effort required for open tasks is tool little to workload the entire team
• Probability - 5%, Impact - Immeasurable
• Let the team do some research for future projects. Or let them study new techs.
9. Идентификация рисков
• Как должен быть сформулирован риск:
o Понятная проблема
o Понятное влияние на проект
o Понятные способы решения проблемы
• В нашем случае практически всегда риски негативно влияют
на …
• Почему про некоторые риски забывают:
• Не хватает опыта или данных для идентификации
проблемы
• Невозможно или сложно измерить влияние риска на
проект
• Не ясны пути решения проблемы
10. Типичные источники рисков
• Требования
• Технологии и средства разработки
• Программный код и другие проектные артефакты
• Процесс разработки
• Окружение
• Человеческий фактор
11. Чеклист по управлению рисками I
• Регулярно пересматривайте матрицу рисков
• Привлекайте членов команды для анализа и оценки
рисков
• События происходят не так, как вы задумали. Надежда
на это – плохой план.
• Что если из проекта уйдет кто-то из членов команды?
• Что если ключевой дедлайн будет перемещен на более
раннее время?
• Анализируйте критический путь проекта.
12. Чеклист для поиска рисков II
• Какие аспекты проекта новы для вашей команды?
• Было ли у вас достаточно времени на
планирование?
• Есть ли риск что результаты проекта не будут
приняты клиентом?
• Есть ли зависимости от других команд, организаций,
сторонних продуктов?
• Возможно ли что цели проекта изменятся?
• У вас нет замены для ключевой фигуры/части
проекта.
• Интеграция подсистем, подпроектов – это источник
рисков.
• Вы четко понимаете цель проекта?
13. Оценка риска
• Выбрать метрику и пороговое значение
• Спрогнозировать ее значения в ходе проекта
• Определить размер потерь для пессимистичного варианта
(Risk Impact - RI)
• Рассчитать Risk Probability (RP) как вероятность перехода
через пороговое значение
• Расcчитать Risk Exposure как произведение Risk Impact и Risk
Probability
14. Метрики рисков
• Риск – трудности с использованием сторонней компоненты, что
приведет к высоким трудозатратам, соизмеримым на
самостоятельную разработку функциональности компоненты. (10
ч-дней)
• Метрика: средние трудозатраты на интеграцию компоненты
• Оптимистичный вариант: 1 ч.-день
• Реалистичный вариант: 4 ч.-дней
• Пессимистичный вариант: 14 ч.-дней (если через 4 дня поймем,
что надо писать самим)
• Transition Threshold: 4 ч.-дня
• Потери в пессимистичном случае: 10 ч.-дней
• Risk Probability: Средняя - 30%
• Risk Exposure: 3 ч-дня
15. Какие метрики можно подобрать?
• Риск – болезнь членов команды
• Риск – много ошибок
16. Метрики из упражнения 1
Текущий процент заболевших в компании
Отношение времени на bug-fixing ко времени
реализации функциональности
17. Как оценить вероятность?
Хороший подход – на основе вербальных оценок, связанных с
конкретными числами.
• Критическая 95% – 80%
• Максимальная 80% – 60%
• Высокая 60% – 40%
• Средняя 40% – 30%
• Малая 30% – 20%
• Минимальная 20% – 10%
Или
• Очень высокая (Very high) 80%
• Высокая (High) 60%
• Средняя (Medium) 40%
• Низкая (Low) 20%
18. Каким рискам нужно уделить больше внимания?
Приоритизация должда базироваться на common sense
Приоритизация по принципу Impact - Probability:
• High - High
• High – Low
• Low - High
• Low – Low
Приоритизация по Risk Exposure:
• Risk Exposure = Impact * Probability
19. Что дальше?
• Mitigate – смягчать
A.Совершать предварительные действия до материализации риска для снижения размера
возможных потерь
B.Планировать действия по борьбе с последствиями в случае материализации риска для
снижения размера фактических потерь
• Accept – принять
• Счесть допустимым и не закладывать резервов в бюджет
• Avoid – избегать
• тем или иным способом избавиться от источников риска
• Contain – включать в резерв
• Резервировать средства в бюджете в размере ожидаемых потерь в случае материализации
риска
• Transfer –
• Резервировать средства в бюджете в размере ожидаемых потерь в случае материализации
риска
20. Возможности
• Exploit
• Убрать неопределенность, так чтобы событие точно
произошло. Обратное к Avoid.
• Share
• Постараться выжать максимум из возможности для всех
вовлеченных сторон.
• Enhance
• Opposite to mitigate. Do all possible actions
• Accept
• Принять. Случится – хорошо. Не случиться – ничего
страшного.
21. Как выбрать стратегию?
Стоимость стратегии:
V = VA + RP * (VB + VC) = VA + RP * VB + RE
здесь:
VA – стоимость превентивных мер
VB – стоимость мер по борьбе с последствиями
VC – стоимость понесенных потерь
RP – вероятность риска (Risk Probability)
RE – средние ожидаемые потери (Risk Exposure)
Для стратегии Contain: V = Risk Exposure
22. Пример рассчета стратегии
• Риск – трудности с использованием сторонней компоненты, что
приведет к высоким трудозатратам, соизмеримым на
самостоятельную разработку функциональности компоненты. (10
ч-дней)
• Стратегия Mitigate – создание прототипа. 2 ч-дня. Тем самым
мы перейдем от пессимистичного варианта к оптимистичному и
сэкономим 3 дня.
• VA + RP * (VB + VC) = 2+0,3*(10+1) = 5,3 ч-дней.
• Стратегия Avoid – сразу начать писать самим. В этом случае
риск пропадает (VB и VC=0).
• VA + RP * (VB + VC) = 10 ч-дней.
23. Risk Assessment Form
• ID – уникальный идентификатор риска
• Date – дата выявления риска
• Description – описание риска
• Affected milestone
• Probability – вероятность наступления негативных последствий
• Impact – дополнительный effort, необходимый для преодоления негативных
последствий
• Exposure – среднеожидаемые потери
• Mitigation plan – стратегия смягчения риска и потерь
• Responsible – лицо, ответственное за выполнение Mitigation plan
• Close date – дата успешного завершения плана
24. Управление рисками по ходу проекта
• Регулярный сбор метрик
• Регулярный анализ ситуации и корректировка
параметров рисков
• Реализация задач Mitigation A согласно основному
плану проекта
• Включение задач Mitigation B в план, как только
«сработал» Transition Indicator
• Регулярная идентификация новых рисков