Документирование объёмов работ проекта

Итак, мы формально и документально запустили проект. Теперь нужно разобраться, как выявить все объёмы работ нашего проекта и правильно их оформить. В классике проектного управления это называется «Планирование содержания проекта». Я же рассказу, как это «содержание» документировать.

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

Выяснить и оформить требования

Требования бывают двух типов:

1. Требования к проекту – т.е. как мы должны управлять проектом.
2. Требования к продукту – т.е. что мы должны получить в итоге проекта.

Требования к проекту можно получить из регламентирующих документов корпоративного стандарта управления проектами нашей компании, из контракта или просто выяснив их у спонсора и заказчика проекта. Требования к продукту получаются в результате проведения анкетирования и опросов будущих пользователей продукта проекта.
Все требования нужно дискретно выразить в Реестре требований и в Документации по требованиям. Что это за документы и чем они отличаются?
Реестр требований — это таблица с перечнем и ключевыми характеристиками всех требований к проекту и продукту. Применение данного Реестра позволяет отслеживать требования на протяжении всего жизненного цикла проекта, что помогает нам быть уверенным в том, что все требования выполнены к концу проекта. Более того, Реестр требований позволяет организовать грамотное управление изменениями в проекте.
Нужно понимать, что изменения в проекте неизбежны. О документировании изменений я подробно расскажу в статье по документированию проекта в процессе контроля, а сейчас просто отмечу, что основным источником изменений в проекте являются меняющиеся хотелки и новые пожелания основных стейкхолдеров проекта (заказчика, спонсора и ключевых пользователей продукта). Конечно, изменения в проекте неизбежны, но они и крайне важны для успеха проекта. Всё дело в том, что в начале проекта пожелания стейкхолдеров могут быть не внятными, а по мере «взросления» самого проекта и требования к проекту и продукту становятся всё более зрелыми. Именно грамотное внесение изменений в проект и обеспечивает успешность проекта. Как уже отмечалось в прошлой статье, мы живём в VUCA-мире и то, что заказчик хочет в начале проекта не равно тому, что ему будет нужно в конце.
Следовательно – требования будут меняться, а Реестр требований позволяет отследить эти изменяющиеся требования на всём протяжении проекта. Идеальным вариантом оформления и ведения этого документа – использование специального ПО для отслеживания требований, типа Redmine или того же MS Project Server, только немного «доработанного напильником».
Типовые колонки таблицы, описывающие требования, включают в себя: уникальный идентификатор, текстовое описание требования, источник, критерии приемки, приоритет, версию и текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено). Примерная таблица приведена на рисунке:

Из рисунка видно, что описание требований в Реестре достаточно краткое и часто требует дополнительной описательной информации. Для этого и используется второй документ - Документация по требованиям, который описывает каждое требование во всех деталях, чтобы они стали однозначными (измеримыми и проверяемыми), отслеживаемыми и полными. Формат Документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до некой папки-скоросшивателя или электронной папки на портале проекта, которая включает в себя все документы и файлы, связанные с требованиями из Реестра требований. Например, в Реестре сказано, что документирование некой автоматизированной системы должно быть произведено в соответствии с ГОСТ 34.201. Соответственно в Документации по требованиям сам этот ГОСТ должен быть в бумажном или электронном виде, чтоб любой разработчик мог получить к нему доступ и выяснить все делали данного ГОСТа.

Шаблоны документов по требованиям можно полистать здесь: Реестр требований и Документация по требованиям по PMBOK (5th edition) Папка "Требования" с Матрицей отслеживания требований по ISO 21500:2012

Если есть требования, то можно легко описать, какие объёмы работ нужно выполнить, чтоб все утверждённые требования удовлетворить.

Описать объёмы работ

Но целью данного действа является не только описание робот по удовлетворению требований, но и прояснение содержания проекта, включая цели, результаты и границы проекта. Итогом действа будет документ, который ПМ-ы называют Описание содержания проекта. Это изложение основных результатов, допущений, ограничений, а также явных исключений из содержания проекта, что помогает в управлении ожиданиями стейкхолдеров. Описание содержания включает в себя:

