Основные методы и инструменты управления качеством проектов. Основные инструменты проектного менеджмента

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

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

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

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

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

Руководители образуют координационную группу, в задачи которой входит:

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

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

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

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

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

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

Четкая формулировка проблемы и постановка задачи важна для:

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

В современном менеджменте действуют девизы:

- Семь раз отмерь, один раз отрежь!
- Подумай, прежде чем делать!

В этапах выполнения проекта принимаются решения:

· нужно продолжать или скорректировать задания;
· не надо ли уточнить последний этап;
· форма завершения последнего этапа.

Подразделение на этапы позволяет контролировать ход выполнения проекта.

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

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

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

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

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

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

В понятие структуры разбиения работ входят:

· структура -- совокупность отношений между элементами системы, необходимых и достаточных для достижения цели проекта;
· разбиение -- разделение на составные части или категории,на более простые составные части, декомпозиция;
· работа -- продолжительное физическое или умственное усилие направленное на достижение результата; деятельность обязанность, функция, операция, выполняемая сотрудником или коллективом; часть трудового процесса, требующего затрат времени и ресурсов Управление организацией: Учебник / Под ред. А.Г.Поршнева, З.П.Румянцевой, Н.А.Саломатина. - 2-е изд., перераб. и доп.-М.:ИНФРА-М, 1998.-669 с. - с.43.

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

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

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

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

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

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

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

При разработке дерева работ необходима формализация представления о конечном продукте проекта:

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

Общий процесс создания структуры разбиения работ проекта состоит из следующих шагов:

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

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

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

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

Пример шаблона структур разбиения работ

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

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

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

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

1. Битрикс24

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

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

2. Jira

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

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

3. Asana

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

Отдельно стоит упомянуть, что функциональность продукта расширяется с помощью подключения сторонних сервисов: от Dropbox и Google Drive до Zapier и Bitbucket.

4. ActiveCollab

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

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

5. Slack

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

И, конечно, в Slack доступны боты в больших количествах. Мессенджер попытался взять лучшее от своих прародителей вроде IRC и Jabber.

6. Wrike

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

Отдельно указывается, что есть функция создания отчетов для экономии времени. Дополнение к Outlook и Apple Mail помогает создавать задачи напрямую из писем.

7. MS Project

Старожил рынка, не так давно получивший и онлайн-версию. Очень популярен у западных пользователей и едва ли не синоним диаграммы Ганта. Позволяет планировать проекты, управлять ресурсами, планировать сценарии вида «что, если» и следить за дедлайнами и прогрессом. Плотно интегрируется с Microsoft Office последних версий, SharePoint.

Требует очень много времени на освоение. Его внедрение - целая история для компании.

8. Evernote

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

Сам проект идеально подходит именно для последней задачи.

9. Trello

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

Главный плюс проекта - возможность быстро и просто увидеть проект «с высоты птичьего полета» и визуально оценить степень готовности.

10. Basecamp

Один из первопроходцев систем управления проектами «новой волны», запущен в 2004 году. Среди возможностей: ведение списков, просмотр расписания сотрудников и команд, хранение файлов и групповой чат. При помощи API можно подключать сторонние приложения. За14 лет проект сохранил свою главную черту: функциональную простоту.

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

Выводы

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

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

«Из всех трудностей, с которыми столкнулись НАСА, отправляя человека на Луну, управление было наверно самой сложной задачей»

— Роджер Лаунис, историк НАСА

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

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

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

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

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

В этой статье мы рассмотрим:

Классический проектный менеджмент
Agile
Scrum
Lean
Kanban
Six Sigma
PRINCE2

И прежде чем рассматривать конкретные методы, давайте ответим на очевидный вопрос – «А зачем вообще нужны системы и методы управления проектами?» – рассмотрим, естественно, кратко, историю управления проектами и определим базовые термины проектного управления.

Почему «управление проектами»?

Имена Нила Армстронга и Базза Олдрина навсегда войдут в историю как символы одного из величайших достижений человечества – высадке человека на Луну. Однако основной вклад в это событие внесли 400 000 сотрудников НАСА и 20 000 компаний и университетов, работавших вместе над миссией «Аполлон».

В 1961 году Джон Кеннеди поставил задачу высадить человека на спутнике Земли и вернуть его обратно – при том, что на тот момент НАСА отправляли человека в космос лишь на 15 минут. Такая амбициозная цель потребовала невероятного количества ресурсов, кооперации, инноваций и планирования.

Как говорится в книге НАСА «Managing the Moon Program», основная проблема состояла не в том, «что делать?» , а в том, «как сделать столько за такой короткий срок?». По словам доктора Макса Фагета (Dr. Max Faget), главы инжиниринга в Космическом центра имени Линдона Джонсона (The Lyndon B. Johnson Space Center, JSC) , тогда в НАСА не представляли, как уложить все необходимые действия в 10 лет. А потому первым шагом стало «разбить проект на управляемые этапы».

Затем важно было ускорить выполнение каждой отдельной фазы и удостовериться, что команды и компании, работающие на каждой фазе, эффективно взаимодействуют друг с другом и вовремя поставляют результаты. Эта задача была возложена на доктора Джорджа Мюллера (George E. Muller), управлявшего каждой частью проекта «Аполлон», от Белого Дома до поставщика самой мелкой детали. Чтобы контролировать проект было легче, он решил разбить проект на 5 областей: «Контроль Программы», «Системная Инженерия», «Тестирование», «Надёжность и Качество» и «Лётная эксплуатация». Схема управления программой Аполлон представлена на Рисунке 1 .

