Технологии планирования проектной деятельности. Планирование проекта: методы и этапы План по составлению проекта

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

Цели, сущность и определение

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

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

Главная задача и основообразующая цель планирования проектирования процессов в управлении – это составление модели для реализации бизнес-идеи в желаемой концепции.

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

Основные стадии реализации планирования проектной деятельности

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

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

Однако весь процесс осуществления плана можно для удобства разделить на несколько стадий:

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

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

7 принципов планирования проектной деятельности

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

Принцип №1: Целенаправленность

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

Принцип №2: Системность

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

Принцип №3: Комплексность

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

Принцип №4: Обеспеченность

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

Принцип №5: Приоритетность

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

Принцип №6: Безопасность

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

Принцип №7: Время

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

Планирование процессов управления: структура

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

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

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

Еще одна схема

Краткий словарь понятий, характеризующих процесс планирования проекта:

• ССО – структурная схема организации;
• СРР – структура разбиения (распределения) работ;
• СДР – структурная декомпозиция работ.

Структура в стандартном формате проекта планируемых работ:

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

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

Виды планирования проектной деятельности

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

• микропроекты (узкая форма реализации проекта индивидуальной инициативы, объёмы которого могут меняться);
• малые проекты (инструменты реализации с малым трудовым и денежным ресурсом, не нуждаются в крупном финансировании);
• мегапроекты (целевые программы, которые в основе несут взаимосвязь с несколькими малыми или средними проектами).

Виды проектной деятельности по срокам реализации:

• краткосрочные;
• среднесрочные;
• долгосрочные.

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

Виды проектного планирования по типу финансирования (бюджетированной основы):

• спонсорские;
• кредитные или инвестируемые;
• бюджетные;
• благотворительные.

Выводы

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

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

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

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

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

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

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

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

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

Полноценная техника планирования включает в себя следующие этапы:

• 1) Определение целей проекта и их описание. Довольно часто проекты начинаются без четкой цели.
• 2) Определение технологических стадий. Для проекта должна быть выбрана технология реализации, определяющая стадии развития проекта. Одной из типичных ошибок планирования является несоответствие плана технологическому циклу.
• 3) Для технологических стадий необходимо определить список задач, указать их взаимосвязи (последовательность) и прогнозируемую длительность (зависит от назначенных ресурсов).
• 4) Необходимо согласовать вопрос о выделяемых проекту ресурсах. Следует отметить, что все ресурсы компании должны распределяться централизованно. Довольно часто возникает ошибка планирования, связанная с тем, что некоторые дефицитные ресурсы используются одновременно в двух разных проектах в одно и тоже время.
• 5) Если определить расценки на ресурсы, бюджет может быть получен также автоматически. Одна из типичных ошибок заключается в том, что бюджет назначают, не обращая внимания на прогнозируемую себестоимость проекта.
• 6) Письменное задание, бюджет и график работ образуют формальный документ "План проекта". Довольно часто перед началом проекта некоторые из указанных документов отсутствуют.

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

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

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

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

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

Таблица 1 - Основные этапы процесса планирования проекта

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

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

• · планирование качества;
• · планирование рисков и мероприятий по работе с ними;
• · организационное планирование;
• · планирование коммуникаций.

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

Рисунок 3 Схема планирования проекта

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

Существуют более простые варианты, такие как сделать Landing Page с помощью сервиса LP Generator или подобного ему. Можно не ограничиваться одностраничником и сделать полноценный сайт на конструкторе сайтов. Это рабочие варианты, я никого не отговариваю от них. Все зависит от целей, которые вы ставите перед сайтом и, соответственно, от ваших требований. Я предлагаю план проекта многостраничного сайта с ориентацией на SEO продвижение без использования конструктора сайтов.

Определение основных блоков работ

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

1. Классический маркетинг: знакомство с продуктом, конкурентами, разработка УТП
2. Подбор семантики
3. Разработка структуры сайта
4. Прототипирование
5. Дизайн
6. Верстка
7. Программирование
8. Тестирование
9. Запуск

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

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

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

