Методы и инструменты управления проектами. Классическое проектное управление

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

Ниже мы расскажем о следующих методах:

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

Наиболее популярным среди таковых является уже рассмотренная нами диаграмма Гантта, где указаны основные задачи и сроки начала и завершения их решения. Но если она подходит для проектов с жесткими сроками и ресурсными ограничениями, то для проектов, требующих большего уровня контроля самого процесса реализации, лучше всего использовать гибкие методы проектного управления, такие как Agile, и взаимосвязанные с ним Kanban, Lean и прочие, а также такие, которые позволяют управлять сразу несколькими составляющими, например, ресурсами, временем и работой, - это Scrum и Six Sigma. Но не будем забегать вперед, а расскажем обо всем по порядку.

Agile

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

Упрощенная схема работы по Agile выглядит так:

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

Преимущества Agile:

• Адаптивность и гибкость (его можно подстраивать под разные процессы и условия)
• Быстрое и относительно безболезненное реагирование на изменения
• Прекрасно подходит для разработки инновационных продуктов с высоким уровнем неопределенности и низкой информативности

Недостатки Agıle:

• Не является методом
• Необходимость каждый раз составлять новую систему управления на основе принципов подхода Agıle
• Применение подхода сопряжено с изменениями процедур реализации проекта и базовых ценностей
• Требует знаний, упорства, больших затрат и административных ресурсов (для облегчения применения подхода принято использовать методы Scrum, Kanban и другие)

Scrum

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

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

Упрощенная схема работы по Scrum такова:

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

Вся процессуальная структура метода вращается вокруг пяти основных встреч:

• Упорядочивание беклога. Встреча напоминает планирование, рассмотренное нами в первом уроке. Проводить ее нужно в первый день нового спринта. На встрече обсуждается то, что уже удалось сделать по проекту и что еще нужно сделать, и определяются дальнейшие шаги. Инициатор ставит задачи, соответствующие новому этапу. Упорядочивание беклога определяет результативность нового спринта.
• Планирование спринта. После расстановки приоритетов и определения задач инициатором команда принимает решение о своих действиях на протяжении наступающей итерации и ищет способы достижения поставленной цели. Для этого могут использоваться самые разные инструменты планирования и оценки (важно, чтобы они соответствовали принципам метода). Планировать спринт нужно в самом начале итерации, но по окончании встречи по упорядочиванию беклога.
• Летучки. Летучки - это ежедневные встречи, проводящиеся в одно и то же время (на них тратиться, как правило, до 15 минут). Члены команды делятся информацией о статусе своей работы и состоянии проекта, однако никакие решения не принимаются и проблемы не обсуждаются (для этого выделяется отдельное время, и устраиваются дополнительные встречи). Летучки нужны лишь для обмена сведениями.
• Подведение итогов спринта. На этом этапе исследуется и адаптируется созданный продукт. Члены команды делятся своими результатами со всеми заинтересованными лицами. Главной задачей здесь является удостовериться в том, что продукт спринта соответствует целям проекта и ожиданиям участников проекта.
• Ретроспектива спринта. Этап, проводящийся сразу же после предыдущего, но до того как начнет планироваться новый спринт. Команда определяет степень четкости и слаженности пройденного этапа, исследует появившиеся проблемы в методологии, работе и взаимодействии. Благодаря ретроспективе команда может сделать выводы и повысить эффективность следующего спринта.

Преимущества Scrum:

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

Недостатки Scrum:

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

Многие считают, что метод «Скрам» сложен для внедрения, указывая на необходимость в делегировании полномочий, необычную организационную структуру и т.п., однако при умелом использовании и благодаря своей гибкости метод не позволит работе пойти в неверном направлении. Это существенно отличает Scrum от общих принципов Agile.

Lean

Согласно Agile, проект должен быть разбит на небольшие подпроекты и пакеты работ, но вот как разрабатывать эти подпроекты и пакеты работ - непонятно. Метод «Лин» дополняет принципы Agile своей схемой потока операций для качественного выполнения каждой отдельной итерации.

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

Ниже представлена упрощенная схема работы по Lean:

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

Преимущества Lean:

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

Недостатки Lean:

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

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

Kanban

Если рассмотренный выше метод «Лин» представляется отчасти абстрактным, то при совмещении его с Kanban он становится превосходным инструментом, позволяющим выстраивать эффективную систему проектного управления. Метод «Канбан» предполагает передачу инкремента продукта от этапа к этапу, в результате чего на выходе появляется готовый продукт.

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

Упрощенная схема работы по Kanban выглядит так:

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

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

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

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

Преимущества Kanban:

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

Недостатки Kanban:

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

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

Six Sigma

Метод Six Sigma или, проще говоря, «6 сигм» представляет собой более структурированную версию Lean, причем даже более структурированную, чем Kanban. Она отличается еще большим планированием, что позволяет экономить ресурсы, повышать качество продукта и минимизировать объем потерь и брака.

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

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

Преимущества Six Sigma:

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

Недостатки Six Sigma:

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

Метод «6 сигм» напоминает «Канбан», но устанавливает конкретные этапы реализации задач - планирование, постановку целей и тестирование качества. Также Six Sigma требует более частых встреч команды, но сам процесс осуществления проекта будет более понятен, а команда всегда сможет придерживаться намеченного плана.

PRINCE2

От прочих методов проектного управления PRINCE2 (от англ. PRojects IN Controlled Environments version 2) отличатся отсутствием итеративного подхода. По сути, это гибрид классического проектного управления с концентрацией на качестве, как это делается в Six Sigma.

Схематично процессы работы по PRINCE2 выглядят так:

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

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

• Бизнес-аспект: выгоден ли проект?
• Потребительский аспект: какой нужно создать продукт?
• Ресурсный аспект: есть ли возможности и ресурсы для достижения цели?

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

Сами же процессы можно охарактеризовать так:

• Старт проекта. В ходе первого процесса назначается руководитель, и устанавливаются общие требования к характеристикам конечного результата. Проект-менеджер должен уделять особое внимание деталям и давать отчет Управляющему комитету проекта, отвечающему за общее руководство проектом и успех его реализации.
• Инициация проекта. В ходе второго процесса руководителем составляется «Документация по инициации проекта», содержащая в себе разбитый на стадии план проекта. Стадии всегда следуют одна за другой, но по продолжительности вполне могут различаться.
• Руководство проектом. Третий процесс основан на том, что дает Управляющему комитету возможность нести общую ответственность за успех реализации задумки без погружения в детали, находящиеся в области полномочий проект-менеджера.
• Контроль стадии. Даже если проект осуществляется в идеальных условиях, в него будут вноситься какие-то поправки. Четвертый процесс необходим для реализации одного из принципов PRINCE2 - принципа управления по исключениям. Руководитель проекта должен выявлять отклонения от заданных параметров проекта (сроки, качество, бюджет и т.д.) в ходе выполнения стадии. В случае, когда отклонения превышают полномочия (допуски) руководителя, он должен поставить об этом в известность Управляющий комитет и предложить варианты решения возникших проблем.
• Управление созданием продукта. Пятый процесс - это взаимодействие руководителя и его команды, направленное на создание одного из проектных продуктов. К числу обязанностей руководителя добавляется делегирование соответствующих полномочий менеджеру команды и приемка готового продукта.
• Управление границами стадии. В ходе шестого процесса руководитель снабжает Управляющий комитет всей информацией, позволяющей оценить результаты завершенной стадии и принять решение о переходе к следующей стадии.
• Завершение проекта. Процесс завершения проекта является частью финальной стадии создания продукта. Его цель состоит в подтверждении или факта принятия продукта, или факта того, что проект не принесет больше ничего стоящего.

Преимущества PRINCE2:

• Легко адаптируется к особенностям организации
• Имеет четкое описание ролей и распределения ответственности
• Концентрируется на продукте проекта и экономической целесообразности
• Имеет конкретные уровни управления
• Позволяет последовательно выстроить проектную работу
• Фиксирует опыт и позволяет постоянно совершенствоваться

Недостатки PRINCE2:

• Отсутствуют отраслевые практики
• Отсутствуют конкретные инструменты для проектной работы

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

Управление проектами - это, пусть и не совсем точная, но серьезная наука. Конечно, в ней вряд ли удастся отыскать универсальные решения и основы, однако если вы сможете найти такой метод проектного управления, который подойдет вашему проекту по большинству параметров, вы можете быть уверены, что достичь успеха - в ваших силах. Главное - это применять метод, в котором есть хоть какая-то структура, а также использовать в своей проектной деятельности вспомогательные инструменты, такие как системы управления проектами, например, MS Project, Asana, Wrike, Basecamp и другие. И о самых популярных системах вы узнаете из заключительного урока, после чего в вашем распоряжении будет вся основная информация по управлению проектами.

Проверьте свои знания

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

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

Управление командой начинается с планирования и проектирования. Существуют десятки, если не сотни, методологий управления проектами: от “Разработки по 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”. Цели и условия, которые у нас были, диктовали именно их.

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

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