Эта система из 5 этапов – названных «Этапами GEM» в честь инициалов доктора Мюллера – была разработаны «ради фокусировки на тестировании продукта, и на его разработке с учётом того, что его будут тестировать», как отмечает сам Мюллер. «Контроль Программы» определял, что нужно сделать, управлял бюджетом и требованиями, а также управлял взаимосвязями элементов программы. Область «Системная инженерия» отвечала за разработку новых устройств и узлов, «Тестирование» за то, что эти новые элементы работают, «Надёжность и Качество» проверяли разработанные элементы на соответствие требованиям и стандартам, а «Лётная эксплуатация» отвечала за то, что эти узлы будут работать во время полёта.

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

Краткая история проектного управления

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

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

Однако, если Вы – шеф-повар, и готовите не одно блюдо, а несколько, например, салат (приготовление которого состоит из 3 этапов) и десерт (который нужно только подать), то Вам потребуется инструмент, позволяющий отслеживать временные затраты на каждый из элементов и время, когда они должны быть готовы. И тут на помощь приходит один из первых современных инструментов проектного управления: Диаграмма Гантта, представленная на Рисунке 2 .

Изобретённая независимо Ко ролем Адамеки (Korol Adamecki) и Генри Л. Ганттом (Genry L. Gantt) в начале XX в., диаграмма Гантта показывает расписание проекта основываясь на датах окончания и завершения задач. В неё вносятся задачи, их длительности и взаимосвязи, а затем высчитывается критический путь – самая длинная цепочка взаимосвязанных задач, определяющих длительность проекта. Взаимосвязи между началом и окончанием разных задач очень важны – вы же не можете подать гостям суп, пока вы его не сварили, не так ли?

Так вот, типовой проект очень похож на проект приготовления и подачи ужина, только в нём гораздо больше задач, взаимосвязей, дедлайнов и видов ресурсов. Проектам с жёсткими дедлайнами диаграмма Гантта помогает решить, когда лучше начинать те или иные задачи, чтобы сократить время реализации. А для проектов с сильными ресурсными ограничениями, диаграмма Гантта предоставляет возможность построить схему в форме событийной цепочки процессов (event-driven process chain) для планирования ресурсов.

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

Для таких проектов лучше подходят гибкие методы управления проектами Agile и связанные с ним подходы, такие как Lean, Kanban и другие. Есть и методы, позволяющие управлять как рабочим потоком, так и временем, и ресурсами – 6 Сигм и Scrum.

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

Наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень не завершив предыдущий. Схема рабочего процесса приведена на Рисунке 3 .

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

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

5 этапов традиционного менеджмента:

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

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

Этап 3. Разработка. Данная стадия реализуется не для всех проектов — как правило она является частью фазы планирования. В фазе разработки, характерной для технологических проектов, определяется конфигурация будущего проекта и/или продукта и технические способы его достижения. Например в ИТ-проектах на данном этапе выбирается язык программирования. (В отечественной практике данная фаза обычно не выделяется, а термин «разработка» не используется — прим. пер.)

Этап 4. Реализация и тестирование. На этой фазе происходит собственно основная работа по проекту – написание кода, возведение здания и тому подобное. Следуя разработанным планам начинает создаваться содержание проекта, определённое ранее, проводится контроль по выбранным метрикам. Во второй части данной фазы происходит тестирование продукта, он проверяется на соответствие требованиям Заказчика и заинтересованных сторон. В части тестирования выявляются и исправляются недостатки продукта.

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

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

Благодаря тому, что классический проектный менеджмент строго привязан ко времени исполнения задач, как правило, заранее определённому на этапе планирования, для реализации проектов в рамках данного подхода отлично подходят инструменты календарно-сетевого планирования. Самым распространённым инструментом календарно-сетевого планирования является уже упомянутая ранее диаграмма Гантта. Существует множество инструментов для её построения – от простых таблиц вроде Excel и Smartsheet до профессиональных программных пакетов вроде Microsoft Project и Primavera.

Сильные стороны классического проектного менеджмента

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

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

Слабые стороны классического проектного менеджмента

Основная слабая сторона классического проектного менеджмента – нетолерантность к изменениям. Руководство компании Toyota, знаменитую созданием таких систем как Lean и Kanban, часто критикуют за то, что они применяют классический подход в разработке софта для своей компании, причём именно за недостаток гибкости.

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

Agile

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

И тут в игру вступает Agile – семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на Рисунке 5 .

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

Несмотря на то, что Agile вошёл в моду относительно недавно, идея итеративной разработки не нова (об истории появления Agile можно прочесть – прим.пер.). Своё нынешнее название семейство гибких методологий получило в 2001 с публикации Манифеста Agile (Agile Manifesto) , закрепившем основные ценности и принципы гибкой разработки программного обеспечения, в основе которых – командная работа и адаптация, даже «любовь» к изменениям.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): Scrum, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

Сильные стороны Agile

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

Один из принципов Agile: «Реакция на изменения важнее следования плану». Именно быстрая и относительно безболезненная реакция на изменения является причиной тому, что многие крупные компании стремятся сделать свои процессы более гибкими. Кроме того, Agile отлично подходит для проектов с «открытым концом» — например, запуску сервиса или блога.

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

Слабые стороны Agile

В отличие от PRINCE2 и PMBOK Agile – не является ни методологией, ни стандартом. Agile — это набор принципов и ценностей. Слабая сторона состоит в том, что каждой команде придётся самостоятельно составлять свою систему управления, руководствуясь принципами Agile. Это непростой и длительный процесс, который потребует изменений всей организации, начиная процедурами и заканчивая базовыми ценностями. Это тернистый путь и не всем организациям он под силу.