Страницы (маски)	Кол-во страниц	Собрать СЯ	ТЗ от SEO специалиста	Текст	Прототип	Дизайн	Верстка	Программирование
Главная	1	1	1	1	1	1	1	1
Корпоративным клиентам	1	1	0	1	1	1	1	1
Услуги (страница раздела)	1	1	1	1	1	1	1	1
Раздел услуги	3	3	3	3	2	2	2	2
Подраздел услуги	7	7	7	7	1	1	1	1
Вопросы и ответы (FAQ)	1	0	1	0	1	1	1	1
Страница отдельной статьи	х	х	х	х	1	1	1	1
Контакты	1	0	1	1	1	1	1	1
О компании	1	0	1	1	1	1	1	0
Цены	1	0	1	0	1	1	1	1
	17	13	16	15	11	11	11	10

Детализация списка задач

Для расчета трудозатрат я стараюсь поделить задачи так, чтобы на каждую задачу можно было назначить одного ответственного специалиста. Сразу к списку задач добавляю колонку «Исполнитель» и расчетное количество часов на выполнение задачи.

Задача	Исполнитель	Часы	Комментарий
Выделение основных услуг и определение конкурентов	Маркетолог	6	Важно для понимания объема сайта. После изучения конкурентов, список может быть скорректирован.
Экспресс-анализ сайтов конкурентов	Маркетолог	24	В зависимости от знания рынка и сложности проекта, время может быть скорректировано.
Формулировка преимуществ и разработка УТП	Маркетолог	8	На основе информации о компании и конкурентах вырабатываем основное предложение и тезисно отвечаем на вопрос: «почему надо купить у нас».
Начальное планирование структуры сайта	Маркетолог	2	Только после этого можно составить базовую структуру сайта, которая выглядит на данном этапе как список страниц.
Сбор семантического ядра и сегментирование	SEO-спец	26	SEO-специалист собирает полный список запросов и объединяет их в смысловые группы. Время я рассчитываю примерно по 2 часа на каждую страницу предварительной структуры сайта (для которых актуально SEO, разумеется). Если уже существует сайт, то следует учесть запросы, по которым сайт уже находится в поисковой выдаче.
Согласование и утверждение сем. ядра	Маркетолог	8	Лучше семантическое ядро согласовать и с заказчиком, чтобы избежать недопонимания в дальнейшем.
Корректировка структуры сайта с учетом сем.ядра	SEO-спец	6	Предложения SEO-специалиста по списку страниц, навигации.
Доработка и согласование структуры сайта с учетом сем.ядра	Маркетолог	4	На данном этапе мы получаем скелет сайта. Дальше я предполагаю наличие типовых страниц. К примеру, что все страницы разных услуг выполнены по одному шаблону.
Базовые рекомендации SEO по контенту для страниц постранично	SEO-спец	8	Чтобы не пришлось переделывать прототипы или даже готовые страницы, я рекомендую, получить SEO пожелания уже на этом этапе. Этот пункт про блоки на странице. Я закладываю 0,5 часа на 1 стр.
SEO ТЗ на контент страниц	SEO-спец	30	Данный пункт про рекомендации по текстам, которые должны быть на страницах. Я закладываю по 2 часа на каждую страницу.
Написание текстов	Копирайтер/Маркетолог	90	Если вам повезло найти хорошего копирайтера, можете доверить написание текстов ему. В большинстве случаев тексты для страниц услуг, уникальных страниц типо «О компании», «404», «Контакты» и т.п. я пишу сама. Время беру по своим меркам, поэтому закладываю по 6 часов на 1 стр. Но от проекта к проекту может меняться.
Прототипирование страниц	Маркетолог	82	Закладываю также по 6 часов на 1 страницу, плюс 2 рабочих дня на главную, так как необходимо подготовить разметку макета, шапку и подвал. Мне удобно делать прототипы параллельно с написанием текстов.
Подготовка ТЗ дизайнеру	Маркетолог	13	Хотя прототипы в Axure RP достаточно наглядные, по некоторым пунктам дизайнеру необходимо дать отдельные рекомендации, особенно в начале. Описать стиль, цветовую гамму. Мне удобно прислать примеры стиля и обсудить устно, чтобы быть уверенной, что мы говорим об одном и том же.
Дизайн главной страницы + рекомендации на адаптив	Дизайнер	16	Так как сейчас невозможно жить без мобильного сайта, то советую подумать об адаптивной версии уже на этом этапе. Показала себя рабочей схема, когда дизайнер готовит не несколько вариантов дизайна, а пишет рекомендации. Времени тратится меньше, а результат одинаковый.
Дизайн остальных страниц + рекомендации на адаптив	Дизайнер	66	Я считаю по 6 часов на страницу. Где-то может быть больше, где-то меньше. В это время закладываю и подготовку верстальщику рекомендаций для адаптивной верстки.
Утверждение и согласование дизайна	Маркетолог	14	На утверждение макетов всегда тратится время, особенно, когда речь идет об утверждении стиля и дизайну первых страниц. Советую заложить в плане время на это.
Подготовка оптимизированных метатегов и H1	SEO-спец	16	В целом этот пункт можно включить в любой момент до запуска сайта, но не забываем!
Составление ТЗ на верстку и программирование	Маркетолог	17	Так как я рассматриваю вариант сайта услуг, то не предполагаю сложных в реализации модулей. Поэтому закладываю 1,5 часа на страницу.
SEO рекомендации для этапа верстка и программирование	SEO-спец	6	Опять же, чтобы не переделывать, лучше сразу готовить сайт с учетом дальнейшего продвижения в поисковиках.
Верстка (адаптивная)	Верстальщик	104	Тут все зависит от сложности макетов. Я предполагаю 2 дня на разворачивание инфраструктуры, подготовку к работе и по 8 часов на 1 стр.
Утверждение и согласование верстки	Маркетолог	24	Можно не включать этот пункт, но проверять верстку, писать правки и принимать все равно придется. В зависимости от команды и проекта на это может уйти достаточно много времени. Поэтому я рекомендую заложить его в проект.
Программирование	Программист	80	Сборка разрозненных страничек в готовый сайт. Вывод в CMS модулей для дальнейшего управления контентом сайта без участия разработчика.
Утверждение и согласование программной части	Маркетолог	15	Честно говоря, кажется, что я мало времени закладываю на эту задачу. Без этого этапа вы 100% не обойдетесь, оставляйте на него время.
Тестирование и отладка	Маркетолог	40	Это задача нажать на все кнопочки, посмотреть все странички, попробовать все функции в CMS и проверить сайт в разных браузерах и на разных устройствах. Если проект небольшой, то может быть достаточно проверки своими силами, для сложных подключаем тестировщиков.
Запуск боевой версии сайта	Программист	8	До этого момента все проверки шли на тестовой площадке. Только сейчас переходим на открытый сайт для пользователей.
Подключение аналитики+CallTouch+настройка целей	Маркетолог/Программист	16	Опциональный пункт, который начинает становится нормой, так как без аналитики невозможно понять, на сколько сайт справляется со своими задачами.
Рекомендации по первичная SEO-оптимизации	SEO-спец	8	Внимательно слушаем, что нам говорит SEO-специалист и выполняем его рекомендации. Если изначально сайт готовился по текущему плану, то доработок должно быть минимум, но robots.txt и карту сайта готовим только сейчас.
Реализация SEO-рекомендаций	Верстальщик/Программист	16	Рассчитываю 2 рабочих дня.
Проверка применения SEO-рекомендаций на тестовой площадке	Маркетолог	4
Применение SEO-рекомендаций на основном сайте	Программист	3