• традиционная КИС разрабатывается для конкретной функциональной структуры или конкретного функционального подразделения компании;
• обычно КИС собирает, обрабатывает и хранит информацию согласно календарным графикам, определяемым технологией бизнес-процессов компании, которые не совпадают с календарными графиками проектов;
• большинство КИС (за исключением систем MRP и ERP) имеют низкую интеграционную способность.

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

Таблица 18.1

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

Этап жизненного цикла проекта	Типы информационных систем	Информационные системы
Предынвестиционная	предынвестиционного	Projectexpert; «Альт-Инвест»; Primavera; «Калькулятор финансового аналитика»; системы собственной разработки отдельных девелоперских компаний
Планирование	Системы ресурсного планирования	MS Project; Oracle Projects; Primavera; Plan View; Niku; Mercury; SAP xRPM; IBM RPM; Spider;
Реализация (контроль, корректировка планов)	Системы контроля (включая финансовый контроль)	MS Project; Oracle Projects; Primavera; Time line; Plan View; Niku; Mercury; SAP xRPM; IBM RPM; Spider; Open Plan; Cobra
Завершение (документирование)	Системы электронного документооборота	Lan Docs; Lotus Notes; Staffware

На сегодняшний день наиболее популярной информационной средой, принятой во всем мире для управления строительством электросетевых объектов и ТЭС, являются программные комплексы на базе платформы Primavera компании Primavera Systems Inc. Они предназначены для управления инвестиционной деятельностью, капитальным строительством, техническим обслуживанием и ремонтом оборудования, зданий и сооружений в соответствии с требованиями нормативов PMI, IPMA и стандартов ISO.

Решения Primavera разработаны для ключевых участников инвестиционного процесса: застройщиков, заказчиков, инвесторов, девелоперов, генеральных подрядчиков [также в форме ЕРС (ЕРСМ)], поставщиков и производителей оборудования, инжиниринговых организаций, ремонтных и сервисных предприятий. Эти решения применяются при управлении проектами в строительстве, нефтегазовой отрасли, машиностроении, энергетике, металлургии, судостроении, информационных и телекоммуникационных проектах и позволяют выполнять обеспечение задач календарно-сетевого планирования, контроля процедур согласования документов, включая проектно-сметную документацию, управления рисками и т.д.

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

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

Компания Primavera Systems Inc. разрабатывает и непрерывно совершенствует специализированное программное обеспечение для управления проектами с 1983 г. За это время на рынке сменилось два поколения программных продуктов Primavera. Программные модули этих продуктов обеспечивают хранение и обработку данных по всем проектам инжиниринговой компании в едином хранилище данных, построенном на базе СУБД Oracle или Microsoft SQL Server (по выбору заказчика).

Модуль Project Management предназначен для использования в составе КИС, хотя вполне может работать и автономно, обеспечивая решение задач календарно-сетевого планирования, расчета критического пути, выравнивания ресурсов, what-if-анализа и других задач моделирования проектов, групп проектов, портфелей проектов и программ.

Модуль Methodology Management позволяет сохранять и использовать в дальнейшем базу знаний компании по управлению проектами.

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

• по портфелям проектов (myPrimavera Portfolios);
• по управлению проектами, разработке и актуализации графиков (myPrimavera Projects);
• по управлению ресурсами и ролями (myPrimavera Resources);
• по отслеживанию процессов инициации и изменения проектов, управлению документооборотом и др. (Collaboration).

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

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

Эти возможности предоставляет функциональный модуль Primavera Timesheets. Однако далеко не всегда компания может обеспечить сотрудникам постоянный доступ к сети. Также возможна ситуация, когда по работам заказчика отчитываются подрядчики, которым не разрешен доступ в корпоративную сеть заказчика. В этих случаях становятся актуальными другие средства для контроля и учета работ по проектам, которые должны работать в режиме отсутствия постоянного подключения к сети. К таким средствам относится модуль PMexchange. Для исполнителей, работающих на удаленных объектах, предусмотрено решение, реализованное в модуле Sensory ProTracker.

При реализации масштабных проектов с большим числом организаций- участников (что характерно для строительства ТЭС) одним из факторов наибольшего влияния на сроки и стоимость проекта становятся процессы взаимодействия между участниками. Модули PMcontract и PMprocurement обеспечивают автоматизацию процессов управления соответственно договорами и поставками в проектах. Благодаря этим модулям информация по заключенным договорам и поставляемому оборудованию может автоматически увязываться с календарно-сетевыми графиками в Primavera.

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

Задачи календарно-сетевого планирования решает также модуль Primavera Contractor. Его особенность - только однопользовательская работа единовременно с графиком одного проекта, ограниченным по числу работ.

