Размещено на http://www.allbest.ru/

Контрольная работа

Тема 8

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

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

Так зачем же нужно планирование, если все меняется? Дело в том, что в управлении проектами главным является не выполнение плана, а эффективное достижение цели проекта, поэтому основное назначение планирования заключается в непрерывном поддержании «курса» развития проекта на пути к его успешному завершению.

Что планируется в проекте? Все, что подлежит учету, контролю, анализу и регулированию! И, прежде всего, - функции управления проектами.

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

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

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

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

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

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

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

Процессы планирования

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

К основным процессам планирования относят:

· планирование содержания проекта и его документирование;

· определение основных этапов реализации проекта, декомпозиция их на более мелкие и управляемые элементы;

· составление сметы и оценку стоимости ресурсов, необходимых для выполнения работ проекта;

· формирование списка конкретных работ, которые обеспечивают достижение целей проекта;

· установление последовательности работ, определение и документирование технологических зависимостей и ограничений на работы;

· оценку продолжительности работ, трудозатрат и других ресурсов, необходимых для выполнения отдельных работ;

· планирование ресурсов, определение того, какие ресурсы (люди, оборудование, материалы) и в каких количествах потребуются для выполнения работ проекта. Определение, в какие сроки работы могут быть выполнены с учетом ограниченности ресурсов;

· составление бюджета, привязку сметных затрат к конкретным видам деятельности;

· разработку плана проекта, сбор результатов остальных процессов планирования и объединение их в общий документ.

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

Вспомогательные процессы выполняются по мере необходимости. К ним относят:

· планирование качества, определение стандартов качества, соответствующих данному проекту, и поиск путей их достижения;

· организационное планирование, определение, обследование, документирование и распределение проектных ролей, ответственности и отношений подчиненности;

· подбор кадров, формирование команды проекта на всех стадиях жизненного цикла проекта;

· планирование коммуникаций, определение информационных и коммуникационных потребностей участников проекта: кому и какая информация необходима, когда и как она им должна быть доставлена;

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

· планирование поставок, определение того, что, каким образом, когда и с помощью кого закупать и поставлять.

Уровни планирования

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

Уровни планирования должны соответствовать уровням управления. Чем выше уровень, тем более агрегированная, обобщенная информация используется для управления.

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

· договорные требования и обязательства;

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

· оценочные и стоимостные модели;

· документация по аналогичным разработкам.

Обычно выделяют следующие виды планов:

· концептуальный план проекта;

· стратегический план реализации проекта;

· тактические (детальные, оперативные) планы.

В успешных проектах планирование начинается на ранних стадиях с разработки предварительного (концептуального плана). Цель концептуального планирования - оценка параметров проекта для принятия решения о целесообразности его выполнения, согласования с заказчиком ограничений проекта и подготовки контракта. Оно сопровождается разработкой основной документации по проекту, технических требований, оценок, укрупненных календарных планов, процедур контроля и управления. Концептуальное планирование проводится в начальный период жизненного цикла проекта.

Несколько слов о важности концепции проекта

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

Концепция должна не просто существовать, а быть достижимой. То же относится и к целям, которые должны быть не только достижимы по отдельности, но и все вместе.

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

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

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

Стратегическое планирование представляет собой процесс разработки стратегических, укрупненных, долгосрочных планов.

Уровень стратегического планирования связан с двумя основными вопросами:

· что мы собираемся сделать?

· как мы это сделаем?

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

Одним из методов, который часто используется для целей стратегического планирования, в особенности для оценки специфических параметров самой организации и ее окружения, является SWOT-анализ (Strengths, Weaknesses, Opportunities and Threats -- преимущества, слабые стороны, возможности, угрозы). Это подход сверху вниз, который начинается определения миссии проекта. Формулировка миссии фиксирует уникальный характер проекта. Правильно сформулированная миссия отводит главное место потребностям пользователей, а не просто коммерческим и другим интересам самой организации.

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