Расчет сроков проекта

Большая часть работы сделана, дальше расписываем полученные часы по дням. Некоторые этапы будут идти параллельно. Я привожу для примера расчет, когда над проектом работает 1 специалист каждого направления, соответственно, максимальное количество рабочих часов в день – 8 часов на специалиста.

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

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

Также добавляю общую таблицу по срокам проекта.

	Часов	Дни
Итого время на проект:	760	62
Рабочих дней в мес		20
Срок проекта (мес.)		3.1

Я понимаю, что 62 дня не равняется 760 часам. Разница обусловлена за счет одновременного выполнения части задач разными специалистами.

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

03.03.2017

Шаги от «А» до «Я» для новичков и опытных

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

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

Основные требования, которым должен отвечать проект:

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

время – проект должен быть ограниченным по времени;

ресурсы – проект должен иметь четкое описание потребностей;

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

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

Как написать и оформить проект? Шаги от «А» до «Я»

Шаг №1: Определитесь с идеей, проанализируйте проблему.

Что бы вы хотели изменить?

Чего и каким способом (в самом общем плане) бы вы хотели достичь?

Какую проблему хотите решить?

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

Шаг №2: Пишем цель проекта.

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

Цель должна формулироваться так, чтобы её достижение полностью решало возникшую проблему. Формулировка цели должна опираться на формулировку проблемы. Можно сказать, что цель - это проблема наоборот.

Задайте вопросы для цели своего проекта:

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

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

Реальна ли поставленная цель? Возможно ли достижение заявленной цели с учетом имеющихся ресурсов?

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

Шаг №3: Пишем задачи проекта.

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

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

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

Проверьте . Задачи должны полностью «закрывать» решение проблемы (поставленную цель).

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

Шаг №4: Проверяем цель и задачи по критерию smart.

Смотрим на нашу цель и задачи, проверяем их по критерию SMART, при необходимости корректируем.

	Конкретность (specific)
	Измеримость (measurable)
	Достижимость (achievable)
	Выгодность (rewarding)
	Временные рамки (time bound)

Например: Цель: «Строительство дома» - может быть конкретизирована по критерию SMART следующим образом: «Строительство и сдача в эксплуатацию 2-этажного, 6-квартирного дома для семей молодых специалистов поселка Вычегда ко второму кварталу 2014 года».

Шаг №5. Из задач строим логическую цепочку действий.

Определили цель и задачи → Приступаем к планированию: как все это будет.

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

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

непосредственно строительством

согласованиями с органами государственной власти

с работой с целевой аудиторией – семьями молодых специалистов

работой с прессой по PR проекта и события в целом.

Эта логическая цепочка поможет нам написать план-график проекта в его логической последовательности.

Шаг № 6. Пишем план действий, график выполнения работ.

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

Например: План реализации проекта. Пример №1

План реализации проекта. Пример №2

План реализации проекта. Пример №3

Также полезно будет сделать сетевой план – график.

Шаг №7. считаем, сколько будет стоить наш проект.

Каждый этап реализации проекта требует определенной затраты денежных средств и ресурсов:

сколько денег требуется для реализации проекта? На что они будут потрачены?

из каких источников предполагается получить деньги? Гранты, субсидии, спонсорские средства, иное?

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

Возможный вариант сметы расходов в рамках проекта:

	Наименование статей и расходов	Расчет суммы затрат	Финансовые затраты по проекту
			Имеющиеся средства	Запрашиваемые средства

«Бюджет» (смета) должен быть расписан по статьям.

Основные расходы:

аренда помещений и коммунальные платежи

командировочные и транспортные расходы

оборудование

связь и коммуникации

проведение специальных мероприятий

издательские расходы

расходные материалы

и другие прямые расходы, которые непосредственно идут в рамках вашего проекта.

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

«Оплата труда» - включает непосредственно заработную плату персонала проекта и привлекаемых на время по договору специалистов, а также “Начисления налогов на доходы” – 35,8% от общего фонда оплаты труда персонала и привлеченных специалистов.

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