Конкуренцию системам Primavera при управлении проектами, особенно IT-проектами, проектами в сфере создания высоких технологий и строительства малой и средней сложности, составляет продукт корпорации Microsoft - Microsoft Office Project 2007. Он предоставляет надежные инструменты управления проектом, сочетающие в себе практичность, мощность и гибкость. Это позволяет с малыми трудозатратами управлять проектными работами, планами, ресурсами и финансами, сохранять согласованность работы команды и составлять разнообразные отчеты.

Microsoft Project имеет понятный и очень удобный интерфейс, поэтому работать в нем не сложнее, чем в Microsoft Excel. Меню и справка полностью русифицированы, а на сайге www.microsoft.com/rus/office всегда имеются полезные шаблоны проектов. Следует отметить, что в последних версиях Primavera и Microsoft Project появились эффективные и несложные инструменты взаимной интеграции. В результате этого стал реальным обмен между базами данных проектов, что открывает широкие возможности для создания интересных интегрированных решений.

Желающие более подробно ознакомиться с решениями Primavera и Microsoft Project в области управления проектами могут обратиться на сайты корпорации Microsoft и ее авторизованных представителей или к многочисленной литературе по этому вопросу.

• При описании ПО использованы материалы сайта группы компаний ПМСОФТ - авторизованного представителя фирмы Primavera Systems Inc. в России, СИГ и странах Балтии.
• В переводе с англ, означает «что, если...».

Замечание 1

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

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

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

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

1. Инициация – определение требований к проекту и его результатов;
2. Планирование – выбор способов достижения поставленной цели, определение состава задач, календарного плана, бюджета и рисков;
3. Разработка – определение конфигурации будущего проекта, методов и способов решения задач;
4. Реализация и тестирование – выполнение задач по проекту, тестирование на предмет соответствия требованиям, внесение корректировок;
5. Мониторинг и завершение – передача результатов проекта заинтересованным сторонам.

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

Пример 1

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

Agile

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

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

Scrum

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

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

Lean

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

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

Kanban

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

Kanban часто считают визуализацией идеи Agile – схожие принципы выражены в инструментах типа карточек.

Six Sigma

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

Методы 6 сигм схожи с Kanban, а их ключевые различия состоят в определенности этапов планирования, целеполагания и контроля качества.

PRINCE2

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

Замечание 2

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

На управление проектами оказывает влияние окружение проекта, которое можно разделить на внешнее и внутреннее.

Внешнее окружение:

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

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

Внутреннее окружение. Наиболее существенными факторами "внутреннего" окружения являются:

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

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

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

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

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

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

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

организация, система документации проекта .

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

PMI PMBOK 2015 Guide 4d Edition (оценка проектов на основании британской методики) состоит из двух частей:

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

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

Таблица 1.2.

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

	Процессы
1. Управление Интеграцией	1. Процессы, обеспечивающие координацию между элементами проекта.
2. Управление Замыслом	2. Процессы, обеспечивающие замысел и выполнение всех требуемых и только тре-буемых работ.
3. Управление Временем	3. Процессы, обеспечивающие завершение работ в заданное время.
4. Управление Стоимостью	4. Процессы, обеспечивающие завершение работ в заданном бюджете.
5. Управление Качеством	5. Процессы, обеспечивающие выполнение требований и ожиданий заказчика.
6. Управление Ресурсами	6. Процессы, обеспечивающие наиболее эффективное использование ресурсов, участ-вующих в проекте.
7. Управление Коммуникацией	7. Процессы, обеспечивающие создание, хранение и своевременное распределение информации о проекте.
8. Управление Риском	8. Процессы, связанные с определением, анализом и реакцией на возможный риск, связанные с проектом.
9. Управление Поставками	9. Процессы, необходимые для заказа товаров и услуг у других организаций.

Примечание: источник .

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

Таблица 1.3

Процессы внутри фазы по проекту

Примечание: источник .

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

международная организация по стандартизации ISO опубликовала стандарт ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов». В настоящее время выполняется разработка стандарта ISO 21500 «Руководство по менеджменту проектов». Однако официально данный стандарт будет утвержден только в 2012 году;

международная ассоциация проектного менеджмента (International Project Management Association - IPMA) объединяет 45 национальных ассоциаций и является авторитетной профессиональной организацией в области управления проектами. Россию в IPMA представляет национальная ассоциация управления проектами СОВНЕТ. Основным стандартом, разработанным IPMA, является ICB (IPMA Competence Baseline, 3-я версия выпущена в 2015 году), определяющая требования к квалификации специалистов в области управления проектами и являющаяся основой для международной сертификации. В соответствии с правилами и требованиями IPMA в России разработаны национальные требования к компетенции менеджера проекта и программа сертификации специалистов по управлению проектами. Специалисты, прошедшие сертификацию по этой системе, получают сертификаты международного образца, которые признаются во всем мире;