Для проведения SWOT-анализа используют таблицу, структура которой приведена на рис.1. Для ее заполнения необходимо ответить на следующие вопросы:

· каковы наши преимущества, как мы можем их реализовать?

· в чем наши слабые стороны, как мы можем уменьшить их влияние?

· какие существуют возможности, как и какую мы можем извлечь выгоду из них?

· что могло бы воспрепятствовать угрозам?

· что мы могли бы сделать для каждого из обстоятельств, чтобы преодолеть или избежать возникновение проблемы?

Рис. 1. Таблица для проведения SWOT-анализа.

Принципы планирования в проекте

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

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

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

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

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

Многофункциональность планирования означает обязательное планирование по всем функциям управления проектом.

Оптимальность планирования предполагает способность системы формировать не просто приемлемые (допустимые с точки зрения принятых ограничений) планы, а лучшие планы по выбранным критериям.

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

Непротиворечивость планирования обеспечивается преемственностью и взаимоувязанностью всех плановых решений.

Непрерывность планирования заключается в мониторинге, контроле а при необходимости актуализации плановых решений;

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

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

В стандарте ISO 15504 «Оценка процессов разработки и поддержки ПО» определены задачи и виды деятельности, которые следует отражать в плане управления проектом разработки программного средства:

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

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

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

· установить график (исполнители, сроки, ресурсы) выполнения проекта, основываясь на распределении работ, оценках и элементах инфраструктуры;

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

· идентифицировать интерфейсы между элементами проекта, а также с другими проектами и организационными единицами системы;

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

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

Структурная декомпозиция работ (WBS)

Общая картина проекта содержится в плане разработки программного продукта, который определяет способы достижения целей, поставленных перед проектом. Создание плана разработки программного продукта начинается с построения структуры пооперационного выполнения работ (work breakdown structure, WBS). WBS - это иерархическая структура, получающаяся в результате последовательной декомпозиции проекта на подпроекты, пакеты работ различного уровня и отдельные рабочие задания. В ней описываются шаги, необходимые для выполнения проекта, а также их взаимосвязи.

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

Создать хорошую структуру работ, которая является полезной и пригодной к употреблению, не так просто, как кажется на первый взгляд.

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

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

· определить работы, обеспечивающие достижение целей и подцелей (частных целей) проекта;

· проверить, все ли цели будут достигнуты в результате реализации проекта;

· создать удобную, соответствующую целям проекта структуру отчетности;

· определить на соответствующем уровне детализации плана вехи (ключевые результаты), которые будут играть роль контрольных точек по проекту;

· распределить ответственность за достижение целей проекта между его исполнителями и тем самым гарантировать, что ни одна работа не выпадет из поля зрения;

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

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

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

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

Основанием декомпозиции WBS могут служить:

· компоненты продукта (объекта, услуги, направления деятельности), получаемого в результате реализации проекта;

· процессные или функциональные элементы деятельности организации, реализующей проект;

· этапы жизненного цикла проекта, основные фазы;

· подразделения организационной структуры;

· географическое размещение для пространственно распределенных проектов.

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

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

Подход снизу вверх идеально подходит для разработки проектов новых типов, когда команда разработчиков плохо ознакомлена с этапами, которые им придется реализовать на практике. Применение этого подхода на практике обычно сопровождается использованием метода «мозгового штурма» по отношению ко всему, что должно выполняться в рамках проекта. Затем производится группировка действий с одинаковым уровнем детализации, параллельно с которой выполняется приблизительная оценка объемов работ. Группирование производится до тех пор, пока не будет достигнут элемент высшего уровня. Этот процесс еще называют созданием диаграмм связности.

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

Обычно при построении WBS используется следующая последовательность действий:

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

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