Этот путь потребует от лидера изменений не только знаний и упорства, но и серьёзных административных ресурсов, а также затрат. К счастью, существуют готовые наборы практик, которые облегчают Agile-трансформацию организации. К таким наборам относятся фреймворк Scrum, метод Kanban и многие другие – Crystal, LeSS, SAFe, Nexus.

Scrum

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

Следуя заветам Agile, Scrum разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в Scrum, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, Scrum Мастер (Scrum Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. Scrum Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики Scrum. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов Scrum вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

Многим Scrum может показаться сложным для внедрения – новый процесс, новые роли, много делегирования и совершенно новая организационная структура. Но это гибкий и при этом структурированный подход к реализации проектов, который, в отличие от размытых и общих принципов Agile, не позволит работе пойти не в то русло.

Сильные стороны Scrum

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

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

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

Слабые стороны Scrum

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

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

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

Lean

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

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

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

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

Сильные стороны Lean

Если Вам нравятся идеи Agile, но проект требует очень ровного качества и чёткого исполнения, Lean предоставляет набор инструментов для того, чтобы удовлетворить эти требования. Lean сочетает гибкость и структурированность, как Scrum, но в немного другом ключе.

Слабые стороны Lean

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

А ещё, в отличие от Scrum, Lean не предлагает чёткого рабочего процесса для реализации «кусочков» проекта, что способствует растягиванию сроков проекта. Эта проблема может быть решена при помощи эффективного руководства и чётких коммуникаций ̶ главное помнить об этом.

Kanban

Lean выглядит немного абстрактным сам по себе, но в комбинации с Kanban его становится гораздо проще использовать для построения собственной системы управления проектами. Созданный инженером компании Toyota Тайичи Оно (Taiichi Ono) в 1953 году, Kanban очень похож на схему промышленного производства. На входе в этот процесс попадает кусочек металла, а на выходе получается готовая деталь. Также и в Kanban, инкремент продукта передаётся вперёд с этапа на этап, а в конце получается готовый к поставке элемент.

Кроме того, создатель Kanban вдохновлялся супермаркетами, а именно их принципом – «держи на полках только то, что нужно клиенту». А потому в Kanban разрешается оставить неоконченную задачу на одном из этапов, если её приоритет изменился и есть другие срочные задачи. Неотредактированная статья для блога, подвешенная без даты публикации или часть кода функции, которую возможно не будут включать в продукт – всё это нормально для работы по Kanban.

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

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

Ваша собственная система Kanban может быть настолько гибкой, насколько Вы сами того пожелаете – ведь во многом Kanban является визуализацией идеи Agile. Но у Kanban есть 4 столпа, на которых держится вся система:

Карточки: Для каждой задачи создаётся индивидуальная карточка, в которую заносится вся необходима информация о задаче. Таким образом, вся нужная информация о задаче всегда под рукой.
Ограничение на количество задач на этапе: Количество карточек на одном этапе строго регламентировано. Благодаря этому сразу становится видно, когда в потоке операций возникает «затор», который оперативно устраняется.
Непрерывный поток: Задачи из беклога попадают в поток в порядке приоритета. Таким образом, работа никогда не прекращается.
Постоянное улучшение («кайзен» (kaizen)): Концепция постоянного улучшения появилась в Японии в конце XX века. Её суть в постоянном анализе производственного процесса и поиске путей повышения производительности.

Сильные стороны Kanban

Как и Scrum, Kanban хорошо подходит для достаточно сплочённых команды с хорошей коммуникацией. Но в отличие от Scrum, в Kanban нет установленных чётких дедлайнов, что хорошо подходит для замотивированных и опытных команд.

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

Слабые стороны Kanban

Часто можно слышать, что по Kanban, в отличие от Scrum, можно работать с практически любой командой. Но это не совсем так. Kanban лучше всего подходит для команд, навыки членов которых пересекаются друг с другом. Таким образом они могут помогать друг другу преодолевать трудности при решении задач. Без этого Kanban будет не так эффективен, как мог бы быть. Также, как уже было сказано, Kanban лучше подходит в тех случаях, когда нет жёстких дедлайнов. Для жёстких дедлайнов лучше подходит классический подход или Scrum.

6 сигм (Six Sigma)

Компания Motorola, наряду с Toyota, также внесла вклад в развитие мирового проектного управления. Инженер этой компании Bill Smith создал концепцию 6 сигм в 1986 году. Это более структурированная версия Lean нежели Kanban, в которую добавлено больше планирования для экономии ресурсов, повышения качества, также снижения количества брака и проблем.

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

Для этого было предложен процесс из 5 шагов, известных как DMEDI:

Определение (Define): Первый этап очень похож на ранние этапы других систем проектного управления. На нём определяется содержание проекта, собирается информация о предпосылках проекта, ставятся цели.
Измерение (Measure): 6 сигм ориентирована на сбор и анализ количественных данных о проекте. На данном этапе происходят определяется, какие показатели будут определять успех проекта и какие данные нужно собирать и анализировать.
Исследование (Explore): На стадии исследования менеджер проекта решает, каким же образом команда может достичь поставленных целей и исполнить все требования в срок и в рамках бюджета. На данном этапе очень важно нестандартное мышление руководителя проектов при решении возникших проблем.
Разработка (Develop): На данном этапе реализуются планы и решения, принятые на предыдущих этапах. Важно понимать, что на данном этапе необходим детальный план, в котором описаны все действия, необходимые для достижения поставленных целей. Также на данном этапе измеряется прогресс проекта.
Контроль (Control): Ключевой этап в методологии 6 сигм. Его основная задача – долгосрочное улучшение процессов реализации проектов. Данный этап требует тщательного документирования извлечённых уроков, анализа собранных данных и применения полученных знаний как в проектах, так во всей компании в целом.

6 сигм очень похожа на Kanban, только с установленными этапами реализации задач – планированием, определением целей и тестированием качества. Вероятнее всего, встреч команды при применении 6 сигм будет значительно больше, чем при Kanban, но зато процесс реализации проектов более структурирован и команде сложнее сбиться с пути. И, как и Kanban, 6 сигм можно относительно легко адаптировать к нуждам конкретной компании или команды. Жёстким требованием является лишь тщательное измерение и контроль показателей проекта на этапах реализации – без этого невозможно постоянное долгосрочное улучшение процессов реализации проекта.

Сильные стороны 6 сигм

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

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

Слабые стороны 6 сигм

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

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

PRINCE2

НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PR ojects IN C ontrolled E nvironments version 2 », что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм.

Методология PRINCE2 в отличие от, например, свода знаний PMBOK не содержит:

Специализированных аспектов управления проектом, например, отраслевых;
Конкретных практик и инструментов управления проектами, таких как диаграмма Гантта, WBS и т.п.

PRINCE2 концентрируется на управленческих сторонах проекта, выраженных в 7 принципах, 7 процессах и 7 темах проекта.

7 принципов определяют общие правила управления проектами по PRINCE2, определяют базу методологии;
7 процессов определяют шаги продвижения по проектному циклу;
7 тем – аспекты, по которым проводится контроль для достижения успеха проекта.

В начале проекта PRINCE2 предлагает нам определить 3 основных аспекта проекта:

Бизнес-аспект (Принесёт ли этот проект выгоду?)
Потребительский аспект (Какой нужен продукт, что мы будем делать?)
Ресурсный аспект (Достаточно ли у нас всего, чтобы достичь цели?)

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

Согласно PRINCE2 у каждого члена команды есть своя чёткая роль в каждом из 7 процессов:

Начало проекта (Start ing up a project ): В ходе данного процесса назначается менеджер проекта и определяются общие требования к характеристикам продукта. Менеджер проекта, чья основная задача – внимание к деталям, отчитывается перед Управляющим комитетом проекта, который отвечает за общее руководство проектом. Именно Управляющий комитет следит за тем, чтобы проект не сбился с курса, и он же полностью отвечает за успех проекта.
Инициация проекта (Initiation a project ): В ходе данного процесса менеджер проекта составляет «Документацию по инициации проекта», в которой содержится план проекта по стадиям. Стадии могут длиться разное количество времени, но, как и в классическом подходе, они следуют строго друг за другом.
Руководство проектом (Directi ng a project ): Данный процесс предоставляет возможность Управляющему комитету нести общую ответственность за успех проекта, не погружаясь в детали, которые находятся в границах полномочий менеджера проекта.
Контроль стадии (Control ling a stage ): При реализации проекта, даже в идеальных условиях, будут вноситься определённые изменения. Процесс «Контроль стадии» реализует один из принципов PRINCE2 – принцип управления по исключениям. В обязанности менеджера проекта входит отслеживать в ходе выполнения стадии отклонения от плановых параметров проекта по срокам, содержанию, бюджету и др. Если эти отклонения превышают данные руководителю проекта Управляющим комитетом полномочия (в терминологии PRINCE2 – допуски), менеджер проекта обязан проинформировать Управляющий комитет и предложить пути выхода из ситуации.
Управление созданием продукта (Managing Product Delivery): Процесс управления созданием продукта представляет собой взаимодействие менеджера проекта и менеджера команды по созданию одного из продуктов проекта. В обязанности менеджера проекта в данном процессе входит делегирование полномочий по созданию продукта менеджеру команды и приемка созданного продукта.
Управление границами стадии (Manag ing a stage boundary ): В ходе данного процесса менеджер проекта предоставляет Управляющему комитету всю необходимую информацию для оценки результатов пройденной стадии и принятия решения о переходе на следующую стадию.
Завершение проекта (Closing a project ): Одно из отличий PRINCE2 в том, что процесс завершения проекта не выделяется в отдельный этап или стадию, как в классическом подходе, а выполняется в рамках финальной стадии создания продукта. Цель процесса – подтвердить, что продукт проекта принят, или проект больше не может принести ничего полезного.

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

Сильные стороны PRINCE2

Адаптируемость к особенностям организации;
Наличие чёткого описания ролей и распределения ответственности;
Акцент на продуктах проекта;
Определённые уровни управления;
Фокус на экономической целесообразности;
Последовательность проектной работы;
Акцент на фиксации опыта и постоянном совершенствовании.

Слабые стороны PRINCE2

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

Лучшая система управления проектами … для Вас!

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

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

Управление командой начинается с планирования и проектирования. Существуют десятки, если не сотни, методологий управления проектами: от “Разработки по ReadMe” до громоздкого, зато на все случаи жизни PMBOK . Как программисты, бывает, изобретают велосипеды, так и проект-менеджеры могут этим грешить. Если с методологией мы могли позволить себе некоторые вольности, то инструмент подбирался уже без “велосипедостроения”…

Что такое “pivot” стартапа

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

ограниченные ресурсы - 4 человека на все работы;
жестко определенные сроки - 30 календарных дней;
необходимость выполнить поставленную задачу: “получить первый доход с продукта”.

Подробнее об исходной точке

Проект начинается не с “0” - программный продукт-предок был версии 2.3, имел хорошую архитектуру после рефакторинга, с отловленными и исправленными багами;
Задача по разработке: из продукта-предка v2.3 сделать продукт-потомок v0.1 alpha-1. Основные изменения касаются переработки архитектуры под многопроектность, добавления новых типов конечных документов, удаления ненужных функций, редизайна в соответствии со вкусами новой ЦА, создания “демо-режима” работы;
Финансово-маркетинговая задача: в кратчайшие сроки выпустить продукт и привлечь к нему аудиторию, проанализировав реакцию на него. По анализу составить план дальнейшего развития. С полученных дополнительных финансов ускорить разработку нового функционала;
Проектирование началось с создания маркетингового концепт-документа , в котором были сформулированы основные идеи и тезисы: какие работы нужно провести, чтобы реализовать поставленные задачи;
Состав команды и обязанности, которые они выполняют:
“Программист” - фронтенд\бэкенд разработка, системное администрирование;
“Тестер” - тестирование ПО, написание баг-репортов, SMM- и контент- менеджмент, анализ и обработка фидбэка;
“Дизайнер” - разработка внешнего вида и механики GUI, создание и подготовка медиа-контента;
“Проект менеджер” - аналитика, проектирование, планирование, управление (проектное, маркетинговое, финансовое и т.д.), разработка технической документации, текстового контента, SEO.
Ограничение-требование от наших менторов-инвесторов: за 30 дней переделать продукт, подготовить материалы и работы по продвижению.

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

У нашей команды есть опыт работы с тремя “связками” инструментов по управлению проектами:

“Связка первая”

Мегаплан - трекинг задач, не связанных с разработкой кода;
Redmine + GIT - баги и задачи, связанные с разработкой кода + контроль версий;
Kayako - сервис для сбора фидбэка, баг-репортинга;

Такая связка хороша, когда в разработке несколько проектов, несколько заказчиков и т.д. (Redmine), много сотрудников и задач, не связанных с работой над кодом (Мегаплан), много пользователей, а соответственно много: саппорта, фидбэка, баг-репортов (Kayako).

“Связка вторая”
Google Docs - электронный документооборот и облачный редактор документов;
Мегаплан - трекинг задач, не связанных с разработкой кода + CRM-система;
BitBucket вместо Redmine + GIT;

“Вторая связка” подходит, когда проект один, и он относительно простой (BitBucket); при этом работы, не связанной с кодом (Мегаплан), много, а фидбэка-саппорта пока мало, так что хватает настроенного веб-интерфейса от почты (Yandex.pdd).

“Связка третья”
Google Docs - как облачный редактор;
TrackStudio + GIT - трекер задач, как по коду, так и прочих + электронный документооборот;
Яндекс.Почта для домена - для сбора фидбэка, баг-репортинга.

Эта связка - самая правильная, она позволяет в одной системе вести работу над задачами как по коду, так и по всему остальному. К сожалению, основной инструмент в этой связке требует много ресурсов на настройку-допиливание (TrackStudio); по фидбэку-сапорту, как и во “второй связке”, хватает Yandex.pdd,

Эти связки были подобраны под разные условия работы. Google Docs используется всегда: мы просто его любим - это приятный, быстрый и удобный облачный редактор документов.

Под наши условия: один проект, работать надо как над кодом, так и над продвижением, пользователей пока вообще нет, много саппорта-фидбэка не предвидится, предполагали выбор второй или третьей “связки”. “Третья связка” (основанная на TrackStudio) после коротких размышлений отпала - не было ни времени, ни ресурсов, чтобы настроить-довести этот инструмент под новый проект. Решили использовать “Вторую связку” с инструментами, которые работали из коробки (BitBucket, Мегаплан).

Вариант попробовать что-то новое не рассматривался по той же причине, по какой отказались от использования “Третьей связки”. Не было времени на эксперименты, нужно было начинать работать. Учитывая отсутствие возможности попробовать новое, положились на опыт проект-менеджера по общению с парой десятков прочих систем управления проектами (СУП) как специализированных для разработки ПО, так и широкой области применения: от Teamer’а до BugZill’ы.

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

Почему мы начали с выбора инструментов, а не с планирования?

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

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

Общие задачи ставятся в Мегаплане, будем использовать его терминологию. Отправная точка в иерархии таск-менеджера Мегаплана - “Вехи”. Веха - срез проекта на определенном сроке, её еще можно описать, как набор целей, которые нужно достичь к конкретному времени. Планирование сводится к созданию вех. Рассмотрим их на примере нашей ситуации (переделываем один проект в другой, подготавливаем его продвижение, на всё 30 дней, с 5 сентября по 5 октября).

Веха #1. “Подготовительный этап”, закончено к 10 сентября:
- Выбраны и настроены инструменты, локальные сервера;
- Спланирован ход работ;
- Поставлены и распределены задачи;
- Составлены ТЗ по всем задачам.

Веха #2. “Базовые работы”, закончено к 15 сентября:
- Произведен рефакторинг кода проекта (ускорит реализацию будущих задач);
- Подготовлены серверы и учетные записи, домены для продакшна;
- Разработан и собран ключевой контент для продвижения (по правилу «Бритвы Оккама»: 20% “ключевого” контента дадут 80% трафика);

Веха #3. “Первый наглядный результат”, закончено к 20 сентября:
- Рефакторинг редактора (перенесен в iframe, что позволит быстро реализовать “демо-режим”);
- Произведен редизайн GUI;
- “Запущены” блог проекта, сообщества в социальных сетях.

Веха #4. “Первый публичный результат”, закончено к 25 сентября:
- Добавлена форма приема платежей;
- Реализован демо-режим;
- На демо-режиме запущен промо-сайт с 90-100% запланированного контента;
- Версия 0.0.11 задеплойдена в продакшн;
- Сообщества в соц. сетях и блог на сайте наполнены первыми постами.

Веха #5. “Подготовлено продвижение проекта”, закончено к 30 сентября:
- Заведен блог на Хабрахабре;
- Реализованы мелкие фичи и доработки;
- Пройдена модерация и подключена система биллинга;
- Версия 0.0.17 задеплойдена в продакшн;
- Согласно плану публикаций продолжается постинг в соц. сети и в блог на сайте.

Финальная Веха #6. “Первое продвижение проекта”, закончено к 10 октября:
- Реализован весь задуманный на альфа-версию функционал;
- Релиз версии R0.1 Alpha-1 задеплойден в продакшн;
- Первая статья опубликована в блоге на Хабрахабре;

Запланированные Вехи #7-Х. “Создание комьюнити проекта”, закончено к 30 октября:
- Опубликованы 3-5 статей в блог на Хабрахабре;
- Подготавливаются и публикуются посты в блог на сайте, в сообщества соц. сетей;
- Идет сбор и анализ фидбэка, общая переписка с заинтересовавшимися в проекте пользователями;
- Планируются и проводятся работы по прочему продвижению согласно маркетинговому концепту;
- Производятся хот-фиксы;
- Анализируются суммы собранных средств, соотносятся с возможностями по дальнейшему развитию проектов.

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

Напомню: первые Вехи планировались, опираясь на “маркетинговый концепт” . Наша команда состоит из 4-х человек, несколько лет работающих вместе над разными проектами. Схожие с теми, что поставлены в Вехах для Alpha-версии Ahoba (; задачи, мы уже реализовывали в других проектах. Поэтому, составляя Вехи, проект-менеджер уже представлял кто и как будет решать поставленные задачи. Этот процесс происходил неформально, опираясь на прошлый опыт, эмпирическую оценку и аналитическое прогнозирование.

Можно написать книгу о этих неформальных мыслительных процессах, о истории их возникновения, проб вариантов, обучение на ошибках и т.д. Получится этакий “PMBOK Lite for Brain”. Однако, на данный момент нет не то что книги, но и оформленной на бумаге концепции: все на 70% - в голове ПМ’а, и лишь оставшиеся 30% - в его личных шпаргалках-тезисах. Возможно когда-нибудь и из этих наработок получится, пускай и не книга, но достойная статья для Хабрахабра точно. Сейчас же мы просто отметим, что было сделано, не вдаваясь в вопрос “Как?”.

Проработка структуры проекта

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

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

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

0. Проектирование
1. Разработка проекта
2. Продвижение проекта
2.1. Сайт и блог Ahoba (;
2.2. Продвижение в соц. сетях
2.3. Продвижение на Хабрахабре
3. Разработка дизайна и медиа-контента

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

Постановка задач

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

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

Краткая концепция задачи → Разработка подробного ТЗ → Создание тестового\демо контента → Создание макетов GUI по ТЗ → Постановка формальной задачи на реализацию в таск-трекер (ТЗ + Макет) → Реализация → Тестирование → Багфикс (если нужно) → Закрытие задачи.

Над задачей на разных этапах работают разные люди с разными ролями: ПМ разрабатывает концепцию задачи; бизнес-аналитик, технический писатель составляют ТЗ; дизайнер рисует макет; ПМ передает ТЗ и Макет программисту; программист реализует задачу, передает её на тестирование; тестер проверяет реализацию и, если всё в порядке, соответствует ТЗ и Макету, то уже как QA-специалист закрывает задачу.

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

В итоге имеем около 5-ти типовых моделей жизненных циклов задач и еще пару десятков “атипичных”.

Гибкие инструменты для трекинга задач, такие, как TrackStudio, хороши тем, что позволяют формально настроить менеджмент по любой модели жизненного цикла задачи. Это и их достоинство, и их недостаток. Как уже говорилось выше, когда нет ресурсов на первоначальную настройку, использовать эту систему не получится. Взяв коробочные Мегаплан и BitBucket, мы понимали, что формально настроить их для наших жизненных циклов реализации задач не выйдет. Поэтому, дальнейший рассказ а-ля “много-много костылей” о неформальном использование этих сервисов.

Как в связке “Мегаплан + BitBucket” реализовать нашу модель жизненного цикла задачи? Во-первых, конкретные фичи, связанные с кодом (п.1. “Разработка” из иерархической структуры, определенной ранее), заносятся в BitBucket, а задачи по подготовке материалов для реализации фич (ТЗ + Макет + Тестовые\Демо данные) - в трекер Мегаплана.

Алгоритм примерно такой:
Ставим в Мегаплан задачу для бизнес-аналитика: “Разработать ТЗ ” - со ссылкой-примечанием “Готовое ТЗ выложить в задачу Х для дизайнера ”. Дизайнеру, также в Мегаплан, ставим задачу “Разработать Макет по ТЗ ” с теми же ссылками-примечаниями: “Позже ТЗ в задачу выложит бизнес-аналитик, готовый Макет выложить в задачу Y в BitBucket ”. Программист и тестер работают только в BitBucket’e, оперируя сменой статусов у задач.

В интерфейсе этих СУП’ов объединения этапов работы над задачами нет. При неумелом проект-менеджменте это может привести к негативным последствиям. Из личного опыта: если вручную не согласовывать распределение работ (а автоматизировано инструменты этого не делают), может возникнуть ситуация, когда, например, программист простаивает неделями в ожидании формальных описаний для фич. Такое я наблюдал на прошлом месте работы. В итоге ведущий разработчик уволился, аргументируя своё увольнение монологом в духе: “Мне скучно, так как нет работы, а я код писать хочу”. Это показательный пример того, как неподходящие инструменты или их неформальное использование, могут деморализовать членов команды. Всем, решившим, как и мы, использовать “Вторую связку”, нужно понимать и учитывать эти риски при работе в таких системах управления проектами.

Наша команда - 4 человека. Каждый занимается несколькими проектными работами. Мне, как проект-менеджеру, нужно было поскорее закончить с этим самым проект-менеджментом и приступать к работе бизнес-аналитика\технического писателя, SEO-специалиста, маркетолога и копирайтера. К работе ПМ’а возвращаться не хотелось, да и не было возможности.

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

Таблица: “Работы по реализации и продвижению проекта Ahoba (; ver. Alpha-1”

И т.д., всего около 50 задач.

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

Отдельно стоит отметить распараллеливание на раннем этапе. Пока ПМ прорабатывает задачи, команде нечем заняться. Чтобы избежать простоя, работа ПМ’а начинается с постановки задач, не требующих детального ТЗ или аналитики: Программист начинает с удаления ненужного функционала; Дизайнер рисует лого проекта; SMM-менеджер подбирает контент для постов по тематике, определенной еще в концепте. Все при деле, а проект-менеджер спокойно работает над полусотней задач, распланировав деятельность команды на следующие 30 дней.

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

Формальные правила постановки и выполнения задач

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

Любая идея, предложение, пожелание и т.д. проходят через ПМ’а, т.к. он отвечает за общую работу и жизненные циклы отдельных задач, определяя и внося всё новое согласно текущей ситуации;
Все задачи фиксируются в системах управления проектом. Связанные с кодом - в BitBecket’е, все прочие - в Мегаплане;
Для каждой задачи должен быть назначен ответственный и определен дедлайн;
Задача должна иметь полное, формальное, однозначное описание. Если исполнитель не уверен в смысле задачи, он обязан перед её выполнением уточнить его у постановщика задачи. Постановщик, если необходимо, дополняет описание;
Порядок выполнения задач - согласно их дедлайнам. Если задачи имеют одинаковый дедлайн, исполнитель сам выбирает, в какой последовательности их реализовывать;
Статусы при работе над задачами (выставляются автоматически и вручную) и реакция на них в Мегаплане:
1. “Новая задача” - необходимо ознакомится с сутью и условиями задачи, согласовать порядок выполнения прочих своих задач и новой.
2. “Принята к исполнению” - ответственный за задачу знает о ней, если свободен, работает над её реализацией.
3. “Условно завершена” - статус устанавливается вручную, после того, как исполнитель закончил работу над задачей, выполнил все условия описанные в ней. (Например, по условию: выложил готовый Макет в связанную задачу по разработке GUI).
4. “Завершена” - устанавливается вручную, после того как поставщик задачи проверил качество её исполнения;
Статусы при работе над задачами, служебная информация в заголовках (задаются только вручную) и реакция на них при работе в BitBucket’e:
1. Задаче должен быть указан тип. Тип “task” - задается для задач, связанных с добавлением нового или изменением текущего функционала; тип “bug” - для задач по исправлению ошибок, недочетов.
2. Т.к. в BitBucket’е нет сущности “версия” или “релиз”, для каждой задачи, в начале её заголовка добавляется служебная информация типа “RX”, где “R” - метка обозначающая релиз, а “X” - номер релиза. Пример метки - “R0.1”. Перенос задач из релиза в релиз осуществляется изменением служебной метки в заголовке задачи.
3. Задача добавляется без статуса, если в ней отсутствуют какие-то данные (например, макет нового GUI), при этом в описании должно быть примечание (например: “Позже дизайнер выложит макет, подробности в задаче - ссылка_на_задачу_по_разработке_макета ”).
4. Задаче ставится статус “new”, что означает, что все описания по ней готовы, и программист может приступать к работе над ней;
5. Задаче ставится статус “resolved”, когда программист заканчивает работу над задачей и деплойдит изменения на тестовый сервер. Данный статус означает, что тестер может приступить к тестированию задачи.
6. Если в выполненной задаче найдены ошибки, и их можно исправить в рамках текущей задачи, тестер ставит статус “invalid”. Это означает, что программисту необходимо исправить найденные недочеты. После правки программист опять ставит статус “resolved”.
7. После того как текущая задача реализована без ошибок, или ошибки вынесены в отдельную задачу с типом “bug”, задаче присваивается статус “closed”.
8. Каждой задаче автоматически присваивается уникальный ID. Он необходим для двух вещей: а) для привязки коммитов в git-репозиторий к определенной задаче; б) для получения номера версии текущего релиза.

На этих правилах, инструментах и методологии было реализовано управление проектом при создании и продвижении стартапа Ahoba (; на этапе “Alpha-1”. Цели и условия, которые у нас были, диктовали именно их.

Кирилл,
руководитель проекта

Название вуза

Курсовая работа

«Инструментарий

проектного управления»

Выполнил:

Проверил:

Введение 4

1 Основные инструменты управления проектом: теоретические аспекты 5

1.1 Роль инструментария проектного управления 5

1.2 Характеристика и разработка основных инструментов проектного управления 6

2 Применение инструментария проектного управления на примере проекта создания АНО «Рекрутинговое агентство «Старт» 7

2.1 Общая характеристика проекта 7

2.2 Планирование проекта с использованием основных инструментов управления проектами 8

Заключение 9

Список используемых источников 10

Приложения

Приложение А. Структурная декомпозиция работ по проекту

Приложение Б. Сетевая модель по проекту «Рекрутинговое агентство «Старт»

Приложение В. Диаграмма Ганта

Введение

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

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

Для успешного осуществления проекта имеются два значимых фактора:

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

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

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

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

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

Данная цель обуславливает необходимость решения следующих задач:

изучение теоретических аспектов проектного управления;

1 Основные инструменты управления проектом: теоретические аспекты

1.1 Роль инструментария проектного управления

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

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

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

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

3. Жизненный цикл проекта. Проект в процессе его создания и

1.2 Характеристика и разработка основных инструментов проектного управления

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

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

Структура разбиения работ, или дерево работ, иерархическая структура работ, структурная декомпозиция работ – иерархический граф, узлы которого изображают работы и комплексы работ, а связи, всегда имеющие вид «один к одному», - разбиение вышестоящего элемента на нижестоящие 2 . Общая схема СДР приведена на рисунке 4.

Рисунок 4 – Общая схема структурной декомпозиции работ проекта

2 Применение инструментария проектного управления на примере проекта создания АНО «Рекрутинговое агентство «Старт»

2.1 Общая характеристика проекта

Проект предполагает создание в городе Москва рекрутингового агентства, занимающегося подготовкой и трудоустройством молодых специалистов – выпускников ВУЗов, ССУЗов на предприятия, в организации и в органы власти города Москва и Московской области.

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

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

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

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

2.2 Планирование проекта с использованием основных инструментов управления проектами

В приложении А представлена структурная декомпозиция работ по проекту создания рекрутингового агентства «Старт».

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

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

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

Теперь рассчитаем для проекта «Рекрутинговое агентство» критический путь.

На рисунке 8 изображен сетевой график проекта с рассчитанными ранними и поздними моментами событий (длительности операций указаны в таблице 5).

В сетевом графике предусмотрены следующие работы:

1- определение цели и плана действий

2- мониторинг ситуации на рынке труда Москвы и Московской области

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

Таблица 4 – Сетевая матрица по проекту «Рекрутинговое агентство «Старт»

4- регистрация Автономной некоммерческой организации «Рекрутинговое агентство «Старт»

5- разработка программы презентации

7- проведение презентаций в учебных заведениях

8- организация и проведение Дня резюме

9- обработка резюме, сведение в единую базу данных

Заключение

Известный закон Лермана гласит: «Любую техническую проблему можно преодолеть, имея достаточно времени и денег», а следствие Лермана уточняет: «Вам никогда не будет хватать либо времени, либо денег». Именно для преодоления сформулированной в следствии Лермана проблемы и была разработана методика управления деятельностью на основе проекта. А распространение данной методики управления на различные сферы деятельности является дополнительным доказательством ее эффективности. Если попросить менеджера описать, как он понимает свою основную задачу в выполнении проекта, то, скорее всего, он ответит: «Обеспечить выполнение работ». Это действительно главная задача руководителя. Но если задать тот же вопрос более опытному менеджеру, то можно услышать и более полное определение главной задачи менеджера проекта: «Обеспечить выполнение работ в срок, в рамках выделенных средств, в соответствии с техническим заданием». Именно эти три момента: время, бюджет и качество работ находятся под постоянным вниманием руководителя проекта. Их также можно назвать основными ограничениями, накладываемыми на проект. Таким образом, под управлением проектом подразумевается деятельность, направленная на реализацию проекта с максимально возможной эффективностью при заданных ограничениях по времени, денежным средствам (и ресурсам), а также качеству конечных результатов проекта (документированных, например, в техническом задании).

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

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

Список используемых источников

Андронов С. А., Макарчук Н. В., Макарчук А. В. Менеджмент в проектной деятельности: учебное пособие. – СПб.: СПбГУАП, 2001. – 126 с.

Бэгьюли Ф. Управление проектом/ Фил Бэгьюли. – Пер. с англ. В. Петрашек. – М.: ФАИР-ПРЕСС, 2002. – 208 с.

Богданов В. В. Управление проектами в Microsoft Project 2007. Учебный курс. – СПб.: Питер, 2008. – 592 с.

Верзух Э. Управление проектами: ускоренный курс по программе МВА. – М.: ООО «И.Д. Вильямс», 2008. – 480 с.

Герасимов В. В., Чередникова Л. Е. Управление проектами: задачи, методы и инструменты. Учебное пособие. – Новосибирск: Сибирская академия финансов и банковского дела, 2007. – 256 с.

Гонтарева И.В., Нижегородцев Р.М., Новиков Д.А. Управление проектами: учеб. пособие. – М.: Книжный дом «Либроком», 2009. – 384 с.

Грей К. Ф., Ларсон Э. У. Управление проектами: Практическое руководство. – М.: Изд-во «Дело и сервис», 2003. – 528 с.

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

Кух С.Х., Тейн К. Управление проектами: учебник. – М.: Поколение, 2007. – 432 с.

Локир К. Управление проектами: ступени высшего мастерства. – Минск: Грувцов Паблиситер, 2008. – 352 с.

Мазур И. И., Шапиро В. Д. Управление проектами: учебное пособие / под общ. ред. И. И. Мазура. – М.: Омега-Л, 2004. – 664 с.

Милошевич Д. Набор инструментов для управления проектами. – М.: Компания АйТи; ДМК Пресс, 2008. – 729 с.

Просветов Г. И. Управление проектами: задачи и решения: учебно-практическое пособие. – М.: Изд-во «Альфа-Пресс», 2008. – 200 с.

Романова М. В. Управление проектами: учебное пособие. – М.: ИД «

1 Хэлдман К. Управление проектами. Быстрый старт: эффективные инструменты и приемы. – М.: Компания АйТи; ДМК Пресс, 2008. – С. 131.

2 Управление проектом. Основы проектного управления: учебник/ кол. авт.; под ред. проф. М. А. Разу. – М.: КНОРУС, 2006. – С. 489. управленческого учета способно обеспечивать... 52. Бюджетирование как инструментарий проектному управлению . Главная задача состоит в...

Управление проектами (2)

Документ

Планирование и контроль), как инструментарий управленческого учета способно обеспечивать... 52. Бюджетирование как инструментарий управленческого учета. Составление и... волнуют руководителей и специалистов по проектному управлению . Главная задача состоит в...

Управление портфелями проектов на основе международных стандартов

Программа

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