#знания

СОДЕРЖАНИЕ ПРОЕКТА (часть 1).
Требования и иерархическая структура работ проекта.

ℹ️ Сперва определения 💬

* Описание содержания продукта (Product scope description) — это текстовый документ, который последовательно (сначала на высоком уровне, а затем более детально) уточняет характеристики продукта, услуги или результата, описанного в уставе проекта.
* Критерии приемки (Acceptance criteria) — четкий перечень условий, которые должны быть выполнены, чтобы результаты проекта могли быть приняты заказчиком. Это чек-лист, согласно которому заказчик будет принимать работу и проверять, насколько она соответствует его требованиям.
* Поставляемый результат (Deliverable) — любой уникальный и поддающийся проверке продукт, результат или способность оказывать услугу, которые необходимо произвести для завершения процесса, фазы или проекта. Т.е. какие артефакты проекта мы должны передать заказчику в итоге. Например, разработали мобильное приложение, то помимо приложения мы передаем исходный код, документацию, обученных сотрудников, подготовленных для поддержки и сопровождения приложения.
* Исключения из проекта (Project exclusions) — формулировка того, что именно находится вне содержания проекта. Т.е. описание того, что в проект не входит.

Касательно последнего — очень крутая штука! Например, проектный менеджер с заказчиком обсуждает устав проекта и работы по нему. Потом подключается еще один стейкхолдер, который предлагает “запилить” какую-то фичу, пусть это будет раздел аналитики на сайте, который мы разрабатываем. Нет проблем! Однако в первоначальной идее данной фичи не было предусмотрено. И в данном случае менеджеру лучше прописать в исключениях, что в рамках данного релиза этот функционал разрабатываться не будет. Это избавит от возможных недопониманий или даже конфликтов. Представьте себе, что спустя какой-то промежуток времени этот самый стейкхолдер приходит к руководителю и спрашивает, как продвигаются дела по его фиче. Тот вспоминают, что был такой разговор. Идут к вам спрашивать, а у вас ничего нет, кроме слов, мол, мы же перенесли это на другой релиз. Это возможный конфликт.

* Ограничения проекта (Project constraints) — то, в чем ограничивает нас заказчик. Например, в выборе субподрядчиков, технологии, методологии и т.п. Но ограничения по срокам и бюджету в этот пункт не вписываем (для них есть другое место).
*Допущения проекта (Project assumptions) — факторы, которые считаются верными без предоставления доказательств и демонстраций. Здесь описывается влияние этих факторов на проект. Это предположения, с которыми согласны вы и спонсор проекта. Без этих предположений дальнейшее планирование проекта невозможно.

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

Существует три вида базового плана:
- По содержанию работ
- По стоимости
- По расписанию

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

Базовый план по содержанию проекта состоит из требований к проекту, соответствующей иерархической структуры работ (ИСР) и ее словаря.

Сперва мы создаем высокоуровневые требования. Для этого мы готовим вопросы, которые впоследствии задаем заказчику. Допустим, мы сами это делаем (есть различные варианты сбора требований).
После того, когда все желания заказчика задокументированы, необходимо разделить их на требования и исключения.
Хорошие требования — это те, которые имеют четкий критерий завершенности (Definition of done/DoD).
Все требования должны быть задокументированы и согласованы со всеми стейкхолдерами.