Требования проекта: эффективное планирование управления

Оказывается, у бизнесменов и программистов есть один общий профессиональный инструмент, содержащий набор опций, подстраиваемых под любые задачи, — фреймворк. Это особый, содержащий комплексный свод информации, «конструктор», используемый для качественного описания и эффективной систематизации крупных проектов!

Можно поступить, конечно, проще: например, применить CMS-систему для запуска нового сайта или просто ориентироваться по готовому сценарию приобретенной франшизы. Но типовой план управления требованиями из готового движка или кем-то когда-то составленной инструкции по франшизе — не универсальное решение, особенно если речь заходит об индивидуальных и/или особо масштабных проектах, требующих вдумчивого подхода и нестандартных приемов. В таких случаях и приходят на помощь «каркасные» фреймворки, прекрасно адаптирующиеся под клиентские запросы.

Как органично настраиваемый «конструктор» справляется с управленческой ролью? Рассмотрим на примере PMBoK — международном документе, практическом руководстве, позволяющем запускать проекты любой сложности!

Англоязычная аббревиатура PMBoK зашифровала четыре слова, отражающих суть этого фреймворка:

Дословный перевод оригинала понятен даже тем, кто плохо знает иностранный язык: «Свод знаний для управления проектом».

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

Целевая аудитория может получить «Свод» на почти всех языках (в том числе на русском) и в двух версиях:

На сегодня актуально седьмое издание.

Объем PMBoK составляет более 600 страниц на английском, что превышает разработанный Американским национальным институтом стандартов объем отраслевого стандарта управления проектами! При этом оба руководства — от Project Management Institute и от ANSI — взаимно согласованны в том, что касается управления проектами.

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

Оригинал распространяется платно в книжных магазинах и на официальном сайте проекта PMI.

Наконец, рассчитанный на форсированное использование «Свод» не носит методологического характера. Однако на основе этого документа разрабатываются готовые к применению бизнес-решения, в том числе подходящие для Agile-команд.

Это одна из структурных частей фреймворка, а точнее — второй раздел плана управления проектом! Тематически Requirements Management Plan (т. е. план управления требованиями) относится к группе процессов планирования, содержащихся в многостраничном руководстве PMBoK.

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

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

Не меньшей фатальностью станет для проекта и неподходящий для его разработки коллектив, а также субъективный подход всех лиц, оказывающих прямое или косвенное влияние. «Целого видения» ситуации не получится: каждый участник будет смотреть на будущий проект «со своей колокольни». Вот почему для гарантирующего однородность и адекватность реальности консенсуса необходимо до планирования определить не только ответственных за него исполнителей, но и распределить между ними роли. Еще одно обязательное требование к процессу — не просто найти максимум требований, но и обработать их:

Разумеется, подготовленный материал придется проверить на «жизнеспособность», а затем уже разрабатывать на его основе пакет документов.

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

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

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

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

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

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

Когда требования (а, вернее, документация по ним и матрица их отслеживания) получены, материал обрабатывают (например, удаляют дубли), а затем передают на утверждение уполномоченному лицу.

Разработана универсальная система управления проектами на основе совместимости Projecto почти со 100 % методологий. Для знакомства бесплатно предоставляется демоверсия сервиса.

#методология #управление_проектами #управлениепроектами #менеджментзадач #менеджмент #проектныйменеджмент

Источник: официальный канал Projecto на Дзен