Если организация, вы или спонсоры предоставляют для реализации проекта какую-либо оргтехнику, то в столбце «имеется» стоит указать её примерную стоимость с учетом срока эксплуатации.

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

Шаг №8. Пишем результаты.

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

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

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

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

Эффективность - соизмеримы ли полученные результаты с затраченными усилиями.

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

Шаг №9. оформляем проект.

Оформленный проект обычно содержит следующие разделы:

Краткая аннотация проекта: кратко опишите вашу идею (3-5 предложений), цели, результаты (не более 1 листа А4, 12-14 шрифт)

Подробное описание проекта:

Актуальность проблемы, почему именно ваш проект важен и нужен.

Цели и задачи проекта.

Целевая группа проекта: на кого рассчитан ваш проект, для кого вы его делаете.

Механизм реализации проекта: этапы, содержательная деятельность, мероприятия и т.д.

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

Бюджет (смета).

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

Возможное дальнейшее развитие проекта, если предполагается.

приложения (фото-материалы, схемы, эскизы и т.д.)

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

Если вам необходимо сделать презентацию:

на каждый раздел не более 1-2 слайдов;

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

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

Основные функции планирования приведены далее.

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

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

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

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

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

Группа процессов планирования представлена на рис. 3.10. Эти процессы могут повторяться и входить в состав итерационной процедуры, выполняемой до достижения определенного результата. Например, если первоначальная дата завершения проекта неприемлема, то требуемые ресурсы, стоимость, а иногда и содержание про-( Группы процессов ^управления проектом

Группа процессов планирования

Управление человеческими ресурсами проекта

Планирование

Разработка плана управления челове-ческими ресурсами

Определение

Управление сроками проекта

Определение

операций

Управление

целостностью

Планирование закупок

Управление стоимостью проект^

Оценка стоимости

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

Разработка плана управления проектом

Определение

последовательности

операций

ресурсов операций

Планирование

качества

длительности

операций

Разработка

расписания

Управление рисками проекта

Определение

Планирование

управления

риском

Проведение качественнного анализа рисков

Проведение количественного анализа рисков

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

Рис. ЗЛО. Процессы планирования

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

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

Планирование в том или ином виде выполняется в течение всего срока реализации проекта. В начале ЖЦ проекта обычно разрабатывается неофициальный первоначальный план - грубое представление о том, что потребуется выполнить в случае реализации проекта. Решение о выборе проекта в значительной мере базируется на оценках этого первоначального плана. Формальное и детальное планирование проекта начинается после принятия решения о его реализации.

Планирование заключается в составлении следующих планов :

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

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

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

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

Сетевой план с несколькими проектами (для высшего руководства)

Уровень 1

Уровень 3

Уровень 2

Сетевой план с ключевыми этапами (вехами)

Детальный сетевой план

Рис. 3.11. Многоуровневые сетевые планы

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

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

Детальное (оперативное , тактическое) планирование связано с разработкой тактических, детальных планов (графиков) на основе иерархической структуры работ (ИСР) для оперативного управления

на уровне ответственных исполнителей.

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

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

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

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

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

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

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

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

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

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

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

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

План управления качеством должен включать в себя следующие работы:

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

Уточнение содержания и состава работ. Уточнение содержания (декомпозиция) проекта - одна из важнейших составных частей дисциплины управления проектами. Детализация позволяет оценить, например, общую стоимость проекта через совокупность стоимости отдельных его работ. Результат детализации содержания проекта есть структура декомпозиции работ (Work Breakdown Structure - WBS). В большинстве случаев такая структура является иерархической. При этом сам процесс детализации - это структурная декомпозиция работ , т.е. деятельность по созданию детализированной структуры работ или задач проекта.

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

Выполнять декомпозицию работ проекта можно по-разному. Например, ГОСТ 19.102-77 предусматривает каскадный подход и определяет следующие стадии разработки программной системы.

• 1) техническое задание;
• 2) эскизный проект;
• 3) технический проект;
• 4) рабочий проект;
• 5) внедрение.

