Дэйв, менеджер проекта Chemical Tracking System для Contoso Pharmaceuticals, встретился с ведущим программистом проекта Хелен и ведущим тестировщиком Рамешем. Все выразили радость по поводу новой совместной работы, но вспомнили и о проблемах, с которыми столкнулись в прошлом проекте под названием Pharm-Simulator.
«Помните, как мы узнали, что пользователи терпеть не могут интерфейс Pharm-Simulator только после бета-тестирования? — спросила Хелен. — У нас ушло четыре недели на то, чтобы переделать и заново протестировать его. Не хотела бы я еще раз пережить тот ужасный март».
«Это было невесело, — согласился Дэйв. — Также раздражает, что пользователи, с которыми мы беседовали, клялись, что им нужно много функций, но до сих пор с ними никто не работает. На программирование функции моделирования взаимодействия препаратов потребовалось в три раза больше времени, чем мы ожидали, и в конце концов мы все равно ее исключили. Какая трата времени!»
«Работа над Pharm-Simulator действительно была гонкой, и нам не хватило времени, чтобы написать детальные требования, — вспомнил Рамеш. — В половине случаев тестировщикам приходилось спрашивать у программиста, как должна работать та или иная функция, чтобы иметь возможность ее протестировать. Затем оказывалось, что некоторые функции, реализованные программистами, все равно не делали того, что желали пользователи».
«Меня бесило, что менеджер, запросившая Pharm-Simulator, отказалась обсуждать требования, даже не взглянув на них, — добавил Дэйв. — А потом помните постоянный поток запросов на изменения от людей из ее отдела? Неудивительно, что проект удалось завершить с опозданием на пять месяцев, и стоил он почти в два раза дороже, чем планировалось. Если такое произойдет еще раз, меня наверно уволят».
У Рамеша родилось предложение, «Может быть, нам нужно составить список проблем, возникших при работе над Pharm-Simulator, чтобы попытаться избежать их сейчас. Я читал статью по управлению риском при создании ПО, где говорилось, что мы должны выявлять риск с самого начала и выяснять, как предотвратить причинение им вреда проекту».
«Не уверен, что стоит, — возразил Дэйв. — Мы многому научились на опыте Pharm-Simulator, так что, скорее всего, эти проблемы не возникнут снова. Этот проект — не настолько крупный, чтобы требовалось управлять рисками. Если мы выпишем все проблемы, возможные при разработке Chemical Tracking System, это будет выглядеть, как будто я не знаю, как вести проект. Я не хочу, чтобы в этом проекте кто-то думал о плохом. Мы должны планировать успех!».
Как показывают последние высказывания Дэйва, программные инженеры — вечные оптимисты. Мы часто ожидаем, что наш следующий проект пройдет гладко, несмотря на большое количество проблем в прошлых проектах. Реальность такова, что десятки потенциальных ловушек могут замедлить или пустить под откос проект по разработке ПО. Вопреки убеждениям Дэйва, менеджеры проектов по разработке ПО должны выявлять риск и управлять им, начиная с факторов, связанных с требованиями.
Риск (risk) — это условие, которое может повлечь какие-либо потери или другим способом поставить под угрозу успех проекта. Это условие еще не породило проблему, и вы хотите, чтобы так оно и оставалось. Эти потенциальные проблемы могут оказать неблагоприятный воздействия на стоимость, сроки, технический успех, качество продукта или эффективность работы команды. Управление риском — лучшая практика индустрии ПО (Brown, 1996) — это процесс выявления, оценки и управления риском до того, как он нанесет ущерб вашему проекту. Если что-либо нехорошее уже произошло с вашим проектом, то это — проблема, а не риск. Решайте текущие проблемы и вопросы, постоянно контролируя статус проекта и процессы введения поправок.
Так как никто не может уверенно предсказывать будущее, управление риском — это способ минимизации вероятности потенциальных проблем или ущерба от них. Управление риском означает работу над потенциальной опасностью до того, как она перейдет в кризисную фазу. Это улучшает вероятность успеха проекта и уменьшает финансовые или другие последствия риска, которого удастся избежать. Риск, лежащий вне сферы компетенции команды, следует передать руководству соответствующего уровня.
Поскольку требования так важны в проектах по созданию ПО, предусмотрительный менеджер уже на ранних стадиях проекта выявит риск, связанный с требованиями, и будет достаточно агрессивно контролировать его. Распространенные факторы риска, связанные с требованиями, включают неверное понимание требований, недостаточное вовлечение пользователей, неточности или изменения в масштабах и целях проекта, и постоянно изменяющиеся требования. Менеджеры проектов могут управлять риском, связанным с требованиями, только в сотрудничестве с клиентами или их представителями. Совместное документирование факторов риска, связанных с требованиями и планирование действий по уменьшению их последствий укрепляет партнерство клиента и разработчика, о котором говорилось в главе 2.
Просто знать о факторах риска недостаточно, чтобы они исчезли, и поэтому в этой главе рассказано о краткой обучающей программе для управления риском при создании ПО (Wiegers, 1998b). Позже в этой главе я также перечислю несколько факторов риска, которые могут поднять свои уродливые головы во время конструирования требований. Используйте эту информацию, чтобы атаковать риск, связанный с требованиями, до того, как он нападет на ваш проект.