SlideShare a Scribd company logo
1 of 29
Риски в разработке ПО связанные с требованиями
Рамки проекта 2 Возможные решения
Возможности vs. Качество Качество – это свойство продукта или услуги, характеризующее его соответствие цели, ради которой создается, или, другими словами, соответствие предъявляемым требованиям, так, чтобы удовлетворить потребителя, и, в тоже время, гарантировать, что нужды всех заинтересованных сторон учтены.  3
Что такое риски? Риск проекта  - это неопределенное событие или условие, которое будет иметь положительное или отрицательное воздействие как минимум на одну цель проекта, если оно произойдет. (PMBOK) 4
Бонус - «Популярные» риски 5 Трамвай 'Аннушка' на Патриарших прудах
Бонус - Как победить трамвай? 6 Делайте остановки Дублируйте критические функции и органы
Некоторые другие события Поступил запрос на изменение требований в ходе работы; Обнаружена ошибка в оценках; Продукт не прошел приемку у Заказчика. 7
Структура идентификации риска Описание события. Последствия влияния события на проект. Причины возникновения. Методы увеличения/уменьшения влияния. 8
Запрос на изменение 9
Запрос на изменение Описание события:  	Поступил запрос на изменение в ходе работы Последствия влияния события на проект: 10
Запрос на изменение 	От чего зависят последствия возникновения запроса на изменение: Размер и сложность запроса; Его влияния на ход проекта; Процедуры управления изменениями; Договора/контракта; 11
Запрос на изменение Причины возникновения: На стороне Заказчика: Изменения внешних факторов (законодательство, конкуренция); Изменение бизнеса; еще ? На стороне Разработчика: Низкое качество требований; Пропущенные требования; Пропущенные заинтересованные стороны; Низкое качество дизайна и прототипов; еще?  12
Запрос на изменение 	Методы увеличения/уменьшения влияния: «Правильные люди» на стороне Заказчика и Разработчика участвующие в процессе проектирования; Проверенные методы улучшения качества проектной документации; Работающие процедуры управления изменениями, в т.ч. в контрактах; Разбиение проекта на фазы. 13
Обнаружена ошибка в оценках 14
Обнаружена ошибка в оценках Описание события:  	Обнаружена ошибка в оценках Последствия влияния события на проект: 15
Обнаружена ошибка в оценках Причины возникновения: Недостаточная квалификация людей дававших оценки;  Оценки даны на основе неточных данных: Низкое качество информации на основе которой давалась оценка; Использована новая технология/среда разработки; еще?  16
Обнаружена ошибка в оценках 	Методы увеличения/уменьшения влияния: «Правильные люди» в команде Разработки; Улучшение качества требований и другой проектной документации; Использование проверенных методологий/инструментов; Обучение;  Прототипирование. 17
Продукт не прошел приемку 18
Продукт не прошел приемку Описание события:  	 Продукт не прошел приемку у Заказчика Последствия влияния события на проект: 19
Продукт не прошел приемку Причины возникновения: Продукт был не готов к приемке (ну не успели);  Сделали не то что нужно: Сменился бизнес (но у разработчика не было информации об этом); Сменились люди на стороне Заказчика (принимают не те, кто формулировал требования); Потеря в канале (аналитики не донесли требования Заказчика до разработчиков); еще?  20
Продукт не прошел приемку 	Методы увеличения/уменьшения влияния: Квалифицированный ПМ (управление объемом, сроками, ожиданиями). Постоянный контакт с Заказчиком. Прототипирование, предварительные показы, регулярные встречи; «Правильные» аналитики доступные на протяжении всего срока проекта; Улучшение качества требований и другой проектной документации. 21
Методы снижения рисков Можно выделить следующие методы увеличения/уменьшения влияния рисков связанные с требованиями (и прочей проектной документацией), а так же с процессом их разработки: Выбор правильных людей на соответствующие позиции как на стороне Разработчика, так и на стороне Заказчика. Постоянный состав людей участвующих в разработке требований на протяжении всего проекта (как минимум преемственность и взаимозаменяемость) Проверенные методы улучшения качества проектной документации; Работающие процедуры управления изменениями, в т.ч. в контрактах; Прототипы. 22
Правильные люди Каждая проектная роль обладает своей спецификой. Очень немногим людям удается совмещать сразу несколько ролей на одном проект эффективно.  К любой работе нужно иметь способности/склонности. Нужно учиться. Опыт важен. Экспертиза vs. Практика. 23
Улучшение качества документов Чем раньше удается устранить ошибки, тем дешевле их исправление 24
Виды проверок	 Формальные и неформальные проверки Проверки требований коллегами аналитиками (peer review) Согласования требований с представителями заинтересованных сторон Согласования требований с разработчиками/проектировщиками.  25
Работающие процедуры Управление требованиями Управление изменениями Инструменты 26
Прототипы Преимущества: Визуализация; Динамика. Опасности: Завышенные ожидания Заказчика; Отвлечение от важных аспектов в сторону несущественных мелочей. 27
Заключение 	Сделать проект успешным вам помогут: Правильные люди доступные на все время проекта; Работающие процедуры; Проверки и еще раз проверки; Прототипы (а куда без них?)! 28
Спасибо! Вопросы и ответы 29