Если следовать этому стандарту, то на первом уровне ИСР должны находиться именно эти проектные продукты. Если бы пришлось разрабатывать АСУ для управления ядерным реактором или пилотируемым космическим аппаратом, то именно так и следовало поступать. Однако в коммерческой разработке ПО такой подход неэффективен.

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

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

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

В общем случае можно говорить о детализации : «программа - проект - задача - операция». На рис. 3.12 представлен пример такой детализации (показаны только операции Задачи А).

Рис. 3.12. Пример применения терминов: программа, проект, задача, операция

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

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

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

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

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

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

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

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

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

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

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

СТОИМОСТЬ = {а + Ь?)т(Х),

где 5 - некая оценка размера системы; а, Ь, с - эмпирические константы; X - вектор факторов стоимости размерностью пт - регулирующий множитель, основанный на затратных факторах.

Более упрощенная оценка, полученная экспериментальным путем, выражается в следующем виде:

СТОИМОСТЬ = 5,255 0,91 .

Эти оценки были получены на основе анализа проектов, где программы имели размер от 4000 до 467 000 строк кода и были написаны на 28 различных языках программирования для 66 компьютеров. На разработку было затрачено от 12 до 11 758 чел.-мес. Известны и другие техники эмпирического моделирования.

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

Базовой моделью экспериментальной оценки стоимости проекта на сегодняшний день служит следующее уравнение:

СТОИМОСТЬ = bS c m(X),

где bS c - первичная оценка, которая корректируется с помощью вектора стоимости т(Х) и учета числа старых и новых объектов; с - параметр, который изменяется от нуля до единицы для первой стадии ведения проекта и от 1,01 до 1,26 - для остальных стадий.

При формализованном подходе выполнение оценки проекта основывается на использовании LOC- и FP-метрик.

Конструктивная модель стоимости (СОСОМО - Constructive cost model), предложенная Б. Боэмом, объединила в себе наиболее известные формализованные техники оценки проекта - LOC-оценки (LOC - Lines of Code), которые базируются на числе строк программного кода. В процессе применения этой модели формируются предварительные оценки, позволяющие предъявить заказчику корректные требования по стоимости и затратам на разработку ПП, а также обеспечивается возможность составления плана ПП.

Функционально-ориентированные FP-метрики вместо подсчета LOC-оценки косвенно измеряют программный продукт. Рассматривается не размер, а функциональность или полезность продукта. Автором этой метрики является А. Албрехт. Определение функционального размера состоит из нескольких шагов и начинается с идентификации функций, которые должно иметь приложение. Международная группа пользователей функционального измерения (IFPUG - International Function Point Users Group) опубликовала критерии, по которым определяются функции приложения. При расчете FP-метрики используются пять информационных характеристик: количество внешних вводов; количество внешних выводов (выводы означают отчеты, экраны, распечатки, сообщения об ошибках); количество внешних запросов; количество внутренних логических файлов; количество внешних интерфейсных файлов.

После сбора всей необходимой информации приступают к расчету метрики - определяют количество функциональных указателей FP (Function Points) по некой формуле, где значения входящих коэффициентов регулировки сложности (каждый коэффициент может принимать значения: 0 - нет влияния; 1 - случайное; 2 - небольшое; 3 - среднее; 4 - важное; 5 - основное) выбираются эмпирически в результате ответов на 14 вопросов, которые характеризуют системные параметры приложения.

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

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

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

С помощью стандартных таблиц FP-оценки можно легко пересчитать в LOC-оценки, т.е. по функциональному размеру вычислить количество строк кода. Однако результаты пересчета зависят от языка программирования, используемого для реализации ПО (например, на Java одна единица функционального размера равна 53 строкам исходного кода). В свою очередь, количество строк кода позволяет определить общую трудоемкость, выраженную в чел.-мес., и сроки проекта.

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