• Описание продукта, описанного в Уставе проекта и в Документации по требованиям.
• Критерии приемки, т.е. условия, которые должны быть выполнены для того, продукт и результаты проекта были приняты заказчиком.
• Исключения из проекта - явная формулировка того, что именно в проекте точно не будет выполняться, чтоб не раздувать объёмы работ проекта.
• Ограничения, т.е. пределы или ограничивающие условия, которые оказывают влияние на исполнение проекта, например, предопределенный бюджет.
• Допущения - факторы, которые считаются верными, реальными или определенными без предоставления доказательств и без демонстрации. Допущения могут оказаться ошибочными и как правило являются источником рисков в проекте, но они позволяют запустить планирование проекта без долгих исследований. Одним из ярчайших примеров допущения в истории управления проектами является допущение, что луна твёрдая. Слышал о таком допущении? Нет? Я расскажу:
  Середина 60-х годов XX-го века. Советская лунная программа разрабатывается полным ходом. И тут возникает вопрос: каким делать шасси посадочной станции? Ведь невозможно проектировать его, не зная, хотя бы приблизительно, куда станция будет садиться. А что представляет собой грунт лунной поверхности, никто ещё точно сказать не мог. Одна группа астрономов утверждала, что на Луне почва твердая, а вторая столь же убедительно доказывала, что за многовековую историю Луны из-за постоянной бомбардировки метеоритами там образовался слой пыли, причем его толщина достигает 50-ти метров в кратерах, а на ровных участках – десяти… Королёв собрал совещание, пригласив всех заинтересованных в лунной программе специалистов. За два часа совещания все переругались друг с другом, и только сам Королев не произнес ни слова. Смотрел и слушал. Словно ждал чего-то. Наконец, взял слово.
  – Луна – твердая! – сказал он резко и, как обычно, безапелляционно.
  Кто-то из астрономов все-таки возразил:
  – Это еще доказать надо! Никто из учёных не берёт на себя смелость написать — на Луне, мол, такой-то грунт... и подписаться под этим!
  Королев посмотрел усталыми глазами на сидящих за столом:
  – Ах, вот чего вам не хватает... Взял блокнот, крупным почерком написал на его листке: «ЛУНА – ТВЕРДАЯ». Подписался: «С. КОРОЛЁВ». Поставил дату, вырвал листок из блокнота и передал сотруднику, которому предстояло непосредственно руководить проектированием станции.

Что касается ограничений проекта, то тут нужно учитывать, что ограничения часто конкурентны, и влияют друг на друга. Как правило, выделяют шесть основных ограничений: бюджет, срок, ресурсы, качество, риски, ну, и сами объёмы работ. И если, к примеру, уменьшается срок проекта, то, как правило, увеличивается нагрузка на ресурсы, или увеличивается бюджет, или ухудшается качество, увеличиваются риски, режутся объёмы работ. Все подобные конкурентные взаимозависимости ограничений представлены на рисунке:

В синих ячейках указано, какое ограничение меняется, в чёрных ячейках указаны зависимые ограничения. Зелёными стрелками показаны изменения, которые облегчают достижение целей проекта, красными – которые усложняют.

Шаблоны документов Описания содержания можно полистать здесь: Описание содержания по PMBOK (5th edition) Описание содержания по ISO 21500:2012

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

Разбить на составляющие

Разбиение объёмов работ проекта на более мелкие и, следовательно, легче управляемые части позволяет получить WBS - структурированное видение того, что необходимо достичь.
WBS, т.е. work breakdown structure или иерархическая структура работ может быть организована по разному, к примеру, по этапам проекта, по основным конструктивам, по подпроектам или микс из этих элементов.

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

Визуализация на схеме:

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

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

1. Для разбивки проекта на управляемые блоки
2. Для перехода от общих описаний к конкретным заданиям
3. Для распределения ответственности и определения комплексов работ/подрядов
4. Для более точной оценки затрат

Наиболее подробно методика разработки WBS описана в Practice Standard for Work Breakdown Structures – Second Edition.

Шаблоны WBS можно полистать здесь: WBS и Справочник WBS по PMBOK (5th edition) WBS и Справочник WBS по ISO 21500:2012

Итого

В конце процесса планирования объёмов работ проекта, Описание содержания и WBS должны быть собраны в один Базовый план по содержанию, который согласовывается со спонсором или заказчиком. С точки зрения документирования, итог планирования содержания проекта выглядит следующим образом:

1. Реестр требований и Документация по требованиям, определяющие, какие именно требования к проекту и продукту нужно удовлетворить для успешного достижения целей проекта.
2. Описание содержания проекта — изложение содержания проекта, в том числе основных результатов, объёмов работ, допущений и ограничений.
3. Базовый план по содержанию и WBS, согласованные со спонсором или заказчиком описание и разбиение объёмов работ проекта на мелкие управляемые части.

---

• Шаблоны всех этих документов можно полистать здесь:
  • ОСУП.Содержание.Комплект по PMBOK (5th edition).
  • ИСО21500.Содержание по ISO 21500:2012.
• Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
• Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект