Всего за 6 руб. Купить полную версию
Каждый проект имеет подход к разработке. Это может быть подход, управляемый планом, управляемый изменениями или комбинированный, или гибридный подход. Подход к разработке влияет на то, как будут выявляться требования, а также как будет разрабатываться описание содержания и ИСР (для всего проекта сразу или на высоком уровне для всего проекта, а затем более подробно для каждого релиза).
ПЛАН УПРАВЛЕНИЯ СОДЕРЖАНИЕМ. План управления содержанием, который является основным результатом процесса планирование управления содержанием, является частью плана управления проектом, и руководитель проекта использует его для руководства проектом до закрытия. План управления содержанием, по существу, содержит три части, в которых подробно описывается, как содержание будет планироваться, выполняться и контролироваться. Он определяет следующее:
Как выполнить содержание
Какие инструменты следует использовать для планирования выполнения содержания
Как создать ИСР
Как содержание будет управляться и контролироваться в плане управления проектом
Как получить принятие результатов
План управления содержанием каждого проекта уникален, но он может охватывать темы, которые могут быть стандартизированы для компании или для типа проекта. Поэтому компании часто могут использовать шаблоны, формы и стандарты для управления содержанием. Это ценные активы для проекта. План управления содержанием может разрабатываться поэтапно или итеративно в ходе планирования проекта. Первым шагом является планирование того, как содержание будет определено.
Другим аспектом итераций является то, что более поздние части планирования проекта, могут привести к добавлению содержания в проект, тем самым изменяя план управления содержанием, описание содержания проекта и ИСР.
Давайте разберёмся с тем, что такое итерация. Это как веха, которая включает в себя набор каких-либо работ, в нашем случае это веха будет включать то, из чего будет стоять наш план управления проектами.
Так вот когда выполняется план управления проектами методом итераций, то есть постепенно добавляя какую-то информацию, которая разрабатывается в настоящее время, новая итерация может включать в себя информацию, которая будет требовать изменить что-то в предыдущей итерации и за счёт этого нам придётся изменять содержание. Процесс изменения вкратце мы с вами прошли, вы об этом прочитали и ещё прочитаете, но напомню изменения чего-либо в проекте, содержании плана, расписании неважно чего у нас осуществляется за счёт того, что заинтересованные стороны вносят какое-то изменение, обосновывает его, защищают его, документируют его и утверждают его. После этого, изменение вступает в силу и применяется уже на той или иной работе. В нашем случае это план управления проектами.
Идея создания плана управления содержанием и всех планов управления: если вы не можете планировать это, вы не можете сделать это.
Тем не менее, многие люди совершают ошибку, начиная работать над проектом до того, как продукт и содержание проекта определены и до того, как они правильно спланировали, как они будут управлять содержанием.
2.6 Сбор требований
Давайте предположим. У вас появилась какая-то идея, которая в будущем должна стать проектом. вы создали устав проекта, вы написали на коленке всё что было у вас в голове об этом проекте и теперь готовы к нему приступать, но как вы видите у вас нет чёткой картинки того что должно произойти, как этот проект будет развиваться со временем и какой результат он должен в итоге дать. Для этого и формируются требования, которые фиксируются и документируются. Об этом я вам сейчас подробнее расскажу поэтому по традиции я вам желаю настроиться на работу, погрузиться в сегодняшний урок, и вы увидите, как много нового появится в вашем багаже знаний. Поэтому я с удовольствием начинаю рассказывать и надеюсь вы с удовольствием будете меня слушать.
СБОР ТРЕБОВАНИЙ
Процесс: Сбор требований
Группа процессов: Планирование
Область знаний: Управление содержанием
Требования это то, что нужно заинтересованным сторонам от проекта или продукта. Помните, что работа не должна включаться в проект только потому, что кто-то этого хочет. Вместо этого требования должны касаться решения проблем или достижения целей, изложенных в уставе проекта. Требования могут включать запросы о планировании и управлении работой.
Требования могут включать возможности, которые заинтересованные стороны хотели бы видеть в продукте, такие как программное приложение, которое позволяет нескольким пользователям получать доступ к нему одновременно.
Качество: Прописанные параметры качества для чего либо, которые нельзя нарушать.
Бизнеспроцессы: «вы должны отслеживать и сообщать о расходах проекта таким образом.»
Соответствие: «по закону, мы должны соответствовать этому стандарту безопасности.»
Управление проектами: «мы требуем, чтобы процедура управления рисками X использовалась в проекте.»
Процесс сбора требований ищет все требования, а не только те, которые связаны с продуктом проекта. Этот процесс имеет решающее значение для успеха проекта, так как пропущенное требование может означать значительные изменения и конфликты на протяжении оставшейся части проекта и даже провал проекта.
Процесс сбора требований ищет все требования, а не только те, которые связаны с продуктом проекта. Этот процесс имеет решающее значение для успеха проекта, так как пропущенное требование может означать значительные изменения и конфликты на протяжении оставшейся части проекта и даже провал проекта.
Усилия по сбору требований также включают в себя выявление ожиданий заинтересованных сторон их убеждений или ментальных представлений о том, как получится проект и перевод этих ожиданий в требования по мере необходимости. Сбор требований могут включать использование различных методов (описанных далее). Менеджер проекта должен выбрать методы, наиболее подходящие для проекта и его заинтересованных сторон. Обратите внимание, что многие из этих методов могут также использоваться в других усилиях по сбору данных, таких как выявление рисков в процессе управления рисками.
Для сбора требований можно использовать следующие инструменты и методы.
МОЗГОВОЙ ШТУРМ. Цель мозгового штурма заключается не столько в том, чтобы заставить людей поделиться своими мыслями по теме, сколько в том, чтобы побудить участников развивать идеи друг друга.
Мозговой штурм это не общее собрание, на котором возможно обсудить какие-то идеи, это конкретно направленное совещание, на котором люди обсуждают конкретную тему и выдают какие-то решения, которые в будущем будут документироваться.
ИНТЕРВЬЮ. Команда или руководитель проекта проводят собеседование с заинтересованными сторонами проекта, чтобы выяснить их требования к конкретному элементу продукта или к проектной работе, или к проекту в целом.
ФОКУСГРУППЫ. Метод фокусгрупп помогает получить мнения и требования к продукту или аспекту проекта от заинтересованных сторон и экспертов по предметной области.
БЕНЧМАРКИНГ. Бенчмаркинг фокусируется на измерении эффективности организаций по сравнению с другими организациями в той же отрасли.
ГОЛОСОВАНИЕ. Голосование обычно используется для принятия решений в группе
АНАЛИЗ РЕШЕНИЙ НА ОСНОВЕ МНОЖЕСТВА КРИТЕРИЕВ. С помощью этого метода заинтересованные стороны количественно оценивают требования, используя матрицу принятия решений, основанную на таких факторах, как ожидаемые уровни риска, оценки времени и оценки затрат и выгод.