· для каждой, выделенной таким образом, части проекта определяются имеющие к ней отношение данные (продолжительность и объем работ, ответственные исполнители, бюджет и затраты, оборудование и материалы и т.д.) Каждый следующий уровень в WBS добавляет более детальные элементы, каждый из элементов связан с более общим элементом, расположенным на уровень выше. На любом из уровней группе «дочерних» (детальных) элементов соответствует только один «родительский» (суммарный) элемент. Это правило обеспечивает корректность суммирования стоимостей, вывода объединенных календарных графиков и обобщения информации о работах при переходе с одного уровня на другой.. Наибольший интерес на этом этапе представляют данные по персональной ответственности за выполняемые работы -- матрица ответственности, в которой определяется, кто и за что отвечает. Она служит основой для решения проблем координации работ по проекту, выявления узких мест, где нет баланса между правами и обязанностями исполнителей.

· по каждой выделенной части проекта проводится критический анализ с ее исполнителями (членами команды проекта, менеджерами и другими участниками) для подтверждения правильности WBS.

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

Возможные ошибки структуризации проекта:

· пропуск стадии структуризации проекта и переход непосредственно к поиску и решению текущих, оперативных проблем проекта;

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

· повторение элементов структуры;

· отсутствие интеграции структуры проекта с системой ведения бухгалтерских счетов в компании и с системой подготовки проектно-сметной документации;

· излишняя или недостаточная детализация;

· невозможность компьютерной обработки результатов структуризации -- планов проекта из-за ошибок формального характера (каждый уровень или элемент плана должен быть определенным образом закодирован);

Проблемы традиционной WBS при разработке ПО

Традиционные декомпозиции работ обычно имеют три фундаментальных порока, а именно:

1. Традиционные декомпозиции работ создаются преждевременно на основе проектных решений по разработке продукта. На рис. 8.3 показана типичная традиционная WBS, построенная на основе разбиения архитектуры продукта на подсистемы, которые, в свою очередь, разбиты на компоненты. Как только эта структура переходит к ответственным менеджерам в виде бюджетов, сроков и ожидаемых отчетов, устанавливается такая основа планирования, менять которую оказывается сложно и дорого. WBS является архитектурой финансового плана. В архитектуру ПО следует инкапсулировать компоненты, которые, вероятно, будут изменяться, точно так же необходимо поступать и с архитектурой планирования. Жестко привязывать план к структуре продукта имеет смысл только в том случае, если они оба достаточно созрели для этого. В случае если либо план, либо архитектура будут подвергаться дальнейшим изменениям, желательна менее жесткая зависимость.

2. Традиционные декомпозиции преждевременно детализируются, планируются и финансируются либо слишком подробно, либо недостаточно подробно. В больших проектах существует тенденция к избытку планов, а в малых - к недостатку планов. WBS, приведенная на рис. 8.3, оказывается чрезмерно упрощенной для широкомасштабных проектов, где обычными считаются шесть и более уровней детализации. Команда управления проектом тщательно планирует каждый элемент и определяет основы бюджета и сроки создания ПО для каждого задания на данном уровне детализации. С другой стороны, большинство небольших или «домашних» разработок довольствуется созданием WBS с одним уровнем без сопровождения его какими-либо подробностями. Команда управления планирует и ведет проект, используя приблизительное распределение заданий, нежесткую отчетность по срокам и затратам. Оба этих подхода не являются взвешенными. Вообще говоря, имеет смысл WBS, проработанная, по крайней мере, до двух или трех уровней. В случае крупномасштабных систем может понадобиться несколько дополнительных уровней на более поздних стадиях жизненного цикла. Основной проблемой при включении в план с самого начала слишком большого числа деталей заключается в том, что эти детали не меняются параллельно с уровнем качества плана. Например, не представляется возможным точно расписать на первом месяце - когда составляются основы плана, и до того, как будут разработаны архитектура и сценарии тестирования, -- детали работ по тестированию, намеченных к выполнению 18 месяцами позже.

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

Размещено на http://www.allbest.ru/

