Другим аспектом итераций является то, что более поздние части планирования проекта, могут привести к добавлению содержания в проект, тем самым изменяя план управления содержанием, описание содержания проекта и ИСР.
Давайте разберёмся с тем, что такое итерация. Это как веха, которая включает в себя набор каких-либо работ, в нашем случае это веха будет включать то, из чего будет стоять наш план управления проектами.
Так вот когда выполняется план управления проектами методом итераций, то есть постепенно добавляя какую-то информацию, которая разрабатывается в настоящее время, новая итерация может включать в себя информацию, которая будет требовать изменить что-то в предыдущей итерации и за счёт этого нам придётся изменять содержание. Процесс изменения вкратце мы с вами прошли, вы об этом прочитали и ещё прочитаете, но напомню изменения чего-либо в проекте, содержании плана, расписании неважно чего у нас осуществляется за счёт того, что заинтересованные стороны вносят какое-то изменение, обосновывает его, защищают его, документируют его и утверждают его. После этого, изменение вступает в силу и применяется уже на той или иной работе. В нашем случае это план управления проектами.
Идея создания плана управления содержанием и всех планов управления: если вы не можете планировать это, вы не можете сделать это.
Тем не менее, многие люди совершают ошибку, начиная работать над проектом до того, как продукт и содержание проекта определены и до того, как они правильно спланировали, как они будут управлять содержанием.
2.6 Сбор требований
Давайте предположим. У вас появилась какая-то идея, которая в будущем должна стать проектом. вы создали устав проекта, вы написали на коленке всё что было у вас в голове об этом проекте и теперь готовы к нему приступать, но как вы видите у вас нет чёткой картинки того что должно произойти, как этот проект будет развиваться со временем и какой результат он должен в итоге дать. Для этого и формируются требования, которые фиксируются и документируются. Об этом я вам сейчас подробнее расскажу поэтому по традиции я вам желаю настроиться на работу, погрузиться в сегодняшний урок, и вы увидите, как много нового появится в вашем багаже знаний. Поэтому я с удовольствием начинаю рассказывать и надеюсь вы с удовольствием будете меня слушать.
СБОР ТРЕБОВАНИЙ
– Процесс: Сбор требований
– Группа процессов: Планирование
– Область знаний: Управление содержанием
Требования – это то, что нужно заинтересованным сторонам от проекта или продукта. Помните, что работа не должна включаться в проект только потому, что кто-то этого хочет. Вместо этого требования должны касаться решения проблем или достижения целей, изложенных в уставе проекта. Требования могут включать запросы о планировании и управлении работой.
Требования могут включать возможности, которые заинтересованные стороны хотели бы видеть в продукте, такие как программное приложение, которое позволяет нескольким пользователям получать доступ к нему одновременно.
– Качество: Прописанные параметры качества для чего либо, которые нельзя нарушать.
– Бизнеспроцессы: «вы должны отслеживать и сообщать о расходах проекта таким образом.»
– Соответствие: «по закону, мы должны соответствовать этому стандарту безопасности.»
– Управление проектами: «мы требуем, чтобы процедура управления рисками X использовалась в проекте.»
Процесс сбора требований ищет все требования, а не только те, которые связаны с продуктом проекта. Этот процесс имеет решающее значение для успеха проекта, так как пропущенное требование может означать значительные изменения и конфликты на протяжении оставшейся части проекта – и даже провал проекта.