Планирование для начинающих. Методическое пособие. Теория

2.6 Сбор требований

Давайте предположим. У вас появилась какая-то идея, которая в будущем должна стать проектом. вы создали устав проекта, вы написали на коленке всё что было у вас в голове об этом проекте и теперь готовы к нему приступать, но как вы видите у вас нет чёткой картинки того что должно произойти, как этот проект будет развиваться со временем и какой результат он должен в итоге дать. Для этого и формируются требования, которые фиксируются и документируются. Об этом я вам сейчас подробнее расскажу поэтому по традиции я вам желаю настроиться на работу, погрузиться в сегодняшний урок, и вы увидите, как много нового появится в вашем багаже знаний. Поэтому я с удовольствием начинаю рассказывать и надеюсь вы с удовольствием будете меня слушать.

СБОР ТРЕБОВАНИЙ

– Процесс: Сбор требований

– Группа процессов: Планирование

– Область знаний: Управление содержанием

Требования – это то, что нужно заинтересованным сторонам от проекта или продукта. Помните, что работа не должна включаться в проект только потому, что кто-то этого хочет. Вместо этого требования должны касаться решения проблем или достижения целей, изложенных в уставе проекта. Требования могут включать запросы о планировании и управлении работой.

Требования могут включать возможности, которые заинтересованные стороны хотели бы видеть в продукте, такие как программное приложение, которое позволяет нескольким пользователям получать доступ к нему одновременно.

– Качество: Прописанные параметры качества для чего либо, которые нельзя нарушать.

– Бизнеспроцессы: «вы должны отслеживать и сообщать о расходах проекта таким образом.»

– Соответствие: «по закону, мы должны соответствовать этому стандарту безопасности.»

– Управление проектами: «мы требуем, чтобы процедура управления рисками X использовалась в проекте.»

Процесс сбора требований ищет все требования, а не только те, которые связаны с продуктом проекта. Этот процесс имеет решающее значение для успеха проекта, так как пропущенное требование может означать значительные изменения и конфликты на протяжении оставшейся части проекта – и даже провал проекта.

Процесс сбора требований ищет все требования, а не только те, которые связаны с продуктом проекта. Этот процесс имеет решающее значение для успеха проекта, так как пропущенное требование может означать значительные изменения и конфликты на протяжении оставшейся части проекта – и даже провал проекта.

Усилия по сбору требований также включают в себя выявление ожиданий заинтересованных сторон – их убеждений или ментальных представлений о том, как получится проект – и перевод этих ожиданий в требования по мере необходимости. Сбор требований могут включать использование различных методов (описанных далее). Менеджер проекта должен выбрать методы, наиболее подходящие для проекта и его заинтересованных сторон. Обратите внимание, что многие из этих методов могут также использоваться в других усилиях по сбору данных, таких как выявление рисков в процессе управления рисками.

Для сбора требований можно использовать следующие инструменты и методы.

МОЗГОВОЙ ШТУРМ. Цель мозгового штурма заключается не столько в том, чтобы заставить людей поделиться своими мыслями по теме, сколько в том, чтобы побудить участников развивать идеи друг друга.

Мозговой штурм это не общее собрание, на котором возможно обсудить какие-то идеи, это конкретно направленное совещание, на котором люди обсуждают конкретную тему и выдают какие-то решения, которые в будущем будут документироваться.

ИНТЕРВЬЮ. Команда или руководитель проекта проводят собеседование с заинтересованными сторонами проекта, чтобы выяснить их требования к конкретному элементу продукта или к проектной работе, или к проекту в целом.

ФОКУСГРУППЫ. Метод фокусгрупп помогает получить мнения и требования к продукту или аспекту проекта от заинтересованных сторон и экспертов по предметной области.

БЕНЧМАРКИНГ. Бенчмаркинг фокусируется на измерении эффективности организаций по сравнению с другими организациями в той же отрасли.

ГОЛОСОВАНИЕ. Голосование обычно используется для принятия решений в группе