Рис. 8.3. Традиционная декомпозиция работ, привязанная к структуре продукта.

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

· Каково соотношение между производительными видами деятельности (требования, проектирование, реализация, оценка, внедрение) и непроизводительными (управление проектом, создание рабочей среды)?

· Каков процент усилий, затраченных на доработки?

· Каков процент затрат на основное программное оборудование (расходы на среду)?

· Каково соотношение между тестированием и интеграцией?

· Каковы затраты на версию N (являющиеся основанием для планирования затрат на версию N+1)?

Эволюционирующие декомпозиции работ

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

· Элементами WBS первого уровня являются рабочие процессы (управление проектом, создание рабочей среды, управление требованиями, проектирование, реализация, оценка и внедрение). Эти элементы обычно закрепляются за одной командой и формируют «скелет» проекта, который используется в целях планирования и сравнения с другими проектами.

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

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

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

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

· Масштаб. Более масштабные проекты будут иметь больше уровней и подструктур.

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

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

· Бизнес-контекст. Проекты, выполняемые на контрактной основе, требуют более совершенного управления и оценки. Проекты, в которых разрабатываются коммерческие продукты для продажи широкому кругу потребителей, могут потребовать более совершенных структур для внедрения. Приложение, внедряемое в единственном месте, может обладать как совершенно тривиальным элементом внедрения (например, в случае разработки бизнес-приложения внутри организации), так и хорошо проработанным (например, при переходе от критически важной унаследованной системы с обеспечением параллельной эксплуатации для достижения нулевого времени простоя).

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

Размещено на http://www.allbest.ru/

Рис. 8.4. Декомпозиция работ, построенная на основе процессов.

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

Методические рекомендации по планированию

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

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

Приступая к созданию или оценке плана, следует принять во внимание два простых указания по планированию. Первое указание (см. таблицу.1) дает предварительное описание стандартного распределения затрат между элементами WBS первого уровня. Второе указание (см. таблицу 8.2) дает предварительное описание распределения усилий и сроков между стадиями жизненного цикла. При наличии начальной оценки стоимости всего проекта и этих двух таблиц структура персонала, распределение людских ресурсов по различным работам, график выполнения проекта верхнего уровня и начальная WBS с бюджетом и сроками выполнения отдельных заданий оказываются очевидными. Эта разновидность разработки плана сверху вниз является полезным опытом по планированию, который обеспечивает основу для его дальнейшего уточнения.

Таб. 1. Стандартные бюджеты WBS.

Элемент WBS первого уровня	Стандартный бюджет
Управление проектом	10%
Создание рабочей среды	10%
Управление требованиями	10%
Проектирование	15%
Реализация	25%
Оценка	25%
Внедрение	5%
Итого	100%

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

· в этих цифрах учтена стоимость различных категорий трудозатрат. Например, управление проектом, управление требованиями и проектирование -- это элементы, где обычно используется персонал с более высокими должностями и с более высокой оплатой. Если управление требованиями и проектирование совместно потребляют 25% бюджета (при использовании сотрудников со средней зарплатой $100/час), этой сумме может соответствовать всего лишь половина необходимого количества человеко-часов по сравнению с элементом оценки, который, хотя и потребляет те же 25% бюджета, но задействует персонал со средним заработком $50/час.

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

Таб. 2. Стандартное распределение усилий и сроков по стадиям.

Область определения	Начальная стадия	Уточнение	Конструирование	Ввод в действие
Усилия	5%	20%	65%	10%
Сроки	10%	30%	50%	10%

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

Процесс оценки сроков и затрат

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

1. Менеджер проекта по созданию ПО вырабатывает общую оценку размера проекта, процесса; среды, персонала и требуемого качества.

2. Производится приблизительная оценка общих усилий и сроков с использованием модели оценки стоимости.