институт управления проектами США (Project Management Institute - PMI) сегодня «де факто» также можно назвать международной профессиональной организацией. Членами PMI являются специалисты в области управления проектами со всего мира, в различных странах функционируют отделения института. PMI ведет активную разработку стандартов в области управления проектами. В настоящее время опубликовано 3 основных стандарта, регламентирующих процессы управления на уровне проекта, программы, портфеля проектов и более 10 дополнительных стандартов. Дополнительные стандарты определяют как требования к отдельным методикам управления проектами (разработка иерархической структуры работ, разработка календарного плана, управление рисками и другие), так и к применению проектного менеджмента для определенных типов проектов (управление строительными проектами, управление государственными проектами и другие) .

По областям применения стандарты могут быть разделены на следующие группы:

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

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

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

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

Таблица 1.4.

Наиболее известные стандарты международного и национального уровня

Классификация стандартов
Международные стандарты, определяющие общие требования к процессам управления проектом.	ISO 10006 «Системы менеджмента качества. Руководящие указания по менеджменту качества проектов»	ГОСТ Р ИСО 10006-2013 «Системы менеджмента качества. Руководство по менеджменту качества при проектировании», 2015.На практике применяется достаточно редко, поскольку носит общий характер.
Национальные стандарты, определяющие общие требования к процессам управления проектом.	A Guide to the Project Management Body of Knowledge (PMBOK Guide). Руководство к своду знаний по управлению проектами. Четвертое издание. PMI. 2015 PRINCE2 (PRojects IN Controlled Environments). OGC UK, 2001 и другие национальные стандарты	Руководство к своду знаний по управлению проектами. Четвертое издание. PMI. 2015 Русская версия. Не является стандартом в России. Однако PMBOK широко применяется на международном уровне и является стандартом «де факто». В России также применяется достаточно широко.
ЕСУП (Евразийский Стандарт Управления Инновационными Проектами)	Не известны иностранные версии стандарта	Евразийский Стандарт Управления Проектами разрабатывается на основе лучших мировых достижений проектного менеджмента с учётом задач и особенностей Евразийской цивилизации. Основная идея стандарта воплощена в корпоративном прототипе ЕСУП.
Стандарты, определяющие общие требования к процессам управления программой и портфелем проектов.	The Standard for Program Management, Second Edition, PMI 2015. The Standard for Portfolio Management, Second Edition, PMI 2015 Managing Successful Programmes, OGC UK, 2014 P2M. Program and Project Management for Innovation of Enterprises, PMCC, 2002
Стандарты, определяющие требования к последовательности и методикам выполнения отдельных процессов.	Practice Standard for Work Breakdown Structure, 2nd Edition, PMI, 2015 Practice Standard for Earned Value Management, PMI, 2013 Practice Standard for Scheduling, PMI, 2014 Practice Standard for Configuration Management, PMI, 2014	ГОСТ Р 52806-2014 Менеджмент рисков проектов. Общие положения.
Стандарты, определяющие требования к квалификации специалистов в области управления проектами.	ICB IPMA Competence Baseline, Version 3.0, IPMA 2015 PMCDF Project Management Competence Development Framework, PMI, 2013	Основы Профессиональных Знаний и Национальные Требования к Компетентности (НТК 3.0) Специалистов по Управлению Проектами, СОВНЕТ, 2013. Не является официальным стандартом в России, но зарегистрирован в Росстандарте России. Используется для сертификации специалистов в соответствии с требованиями IPMA. ГОСТ Р 52807-2014 Руководство по оценке компетентности менеджеров проектов.
Стандарты, определяющие требования к корпоративной системе управления проектами.	OPM3 Organizational Project Management Maturity Model, PMI, 2015	Нет русскоязычных версий стандартов.

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

В рамках организационно - деятельностей (“менеджерской”) модели (ICB IPMA) проект как понятие определяется через предприятие, усилие и деятельность.

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

те, которые можно описать в виде процессов, объектов, методов;

те, которые не описываемы в принципе или трудно описываемы в виде процессов, объектов, методов.

Современные подходы к стандартизации в области РМ основаны на следующем:

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

для тех областей РМ, описание которых в виде объектов для стандартизации нецелесообразно или невозможно, используются профессиональные квалификационные стандарты (требования) к деятельности специалистов по РМ (Project Management Professional) и менеджеров проектов (Project Manager).

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

Вывод по первой главе

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

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