More Related Content

What's hot

мастер класс риски ет 70715
мастер класс риски ет 70715мастер класс риски ет 70715
мастер класс риски ет 70715Evgeny Tyrtyshny
 
Управление рисками в проектах. Попытка сравнения
Управление рисками в проектах. Попытка сравнения Управление рисками в проектах. Попытка сравнения
Управление рисками в проектах. Попытка сравнения Евгений Пикулев
 
Управление рисками. Когда и как?
Управление рисками. Когда и как?Управление рисками. Когда и как?
Управление рисками. Когда и как?Infor-media
 
управление рисками
управление рискамиуправление рисками
управление рискамиIrina Erofeeva
 
Управление рисками - серебряная пуля или данность моды?
Управление рисками - серебряная пуля или данность моды?Управление рисками - серебряная пуля или данность моды?
Управление рисками - серебряная пуля или данность моды?Vladimir Matviychuk
 
AeroHills: Методики определения и работы с рисками в игровых проектах
AeroHills: Методики определения и работы с рисками в игровых проектахAeroHills: Методики определения и работы с рисками в игровых проектах
AeroHills: Методики определения и работы с рисками в игровых проектахDevGAMM Conference
 
Артур Селецький “Управление рисками в бизнесс-анализе”
Артур Селецький “Управление рисками в бизнесс-анализе”Артур Селецький “Управление рисками в бизнесс-анализе”
Артур Селецький “Управление рисками в бизнесс-анализе”Dakiry
 
Модуль 11. Лекция 49-50. Управление рисками проекта
Модуль 11. Лекция 49-50. Управление рисками проектаМодуль 11. Лекция 49-50. Управление рисками проекта
Модуль 11. Лекция 49-50. Управление рисками проектаYana Brodetski
 
Управление рисками
Управление рискамиУправление рисками
Управление рискамиCKPPK
 
Модуль 11. Лекция 47-48. Управление рисками проекта
Модуль 11. Лекция 47-48. Управление рисками проектаМодуль 11. Лекция 47-48. Управление рисками проекта
Модуль 11. Лекция 47-48. Управление рисками проектаYana Brodetski
 
Проект, контракты и риски заказчика
Проект, контракты и риски заказчикаПроект, контракты и риски заказчика
Проект, контракты и риски заказчикаInfor-media
 
Все об эстимейтах
Все об эстимейтахВсе об эстимейтах
Все об эстимейтахElena Sharovar
 
Как защитить CRM проект?
Как защитить CRM проект?Как защитить CRM проект?
Как защитить CRM проект?Pavel Cherkashin
 
Марри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектамиМарри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектамиElena Sharovar
 
Управление рисками
Управление рискамиУправление рисками
Управление рискамиBoris Volfson
 
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаМодуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаYana Brodetski
 

What's hot (20)

мастер класс риски ет 70715
мастер класс риски ет 70715мастер класс риски ет 70715
мастер класс риски ет 70715
 
управление рисками в проектах
управление рисками в проектахуправление рисками в проектах
управление рисками в проектах
 
Управление рисками в проектах. Попытка сравнения
Управление рисками в проектах. Попытка сравнения Управление рисками в проектах. Попытка сравнения
Управление рисками в проектах. Попытка сравнения
 
Управление рисками. Когда и как?
Управление рисками. Когда и как?Управление рисками. Когда и как?
Управление рисками. Когда и как?
 
управление рисками
управление рискамиуправление рисками
управление рисками
 
Управление рисками - серебряная пуля или данность моды?
Управление рисками - серебряная пуля или данность моды?Управление рисками - серебряная пуля или данность моды?
Управление рисками - серебряная пуля или данность моды?
 
AeroHills: Методики определения и работы с рисками в игровых проектах
AeroHills: Методики определения и работы с рисками в игровых проектахAeroHills: Методики определения и работы с рисками в игровых проектах
AeroHills: Методики определения и работы с рисками в игровых проектах
 
Артур Селецький “Управление рисками в бизнесс-анализе”
Артур Селецький “Управление рисками в бизнесс-анализе”Артур Селецький “Управление рисками в бизнесс-анализе”
Артур Селецький “Управление рисками в бизнесс-анализе”
 
Risk_methodologies
Risk_methodologiesRisk_methodologies
Risk_methodologies
 
Модуль 11. Лекция 49-50. Управление рисками проекта
Модуль 11. Лекция 49-50. Управление рисками проектаМодуль 11. Лекция 49-50. Управление рисками проекта
Модуль 11. Лекция 49-50. Управление рисками проекта
 
Управление рисками проекта
Управление рисками проектаУправление рисками проекта
Управление рисками проекта
 
Управление рисками
Управление рискамиУправление рисками
Управление рисками
 
Batrakov 2009
Batrakov 2009Batrakov 2009
Batrakov 2009
 
Модуль 11. Лекция 47-48. Управление рисками проекта
Модуль 11. Лекция 47-48. Управление рисками проектаМодуль 11. Лекция 47-48. Управление рисками проекта
Модуль 11. Лекция 47-48. Управление рисками проекта
 
Проект, контракты и риски заказчика
Проект, контракты и риски заказчикаПроект, контракты и риски заказчика
Проект, контракты и риски заказчика
 
Все об эстимейтах
Все об эстимейтахВсе об эстимейтах
Все об эстимейтах
 
Как защитить CRM проект?
Как защитить CRM проект?Как защитить CRM проект?
Как защитить CRM проект?
 
Марри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектамиМарри Кантор, Управление программными проектами
Марри Кантор, Управление программными проектами
 
Управление рисками
Управление рискамиУправление рисками
Управление рисками
 
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проектаМодуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
Модуль 2: Лекция 5-6. Определение стейкхолдеров и проекта
 

Similar to Риски в разработке ПО связанные с требованиями

Требования в управлении проектами
Требования в управлении проектамиТребования в управлении проектами
Требования в управлении проектамиPeoplemind
 
Инициация проекта (Project Charter)
Инициация проекта (Project Charter)Инициация проекта (Project Charter)
Инициация проекта (Project Charter)Sergii Movchan
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требованийArtem Shapoval
 
Discovery фаза
Discovery фазаDiscovery фаза
Discovery фазаStfalcon
 
Пример внедрения Agile в крупном проекте. Как не следует внедрять Agile
Пример внедрения Agile в крупном проекте. Как не следует внедрять AgileПример внедрения Agile в крупном проекте. Как не следует внедрять Agile
Пример внедрения Agile в крупном проекте. Как не следует внедрять AgileAlexey Krivitsky
 
владелец продукта
владелец продуктавладелец продукта
владелец продуктаISsoft
 
Продуктовый подход в заказной разработке цифровых продуктов
Продуктовый подход в заказной разработке цифровых продуктовПродуктовый подход в заказной разработке цифровых продуктов
Продуктовый подход в заказной разработке цифровых продуктовCreate Digital
 
Подводные камни перехода в продуктовую разработку
Подводные камни перехода в продуктовую разработкуПодводные камни перехода в продуктовую разработку
Подводные камни перехода в продуктовую разработкуKonstantin Bredyuk
 
Туристско-рекреационное проектирование ч 2 т 4-9
Туристско-рекреационное проектирование ч 2 т 4-9Туристско-рекреационное проектирование ч 2 т 4-9
Туристско-рекреационное проектирование ч 2 т 4-9Сергей Заякин
 
Agile на Смертельном Марше
Agile на Смертельном МаршеAgile на Смертельном Марше
Agile на Смертельном МаршеNikita Filippov
 
Ad 2009 - agile в кризис
Ad 2009 - agile в кризисAd 2009 - agile в кризис
Ad 2009 - agile в кризисAlexey Korsun
 
Продуктовый подход в заказной разработке
Продуктовый подход в заказной разработкеПродуктовый подход в заказной разработке
Продуктовый подход в заказной разработкеSPECIA
 
