На этот раз мы решили показать общие принципы и особенности управления рисками в разных используемых подходах и методологиях:
PMBOK PMI - американская методология.
P2M - японская методология.
Agile - подход гибкой разработки программного обеспечения в ИТ- проектах.
MSF (Microsoft Solution Framework) - подход компании Microsoft по итерационной разработке программного обеспечения.
Avos - подход, часто при меняемый в российских компаниях. Его основной тезис выражается как poka grom ne gryanet. Сильно отличается от стратегии принятии рисков.
Андрей Вачегин, Начальник управления администрирования проектов, департамент развития мощностей, «КЭС», Член Совета Директоров «ТГК-9». Доклад "Управление рисками. Когда и как?"
AeroHills: Методики определения и работы с рисками в игровых проектахDevGAMM Conference
В докладе будут рассмотрены виды потенциальных рисков в игровых проектах, их характеристики. Обсудим методы работы с рисками для снижения вероятности наступления и уменьшения влияния рисков на проект. Доклад будет полезен начинающим руководителям и собственникам студий разработки.
Модуль 11. Лекция 49-50. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование реагирования на риски:
● Входы
● Инструменты и методы
● Стратегия реагирования на угрозы
● Стратегия реагирования на возможности
● Стратегия реагирования на потери
● Выходы
● Контроль рисков
● Входы
● Инструменты и методы
● Аудиты и переоценка рисков
● Выходы
Модуль 11. Лекция 47-48. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Качественный анализ рисков:
● Входы
● Инструменты и методы
● Формирование матрицы вероятности и воздействия.
● Определение категорий рисков
● Выходы
● Количественный анализ рисков
● Входы
● Инструменты и методы
● Методы сбора и представления информации
● Методы количественного анализа и моделирования рисков
● Выходы
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
Презентация делалась в 2006 году, но может быть еще актуальна для всех, кто связан с тематикой CRM (Customer Relationship Management).
Я рассказывал о том, как защитить проект перед заказчиком, как объяснить руководителю организации зачем ему нужна система CRM
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
По статистике, три из четырех проектов заканчиваются неудачей. Из-за нечетких целей, плохого планирования, недоучета рисков и так далее и тому подобное.
И есть еще одна причина.
Плохое управление людьми. Проекты делают люди, поэтому, все управление проектами – это управление людьми. А вовсе не вырисовывание красивых картинок в MSProject. Об этом вы поговорите с Олегом Вайнбергом, экс CIO и тьютором факультета менеджмента Открытого Университета Великобритании.
На этот раз мы решили показать общие принципы и особенности управления рисками в разных используемых подходах и методологиях:
PMBOK PMI - американская методология.
P2M - японская методология.
Agile - подход гибкой разработки программного обеспечения в ИТ- проектах.
MSF (Microsoft Solution Framework) - подход компании Microsoft по итерационной разработке программного обеспечения.
Avos - подход, часто при меняемый в российских компаниях. Его основной тезис выражается как poka grom ne gryanet. Сильно отличается от стратегии принятии рисков.
Андрей Вачегин, Начальник управления администрирования проектов, департамент развития мощностей, «КЭС», Член Совета Директоров «ТГК-9». Доклад "Управление рисками. Когда и как?"
AeroHills: Методики определения и работы с рисками в игровых проектахDevGAMM Conference
В докладе будут рассмотрены виды потенциальных рисков в игровых проектах, их характеристики. Обсудим методы работы с рисками для снижения вероятности наступления и уменьшения влияния рисков на проект. Доклад будет полезен начинающим руководителям и собственникам студий разработки.
Модуль 11. Лекция 49-50. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Планирование реагирования на риски:
● Входы
● Инструменты и методы
● Стратегия реагирования на угрозы
● Стратегия реагирования на возможности
● Стратегия реагирования на потери
● Выходы
● Контроль рисков
● Входы
● Инструменты и методы
● Аудиты и переоценка рисков
● Выходы
Модуль 11. Лекция 47-48. Управление рисками проектаYana Brodetski
Управление рисками проекта
● Качественный анализ рисков:
● Входы
● Инструменты и методы
● Формирование матрицы вероятности и воздействия.
● Определение категорий рисков
● Выходы
● Количественный анализ рисков
● Входы
● Инструменты и методы
● Методы сбора и представления информации
● Методы количественного анализа и моделирования рисков
● Выходы
Основано на книге Стив МакКонелл, "Сколько стоит программный проект"
- Цели, План, Эстимейт, Обязательства - как они взаимосвязаны?
- Переоценка и недооценка - последствия
- Основные причины ошибок в оценках
- Факторы и их влияние на оценку (COCOMO ||)
- Методы оценки
- Правильная процедура оценки
Полезные ссылки:
Classic Mistakes Enumerated -
http://www.stevemcconnell.com/rdenum.htm
CoCoMo - https://ru.wikipedia.org/wiki/COCOMO
Экстремальное программирование - https://ru.wikipedia.org/wiki/Экстремальное_программирование
Презентация делалась в 2006 году, но может быть еще актуальна для всех, кто связан с тематикой CRM (Customer Relationship Management).
Я рассказывал о том, как защитить проект перед заказчиком, как объяснить руководителю организации зачем ему нужна система CRM
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
Определение стейкхолдеров
Кто такие стейкхолдеры (Stakeholders)
Способы идентификации стейкхолдеров
Анализ вовлеченности стейхолдеров
Способы коммуникации на проекте
Проект
Структура проекта
Управление проектом
Система ограничений
Организационная структура
Целеполагание
Успешный проект
По статистике, три из четырех проектов заканчиваются неудачей. Из-за нечетких целей, плохого планирования, недоучета рисков и так далее и тому подобное.
И есть еще одна причина.
Плохое управление людьми. Проекты делают люди, поэтому, все управление проектами – это управление людьми. А вовсе не вырисовывание красивых картинок в MSProject. Об этом вы поговорите с Олегом Вайнбергом, экс CIO и тьютором факультета менеджмента Открытого Университета Великобритании.
Презентация во многом является практическим подтверждением необходимости и описанием структуры создания Устава Проекта. В докладе было использовано множество примеров из собственного опыта.
В наше время неразумно начинать проект разработки программного обеспечения без предварительного всестороннего анализа. Начальным этапом любого IT проекта должно стать исследование. Это процедура сбора информации, которая дает понимание отрасли, для которой разрабатывается продукт, бизнеса Вашего заказчика и целевой аудитории.
3. Возможности vs. Качество Качество – это свойство продукта или услуги, характеризующее его соответствие цели, ради которой создается, или, другими словами, соответствие предъявляемым требованиям, так, чтобы удовлетворить потребителя, и, в тоже время, гарантировать, что нужды всех заинтересованных сторон учтены. 3
4. Что такое риски? Риск проекта - это неопределенное событие или условие, которое будет иметь положительное или отрицательное воздействие как минимум на одну цель проекта, если оно произойдет. (PMBOK) 4
6. Бонус - Как победить трамвай? 6 Делайте остановки Дублируйте критические функции и органы
7. Некоторые другие события Поступил запрос на изменение требований в ходе работы; Обнаружена ошибка в оценках; Продукт не прошел приемку у Заказчика. 7
8. Структура идентификации риска Описание события. Последствия влияния события на проект. Причины возникновения. Методы увеличения/уменьшения влияния. 8
10. Запрос на изменение Описание события: Поступил запрос на изменение в ходе работы Последствия влияния события на проект: 10
11. Запрос на изменение От чего зависят последствия возникновения запроса на изменение: Размер и сложность запроса; Его влияния на ход проекта; Процедуры управления изменениями; Договора/контракта; 11
12. Запрос на изменение Причины возникновения: На стороне Заказчика: Изменения внешних факторов (законодательство, конкуренция); Изменение бизнеса; еще ? На стороне Разработчика: Низкое качество требований; Пропущенные требования; Пропущенные заинтересованные стороны; Низкое качество дизайна и прототипов; еще? 12
13. Запрос на изменение Методы увеличения/уменьшения влияния: «Правильные люди» на стороне Заказчика и Разработчика участвующие в процессе проектирования; Проверенные методы улучшения качества проектной документации; Работающие процедуры управления изменениями, в т.ч. в контрактах; Разбиение проекта на фазы. 13
15. Обнаружена ошибка в оценках Описание события: Обнаружена ошибка в оценках Последствия влияния события на проект: 15
16. Обнаружена ошибка в оценках Причины возникновения: Недостаточная квалификация людей дававших оценки; Оценки даны на основе неточных данных: Низкое качество информации на основе которой давалась оценка; Использована новая технология/среда разработки; еще? 16
17. Обнаружена ошибка в оценках Методы увеличения/уменьшения влияния: «Правильные люди» в команде Разработки; Улучшение качества требований и другой проектной документации; Использование проверенных методологий/инструментов; Обучение; Прототипирование. 17
19. Продукт не прошел приемку Описание события: Продукт не прошел приемку у Заказчика Последствия влияния события на проект: 19
20. Продукт не прошел приемку Причины возникновения: Продукт был не готов к приемке (ну не успели); Сделали не то что нужно: Сменился бизнес (но у разработчика не было информации об этом); Сменились люди на стороне Заказчика (принимают не те, кто формулировал требования); Потеря в канале (аналитики не донесли требования Заказчика до разработчиков); еще? 20
21. Продукт не прошел приемку Методы увеличения/уменьшения влияния: Квалифицированный ПМ (управление объемом, сроками, ожиданиями). Постоянный контакт с Заказчиком. Прототипирование, предварительные показы, регулярные встречи; «Правильные» аналитики доступные на протяжении всего срока проекта; Улучшение качества требований и другой проектной документации. 21
22. Методы снижения рисков Можно выделить следующие методы увеличения/уменьшения влияния рисков связанные с требованиями (и прочей проектной документацией), а так же с процессом их разработки: Выбор правильных людей на соответствующие позиции как на стороне Разработчика, так и на стороне Заказчика. Постоянный состав людей участвующих в разработке требований на протяжении всего проекта (как минимум преемственность и взаимозаменяемость) Проверенные методы улучшения качества проектной документации; Работающие процедуры управления изменениями, в т.ч. в контрактах; Прототипы. 22
23. Правильные люди Каждая проектная роль обладает своей спецификой. Очень немногим людям удается совмещать сразу несколько ролей на одном проект эффективно. К любой работе нужно иметь способности/склонности. Нужно учиться. Опыт важен. Экспертиза vs. Практика. 23
25. Виды проверок Формальные и неформальные проверки Проверки требований коллегами аналитиками (peer review) Согласования требований с представителями заинтересованных сторон Согласования требований с разработчиками/проектировщиками. 25
27. Прототипы Преимущества: Визуализация; Динамика. Опасности: Завышенные ожидания Заказчика; Отвлечение от важных аспектов в сторону несущественных мелочей. 27
28. Заключение Сделать проект успешным вам помогут: Правильные люди доступные на все время проекта; Работающие процедуры; Проверки и еще раз проверки; Прототипы (а куда без них?)! 28