Повторное использование документов

Проектные группы подвергаются постоянному прессингу по поводу сокращения временных затрат на планирование. Поэтому возникает вопрос: как производить качественное планирование, минимизируя связанные с ним накладные расходы?

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

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

Планы проекта

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

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

План	Ведущий ролевой кластер
Коммуникационный план	Управление продуктом
План разработки	Разработка
План обучения	Удовлетворение потребителя
План мер безопасности	Разработка, Управление выпуском
План тестирования	Тестирование
План финансирования	Управление программой
План внедрения	Управление выпуском
План закупок и материального обеспечения	Управление выпуском, Управление программой
План пилотного внедрения	Управление выпуском

Иерархическая структура работ

Иерархическая структура работ (Work Breakdown Structure - WBS) – это структуризация работ проекта, отражающая его основные результаты и определяющая его рамки[3]. Работа, не описанная в WBS, находится вне границ проекта. Для лидеров групп и ролевого кластера “Управление программой” WBS – это инструмент управления проектом, облегчающий создание планов и календарных графиков.

В MSF создание WBS является коллективной деятельностью, в которую вовлекаются все ролевые кластеры. Каждая роль ответственна за предоставление детального описания собственной работы. В больших проектах может возникнуть необходимость отдельного определения объема работы подкоманд (функциональных групп и/или групп направлений). Для этого ими может быть проведен мозговой штурм, результаты которого должны документироваться лидерами команд и представляться на рассмотрение всей проектной группе. “Управление программой” затем синтезирует эти составляющие в общую WBS.

Преимущества WBS

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

WBS помогает:

· Оценивать будущие затраты. Формируемая базовая версия списка проектных задач позволяет оценить материальные и временные затраты на реализацию проекта.

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

· Упорядочивать (по времени) выполнение задач. С помощью анализа списка проектных задач выявляются их взаимозависимости и ресурсные ограничения и, исходя из этого, составляется календарный график.

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

· Специфицировать ответственность. WBS может быть использован при создании матрицы ответственности (responsibility matrix).

Соответствие между WBS, функциональными спецификациями и сводным планом проекта

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

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

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

Сводный план проекта и WBS дополняют друг друга. WBS кратко перечисляет стоящие перед проектной группой задачи. Планы же проекта детально документируют, как каждая из имеющихся задач должна выполняться, какие установлены критерии качества (quality bars), какие есть элементарные подзадачи и чеклисты (контрольные списки - checklists) и т.д.

Рис. 6 схематически иллюстрирует использование WBS в качестве инструмента поддержки соответствия между спецификациями, планами и календарными графиками.

Рисунок 6. WBS показывает соответствие между спецификациями, планами и календарными графиками проекта

Создание WBS

Каждый ролевой кластер определяет объем своей работы, необходимой для создания решения, и описывает его в форме планов, чеклистов и т.п.

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

Для создания WBS лидеры ролевых кластеров проводят собрания своих команд. При определении фронта необходимых работ и его разбиении на меньшие части, члены ролевых кластеров совместно анализируют спецификации составляющих решения. Этот процесс называется декомпозицией работы (work breakdown / work decomposition).

Один из результатов процесса управления рисками MSF – появление дополнительных задач, являющихся реакцией на имеющиеся риски. Эта работа может быть включена в WBS, оценена, спланирована и внесена в календарный график точно так же, как и другие задачи. Рассмотрите возможность совмещения процесса составления WBS с мозговым штурмом по выявлению рисков.

Первый уровень структуры WBS может соответствовать фазам жизненного цикла проекта. Фазы модели процессов MSF очень хорошо подходят для этого. Предлагаемые в MSF промежуточные вехи фаз проекта соответствуют созданию базовых или рабочих версий определенных составляющих решения, поэтому их естественно использовать как второй уровень структуры WBS. Ниже этого уровня работа структурируется при помощи процесса декомпозиции работы/задач (work/task decomposition).

Рекомендации по декомпозиции работы

При создании WBS полезно учитывать следующие рекомендации:

· Затраты на каждую задачу должны быть реалистично оцениваемы.

· Оценка времени исполнения каждой задачи не должна быть менее одного или более 40 дней (для IT-проектов).

· Каждая задача должна иметь однозначное описание как её самой, так и ожидаемого результата.

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

· Ответственность за каждую задачу должна быть поручена одному работнику.

· Каждая задача может предполагать дальнейшее разбиение на элементарные подзадачи.

· Деятельность, сопряженная с большими рисками, должна детализироваться больше, чем деятельность, сопряженная с меньшими рисками.

· За исключением двух верхних уровней, задачи должны формулироваться в повелительном наклонении (например, “Спроектировать схему базы данных” вместо “Схема базы данных”).

· В WBS должно быть от трех до пяти уровней определения задач.

· По ходу работы над проектом WBS последовательно дорабатывается, но обычно ее формирование производится на фазе планирования.

Оценка снизу вверх

В IT-проектах предварительные оценки длительности задач, их стоимости и т.п. следует получать от тех, кто будет затем выполнять оцениваемую работу. Оценка снизу вверх (bottom-up estimating) – это процесс выработки и интеграции оценок многими членами команды. Такой подход обладает следующими преимуществами:

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

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

Уполномоченость (empowerment) проектной группы. Календарный график, составленный самой проектной группой, а не продиктованный свыше руководством, вдохновляет проектную группу, поскольку он составлен на основе тех оценок, которые сами члены проектной группы считают реалистичными.

⇐ Предыдущая1234567Следующая ⇒

Поделиться: