2.1.1.2 Планирование проекта. Модуль “Определение содер… — Transcript

Видео объясняет процесс определения содержания проекта, включая сбор и документирование требований для успешного управления проектом.

Key Takeaways

Четкое разделение содержания проекта и содержания продукта важно для планирования.
Сбор и документирование требований — фундамент успешного управления проектом.
Требования должны включать явные и подразумеваемые, согласовываться с заказчиками.
Реестр требований связывает работы проекта с требованиями и служит основой для дальнейшего планирования.
Управление требованиями обеспечивает выполнение целей проекта и удовлетворение заинтересованных сторон.

Summary

Определение содержания проекта — ключевой этап планирования, отличающийся от содержания продукта.
Содержание проекта — это работы, необходимые для создания продукта с заданными характеристиками.
Основные задачи: сбор требований и разработка описания содержания проекта.
Требования бывают явные и подразумеваемые, их нужно тщательно выявлять и документировать.
Различают бизнес-требования, требования заинтересованных сторон, требования к продукту, качеству и самому проекту.
Требования должны быть согласованы с заказчиками для последующего управления ими.
Результатом процесса является реестр требований, который связывает работы проекта с требованиями.
Документирование требований создает основу для разработки описания содержания проекта.
Управление требованиями влияет на успешность реализации проекта и удовлетворение заказчика.
Следующий этап — разработка описания содержания проекта, который рассматривается в следующем видео.

Chapters

Full Transcript — Download SRT & Markdown

Speaker A

Одним из важнейших процессов планирования проекта является процесс определения содержания. Давайте разберемся, что такое содержание проекта. Содержание проекта отличается от содержания продукта. Если содержание продукта — это его свойства, его функции, его характеристики, например цвет, размер, эксплуатационные какие-то данные, технические характеристики, то содержание

Speaker A

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

Speaker A

выполнить две задачи. Первая задача — это собрать требования, и вторая задача — это разработать так называемое описание содержания проекта. С чем же мы занимаемся в ходе сбора требований и вообще зачем это нужно? Дело в том, что работа с требованиями — это очень важная

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

мы можем сказать заказчику: "Дорогой товарищ, ну вот же мы с вами согласовали требования к продукту, согласовали требования к проекту, вы подписались, что шло от нас, теперь требуйте пусть гарантийную поддержку". Итак, какими вообще могут быть требования? Ну, прежде всего это так

Speaker A

называемые бизнес-требования. Они вытекают из бизнес-цели проекта. Об этом мы с вами говорили, когда рассматривали процесс инициации проекта. Бизнес-требования к проекту подразумевают не цель проекта, они подразумевают, а вот что компания получит в результате реализации этого проекта.

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

выдвинуто требование, что руководителем проекта должен быть обязательно обладатель степени PMP, или, предположим, управление проектом должно вестись в соответствии со стандартом ISO 21500. Ну и последнее — это требования к самому проекту. Здесь могут быть требования к порядку предоставления документации, к порядку предоставления

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

чем мы с вами поговорим в следующем видео.

Topics:планирование проектаопределение содержаниятребования проектареестр требованийуправление проектомбизнес-требованиятехническое заданиекачество проектазаинтересованные стороныдокументирование требований

Frequently Asked Questions

В чем отличие содержания проекта от содержания продукта?

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

Почему важно собирать и документировать требования в проекте?

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

Какие виды требований рассматриваются при определении содержания проекта?

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

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →