4. Анализ компромиссов и рисков программного проекта
Управление рисками.
Управление рисками
Если какая-нибудь неприятность может случиться, она случится.
Закон Мерфи
Риск это проблема, которая еще не возникла, а проблема — это риск, который материализовался.
Причиной возникновения рисков являются неопределенности, существующие в каждом проекте.
Риски могут быть “известные”- те, которые определены, оценены, для которых возможно планирование.
Риски “неизвестные” – те, которые не идентифицированы и не могут быть спрогнозированы.
Девиз разработчиков программного обеспечения из Microsoft:
«Мы не боремся с рисками —
мы ими управляем».
Управление рисками – это процессы, связанные с идентификацией, анализом рисков и принятием решений, которые включают максимизацию положительных и минимизацию отрицательных последствий наступления рисковых событий.
Процедуры управления рисками.
В стандарте Project Management Body of Knowledge, принятом в 2000 году, описаны шесть процедур управления рисками:
Планирование управления рисками – выбор подходов и планирование деятельности по управлению рисками проекта.
Идентификация рисков – определение рисков, способных повлиять на проект, и документирование их характеристик.
Качественная оценка рисков – качественный анализ рисков и условий их возникновения с целью определения их влияния на успех проекта.
Количественная оценка – количественный анализ вероятности возникновения и влияния последствий рисков на проект.
Планирование реагирования на риски – определение процедур и методов по ослаблению отрицательных последствий рисковых событий и использованию возможных преимуществ.
Мониторинг и контроль рисков - мониторинг рисков, определение остающихся рисков, выполнение плана управления рисками проекта и оценка эффективности действий по минимизации рисков.
Треугольник компромиссов.
Треугольник компромиссов
Часто бывает очень полезно изобразить эту зависимость заказчику в виде треугольника компромиссов:
После достижения утвержденного равновесия с заказчиком, т.е. на запрашиваемые возможности вы назвали и зафиксировали сроки и смету, любое изменение на одной из сторон треугольника влечет изменение на двух оставшихся.
Такой подход служит удобным инструментом для нахождения компромиссов с заказчиком и поможет объяснить суть имеющихся ограничений.
Целевой коридор обозначает приемлемый срок завершения проекта
Соотношение между сроками и затратами
Соотношение между качеством и затратами
Соотношение между сроками и качеством
Три зоны взаимозависимости между сроками и качеством:
Первый сектор характеризуется давлением сроков, что приводит к соответствующему снижению качества.
Во втором секторе обстоятельства идеальны, а значит, и качество соответствующее.
В третьем секторе мы наблюдаем снижение качества, поскольку из-за различного рода задержек проект не осуществляется с полной отдачей. Здесь очевидна недостаточность давления, оказываемого сроками.
Работа с заказчиком.
Необходимо не просто удовлетворить заказчика, а следует в той или иной форме предоставить ему качество, которого он сам не ожидал, то есть обеспечить себе потенциал «будущих заказов».
Такое качество называется дополнительным и находит свое отражение в формулировке: Make the customer even happier than happy.
Сбор требований
Основная работа ведется с заказчиком системы и ее будущими пользователями.
Цель этапа — точно определить функции продукта и способы его интеграции в существующие процессы.
Качественное выполнение работ на этом этапе гарантирует то, что будущий продукт будет соответствовать ожиданиям заказчика. Четкая расстановка приоритетов обеспечивает реализацию наиболее востребованной функциональности и исключение второстепенной/невостребованной функциональности, что сэкономит бюджет и сроки.
Этап анализа проблемы.
Выявление заинтересованных лиц и пользователей.
Вопросы
Кто пользователь системы?
Кто заказчик (экономический покупатель)?
На кого еще окажут влияние результаты работы?
Кто будет оценивать и принимать систему после установки?
Существуют ли другие пользователи (внешние, внутренние), чьи потребности нужно учесть?
Кто будет заниматься сопровождением системы?
Не забыли ли мы кого-нибудь?
На каждого выявленного пользователя и заинтересованное лицо составляется описание (см. табл)
Интревью
• Преимущество - интерактивность, предоставляющая возможность внесения дополнений или доработки вопросов в зависимости от полученных ответов.
• Хороший способ собрать требования по удобству использования системы, надежности, производительности и удобству сопровождения.
• Обычно заказчики не упоминают эти нефункциональные требования, пока их явно не спросить об этом.
Советы
• При выборе заинтересованных лиц для интервью убедитесь, что Вы понимаете, какую именно группу заинтересованных лиц они представляют.
• Напишите первоначальный список вопросов.
• Проговорите ответы своими словами, чтобы убедиться, что Вы понимаете смысл.
• Вы не должны предлагать ответ на Ваш вопрос. Например: Какое время реакции системы Вы ожидаете? Три секунды?
• Не соединяйте несколько вопросов в один. Например: Необходимо ли Вам печатать ответ, отправлять его по электронной почте и факсу? Быть может, пользователю нужна только возможность печати отчета и отправки его по электронной почте, но нет необходимости в факсе.
• На этом этапе, не спрашивайте о деталях реализации. Например: Вы предпочитаете list-box или radio-buttons для выбора метода оплаты?
• Не используйте слишком длинные и сложные вопросы.
• Не задавайте следующий вопрос, если еще не получен ответ на предыдущий.
• Если ответ непонятен, задайте дополнительные вопросы, даже если их нет в сценарии интервью.
• Когда пользователи отклоняются от темы при ответе на заданный вопрос, не перебивайте их. Позвольте им высказать свои мысли, на какую бы тему они не размышляли. Затем, если Вы не получили ответа на изначальный вопрос, задайте его снова.
• Фиксируйте каждое упомянутое пользователем требование, даже если в настоящий момент оно кажется неуместным.
• Спросите пользователей о дополнительной информации (экранные формы системы).
• При разговоре с заказчиками не говорите о том, будет ли их требование выполнено или нет. Это будет решено позже.
• В конце разговора спросите вопрос для получения дополнительной информации, например «Что еще я должен знать?».
• Выясните у заинтересованного лица приоритет для каждого требования.
• Делайте примечания или используйте записывающее устройство.
• Вопросы должны быть контекстно-свободными, т.е. не содержать желаемый ответ.
• Все требования заносятся в «архив требований», т.е. должны документироваться.
Анкетирование
• Анкеты наиболее полезны, когда есть возможность задать одни и те же вопросы многим заинтересованным лицам, и не надо задавать дополнительные вопросы в процессе беседы.
• Меньше расходов.
• Анкеты структурированные и не интерактивны, получается меньший контроль над результатами.
• Вопросы анкеты должны быть понятными и прямолинейными, потому что отсутствует возможность прояснить непонятные моменты или спорные ситуации
Семинар
• В процессе семинара по требованиям выбранная группа заинтересованных лиц встречается с проектной командой. Они собираются для интенсивных, насыщенных дискуссий.
• Системный аналитик выступает в качестве организатора семинара.
Использование сценариев
• Идея сценариев – применение визуальных или графических инструментов для иллюстрирования желаемого поведения системы.
• Организатор семинара показывает первоначальные сценарии группе.
• На основании полученных комментариев от участников, сценарии корректируются и показываются вновь.
• Корректировка сценариев – процесс многократный.
Инструменты
• Бумага, карандаш, ластик.
• Мольберт, маркеры.
• Доски, с которых можно стирать сухими средствами.
• Доски для презентаций.
• Приложения по созданию пользовательского графического интерфейса, такие как Visual Basic или Visual C++.
• Microsoft Power Point.
• Microsoft Visio.
• Графические редакторы (можно и Microsoft Paint).
• Текстовые редакторы, такие как Microsoft Word.
Матрица компромиссов.
Для эффективного достижения компромиссов в течение всего жизненного цикла проекта, рекомендуется на начальных этапах зафиксировать приоритеты факторов проекта (ресурсы, время, возможности). На один из факторов влиять в течение проекта будет практически невозможно (Фиксируется), - другой будет обладать некоторым приоритетом при разрешении компромиссов (Согласовывается) и оставшийся будет принят в соответствии с первыми двумя (Принимается).
Таблица 8
|
|
Фиксируется (Зафиксировано) |
Согласовыва-ется (Определено) |
Принимается (Корректи-руемо) |
|
Ресурсы |
|
|
|
|
Время (график) |
|
|
|
|
Возможности (набор функций) |
|
|
|
Зафиксировать приоритеты в проектной документации можно с помощью простых текстовых оборотов:
«Зафиксировав ресурсы, мы согласовываем календарный график и принимаем результирующий объем функциональности решения»
«Зафиксировав объем функциональности решения, мы согласовываем затрачиваемые ресурсы и принимаем результирующие сроки» и т.п.
В дальнейшем возврат к приоритетам может сильно помочь при нахождении компромисса внутри проектной группы
Внимание: представитель заказчика тоже является членом проектной группы.
Проявляйте гибкость – будьте готовы к переменам!
В отличие от традиционной модели управления проектами, в которой подразумевается четкая формулировка требований на начальном этапе проекта и разработка на основании ТЗ, подход компромисов основывается на принципе изменяющихся проектных условий.
Проектная группа должна быть готова к переменам и методология MSF предоставляет эффективный инструментарий для адекватной и своевременной реакции на изменения в проектной среде.
Основные риски при реализации ИТ-проекта и ИТ-проекта в образовании.
Основные риски, как правило, характерны для любых проектов и заключаются в:
несоблюдении сроков реализации проекта,
превышения стоимости и
несоблюдения параметров качества.
Основные риски реализации ИТ–проекта
Отсутствие системного аналитика для постановки задачи управления на предприятии.
Сопротивление сотрудников.
Увеличение нагрузки во время реализации проекта.
Отсутствие лидера и квалифицированной команды.
Изменение целей в ходе реализации проекта.
Барии Боэм приводит список 10 наиболее распространенных рисков программного проекта:
Дефицит специалистов.
Нереалистичные сроки и бюджет.
Реализация несоответствующей функциональности.
Разработка неправильного пользовательского интерфейса.
"Золотая сервировка", перфекционизм, ненужная оптимизация и оттачивание деталей.
Непрекращающийся поток изменений.
Нехватка информации о внешних компонентах, определяющих окружение системы или вовлеченных в интеграцию.
Недостатки в работах, выполняемых внешними (по отношению к проекту) ресурсами.
Недостаточная производительность получаемой системы.
"Разрыв" в квалификации специалистов разных областей знаний.
Таблица оценки рисков. Примеры.
Смысл описания рисков реализации ИТ-проектов заключается в том, чтобы заранее выявить эти риски и провести комплекс предупреждающих мероприятий, а не получить трудноразрешимые проблемы во время реализации проекта.
В качестве основных мероприятий, направленных на избежание возникновения этих рисковых ситуаций в ИТ–проектах, являются:
Обязательное документирование целей проекта, а также всех изменений в документации проекта, возникающих при его реализации
Повышение мотивации рядовых сотрудников путем материального стимулирования
Привлечение сторонних квалифицированных специалистов
Обучение членов команды и топ–менеджмента методологии управления проектами.
Для сбора информации о рисках могут применяться подходы:
Опрос экспертов
Мозговой штурм
Метод Дельфи
Карточки Кроуфорда
Все риски оцениваются в матрице компромиссов
Таблица 9
|
Риск |
Последствия |
Меры по предотвра-щению |
Меры по миними-зации |
|
|
|
|
|
Риск – событие. Формулировка должна быть конкретная и однозначная. Например, погодные условия.
Последствия наступления риска – что будет плохого.
Анализ и управление рисками проекта.
Меры по минимизации - действия, если событие уже произошло.
Литература: [1], [2].