Что такое разработка проекта
Работа с проектом: этапы, особенности и артефакты
Начинаем серию статей для быстрого погружения в проджект-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь первый урок в текстовом виде — для тех, кому удобнее читать.
Этапы проекта
Любой проект состоит из четырёх этапов: инициализации, планирования, реализации и завершения. Рассмотрим каждый подробнее.
Инициализация. Заказчик приходит к проджект-менеджеру с запросом. Менеджер анализирует бизнес-идею (определяет содержание и длительность проекта), разрабатывает проектное задание и выполняет стратегическое планирование.
Планирование. Проджект-менеджер определяет, из каких специалистов будет состоять команда, каковы объёмы проекта, его этапы и контрольные точки для сверки с заказчиком. Также выявляет возможные риски и рассчитывает ресурсы.
Реализация. Проджект помогает команде создать конечный продукт или его часть — для этого отслеживает и контролирует каждый из этапов, решает проблемы, информирует заказчика о ходе проекта и управляет изменениями.
Завершение. Проджект-менеджер сдаёт продукт заказчику, оценивает уровень удовлетворённости клиента и приобретённый опыт. Фиксирует успехи, неудачи и их причины, чтобы стать эффективнее и избежать негативного опыта в будущем.
Проектные артефакты
Артефакты проекта — это физические носители информации, которые подтверждают договорённости и позволяют всем членам команды следить за ходом проекта. Например, договор, коммерческое предложение, техническое задание, сопроводительные документы, исполняемые файлы, исходные тексты, веб-страницы, файлы с данными и справочной информацией. При этом универсального набора артефактов не существует — на каждом проекте он свой.
Рассмотрим, как распределяются артефакты на каждом из этапов проекта. При этом от проекта к проекту набор будет немного разным.
Инициализация: техническое задание, коммерческое предложение, договор и приложение к нему, дополнительное соглашение.
Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.
Реализация: акт сдачи-приёмки работ, замечания и доработки.
Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.
Так могут выглядеть основные артефакты по IT-проекту:
Сбор артефактов
Проджект-менеджер собирает артефакты проекта во время согласования требований с заказчиком и уточнения деталей — лучше показаться дотошным и избежать недоразумений, чем поскромничать и недопонять клиента.
Проджект обсуждает требования с командой, чтобы быть уверенным, что каждый понял свою задачу и выполнит работу корректно. Это ещё один этап, на котором формируются артефакты проекта.
Проджект-менеджер согласовывает результаты с конечными пользователями — это подтверждает, что команда делает именно то, что нужно заказчику.
Результаты каждой встречи фиксируются — это позволяет избегать многих неприятных ситуаций. Например, если заказчик попросит разработать новую фичу, которая не была прописана в изначальном техническом задании, — будет возможность обсудить условия дополнительной оплаты и новые сроки. Клиент не сможет сказать, что он говорил о ней ранее и вы обещали реализовать её в рамках стандартной оплаты. Также это не позволит заказчику выставить одни требования, а затем сказать: «Я видел это совсем иначе». У вас всё зафиксировано!
После встречи проджект рассылает её итоги всем участникам проекта, а клиента просит подтвердить, что он тоже ознакомился с ними. Если он не отвечает, то менеджер не стесняется напомнить о письме.
Виды артефактов
Артефакты делятся на формальные и неформальные.
Формальные — обязательные, прописанные в договоре, на которых стоят реквизиты заказчика и исполнителя. Также к формальным артефактам относится документация и элементы, которые указаны в официальных документах. Если в договоре написано, что исполнитель обязан предоставить результаты исследования, то они будут формальным артефактом.
Неформальные артефакты — вся остальная информация: итоги переписок, сообщения в мессенджерах, записи с флипчарта, на котором команда фиксирует ход проекта, стикеры с канбан-доски и даже матрица RACI.
Виды заказчиков
Заказчиков принято разделять по двум принципам. Первый — по традиционному объёму документации, который необходимо вести по проекту. Второй — с точки зрения того, как происходит процесс взаимодействия до запуска проекта. В этой классификации выделяют четыре вида заказчиков:
Есть и другая категоризация заказчиков — по ней они могут быть внутренними и внешними. Внутренний заказчик — это смежный отдел. Если GeekBrains закажет IT-решение у отдела разработки, входящего в Mail.ru Group, то станет для него внутренним заказчиком — всё будет происходить в рамках одной компании. Если GeekBrains поставит задачу разработать IT-решение стороннему подрядчику, то выступит для него внешним заказчиком.
Зона ответственности заказчика
Работая в любом проекте, нужно понимать, к кому и с каким вопросом обращаться: что может решить заказчик, что руководитель, а когда стоит получить больше информации от команды. Чтобы не растеряться в самый неподходящий момент, на старте нужно распределить зоны ответственности. Один из классических инструментов для этого — матрица RACI.
Матрица RACI — это таблица, в которой проджект-менеджер по горизонтали вписывает зоны ответственности, а по вертикали — исполнителей и другие действующие лица на проекте (заказчиков, членов команды, подрядчиков). Этот инструмент помогает распределить ответственность ещё на этапах инициализации и планирования проекта.
В матрице выделяется четыре зоны ответственности: R — responsible (исполняет), A — accountable (несёт ответственность) C — consult before doing (консультирует до исполнения), I — inform after doing (оповещает после исполнения). Рассмотрим это на примере.
По горизонтали прописаны зоны ответственности, а по вертикали — действующие лица. Анна разрабатывает устав, а Бен несёт ответственность за выполнение этой задачи. Если у кого-то из членов команды появится вопрос про устав, он сразу поймёт, к кому обратиться.
Чтобы составить матрицу RACI, нужно выполнить следующие шаги:
При этом важно соблюдать основные принципы:
Удержать все эти вещи в голове непросто, но благодаря практике можно стать эффективным проджект-менеджером. Попробуйте начать свой путь в профессии с бесплатного курса GeekBrains. Желаем удачи!
Начинаем серию статей для быстрого погружения в проджект-менеджмент. Весь курс в видеоформате можно бесплатно пройти на GeekBrains. А здесь первый урок в текстовом виде — для тех, кому удобнее читать.
Этапы проекта
Любой проект состоит из четырёх этапов: инициализации, планирования, реализации и завершения. Рассмотрим каждый подробнее.
Инициализация. Заказчик приходит к проджект-менеджеру с запросом. Менеджер анализирует бизнес-идею (определяет содержание и длительность проекта), разрабатывает проектное задание и выполняет стратегическое планирование.
Планирование. Проджект-менеджер определяет, из каких специалистов будет состоять команда, каковы объёмы проекта, его этапы и контрольные точки для сверки с заказчиком. Также выявляет возможные риски и рассчитывает ресурсы.
Реализация. Проджект помогает команде создать конечный продукт или его часть — для этого отслеживает и контролирует каждый из этапов, решает проблемы, информирует заказчика о ходе проекта и управляет изменениями.
Завершение. Проджект-менеджер сдаёт продукт заказчику, оценивает уровень удовлетворённости клиента и приобретённый опыт. Фиксирует успехи, неудачи и их причины, чтобы стать эффективнее и избежать негативного опыта в будущем.
Проектные артефакты
Артефакты проекта — это физические носители информации, которые подтверждают договорённости и позволяют всем членам команды следить за ходом проекта. Например, договор, коммерческое предложение, техническое задание, сопроводительные документы, исполняемые файлы, исходные тексты, веб-страницы, файлы с данными и справочной информацией. При этом универсального набора артефактов не существует — на каждом проекте он свой.
Рассмотрим, как распределяются артефакты на каждом из этапов проекта. При этом от проекта к проекту набор будет немного разным.
Инициализация: техническое задание, коммерческое предложение, договор и приложение к нему, дополнительное соглашение.
Планирование: план проекта, дорожная карта, точки сверки и ресурсный план.
Реализация: акт сдачи-приёмки работ, замечания и доработки.
Завершение: инструкция по работе, обучение, акт сдачи-приёмки работ.
Так могут выглядеть основные артефакты по IT-проекту:
Сбор артефактов
Проджект-менеджер собирает артефакты проекта во время согласования требований с заказчиком и уточнения деталей — лучше показаться дотошным и избежать недоразумений, чем поскромничать и недопонять клиента.
Проджект обсуждает требования с командой, чтобы быть уверенным, что каждый понял свою задачу и выполнит работу корректно. Это ещё один этап, на котором формируются артефакты проекта.
Проджект-менеджер согласовывает результаты с конечными пользователями — это подтверждает, что команда делает именно то, что нужно заказчику.
Результаты каждой встречи фиксируются — это позволяет избегать многих неприятных ситуаций. Например, если заказчик попросит разработать новую фичу, которая не была прописана в изначальном техническом задании, — будет возможность обсудить условия дополнительной оплаты и новые сроки. Клиент не сможет сказать, что он говорил о ней ранее и вы обещали реализовать её в рамках стандартной оплаты. Также это не позволит заказчику выставить одни требования, а затем сказать: «Я видел это совсем иначе». У вас всё зафиксировано!
После встречи проджект рассылает её итоги всем участникам проекта, а клиента просит подтвердить, что он тоже ознакомился с ними. Если он не отвечает, то менеджер не стесняется напомнить о письме.
Виды артефактов
Артефакты делятся на формальные и неформальные.
Формальные — обязательные, прописанные в договоре, на которых стоят реквизиты заказчика и исполнителя. Также к формальным артефактам относится документация и элементы, которые указаны в официальных документах. Если в договоре написано, что исполнитель обязан предоставить результаты исследования, то они будут формальным артефактом.
Неформальные артефакты — вся остальная информация: итоги переписок, сообщения в мессенджерах, записи с флипчарта, на котором команда фиксирует ход проекта, стикеры с канбан-доски и даже матрица RACI.
Виды заказчиков
Заказчиков принято разделять по двум принципам. Первый — по традиционному объёму документации, который необходимо вести по проекту. Второй — с точки зрения того, как происходит процесс взаимодействия до запуска проекта. В этой классификации выделяют четыре вида заказчиков:
Есть и другая категоризация заказчиков — по ней они могут быть внутренними и внешними. Внутренний заказчик — это смежный отдел. Если GeekBrains закажет IT-решение у отдела разработки, входящего в Mail.ru Group, то станет для него внутренним заказчиком — всё будет происходить в рамках одной компании. Если GeekBrains поставит задачу разработать IT-решение стороннему подрядчику, то выступит для него внешним заказчиком.
Зона ответственности заказчика
Работая в любом проекте, нужно понимать, к кому и с каким вопросом обращаться: что может решить заказчик, что руководитель, а когда стоит получить больше информации от команды. Чтобы не растеряться в самый неподходящий момент, на старте нужно распределить зоны ответственности. Один из классических инструментов для этого — матрица RACI.
Матрица RACI — это таблица, в которой проджект-менеджер по горизонтали вписывает зоны ответственности, а по вертикали — исполнителей и другие действующие лица на проекте (заказчиков, членов команды, подрядчиков). Этот инструмент помогает распределить ответственность ещё на этапах инициализации и планирования проекта.
В матрице выделяется четыре зоны ответственности: R — responsible (исполняет), A — accountable (несёт ответственность) C — consult before doing (консультирует до исполнения), I — inform after doing (оповещает после исполнения). Рассмотрим это на примере.
По горизонтали прописаны зоны ответственности, а по вертикали — действующие лица. Анна разрабатывает устав, а Бен несёт ответственность за выполнение этой задачи. Если у кого-то из членов команды появится вопрос про устав, он сразу поймёт, к кому обратиться.
Чтобы составить матрицу RACI, нужно выполнить следующие шаги:
При этом важно соблюдать основные принципы:
Удержать все эти вещи в голове непросто, но благодаря практике можно стать эффективным проджект-менеджером. Попробуйте начать свой путь в профессии с бесплатного курса GeekBrains. Желаем удачи!
разработка проекта
Смотреть что такое «разработка проекта» в других словарях:
разработка проекта — Совокупность действий, относящихся к определению задач, расписания, ресурсов и порядка реализации проекта. [РД 01.120.00 КТН 228 06] Тематики магистральный нефтепроводный транспорт … Справочник технического переводчика
предварительная разработка проекта — — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN preliminary system designPSD … Справочник технического переводчика
Разработка нефтяных месторождений — (a. oil field exploitation; н. Erdollagerstattenabbau; ф. exploitation des champs de petrole, exploitation petroliere; и. explotacion de yacimientos de petroleo) комплекс работ по извлечению нефт. флюида из пласта коллектора. Добываемые… … Геологическая энциклопедия
разработка плана (проекта программ) — Выработка стратегического замыла, формулировка целей, анализ ресурсных возможностей, путей и способов достижения целей, обоснование избранного варианта действий, состояние, обсуждение, принятие плановых, проектных, программных документов.… … Справочник технического переводчика
разработка эскизного проекта — — [А.С.Гольдберг. Англо русский энергетический словарь. 2006 г.] Тематики энергетика в целом EN contract definition … Справочник технического переводчика
РАЗРАБОТКА — ПЛАНА, проекта, программ выработка стратегического замысла, формулировка целей, анализ ресурсных возможностей, путей и способов достижения целей, обоснование избранного варианта действий, составление, обсуждение, принятие плановых, Проектных,… … Экономический словарь
Разработка компьютерных игр — Разработка игр это процесс создания компьютерных игр. Содержание 1 Обзор 2 Специализации … Википедия
Разработка программного обеспечения — Когда Грейс Хоппер работала с компьютером Гарвард Марк II в Гарвардском университете, её коллеги обнаружили эту моль, застрявшую в реле и таким образом помешавшую работе устройства, после чего она отметила, что они «отлаживали»(debug) систему.… … Википедия
Разработка Duke Nukem Forever — Duke Nukem Forever (DNF, рус. Дюк Нюкем навсегда) компьютерная игра в жанре 3D шутер, которая разрабатывалась компанией 3D Realms и являлась четвёртой частью серии игр Duke Nukem. Разработка DNF началась в 1997 году и велась 14 лет,… … Википедия
Разработка ПО — Разработка программного обеспечения (англ. software engineering, software development) это род деятельности (профессия) и процесс, направленный на создание и поддержание работоспособности, качества и надежности программного обеспечения, используя … Википедия
разработка — 3.6.6. разработка : Стадия конструкторской ПП, выполняемая при помощи CAD системы, в ходе которой разрабатывается подробная 3D мoдeль изделия, а также 3D мoдeли узлов, агрегатов и основных (базовых) деталей, на базе которых формируются 2D… … Словарь-справочник терминов нормативно-технической документации
Урок 1. Разработка и планирование проекта
Прежде чем приступать непосредственно к разговору о разработке и планировании проектов, стоит немного освежить в памяти понимание планирования как такового. Суть планирования заключается в постановке целей и определении способов их достижения посредством создания комплекса мероприятий и действий, необходимых для выполнения, использовании способов и путей осуществления мероприятий и действий, увязки ресурсов, требующихся для выполнения и согласовании функций, выполняемых участниками проекта. Именно с вопроса планирования мы и начнем первый урок (сразу сделаем небольшую оговорку: информации по разработке и планированию проектов очень много, поэтому мы представим ее в концентрированной форме, останавливаясь подробно лишь на наиболее важных моментах).
Планирование проекта
Работа по составлению плана включает в себя все стадии создания и выполнения проекта. Начинается она с разработки концепции проекта руководителем (проект-менеджером), продолжается выбором стратегических решений, разработкой деталей, заключением контрактов и выполнением работ, и заканчивается завершением проекта.
На стадии планирования устанавливаются основные параметры осуществления проекта. К ним относятся:
Любой процесс и любая процедура планирования проекта должны гарантировать осуществляемость проекта в нужные сроки и с соблюдением всех требований, включая стоимость, нормативы и качество. Кроме того, в грамотно организованном проекте за выполнение каждой функции и достижение каждой цели должен нести ответственность отдельный орган: за миссию проекта – проект-менеджер, за частные цели – ответственные лица и т.д. Именно для этого принято разрабатывать матрицу ответственности, определяющую функционал исполнителей и конкретизирующую комплекс их работ.
И здесь мы предлагаем вам поупражняться в планировании проекта и выполнить интересное задание.
Задание на взаимопроверку
Выше вы узнали, что на стадии планирования устанавливаются основные параметры осуществления проекта. Предложите свой план небольшого проекта. При этом обязательно укажите:
Это задание на взаимную проверку, поэтому сначала вам нужно проверить 2 работы других пользователей, а затем загрузить свою. При проверке чужих работ необходимо оценить проекты на предмет детализации, расчета сроков и ресурсов, а также качество выполнения задания в целом.
Напоминаем, что для полноценной работы сайта вам необходимо включить cookies, javascript и iframe. Если вы ввидите это сообщение в течение долгого времени, значит настройки вашего браузера не позволяют нашему порталу полноценно работать.
Уверены, теперь тема планирования проектов стала вам несколько ближе, а потому изучать дальнейшие материал будет интереснее. Давайте же продолжим.
Чем выше уровень управляющего органа, тем более обобщенные он принимает решения по управлению нижестоящими подразделениями. По мере повышения иерархического уровня увеличиваются временные промежутки между постановкой задач, контролем их выполнения и т.д. В этих промежутках нижестоящие подразделения должны работать самостоятельно и вне зависимости от равных им подразделений. Их независимая работа обеспечивается запасами ресурсов, которые также нужно планировать.
Главная цель планирования – это построение модели реализации проекта, необходимой для координации действий причастных к проекту лиц. Благодаря этой модели устанавливается порядок, согласно которому будут проводиться работы и т.д.
На первой стадии планирования проекта разрабатываются первоначальные планы, служащие основой составления проектного бюджета, определения потребностей в ресурсах, организации обеспечения проекта и т.д. Планирование всегда предшествует контролю и считается базой его применения, т.к. позволяет сравнивать плановые и фактические показатели.
Планирование – это наиболее важный для проекта процесс, ведь от него зависит результат. Объем и детализация планирования зависят от полезности информации, которая может быть получена в процессе реализации и обусловлена замыслом самого проекта. Процесс планирования нельзя полностью автоматизировать, т.к. в нем имеется масса переменных параметров. Плюс на него могут влиять случайные факторы.
В дополнение ко всему планирование проекта состоит из ряда основных и вспомогательных процессов.
Основные процессы (присутствуют всегда):
Вспомогательные процессы (присутствуют по мере необходимости):
Представляющие собой результаты планирования планы (сети и графики) в итоге должны выстраиваться в пирамидальную структуру, включающую в себя всю необходимую информацию, дифференцированную по уровням, срокам и т.д. Планирование проекта и систематизация планов выстраиваются по принципам «обратной связи», которые обеспечивают регулярное сравнение плановых и фактических сведений и придают работе больше эффективности, актуальности и гибкости.
Принципы проектного планирования
Принимаемые решения и предпринимаемые действия в сфере проектного планирования основываются на нескольких важных принципах:
Кроме принципов, которые мы назвали, важно учитывать еще и согласованность задач и интересов всех задействованных в разработке и реализации проекта лиц и своевременность достижения поставленных целей в назначенные сроки.
Учитывая особенности планирования проекта и вышеназванные принципы, можно переходить к следующему не менее важному вопросу – разбиению проектных работ на составляющие.
Структура разбиения работ, матрица ответственности, статьи затрат
Структура разбиения работ (СРР) представляет собой иерархическую структуру последовательной разбивки проекта на подпроекты и комплексы детальных работ разного уровня. СРР – это главное средство по созданию системы управления проектом, позволяющее решать разные организационные проблемы, распределять ответственность, оценивать стоимость, создавать систему отчетности, поддерживать сбор данных о выполнении работ и отображать их результаты. Также с помощью СРР удобно согласовывать план проекта с нуждами заказчика.
Для руководителя проекта СРР не менее важна, т.к. позволяет:
Комплексы (пакеты) работ соответствуют, как правило, нижнему уровню детализации СРР и включают в себя детальные работы, которые в свою очередь могут состоять из шагов. Детальные работы и шаги не являются элементами СРР.
СРР можно разрабатывать сверху-вниз (от главного к частному) и снизу-вверх (от частного к главному), либо с применением обоих подходов. Информация для разработки СРР может выявляться при помощи метода мозгового штурма. Итоговая СРР должна учитывать все цели проекта и предпосылки для его реализации.
Детализация СРР зависит от содержания проекта, опыта и навыков команды, системы управления, принципов распределения ответственности, системы отчетности и т.д. Для создания СРР нередко используют функциональные и технические спецификации с общими требованиями к работе.
Благодаря иерархической структуре проекта, основой которой служит СРР, можно использовать процедуры сбора и обработки данных о ходе выполнения проектных работ в соответствии с контрольными точками, пакетами работ и т.д. Также она позволяет обобщать сведения по срокам, ресурсам, затратам и графикам.
Составление СРР может выстраиваться на следующих основаниях:
В практической деятельности почти всегда применяются комбинированные СРР, созданные с применением нескольких оснований, и СРР должна включать в себя все работы проекта, включая детальные работы и шаги.
Одним из важнейших этапов построения СРР является анализ ее полноты, так что если в проекте есть работы, которые контролирует не только проект-менеджер, но и заказчик, они тоже должны быть включены в состав СРР – это и обеспечит полноту структуры.
С учетом информации о плане проектных мероприятий осуществляется разбиение СРР по критериям и признакам проекта. Разбиение происходит до тех пор, пока все важные работы и элементы проекта не будут выделены так, чтобы было возможно их спланировать, определить их бюджет, составить график и план действий по их контролю. Чтобы упростить и автоматизировать СРР, всем ее элементам нужно присвоить идентификатор, соответствующий номеру уровня. Идентификаторы должны отражать критерии разбиения работ.
Не менее важно избегать ряда ошибок при структуризации проекта, а именно нельзя:
СРР – есть основа понимания членами команды сути и зависимостей проектных работ, обеспечивающая последующую согласованную и скоординированную работу всех подразделений.
Упомянутая выше матрица ответственности и структурная схема организации (ССО), реализующей проект, – это два инструмента, помогающие руководителю проекта создавать команду, соответствующую задачам и целям проекта. Применение ССО и СРР при построении матрицы ответственности наглядно отображено на нижеследующем рисунке:
Состав и план проведения проектных работ в огромной степени влияют на форму организационной структуры, необходимой для реализации целей проекта.
Матрица ответственности позволяет обеспечить и согласовать структуры ответственности членов команды (подразделений) за выполнения работ. По сути, это форма описания распределения ответственности за проведение проектных работ, где указываются роли членов команды и/или подразделений. Одна ось матрицы ответственности отображает список пакетов работ по СРР, а другая – список исполнителей, ответственных за их выполнение.
Элементы матрицы – это коды видов работы из составленного заранее списка (также в матрицу можно вносить стоимость работ). Объем видов ответственности обусловлен спецификой проекта и его организации, однако рекомендуется использовать небольшой набор простых для понимания и описания видов деятельности. Ниже представлен пример матрицы ответственности:
В матрице ответственности могут отображаться виды ответственности руководителей и роли людей, помогающих в реализации проекта, но прямого участия в этом не принимающих. Если матрица составлена грамотно, она станет прекрасным инструментом, обеспечивающим и эффективное выполнение работ, и успешную поддержку внутренними и внешними ресурсами.
Ответственные за исполнение работ лица назначаются еще при планировании проекта, т.к. иметь представление о доступных ресурсах нужно еще до принятия мер по реализации плана. После определения ресурсов нужно определить, как они могут быть получены; в частности это касается трудовых ресурсов.
Назначение сотрудников осуществляется поэтапно – сначала формируется рабочая группа, а затем команда проекта, т.к. именно рабочая группа станет костяком будущей команды. Состав же рабочей группы обусловлен задачами и целями проекта. Почти всегда группа состоит из управляющих, авторитетных участников и основного персонала.
Рабочая группа принимает участие в инициации проекта и его планировании. На этом этапе еще нельзя определить ресурсы, т.к. имеются лишь общие сведения о проекте, и более подробные данные будут получены после проведения детальных работ и создания СРР. Итоговое назначение исполнителей и определение их функционала состоится только после окончательной разработки и утверждения плана.
Чтобы правильно назначить ответственных лиц, необходимо знать о нескольких типах ресурсов, которые могут быть использованы:
Несмотря на то, что не всегда исполнители обладают всеми рычагами управления и применения ресурсов, знание семи типов ресурсов значительно упрощает процесс описания проекта и решения вопроса о распределении ответственности, ведь, как уже и был сказано, пакеты работ должны быть обеспечены всем необходимым для их выполнения. А чтобы это сделать, важно ответить на два вопроса:
Как только ответы на эти вопросы будут получены, можно проводить окончательное распределение ответственности.
Здесь же мы должны сказать о дополнительном средстве планирования проектных работ – структуре статей затрат. Ее не следует путать с бухгалтерскими счетами, т.к. по включенным в нее статьям происходит классификация и сбор неподтвержденной документально управленческой информации, необходимой для принятия управленческих решений (имеется в виду, что документации, подтверждающей фактические затраты, нет, но есть предварительные данные об использованных ресурсах, выполненных работах и т.д.).
Статьи затрат – это инструмент управления, который используется с целью сбора данных о фактических затратах выполненных работ и последующего их сравнения с затратами по плану. Эти же статьи применяются для планирования и контроля времени и стоимости, т.к. включают в себя сведения о работах, назначенных, исходя из СРР. Ниже вы можете увидеть пример формирования статей затрат по пакетам работ, за которые ответственны конкретные подразделения (исходя из СРР):
Статьи затрат могут включать в себя данные по множеству пакетов работ, составленных по различным основаниям, таким как:
Подытоживая все вышесказанное о статьях затрат, остается лишь отметить, что они способствуют формированию и мониторингу проектного бюджета, осуществлению текущего управленческого учета и оценке возможных затрат после окончания проектных работ.
Теперь мы можем перейти к рассмотрению наиболее эффективных методов планирования проектов, позволяющих обеспечить своевременное осуществление как проекта в целом, так и отдельных его этапов.
Сетевое планирование проектов
Методы сетевого планирования проектов или, как их еще называют, сетевые диаграммы (граф сеть, PERT-диаграмма) представляют собой графическое отображение проектных работ и имеющихся между ними зависимостей. Понятие «сеть» здесь обозначает полный комплекс работ и контрольных точек проекта с установленными зависимостями между ними.
Сетевые диаграммы отображают сетевую модель в виде графика с рядом вершин, которые соответствуют работам, а связывающие их линии отображают взаимосвязи между этими работами. Граф, часто именуемый диаграммой предшествования-следования или сетью типа «вершина-работа», считается самым распространенным отображением сети. Ниже можно увидеть пример фрагмента такого графа:
Есть также тип сетевой диаграммы, называемый сетью типа «вершина-событие», но в практической работе его применяют не так часто. В этом случае работа имеет вид линии, соединяющей два события (узлы графа), отображающие начало и конец определенной работы. Хорошим примером такой диаграммы является PERT-диаграмма – вот она:
Сетевые диаграммы часто путают с блок-схемами, но это не совсем верно, т.к. отличие сетевой диаграммы состоит в том, что она отображает лишь логические зависимости работ, в то время как блок-схема показывает входы, выходы и процессы. Также в диаграмме нет повторяющихся циклов (петель).
Методами сетевого планирования называют методы, нацеленные на максимальное сокращение продолжительности проекта. Их основой служат метод критического пути (МКП или CPM (от англ. Critical Path Method)) и метод оценки и пересмотра планов (PERT (от англ. Program Evaluation Review Technique)).
Под критическим путем понимается максимально продолжительный путь в сети, а работы, имеющиеся на этом пути, называются критическими. От продолжительности критического пути зависит минимальная продолжительность проектных работ. Общую продолжительность проекта можно сократить посредством сокращения критических работ. Таким образом, задержки по выполнению работ влекут за собой и увеличение продолжительности проекта.
Благодаря методу критического пути можно рассчитать примерные календарные графики выполнения пакета работ, основываясь на логической структуре сети и оценках продолжительности выполнения работ по-отдельности, а также установить общий критический путь для проекта.
Есть также понятие полного резерва (запаса) времени. Это разность между датами позднего и раннего начала или окончания работ. Управленческая суть запаса времени состоит в том, что есть возможность для урегулирования финансовых, ресурсных или технологических ограничений, и руководитель проекта может приостановить работу на имеющийся в резерве срок, не опасаясь отрицательно повлиять на конечный срок завершения проекта. Резерв времени критических работ равен нулю.
Горизонтальная линейная диаграмма, где проектные задачи представлены временными отрезками с конкретными временными параметрами (началом, окончанием, задержками и т.д.) называется диаграммой Гантта, и она тоже является неотъемлемой частью сетевого планирования. Вот ее пример:
Для эффективного планирования удобно использовать и PERT-диаграммы, и граф сети, и диаграмму Гантта. Само же сетевое планирование подразумевает описание всей проектной работы в виде комплекса работ с конкретными взаимосвязями между ними. Чтобы рассчитать и проанализировать сетевой график, обычно применяют набор сетевых операций, называемых процедурами метода критического пути.
Сетевая модель разрабатывается поэтапно:
Списки работ нужно определить, чтобы описать всю деятельность по проекту, включая все детали. Работа – это главный элемент сетевой модели. Пакеты работ обуславливают деятельность, которая должна быть выполнена для достижения проектных результатов. Результаты обычно выделяются контрольными точками.
Перед разработкой сетевой модели нужно удостовериться, что нижний уровень СРР включает все работы, гарантирующие достижение частных проектных целей. Сетевая модель – это результат определения зависимостей между работами и добавления связующих событий и работ. В самой общей форме представленный подход основывается на предположении, что любая работа призвана помочь достичь частной цели. Связующие же работы совсем необязательно должны быть направлены на достижение материального результата, т.к. их целью может быть организация проведения того или иного мероприятия и т.п.
Основная задача проект-менеджера – оценить параметры работ. Для этого могут привлекаться другие участники проекта, ответственные за выполнение отдельных заданий проекта. Оценка продолжительности работ и потребности в финансовых средствах и ресурсах самым прямым образом влияет на актуальность ресурсных и стоимостных планов и календарных графиков, которые составляются после анализа сетевой модели. Такую оценку нужно проводить для каждой из работ. Затем на ее основе обобщаются и формируются уровни СРР в проектном плане.
Чтоб отдельные этапы проекта и весь проект в целом были реализованы своевременно, необходимо также планировать проект по временным параметрам. Рассмотрим этот вопрос подробнее.
Планирование проекта по временным параметрам
Временные параметры следует понимать здесь как временные периоды, в течение которых планируется выполнить работы и пакеты работ, а также точки контроля процесса реализации проекта. Время – важнейший фактор, воздействующий на эффективность осуществления всего замысла.
Сроки реализации элементов проекта и всего проекта всегда планируются заблаговременно, и, конечно же, желательно их минимизировать. Но минимизация сроков ограничена тремя параметрами: техническими возможностями, технологическими требованиями и качеством работ. Все это должно учитываться при планировании.
Планирование по временным параметрам – ключевой элемент проект-менеджмента, включающий в себя несколько составляющих. Этими составляющими являются:
Нередко проект бывает сложно завершить к установленным срокам. Причиной тому служит нечеткое понимание того, чем именно нужно управлять, причем большая часть проблем возникает еще на этапе планирования.
Причиной расхождений с календарным планом могут быть задержки поставок, недостаток ресурсов и т.п. Если же неверно определены масштабы и предметные области проекта, впоследствии придется вносить корректировки в работы и календарный план.
Когда руководитель имеет дело с типовыми повторяющимися проектами, удобно использовать прошлый опыт, позволяющий точно определить время и последовательность действий, хотя на практике проекты повторяются крайне редко.
Если говорить о причинах временных потерь в проекте, то к ним можно отнести:
А еще одной важной составляющей управления проектом по временным параметрам является управление личными временными ресурсами. Это актуально для каждого исполнителя и участника проекта, но в большей степени важно для руководителя, т.к. он ответственен за успех проекта, а значит, ему нужно успевать проделывать массу всевозможных работ.
Для улучшения управления личным временем желательно применять так называемые формы. Форма – это список необходимых для выполнения работ с указанием исполнителей и сроков выполнения. Наиболее приоритетные работы следует переносить во временные блоки планировочного календаря. Планировочный календарь может выглядеть так:
В пустые временные блоки можно вносить внеплановые события или работы меньшей приоритетности. В случаях, когда объем работ больше количества времени, работы могут планироваться на несколько дней вперед. Но злоупотреблять этим не стоит, иначе могут возникнуть задержки в выполнении высокоприоритетных задач. А с учетом того, что в последующие дни приоритет низкоприоритетной работы может повышаться, все задания следует выполнять своевременно.
Для эффективного тайм-менеджмента нужно грамотно устанавливать приоритеты и действовать в соответствии с ними. Руководитель проекта не должен отвлекаться на второстепенные и нечеткие задачи и медлить с принятием важных решений. Также он должен уметь делегировать полномочия.
И последнее, на чем мы заострим внимание в первом уроке, – это некоторые организационные моменты.
Организация работ по проектному планированию
Планирование проекта является процессом формирования решений, которые определяют последовательность проектных работ и мероприятий. Оно играет главенствующую роль в проект-менеджменте, представляя собой организующее начало процесса реализации проекта.
Проектное планирование включает в себя несколько этапов:
План осуществления проекта – это комплексный план, содержащий исчерпывающую систему задач и целей, детальных работ, действий и мероприятий по достижению главной цели проекта. Составлению плана реализации нужно уделять повышенное внимание, стремясь избегать типичных ошибок, таких как:
Несмотря на достаточно большое количество ошибок и их специфичность, обойти их стороной помогает учет всех элементов планирования, о которых мы вам рассказали. Важно только помнить, что планирование проекта – это систематизированное упорядочивание задач, целью которого является достижение основного результата – реализации проекта. А с учетом того, что план всегда содержит в себе указания к действиям и сами действия, его можно смело считать эталоном или ориентиром, с которым будут сравниваться фактические показатели. Если же в результате подобных сопоставлений будут найдены какие-либо расхождения, необходимо предпринимать меры по корректировке плана.
Во втором уроке мы поговорим о другом важном для руководителя элементе проект-менеджмента – управлении командой. Будут рассмотрены такие вопросы, как состав участников проекта, функции проект-менеджера, особенности формирования и развития проектной команды, признаки и состав команды, урегулирование конфликтов и ряд других.
Проверьте свои знания
Если вы хотите проверить свои знания по теме данного урока, можете пройти небольшой тест, состоящий из нескольких вопросов. В каждом вопросе правильным может быть только 1 вариант. После выбора вами одного из вариантов, система автоматически переходит к следующему вопросу. На получаемые вами баллы влияет правильность ваших ответов и затраченное на прохождение время. Обратите внимание, что вопросы каждый раз разные, а варианты перемешиваются.
Напоминаем, что для полноценной работы сайта вам необходимо включить cookies, javascript и iframe. Если вы ввидите это сообщение в течение долгого времени, значит настройки вашего браузера не позволяют нашему порталу полноценно работать.