Документирование объёмов работ проекта
Итак, мы формально и документально запустили проект. Теперь нужно разобраться, как выявить все объёмы работ нашего проекта и правильно их оформить. В классике проектного управления это называется «Планирование содержания проекта». Я же рассказу, как это «содержание» документировать.
Поскольку у нас на данный момент уже есть Устав проекта и Реестр заинтересованных сторон - мы знаем, какие цели преследует проект, и кто будет пользоваться результатами нашего проекта. Следовательно, берём контакты основных стейкхолдеров, связываемся с ними, и приступаем к выяснению и оформлению их требований.
Все требования нужно дискретно выразить в Реестре требований и в Документации по требованиям. Что это за документы и чем они отличаются?
Реестр требований — это таблица с перечнем и ключевыми характеристиками всех требований к проекту и продукту. Применение данного Реестра позволяет отслеживать требования на протяжении всего жизненного цикла проекта, что помогает нам быть уверенным в том, что все требования выполнены к концу проекта. Более того, Реестр требований позволяет организовать грамотное управление изменениями в проекте.
Нужно понимать, что изменения в проекте неизбежны. О документировании изменений я подробно расскажу в статье по документированию проекта в процессе контроля, а сейчас просто отмечу, что основным источником изменений в проекте являются меняющиеся хотелки и новые пожелания основных стейкхолдеров проекта (заказчика, спонсора и ключевых пользователей продукта). Конечно, изменения в проекте неизбежны, но они и крайне важны для успеха проекта. Всё дело в том, что в начале проекта пожелания стейкхолдеров могут быть не внятными, а по мере «взросления» самого проекта и требования к проекту и продукту становятся всё более зрелыми. Именно грамотное внесение изменений в проект и обеспечивает успешность проекта. Как уже отмечалось в прошлой статье, мы живём в VUCA-мире и то, что заказчик хочет в начале проекта не равно тому, что ему будет нужно в конце.
Следовательно – требования будут меняться, а Реестр требований позволяет отследить эти изменяющиеся требования на всём протяжении проекта. Идеальным вариантом оформления и ведения этого документа – использование специального ПО для отслеживания требований, типа Redmine или того же MS Project Server, только немного «доработанного напильником».
Типовые колонки таблицы, описывающие требования, включают в себя: уникальный идентификатор, текстовое описание требования, источник, критерии приемки, приоритет, версию и текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено). Примерная таблица приведена на рисунке:
Из рисунка видно, что описание требований в Реестре достаточно краткое и часто требует дополнительной описательной информации. Для этого и используется второй документ - Документация по требованиям, который описывает каждое требование во всех деталях, чтобы они стали однозначными (измеримыми и проверяемыми), отслеживаемыми и полными. Формат Документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до некой папки-скоросшивателя или электронной папки на портале проекта, которая включает в себя все документы и файлы, связанные с требованиями из Реестра требований. Например, в Реестре сказано, что документирование некой автоматизированной системы должно быть произведено в соответствии с ГОСТ 34.201. Соответственно в Документации по требованиям сам этот ГОСТ должен быть в бумажном или электронном виде, чтоб любой разработчик мог получить к нему доступ и выяснить все делали данного ГОСТа.
Если есть требования, то можно легко описать, какие объёмы работ нужно выполнить, чтоб все утверждённые требования удовлетворить.
В синих ячейках указано, какое ограничение меняется, в чёрных ячейках указаны зависимые ограничения. Зелёными стрелками показаны изменения, которые облегчают достижение целей проекта, красными – которые усложняют.
Описание содержания и Устав проекта иногда воспринимаются как дублирующие друг друга документы, но нужно понимать, Устав проекта содержит лишь высокоуровневую информацию, а Описание содержания — подробное описание продукта и объёмов работ, который позволяет команде приступить к более детализированному описанию проекта и разбиению содержания на мелкие составные части.
Разбиение объёмов работ проекта на более мелкие и, следовательно, легче управляемые части позволяет получить WBS - структурированное видение того, что необходимо достичь.Поскольку у нас на данный момент уже есть Устав проекта и Реестр заинтересованных сторон - мы знаем, какие цели преследует проект, и кто будет пользоваться результатами нашего проекта. Следовательно, берём контакты основных стейкхолдеров, связываемся с ними, и приступаем к выяснению и оформлению их требований.
Выяснить и оформить требования
Требования бывают двух типов:- Требования к проекту – т.е. как мы должны управлять проектом.
- Требования к продукту – т.е. что мы должны получить в итоге проекта.
Все требования нужно дискретно выразить в Реестре требований и в Документации по требованиям. Что это за документы и чем они отличаются?
Реестр требований — это таблица с перечнем и ключевыми характеристиками всех требований к проекту и продукту. Применение данного Реестра позволяет отслеживать требования на протяжении всего жизненного цикла проекта, что помогает нам быть уверенным в том, что все требования выполнены к концу проекта. Более того, Реестр требований позволяет организовать грамотное управление изменениями в проекте.
Нужно понимать, что изменения в проекте неизбежны. О документировании изменений я подробно расскажу в статье по документированию проекта в процессе контроля, а сейчас просто отмечу, что основным источником изменений в проекте являются меняющиеся хотелки и новые пожелания основных стейкхолдеров проекта (заказчика, спонсора и ключевых пользователей продукта). Конечно, изменения в проекте неизбежны, но они и крайне важны для успеха проекта. Всё дело в том, что в начале проекта пожелания стейкхолдеров могут быть не внятными, а по мере «взросления» самого проекта и требования к проекту и продукту становятся всё более зрелыми. Именно грамотное внесение изменений в проект и обеспечивает успешность проекта. Как уже отмечалось в прошлой статье, мы живём в VUCA-мире и то, что заказчик хочет в начале проекта не равно тому, что ему будет нужно в конце.
Следовательно – требования будут меняться, а Реестр требований позволяет отследить эти изменяющиеся требования на всём протяжении проекта. Идеальным вариантом оформления и ведения этого документа – использование специального ПО для отслеживания требований, типа Redmine или того же MS Project Server, только немного «доработанного напильником».
Типовые колонки таблицы, описывающие требования, включают в себя: уникальный идентификатор, текстовое описание требования, источник, критерии приемки, приоритет, версию и текущий статус (например, активно, отменено, отложено, добавлено, одобрено, назначено, выполнено). Примерная таблица приведена на рисунке:
Из рисунка видно, что описание требований в Реестре достаточно краткое и часто требует дополнительной описательной информации. Для этого и используется второй документ - Документация по требованиям, который описывает каждое требование во всех деталях, чтобы они стали однозначными (измеримыми и проверяемыми), отслеживаемыми и полными. Формат Документа по требованиям может варьироваться от простого документа, перечисляющего все требования, разделенные на категории по заинтересованным сторонам и приоритетам, до некой папки-скоросшивателя или электронной папки на портале проекта, которая включает в себя все документы и файлы, связанные с требованиями из Реестра требований. Например, в Реестре сказано, что документирование некой автоматизированной системы должно быть произведено в соответствии с ГОСТ 34.201. Соответственно в Документации по требованиям сам этот ГОСТ должен быть в бумажном или электронном виде, чтоб любой разработчик мог получить к нему доступ и выяснить все делали данного ГОСТа.
Шаблоны документов по требованиям можно полистать здесь:
|
Описать объёмы работ
Но целью данного действа является не только описание робот по удовлетворению требований, но и прояснение содержания проекта, включая цели, результаты и границы проекта. Итогом действа будет документ, который ПМ-ы называют Описание содержания проекта. Это изложение основных результатов, допущений, ограничений, а также явных исключений из содержания проекта, что помогает в управлении ожиданиями стейкхолдеров. Описание содержания включает в себя:- Описание продукта, описанного в Уставе проекта и в Документации по требованиям.
- Критерии приемки, т.е. условия, которые должны быть выполнены для того, продукт и результаты проекта были приняты заказчиком.
- Исключения из проекта - явная формулировка того, что именно в проекте точно не будет выполняться, чтоб не раздувать объёмы работ проекта.
- Ограничения, т.е. пределы или ограничивающие условия, которые оказывают влияние на исполнение проекта, например, предопределенный бюджет.
- Допущения - факторы, которые считаются верными, реальными или определенными без предоставления доказательств и без демонстрации. Допущения могут оказаться ошибочными и как правило являются источником рисков в проекте, но они позволяют запустить планирование проекта без долгих исследований. Одним из ярчайших примеров допущения в истории управления проектами является допущение, что луна твёрдая. Слышал о таком допущении? Нет? Я расскажу:
Середина 60-х годов XX-го века. Советская лунная программа разрабатывается полным ходом. И тут возникает вопрос: каким делать шасси посадочной станции? Ведь невозможно проектировать его, не зная, хотя бы приблизительно, куда станция будет садиться. А что представляет собой грунт лунной поверхности, никто ещё точно сказать не мог. Одна группа астрономов утверждала, что на Луне почва твердая, а вторая столь же убедительно доказывала, что за многовековую историю Луны из-за постоянной бомбардировки метеоритами там образовался слой пыли, причем его толщина достигает 50-ти метров в кратерах, а на ровных участках – десяти… Королёв собрал совещание, пригласив всех заинтересованных в лунной программе специалистов. За два часа совещания все переругались друг с другом, и только сам Королев не произнес ни слова. Смотрел и слушал. Словно ждал чего-то. Наконец, взял слово.
– Луна – твердая! – сказал он резко и, как обычно, безапелляционно.
Кто-то из астрономов все-таки возразил:
– Это еще доказать надо! Никто из учёных не берёт на себя смелость написать — на Луне, мол, такой-то грунт... и подписаться под этим!
Королев посмотрел усталыми глазами на сидящих за столом:
– Ах, вот чего вам не хватает... Взял блокнот, крупным почерком написал на его листке: «ЛУНА – ТВЕРДАЯ». Подписался: «С. КОРОЛЁВ». Поставил дату, вырвал листок из блокнота и передал сотруднику, которому предстояло непосредственно руководить проектированием станции.
В синих ячейках указано, какое ограничение меняется, в чёрных ячейках указаны зависимые ограничения. Зелёными стрелками показаны изменения, которые облегчают достижение целей проекта, красными – которые усложняют.
Шаблоны документов Описания содержания можно полистать здесь:
|
Разбить на составляющие
WBS, т.е. work breakdown structure или иерархическая структура работ может быть организована по разному, к примеру, по этапам проекта, по основным конструктивам, по подпроектам или микс из этих элементов.
- Этапы характеризуются тем, что их выполняет сама команда проекта, а их итог невозможно чётко измерить. Например, этап планирования. Хорошо или плохо спланирован график проекта, команда поймёт только когда по этому графику реализует большинство работ.
- Конструктивы характеризуются тем, что они достаточно чётко измеримы, т.е. существуют возможности однозначно проверить, что созданный результат полностью соответствует требованиям. Выполнять этот элемент WBS может как команда, так и некий подрядчик.
- Подпроеткты характеризуются тем, что их выполняет только подрядчик, а вернее внешняя по отношению к команде проекта организационная структура. Итог подпроектов, может быть, как измерим, так и нет.
Визуализация на схеме:
Каждый последующий уровень иерархической структуры работ более детально описывает работу по проекту, которая должна быть выполнена для достижения целей проекта. Уровень детализации WBS различается в зависимости от масштаба и сложности проекта. На самом низком уровне WBS располагаются пакеты работ, т.е. элементы для которого возможна оценка стоимости и длительности, а также управление ими:
Для лучшего понимания, что имеется ввиду под тем или иным прямоугольником, WBS сопровождают Справочником, в котором для каждого элемента указывают описание работ, допущения и ограничения, ответственную организацию, вехи, требуемые ресурсы, оценки стоимости, требования к качеству, критерии приемки, техническую информацию и прочее.
Для чего структурируем?
- Для разбивки проекта на управляемые блоки
- Для перехода от общих описаний к конкретным заданиям
- Для распределения ответственности и определения комплексов работ/подрядов
- Для более точной оценки затрат
Шаблоны WBS можно полистать здесь:
|
Итого
В конце процесса планирования объёмов работ проекта, Описание содержания и WBS должны быть собраны в один Базовый план по содержанию, который согласовывается со спонсором или заказчиком. С точки зрения документирования, итог планирования содержания проекта выглядит следующим образом:- Реестр требований и Документация по требованиям, определяющие, какие именно требования к проекту и продукту нужно удовлетворить для успешного достижения целей проекта.
- Описание содержания проекта — изложение содержания проекта, в том числе основных результатов, объёмов работ, допущений и ограничений.
- Базовый план по содержанию и WBS, согласованные со спонсором или заказчиком описание и разбиение объёмов работ проекта на мелкие управляемые части.
- Шаблоны всех этих документов можно полистать здесь:
- ОСУП.Содержание.Комплект по PMBOK (5th edition).
- ИСО21500.Содержание по ISO 21500:2012.
- Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
- Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект
Оставьте комментарий