Пример 3.1. Рассмотрим порядок выполнения процедуры оценки работ на основе ШС-метрики.

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

оценить индивидуально

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

Этап 3. Для каждой функцииf t определяется ожидаемое значение оценки:

ЮС Я + ЮС Х + 4 ЬОС^ ож = 6 "

юс.

Этап 4. Вычисляется значение ШС-производительности разработки функции в соответствии с одним из трех правил.

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

ПР, = ПР ср; / = 1, 2, ..., п.

Правило Б. Для /-й функции на основе метрики средней производительности вычисляется настраиваемая величина производительности:

ыс ср

МС ож ’

где ЮС ср - средняя ЬОС-оценка, взятая из метрического базиса (соответствует средней производительности).

Правило В. Для /-й функции настраиваемая величина производительности вычисляется по выбранному аналогу (взятому из метрического базиса):

ЬОСднІ

мс ожі

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

Этап 5. Вычисляется общая оценка затрат (чел.-мес.) на проект, если используется правило А:

если используется правило Б или В:

Ь1У ^ож/

Этап 6. Вычисляется общая оценка стоимости проекта, если используется правило А или Б:

СТОИМОСТЬ = УДСТ ср?юС 0Ж/ ;

если используется правило В:

СТОИМОСТЬ = УДСТ ан/ ^ЮС 0Ж/ ,

где УДСТ ср - метрика средней стоимости одной строки программного кода; УДСТ ан, - метрика стоимости одной строки аналога (обе метрики берутся из метрического базиса).

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

Базовое расписание в большинстве случаев является элементом контракта с заказчиком. Контрольные точки {вехи) служат точками анализа состояния проекта и принятия решения в формате «§о или по1 §о», поэтому они должны зримо демонстрировать статус проекта. Предъявляются определенные требования к выбору и формированию контрольных точек, например контрольная точка «Проектирование завершено» является малоинформативной, более эффективным подходом считается метод последовательных поставок: вышеназванная контрольная точка формулируется в форме «Завершено тестирование требований 1, 3, 5, и 7».

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

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

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

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

Требования График

к проекту

Рис. 3.13. Шаги составления графика работ на проекте

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

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

На этапе планирования могут использоваться также сетевая разбивка работ и диаграмма Ганта.

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

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

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

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

Фаза и

Шаг 1 Шаг 2

Рис. 3.14. Пошаговый граф плана проекта

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

Рис. 3.15.

вершины и входящей в заключительную вершину, соответствует временная отметка «ноль».

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

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

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

План проекта			Ь Эльвест К., Горичева Р., Иванникова О., Плотникова О.
Спецификация требований
2.1. Первичный список требований				Горичева Р.
2.2. Модели требований			Плотникова О.
2.3. Высокоуровневая архитектура системы				к Сорокина О., Эльвест К.
2.4. Критерии аттестации системы				Иванникова О.
2.5. Мифологическая модель базы данных				Счетчикова А.
2.6. Глоссарий				Горичева Р., Плотникова О.
Документация проектирования
3.1. Проект архитектуры			Н Эльвест К.
3.2. Проект интерфейса пользователя			| Счетчикова А., Плотникова О.
3.3. Проект подсистем			I Сорокина О.
3.4. Модель базы данных			Н Иванникова О.
3.5. План тестирования				Ь Горичева Р.
Документ реализации
4.1. Обзор реализации					Счетчикова А., Сорокі		ша О., Ива
4.2. Руководство пользователя					Эльвест К., Горичева
Документ о выполнении тестирования
5.1. Тестирование методом белого ящика				Н Счетчикова А.,			Сорокина
5.2. Интеграционное тестирование		1^ Эльвест К					Плотник
5.3. Аттестационное тестирование							чева Р., Иі
Завершение и сдача проекта							Счетчико

Рис. 3.16. Диаграмма Ганта

Группа процессов исполнения

Группы процессов правления проектом

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

Обеспечение

качества

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