Менеджер проекта может использовать управление риском, чтобы выяснить условия, которые могут повлечь неблагоприятные последствия для проекта. Представьте себе менеджера нового проекта, озабоченного привлечением нужных пользователей в выявление требований. Если он умен, то сообразит, что это условие представляет собой элемент риска, и внесет его в список, оценив его вероятность и влияние, основываясь на предыдущем опыте. Если по прошествии некоторого времени пользователи все еще не вовлечены в работу над проектом, риск возрастет и, может быть, даже уже угрожает успеху проекта. Мне удавалось убеждать менеджеров отложить проект, когда не удавалось привлечь достаточно представителей пользователей, приводя такой аргумент; мы не должны впустую тратить деньги компании на заранее обреченный проект.
Периодическое трассирование рисков позволяет менеджеру проекта знать масштабы угрозы от выявленных областей риска. Сообщайте о недостаточно контролируемом риске вышестоящему руководству, которое может принять решение исправить его либо продолжать работу, несмотря на риск. Управление риском помогает вам держать глаза открытыми и принимать обоснованные решения, даже если вам не удается контролировать каждую неприятность, с которой может столкнуться ваш проект.
| Что дальше? · Определите несколько угрожающих вашему текущему проекту рисков, связанных с требованиями. Не обозначайте текущие проблемы как факторы риска, отмечайте только то, что еще не случилось. Документируйте риски, используя шаблон на рис. 23-2. Предложите по крайней мере один возможный метод смятения для каждого риска. · Проведите «мозговой штурм» риска с ключевыми лицами, заинтересованными в проекте. Выявите как можно больше факторов риска, связанных с требованиями. Оцените каждый фактор по вероятности его реализации и относительному влиянию и перемножьте эти величины для вычисления подверженности этому риску. Отсортируйте список по уменьшению подверженности, чтобы определить пять самых серьезных факторов риска, связанных с требованиями. Назначьте для каждого из них ответственного за исполнение действий по смягчению. |
|
|
Эпилог
Нет ничего более важного для успеха проекта по разработке ПО, чем понимание того, что проблемы необходимо решать. Требования составляют фундамент успеха. Если команде разработчиков и клиентам не удастся достичь соглашения по поводу возможностей и характеристик продукта, то вероятнее всего вы получите такой результат, которого все мы хотели бы избежать. Если применяемые вами сегодня приемы разработки требований не так эффективны, как вам бы хотелось, избирательно и вдумчиво воспользуйтесь теми методами, представленными в этой книге, которые, как вы считаете, помогут вам. Дня успешной разработки требований необходимо:
· вовлекать представителей клиентов как можно раньше и шире;
· разрабатывать требования итеративно и поступательно;
· представлять требования различными способами, чтобы удостовериться, что все понимают их;
· убедиться, что все группы заинтересованных лиц считают требования полными и корректными;
· контролировать внесение изменений в требования.
Изменять способы организации разработки требований трудно. Также трудно признать, что применяемые сегодня методы не работают так хорошо, как хотелось бы, и просчитать, что следует изменить. А как сложно выкроить время, чтобы обучиться новым технологиям, разработать процесс улучшения, опробовать и настроить его, а потом еще и внедрить его на фирме. И какие аргументы вам придется искать, чтобы убедить всех заинтересованных лиц в необходимости этих изменений. Однако, если вы не измените способы работы, нечего надеяться, что текущий проект окажется лучше предыдущего.
|
|
Успех процесса улучшения разработки ПО зависит от многих причин:
· выявите болевые точки в организации;
· сфокусируйте ваше внимание на нескольких проблемах за раз;
· установите ясные цели и разработайте план действий для улучшения процесса;
· выявите связанные с людьми и корпоративной культурой факторы, которые будут затронуты изменениями;
· убедите топ-менеджера, что процесс улучшений следует рассматривать как стратегические инвестиции в успешный бизнес.
Держите в памяти все эти принципы, и когда будете строить дорожную карту реорганизации процесса разработки требований, и когда начнете ваше путешествие. Выбирайте такие приемы, которые подходят для вашей организации и соответствуют духу вашей команды. Если вы активно применяете хорошие приемы и полагаетесь на здравый смысл, вам удастся значительно улучшить процесс обработки требований и получить все преимущества и выгоды, которые за этим следуют. И запомните, что без прекрасных требований разрабатываемый продукт выглядит, как коробка с шоколадом: вы не знаете, что обнаружите, открыв ее.