Интернет-проект. Откуда берутся и куда деваются деньги.
Интернет-проект. Откуда берутся и куда деваются деньги.Интернет-проект. Откуда берутся и куда деваются деньги.
Интернет-проект. Откуда берутся и куда деваются деньги.Yury Shilyaev
 
Kioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опроса
Kioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опросаKioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опроса
Kioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опросаKIODA Management
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требованийSQALab
 

Similar to Риски в разработке ПО связанные с требованиями (20)

Требования в управлении проектами
Требования в управлении проектамиТребования в управлении проектами
Требования в управлении проектами
 
УПРАВЛЕНИЕ ПРОЕКТАМИ – от задумки до внедрения
УПРАВЛЕНИЕ ПРОЕКТАМИ – от задумки до внедренияУПРАВЛЕНИЕ ПРОЕКТАМИ – от задумки до внедрения
УПРАВЛЕНИЕ ПРОЕКТАМИ – от задумки до внедрения
 
Инициация проекта (Project Charter)
Инициация проекта (Project Charter)Инициация проекта (Project Charter)
Инициация проекта (Project Charter)
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требований
 
Discovery фаза
Discovery фазаDiscovery фаза
Discovery фаза
 
Пример внедрения Agile в крупном проекте. Как не следует внедрять Agile
Пример внедрения Agile в крупном проекте. Как не следует внедрять AgileПример внедрения Agile в крупном проекте. Как не следует внедрять Agile
Пример внедрения Agile в крупном проекте. Как не следует внедрять Agile
 
владелец продукта
владелец продуктавладелец продукта
владелец продукта
 
Продуктовый подход в заказной разработке цифровых продуктов
Продуктовый подход в заказной разработке цифровых продуктовПродуктовый подход в заказной разработке цифровых продуктов
Продуктовый подход в заказной разработке цифровых продуктов
 
Подводные камни перехода в продуктовую разработку
Подводные камни перехода в продуктовую разработкуПодводные камни перехода в продуктовую разработку
Подводные камни перехода в продуктовую разработку
 
Туристско-рекреационное проектирование ч 2 т 4-9
Туристско-рекреационное проектирование ч 2 т 4-9Туристско-рекреационное проектирование ч 2 т 4-9
Туристско-рекреационное проектирование ч 2 т 4-9
 
Agile на Смертельном Марше
Agile на Смертельном МаршеAgile на Смертельном Марше
Agile на Смертельном Марше
 
Ad 2009 - agile в кризис
Ad 2009 - agile в кризисAd 2009 - agile в кризис
Ad 2009 - agile в кризис
 
Skykillers
SkykillersSkykillers
Skykillers
 
Продуктовый подход в заказной разработке
Продуктовый подход в заказной разработкеПродуктовый подход в заказной разработке
Продуктовый подход в заказной разработке
 
Quality Principles
Quality PrinciplesQuality Principles
Quality Principles
 
Интернет-проект. Откуда берутся и куда деваются деньги.
Интернет-проект. Откуда берутся и куда деваются деньги.Интернет-проект. Откуда берутся и куда деваются деньги.
Интернет-проект. Откуда берутся и куда деваются деньги.
 
Kioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опроса
Kioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опросаKioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опроса
Kioda lab 2017 Николай Канарейкин Обзор инструментов по результатам блиц-опроса
 
PMIufa_2014-03-20
PMIufa_2014-03-20PMIufa_2014-03-20
PMIufa_2014-03-20
 
Тестирование без требований
Тестирование без требованийТестирование без требований
Тестирование без требований
 
Quality Principles
Quality PrinciplesQuality Principles
Quality Principles
 