АНАЛИЗ РЕШЕНИЙ НА ОСНОВЕ МНОЖЕСТВА КРИТЕРИЕВ. С помощью этого метода заинтересованные стороны количественно оценивают требования, используя матрицу принятия решений, основанную на таких факторах, как ожидаемые уровни риска, оценки времени и оценки затрат и выгод.

ДИАГРАММА СХОДСТВА. В этом методе идеи, порожденные любыми другими методами сбора требований, сгруппированы по сходствам. Каждой группе требований присваивается название. Такая сортировка облегчает просмотр дополнительных областей содержания (или рисков), которые не были определены.

Немного о диаграмме сходства. Я вам объясню, что это такое. Предположим, у нас есть какой-то определённый проект и у этого проекта есть ряд требований. Например, проект создания библиотеки. У нас есть такая зона, как хранение книг, какие книги у нас там будут содержаться, какие будут использованы компьютеры, в каких помещениях всё это будет находиться и для каких посетителей библиотека. Вот смотрите у нас есть четыре критерия которые нам нужно заполнить это и называется диаграмма требования, то есть на основе собранных требований, собранных идей мы расфасовываем эту информацию, в ту зону, которой она соответствует вот как на примере диаграммы.

АССОЦИАТИВНАЯ КАРТА. Ментальная карта это диаграмма идей или заметок, помогающая генерировать, классифицировать или записывать информацию.

МЕТОД НОМИНАЛЬНЫХ ГРУПП. Задается вопрос или проблема, все участники встречи записывают, а затем делятся своими идеями, группа обсуждает, что было поделено, а затем идеи ранжируются на основе того, какие идеи являются наиболее полезными.

НАБЛЮДЕНИЯ/ОБСУЖДЕНИЯ. Этот метод обычно включает в себя наблюдение за потенциальным пользователем продукта на работе и, в некоторых случаях, участие в работе, чтобы помочь определить требования.

ФАСИЛИТАЦИЯ. Этот метод использует консенсусный подход, который позволяет достичь общего согласия в отношении решения.

Простыми словами это такой процесс, в котором заинтересованные стороны приходят к общему мнению, то есть мы с вами прекрасно понимаем, что на нашем проекте много заинтересованных лиц с разным рангом принятия решения с разным рангом голоса, но нам нужно учесть мнение всех. Конечно сделать это невозможно и для этого есть такой процесс как фасилитация где заинтересованные стороны с различными точками зрения приходят к общему мнению.

КОНТЕКСТНАЯ ДИАГРАММА. Она показывает границы содержания продукта, выделяя продукт и его взаимодействие с людьми, процессами или системами.

ПРОТОТИП. Прототип это модель предлагаемого продукта, которая представляется заинтересованным сторонам для обратной связи. Прототип может обновляться несколько раз для учета отзывов заинтересованных сторон до тех пор, пока требования к продукту не будут утверждены.

Конечно же это не все инструменты для сбора требований. Для достижения лучшего результата мы можем использовать что-то своё. Но эти методы сбора требований наиболее распространённые и наиболее часто используется в различных организациях на различных проектах.

Теперь в двух словах про документирование требований. Как я уже говорил вначале, после сбора и доработки всех требований они должны быть задокументированы. Вы просто представьте, какое количество информации и требований вы соберёте за тот момент, когда будете формировать документ и конечно же всё это должно быть документировано.

Документация по требованиям может содержать различные типы информации, но одна вещь, которая должна быть включена это критерии приемки.

Требования должны быть описаны таким образом, чтобы связанные с ними результаты можно было протестировать или измерить в соответствии с требованиями в процессе Подтверждения содержания для подтверждения приемлемости результатов.

Требования задокументированы, теперь нам надо отслеживать эти требования. Для этого формируется Матрица отслеживания требований.

Матрица отслеживания требований, еще один результат процесса сбора требований, помогает связать требования с целями и/или другими требованиями для обеспечения достижения стратегических целей.

Матрица используется на протяжении всего проекта при анализе предлагаемых изменений в содержании проекта или продукта. Такая информация, как идентификационные номера требований, источник каждого требования, кто назначен для управления требованием, и статус требования должны быть задокументированы в матрице отслеживания требований.