flarione.ru → Приметы

Что писать в плане проекта. Технологии планирования проектной деятельности

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

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

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

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

Классический маркетинг: знакомство с продуктом, конкурентами, разработка УТП
Подбор семантики
Разработка структуры сайта
Прототипирование
Дизайн
Верстка
Программирование
Тестирование
Запуск

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

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

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

Страницы (маски)	Кол-во страниц	Собрать СЯ	ТЗ от 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;

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

Структура разбиения работ.

Планирование проекта по временным параметрам.

Методы сетевого планирования проекта.

Организация работ по планированию проекта.

Управление проектами: учебное пособие/ А.Г. Ивасенко, Я.И. Никонова, М.В. Каркавин. – Ростов н/д: Феникс, 2009. – С.177-212.

Мазур И.И. Управление проектами: учеб. пособие для студентов, обучающихся по специальности «Менеджмент организации»/И.И. Мазур [и др.]. ; под общ.ред.И.И. Мазура и В.Д. Шапиро.- 6-е изд., стер. - М. : Издательство «Омега-Л», 2010. -960 с.

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

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

На этапе планирования определяются все необходимые параметры реализации проекта:

продолжительность по каждому из контролируемых элементов проекта,

потребность в трудовых, материально-технических и финансовых ресурсах,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общее планирование проекта

Процедура составления плана называется планированием. Планирование выполняет следующие функции:

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

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

Рис. 10.1.

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

Выделение отдельных работ проекта выполняет следующие функции:

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

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

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

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

Пакет работ должен содержать следующую информацию:

1) ожидаемые после завершения работ результаты;
2) ответственные за выполнение отдельных работ пакета;
3) точки пересечения с другими рабочими пакетами или проектами;
4) конкретные действия, задания и сроки;
5) затрата времени (в часах или днях) для выполнения отдельных работ пакета и заданий;
6) расходы на персонал, оборудование, материалы, необходимые для выполнения работ;
7) кодовый номер для идентификации пакета работ;
8) подпись и данные руководителя, ответственного за выполнение работ пакета и подпись менеджера проекта.

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

сроки или временные рамки проекта;
объем выполняемых работ;
согласованное с заказчиком проекта качество выполнения работ.

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

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

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

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

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

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

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

На основании плана делается несколько документов разного предназначения. Для старших менеджеров организации и внешних стейкхолдеров - инвесторов, кредиторов, заказчиков, поставщиков и др. необходимо сделать выдержки из плана на одной-двух страницах - резюме, которое должно быть привязано к ключевым процессам жизненного цикла проекта. Если информации слишком много для размещения на одной-двух страницах, следует придумать способы ее группирования. Например, определить, что "группа работ № 1" - это первоначальное техзадание на разработку проекта; "группа работ № 2" - строительство нового здания; "группа работ № 4" - монтаж и наладка производственного оборудования; "группа работ № 5" - подготовка персонала; "группа работ № 6" - сдача объекта в эксплуатацию.

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

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

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

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

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

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

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

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

Группа процессов планирования представлена на рис. 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. Это дает возможность разработчику или менеджеру проекта видеть, как выполняются различные виды деятельности - последовательно или параллельно, находятся ли они на критическом пути.