Риски в разработке ПО связанные с требованиями

  • 1. Риски в разработке ПО связанные с требованиями
  • 2. Рамки проекта 2 Возможные решения
  • 3. Возможности vs. Качество Качество – это свойство продукта или услуги, характеризующее его соответствие цели, ради которой создается, или, другими словами, соответствие предъявляемым требованиям, так, чтобы удовлетворить потребителя, и, в тоже время, гарантировать, что нужды всех заинтересованных сторон учтены. 3
  • 4. Что такое риски? Риск проекта - это неопределенное событие или условие, которое будет иметь положительное или отрицательное воздействие как минимум на одну цель проекта, если оно произойдет. (PMBOK) 4
  • 5. Бонус - «Популярные» риски 5 Трамвай 'Аннушка' на Патриарших прудах
  • 6. Бонус - Как победить трамвай? 6 Делайте остановки Дублируйте критические функции и органы
  • 7. Некоторые другие события Поступил запрос на изменение требований в ходе работы; Обнаружена ошибка в оценках; Продукт не прошел приемку у Заказчика. 7
  • 8. Структура идентификации риска Описание события. Последствия влияния события на проект. Причины возникновения. Методы увеличения/уменьшения влияния. 8
  • 10. Запрос на изменение Описание события: Поступил запрос на изменение в ходе работы Последствия влияния события на проект: 10
  • 11. Запрос на изменение От чего зависят последствия возникновения запроса на изменение: Размер и сложность запроса; Его влияния на ход проекта; Процедуры управления изменениями; Договора/контракта; 11
  • 12. Запрос на изменение Причины возникновения: На стороне Заказчика: Изменения внешних факторов (законодательство, конкуренция); Изменение бизнеса; еще ? На стороне Разработчика: Низкое качество требований; Пропущенные требования; Пропущенные заинтересованные стороны; Низкое качество дизайна и прототипов; еще? 12
  • 13. Запрос на изменение Методы увеличения/уменьшения влияния: «Правильные люди» на стороне Заказчика и Разработчика участвующие в процессе проектирования; Проверенные методы улучшения качества проектной документации; Работающие процедуры управления изменениями, в т.ч. в контрактах; Разбиение проекта на фазы. 13
  • 15. Обнаружена ошибка в оценках Описание события: Обнаружена ошибка в оценках Последствия влияния события на проект: 15
  • 16. Обнаружена ошибка в оценках Причины возникновения: Недостаточная квалификация людей дававших оценки; Оценки даны на основе неточных данных: Низкое качество информации на основе которой давалась оценка; Использована новая технология/среда разработки; еще? 16
  • 17. Обнаружена ошибка в оценках Методы увеличения/уменьшения влияния: «Правильные люди» в команде Разработки; Улучшение качества требований и другой проектной документации; Использование проверенных методологий/инструментов; Обучение; Прототипирование. 17
  • 18. Продукт не прошел приемку 18
  • 19. Продукт не прошел приемку Описание события: Продукт не прошел приемку у Заказчика Последствия влияния события на проект: 19
  • 20. Продукт не прошел приемку Причины возникновения: Продукт был не готов к приемке (ну не успели); Сделали не то что нужно: Сменился бизнес (но у разработчика не было информации об этом); Сменились люди на стороне Заказчика (принимают не те, кто формулировал требования); Потеря в канале (аналитики не донесли требования Заказчика до разработчиков); еще? 20
  • 21. Продукт не прошел приемку Методы увеличения/уменьшения влияния: Квалифицированный ПМ (управление объемом, сроками, ожиданиями). Постоянный контакт с Заказчиком. Прототипирование, предварительные показы, регулярные встречи; «Правильные» аналитики доступные на протяжении всего срока проекта; Улучшение качества требований и другой проектной документации. 21
  • 22. Методы снижения рисков Можно выделить следующие методы увеличения/уменьшения влияния рисков связанные с требованиями (и прочей проектной документацией), а так же с процессом их разработки: Выбор правильных людей на соответствующие позиции как на стороне Разработчика, так и на стороне Заказчика. Постоянный состав людей участвующих в разработке требований на протяжении всего проекта (как минимум преемственность и взаимозаменяемость) Проверенные методы улучшения качества проектной документации; Работающие процедуры управления изменениями, в т.ч. в контрактах; Прототипы. 22
  • 23. Правильные люди Каждая проектная роль обладает своей спецификой. Очень немногим людям удается совмещать сразу несколько ролей на одном проект эффективно. К любой работе нужно иметь способности/склонности. Нужно учиться. Опыт важен. Экспертиза vs. Практика. 23
  • 24. Улучшение качества документов Чем раньше удается устранить ошибки, тем дешевле их исправление 24
  • 25. Виды проверок Формальные и неформальные проверки Проверки требований коллегами аналитиками (peer review) Согласования требований с представителями заинтересованных сторон Согласования требований с разработчиками/проектировщиками. 25
  • 26. Работающие процедуры Управление требованиями Управление изменениями Инструменты 26
  • 27. Прототипы Преимущества: Визуализация; Динамика. Опасности: Завышенные ожидания Заказчика; Отвлечение от важных аспектов в сторону несущественных мелочей. 27
  • 28. Заключение Сделать проект успешным вам помогут: Правильные люди доступные на все время проекта; Работающие процедуры; Проверки и еще раз проверки; Прототипы (а куда без них?)! 28