3. Менеджер проекта детализирует эту приблизительную оценку усилий на верхнем уровне WBS, используя рекомендации, аналогичные приведенным в таблице 1. На этом этапе детализируются также сроки путем установления дат основных контрольных точек, и распределяются необходимые усилия в соответствии со штатным расписанием, используя рекомендации, аналогичные приведенным в таблице 2. Таким образом, получается план проекта верхнего уровня. Подобные приблизительные оценки обычно не учитывают многочисленные параметры, специфичные для данного проекта.

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

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

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

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

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

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

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

Практическое планирование

Хорошее планирование в условиях итерационного процесса является более динамичным, тем не менее осуществлять его с достаточной точностью оказывается значительно проще. В процессе выполнения итерации N на любой стадии менеджер проекта по созданию ПО должен отслеживать и контролировать соответствие плану, созданному в процессе выполнении итерации N-I, и при этом планировать итерацию N+1. Высшее искусство управления проектом заключается в том, чтобы достигать всех согласований в планах текущей итерации и в планах очередной итерации, основываясь на объективных результатах текущей и предшествующей итераций. Такая концепция представляется -- и является -- трудноосуществимой на ранних стадиях или в проектах, прокладывающих путь к итерационной разработке. Но если механизм планирования отлажен, процесс становится удивительно простым по мере перехода к стадиям, в которых качественное планирование является залогом успеха.

Помимо плохой архитектуры и неправильного понимания требований, неадекватное планирование (и соответственно плохое управление) является одной из наиболее распространенных причин неудачного завершения проектов. Напротив, удача проекта может быть частично отнесена на счет хорошего планирования, управления требованиями и архитектуры. Конечным продуктам, связанным с этими аспектами (плану разработки ПО, спецификациям требований и документу с описанием архитектуры), не уделяется особого внимания. Для большинства успешных проектов они не являются очень важными после того, как были созданы.

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

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

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

Создание структуры WBS при разработке ПО

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

Для создания структуры WBS программного проекта следует последователь пройти 5 этапов:

1. Идентифицировать работы, связанные с созданием программного продукта, отделяя их от работ, связанных с аппаратным обеспечением и от рабочих процессов.

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

2. Найти структуру WBS для произвольной системы высшего уровня, отделяя ПО от других систем и компонентов.

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

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

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

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

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

5. Определить категории затрат, связанных с ПО.

Этот последний этап не является необходимым для каждого проекта, однако он является важным, если отслеживаются затраты на уровне единиц в структуре WBS. В некоторых проектах с целью упрощения применяется лишь одна категория затрат (чаще всего - это время, затрачиваемое на разработку). В более сложных проектах требуется большее количество категорий, так как возникает потребность в различных единицах. Так, например, затраты на оборудование обычно оцениваются в деньгах, тогда как трудозатраты - в часах, неделях или месяцах, в течение которых выполняется работа (хотя при необходимости их легко можно представить в денежном эквиваленте). Накладные расходы, например, на управление проектом или контроль изменений могут оцениваться с помощью пропорциональных добавлений в базовые оценки трудозатрат на разработку ПО в виде процентных соотношений.

Сетевое планирование

Сетевая диаграмма (сеть, граф сети, PERT-диаграмма) -- графическое отображение работ проекта и зависимостей между ними. В планировании и управлении проектами под термином «сеть» понимается полный комплекс работ и вех проекта с установленными между ними зависимостями.

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

Существует другой тип сетевой диаграммы -- граф типа «вершина--событие», который на практике используется реже. При данном подходе работа представляется в виде линии между двумя событиями (узлами графа), которые, в свою очередь, отображают начало и конец данной работы. PERT- диаграммы являются примерами этого типа диаграмм. Такие диаграммы удобны для всевозможных расчетов обеспеченности работ ресурсами, в том числе и оптимизационных расчетов. В практике планирования развития программных проектов они применяются довольно редко, когда планируются очень большие комплексы работ, для которых сложно обозреть ресурсные потребности в целом.

...