Требования в управлении проектами

1,264 views
1,185 views

Published on

Доклад Ильи Корнипаева в рамках Весенней школы ГУ-ВШЭ 2009 «Software Project Management».

Published in: Business
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,264
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
48
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • This survey was conducted by Jama Software in partnership with Ravenflow. The report includes data collected from 203 survey participants from April 15 to May 9, 2008. по всему миру.
  • Требования в управлении проектами

    1. 1. Требования в управлении проектами<br />
    2. 2. В чем проблема?<br />Процент успешных проектов<br />Запланировано гораздо <br /> больше чем удалось сделать <br />Превышения бюджета<br />Выполнена ненужная работа<br />2<br />26% Успешных<br />46% Частично успешных<br />28% Неудачны (провалы) <br />69% Превышение бюджета<br />79% Превышение сроков<br />$75bn Стоимость провальных проектов<br />$22bn Стоимость превышения бюджета<br />45% Функций систем никогда не используется !!!<br />Источник: The Standish Group 1999<br />
    3. 3. Причины провалов<br />Неполные или неоднозначные требования<br />Низкое вовлечение пользователей в проект<br />Недостаточно ресурсов<br />Нереалистичные ожидания<br />Недостаточная поддержка руководства<br />Постоянно изменяющиеся, нестабильные требования<br />Плохое планирование<br />Проект перестает быть нужным<br />Размер и сложность проекта<br />3<br />Часть причин провалов проектов связаны с управлением проектом, часть причин связано с требованиями, но ни одна из причин не является технической<br />Источник: The Standish Group 1999<br />
    4. 4. Свежая статистика<br />Как часто проект или продукт выпускается вовремя в рамках бюджета, и тем набором возможностей, который был изначально запланирован?<br />4<br />Источник: The 2008 State of Requirements Management Report, © 2008 Jama Software <br />
    5. 5. Свежая статистика<br />Что является причиной неудачных проектов?<br />5<br />Источник: The 2008 State of Requirements Management Report, © 2008 Jama Software <br />
    6. 6. Три ключевых фактора<br />6<br />
    7. 7. Требования и качество<br />Качество – это свойство продукта или услуги, характеризующее его соответствие цели, ради которой создается, или, другими словами, соответствие предъявляемым требованиям, так, чтобы удовлетворить потребителя, и, в тоже время, гарантировать, что нужды всех заинтересованных сторон учтены. <br />7<br />
    8. 8. Заинтересованные стороны<br /> Государства, организации, отдельные люди или группы людей, а так же системы, которые могут прямо или косвенно быть заинтересованы в результатах проекта, или если результаты проекта или ход его выполнения прямо или косвенно влияет на них (как положительно так и отрицательно).<br />8<br />
    9. 9. Управление разработкой требований – сложное дело<br />В отсутствии должного опыта люди, не понимают какой объем работы нужно выполнить, чтобы разработать требования<br />Люди не понимают различия между требованиями заинтересованных сторон и системными требованиями<br />Процесс управления требованиями зависит от типа организации<br />Сложно оценить какой объем работы из запланированного выполнен<br />Наличие большого количества изменений<br />9<br />
    10. 10. Сколько времени это занимает?<br />Очень важно правильно оценить сколько времени займет разработка требований. <br />Разработка требований в календарных днях обычно занимает больше времени чем трудозатраты в рабочих днях из за согласований и других организационных моментов. <br />Работа с требованиями может составить 25% длительности проекта и 5% от суммарных трудозатрат.<br />10<br />
    11. 11. Область проблем и область решений <br />11<br />запросы<br />проблемы<br />инициативы <br />идеи<br />Область возможных решений<br />Область проблем<br />Требования<br />заинтересованных сторон,<br />Бизнес требования<br />Техническое задание,<br />Системные требования<br />
    12. 12. Когда нет понимания решаемых проблем<br />невозможность определить рамки системы, и понять, что нужно включать, а что нет;<br />преобладание разработчиков и исполнителей в дискуссиях о системе, поскольку единственное описание, существующее для системы, описывает ее в терминах реализации;<br />невозможность нахождения наилучшего решения, из-за ограничений свободы в выборе решения.<br />12<br />
    13. 13. Типы требований<br />В рамках одного уровня проектной документации описывается: <br />Возможности – это то, что должно быть достигнуто, или те функции которыми должна обладать система;<br />Ограничения – это то, что при этом будет препятствовать или ограничивать достижению/обеспечению требуемых возможностей.<br />13<br />
    14. 14. Основные типы организаций <br />Заказчики – организации, покупающие системы и использующие их для своих собственных нужд. <br />Поставщики (Интеграторы) – организации, разрабатывающие (или адаптирующие) системы на заказ для конечных заказчиков, или для других поставщиков или продуктовых компаний. <br />Продуктовые компании – организации, которые разрабатывают и продают готовые продукты. <br />14<br />
    15. 15. Три ключевых аспекта <br />Планирование<br />Контроль хода выполнение работы<br />Управление изменениями<br />15<br />
    16. 16. Планирование<br />Для Заказчиков и Продуктовых компаний процесс собора и согласования требований обычно начинается с достаточно неформальной постановки задачи.<br />Для Поставщиков процесс работы с требованиями обычно начинается с тендера<br />16<br />
    17. 17. Заказчик - планирование<br />Концепция, Спонсор<br />Определение полного списка заинтересованных сторон<br />Сбор требований заинтересованных сторон (возможности и ограничения), способы сбора требований<br />Атрибуты требований<br />Проверки и согласования<br />17<br />
    18. 18. Продуктовая компания – особенности планирования <br />Ключевые мотивирующие факторы – конкуренция и прибыль<br />Заказчик и Поставщик в рамках одной организации (характерно так же для In-House разработки)<br />Заинтересованные стороны, спонсор и концепция обычно не вызывают вопросов – Маркетинг и Продажи<br />Несколько версий и модификаций одного продукта<br />18<br />
    19. 19. Несколько версий и модификаций одного продукта<br />19<br /><ul><li>Базовый набор требований
    20. 20. Требования характерные для версии
    21. 21. Требования характерные для модификации </li></li></ul><li>Поставщик - Планирование<br />Анализ полученных от Заказчика требований<br />Вопросы и предложения Заказчику<br />Оценка требований Заказчика<br />Подготовка Предложения<br />20<br /> Ваши вопросы и предложения могут попасть к вашим конкурентам! В этой ситуации вы можете:<br /><ul><li>полностью проигнорировать проблему;
    22. 22. сделать какое-то предположение (допущение), позволяющее устранить проблему, и, зафиксировав его документально, двигаться дальше;
    23. 23. принять решение, что, независимо от последствий, необходимо задать вопрос Заказчику.</li></li></ul><li>Поставщик - Планирование<br />Необходимо сохранять все тендерные материалы, включая все, вопросы которые были не заданы, предположения, которые были сделаны, и т.п.<br />Большой срок между проведением тендера и заключением контракта<br />Разные команды на тендере и на реальном проекте <br />Субподрядчики <br />После заключение контракта: <br />Уточнение вопросов и проблемных требований<br />Планирование разработки детальных требований<br />Определение приоритетов и распределение по фазам<br />21<br />
    24. 24. Контроль разработки требований – общая структура<br />Определение структуры спецификации требований;<br />Определение атрибутов и статусов каждого из требований;<br />Определение процесса рецензирования требований в соответствии с перечнем критериев рецензирования.<br />22<br />
    25. 25. Поставщик – контроль выполнения работ<br />Анализ и оценка исходных требований<br />Моделирование предлагаемого решения<br />После заключения контракта:<br />Контроль в соответствии с планом проекта<br />Контроль субподрядчиков <br />23<br />
    26. 26. Будьте готовы к изменениям<br /> Причины возникновения изменений:<br />Уточнения требований от представителей заинтересованных сторон в процессе сбора и работы с требования а также на этапе согласования;<br />изменение бизнеса или внешних условий;<br />конкуренция;<br />разработчики.<br />24<br />
    27. 27. Заказчик – контроль изменений<br /> Разная степень формализации подхода к изменениям в зависимости от этапа реализации проекта:<br />Внесение изменений без контроля<br />Предупреждение о внесении изменений коллег<br />Формальный процесс предложения, утверждения и внесения изменений<br />25<br />
    28. 28. Поставщик – контроль изменений<br />Источники изменений:<br />заказчик;<br />поставщики (субподрядчики);<br />внутренние источники.<br />Объекты контроля изменений:<br />входящие требования;<br />требования для поставщиков и субподрядчиков (исходящие требования);<br />допущения, предположения и интерпретации, сделанные командой, разрабатывающей коммерческое предложение.<br />26<br />
    29. 29. Важность проверок<br />Чем раньше удается устранить ошибки, тем больше удается сэкономить. <br />27<br />
    30. 30. Виды проверок <br />Формальные и неформальные проверки<br />Проверки требований коллегами аналитиками (peer review)<br />Согласования требований с представителями заинтересованных сторон<br />Согласования требований с разработчиками/проектировщиками. <br />28<br />
    31. 31. Требования и управление проектом<br />Планирование<br />Структура требований помогает получить план работ <br />Контроль за ходом разработки требований<br />Наполнение структуры<br />Статусы и атрибуты требований<br />Наличие связей определенного типа<br />Изменения требований<br />Связи играют ключевую роль в анализе влияния изменений<br />Процедуры внесения изменений не одинаковы на разных этапах проекта<br />29<br />
    32. 32. Заключение<br />Требования имеют огромное влияние на успех проекта<br />Проверенные методы и высокая дисциплина при разработке требований позволяет получить надежную основу для разработки системы<br />Знания, аккуратность, опыт и командная работа позволят вам «почувствовать разницу»<br />30<br />
    33. 33. Спасибо!<br />Вопросы и ответы<br />31<br />

    ×