Проекты рождаются как фундаментальный инструмент, используемый компаниями для получения ответов и построения решений, которые приводят к удовлетворению потребностей бизнеса и достижению целей. Вот почему проект должен быть связан с бизнес-кейсом, который был определен для удовлетворения потребности, содействия достижению бизнес-цели, устранения угрозы, использования возможности, превращения слабости в силу, улучшения навыков, расширения рынки сбыта ваших продуктов и услуг и завоевать предпочтение ваших клиентов, что в конечном итоге приведет к увеличению продаж и прибыли.
Однако сколько раз мы слышали и читали о разочарованиях организаций, которые вложили значительные финансовые ресурсы в реализацию проектов, от которых отказались, или которые были вынуждены потратить много ресурсов на переделку, адаптацию и переработку при адаптации продуктов и результатов. указанных проектов, поскольку они не удовлетворяют бизнес-потребности и ожидания пользователей, для которых они были сформулированы.
Многие из этих проектов были обречены с самого начала, потому что они не потратили достаточно времени на определение и проверку требований, на выбор заинтересованных сторон и на обеспечение приверженности и вовлечения МСП (предметный эксперт для его аббревиатуры на английском языке), которые составляют основу во время исследования, определения и проверки требований.
Давайте помнить, что МСП - это работники с высоким уровнем опыта, знаний и мастерства в работе, процессах и продуктах своих организаций. Аналогичным образом, заинтересованные стороны определяются как люди, пользователи или организации, которые заинтересованы в развитии проекта.
Исправление недостатков и двусмысленностей требований после начала этапа выполнения проекта является чрезвычайно дорогостоящим, поскольку включает в себя доработку, перепроектирование решений, продуктов и результатов; Обновление Плана и всех проектных документов, которое приводит к потреблению финансовых, человеческих и временных ресурсов, не запланированных или не предусмотренных в бюджете.
Воздействие больше в проектах, ориентированных на методологию водопада, потому что Методология предполагает, что Требования четко определены с самого начала и остаются стабильными до конкурса проектов, а после запуска проекта изменения контролируются, сокращаются и избегаются, насколько это возможно. возможно.
Требование может быть неоднозначным или плохо определенным по многим причинам:
- Неправильная идентификация Заинтересованных сторон, то есть список был неполным, они не все, что они есть, и не все Уровень компетенции Заинтересованных сторон, знания, владение бизнес-процессами их организаций не является оптимальным. подходящее. Отсутствие согласованности и приверженности Заинтересованных сторон к проекту, потому что они считают, что выгода для их собственных процессов или организации небольшая или почти нулевая. Небольшой уровень влияния на организацию для достижения приверженности членов организации, к которой они принадлежат. Неопытность бизнес-аналитика и аналитика требований. Позднее назначение руководителя проекта, который должен быть назван и авторизован в Письме о проекте во время процесса Инициирования таким образом, чтобы он мог совместно с Бизнес-аналитиком (в тех случаях, когда он существует) и Аналитиком требований просматривать документы Бизнес-обоснования, Анализ осуществимости и определение решения, выполняемые на этапе обоснования проекта, которые будут использоваться в качестве исходных данных при планировании.
Однако во всех уже упомянутых случаях ответственность ложится на менеджера проекта, который должен уделять особое внимание тому, чтобы требования были точными, чтобы команда проекта имела единую интерпретацию требований, которые были подтверждены МСП, Пользователи и Заинтересованные стороны, и были пересечены, чтобы выявить любой конфликт между ними, и если да, то прояснить его с другими Заинтересованными сторонами и МСП для разрешения конфликта.
Кроме того, менеджер проекта должен гарантировать, что каждое требование может быть идентифицировано в решении, продуктах и результатах, которые будут произведены в рамках проекта. То есть существует механизм, который позволяет «отслеживать» или контролировать каждое требование и продукт или результат, который его содержит.
В методологии Agile или Scrum изменение или переопределение требования (пользовательских историй) проще, потому что предполагается, что требования могут измениться, они не статичны, не требуется, чтобы они были четко определены с самого начала, циклы спринта больше короткие (от 2 до 4 недель), несколько требований для каждого бэклога спринта (все истории, которые могут быть полностью реализованы до конца спринта) и неоднозначное требование могут быть отложены до следующего спринта во время собрания по планированию спринта (спринт Планирование встречи).
Однако в обеих методологиях роль заинтересованных сторон и МСП по-прежнему является фундаментальной, и неправильная идентификация их и их низкая приверженность могут повлиять на эффективность проектов независимо от используемой методологии, потому что даже когда это кажется более простым в использовании. Методология Agile или Scrum для устранения неоднозначности требований будет зависеть от уровня готовности заинтересованных сторон и малого и среднего бизнеса предоставить необходимое время, информацию и бизнес-знания, необходимые для определения и уточнения требований или историй; и уровень влияния владельца продукта (менеджера проекта) на организацию и заинтересованных сторон.
