CC BY
218
КЛАССИФИКАЦИЯ И ОПИСАНИЕ СОВРЕМЕННЫХ ПОДХОДОВ И МЕТОДИК
УПРАВЛЕНИЯ ПРОЕКТАМИ
Ушаков Денис Сергеевич,
Аспирант Московской международной академии, Москва, Россия
Аннотация. В статье рассмотрена классификация современных методологий управления проектами. Проанализированы основные сферы их применения. В работе выделены особенности использования наиболее распространенных методов управления проектами.
Ключевые слова: управление проектами, гибкие методологии, Waterfall, Agile, Scrum, Kanban
CLASSIFICATION AND DESCRIPTION OF MODERN APPROACHES AND METHODS
OF PROJECT MANAGEMENT
Denis S. Ushakov,
Postgraduate student of the Moscow International Academy, Moscow, Russia
Abstract. The article considers the classification of modern project management methodologies. The main areas of their application are analyzed. The paper highlights the features of using the most common project management methods.
Keywords: project management, agile methodologies, Waterfall, Agile, Scrum, Kanban
Методики управления проектами используются везде: от разработки компьютерных приложений до автомобильной промышленности и строительства космических кораблей. При наличии проекта и команды обычно применяется какая-либо методология, комбинация нескольких методик или, по крайней мере, некоторые элементы из них. Использование методологии позволяет менеджерам один раз выбрать инструменты и стандарты, и затем реализовывать проекты по «конвейеру», достигая предсказуемых результатов.
Существуют десятки разных методик и подходов к управлению проектами, которые отличаются принципами работы и используемыми инструментами. В статье исследуем основные современные методологии управления проектами, которые чаще всего применяются на предприятиях.
Цель исследования - проанализировать современные и наиболее распространенные методы управления проектами, выделить их особенности и сферы применения.
Под методологией управления проектом, как правило, подразумевается система принципов, определяющая порядок выполнения задач. В эту систему входят методы оценки и контроля исполнения работы, с помощью которых менеджер управляет проектом [3].
Всё множество методологий и философий управления проектами можно объединить в три большие группы подходов:
• классический;
• гибкий;
• гибридный.
Классический подход (или каскадный) - подход, при котором на проекте соблюдается чёткая последовательность действий. Необходимо закончить один этап производства, чтобы перейти к следующему.
Сферы, в которых используют классический подход:
• промышленное производство;
• строительство;
• разработка программного обеспечения.
• Для каких проектов подойдёт классический подход:
• Проекты с чётко установленными требованиями.
• Проекты с ограниченными сроками и бюджетом.
• Типовые проекты.
Примеры:
Методология Waterfall. Waterfall (в переводе с английского - водопад) - методология разработки, при которой создание продукта происходит последовательно, завершается один этап работ и только потом начинается новый [4].
Проект выглядит как поток, где каждый шаг заранее определён, а все шаги следуют строго один за другим. Этот подход также известен как «жесткий», поскольку все элементы проекта заранее определены и обычно установлены жесткие сроки. Задачи могут накладываться друг на друга и выполняться параллельно.
Основным инструментом этой методологии является диаграмма Ганта, на которой отмечают задачи и сроки их выполнения.
Особенности методологии Waterfall:
Объём работ, бюджет, сроки сдачи проекта и продукт не меняются на протяжении всего проекта.
Так как не меняются главные составляющие проекта (объём работ, бюджет, сроки сдачи проекта), работа идёт стабильно и предсказуемо, её легко контролировать.
На проекте составляются подробные требования и документация, качество которых влияет на успех проекта.
Заказчик почти не вовлечён в работу над проектом. В начале сотрудничества он обсуждает с исполнителем продукт, который хочет получить, а в конце - принимает результат.
Заказчику передаётся уже полностью готовый продукт.
Команда выполняет задачи в строгой последовательности: сначала завершает один этап, потом переходит к следующему.
Сроки выполнения задачи влияют на сроки завершения проекта.
Изначально Waterfall применялся в промышленности и строительстве, где необходимо поэтапно выполнять работы и строго следовать плану. Позже методологию стали использовать для создания цифровых продуктов в IT-сфере, но она сохранила свои особенности.
Обычно Waterfall подходит для проектов, которые можно реализовать за небольшой срок. Это не жёсткое ограничение, но чем длиннее проект, тем меньше шансов, что все перечисленные условия будут к нему применимы.
Методология PRINCE2. Методика PRINCE2 была создана в 1989 году в Великобритании. Ее название произошло от акронима «PRojects IN Controlled Environments version 2» и переводится как «Проекты в контролируемой среде версии 2». В отличие от agile-методов, PRINCE2 не использует итерационный подход к проектам [1]. Сравнивая PRINCE2 с другими методиками, его можно сопоставить с гибридом классического подхода к управлению проектами и шести сигм, ориентированных на качество.
Методология PRINCE2 не включает в себя:
Специализированные аспекты управления проектами (например, отраслевые).
Специфические методы и инструменты управления проектами, такие как диаграммы Ганта.
PRINCE2 фокусируется на аспектах управления проектами, выраженных в семи принципах, семи процессах и семи темах проекта:
Семь принципов определяют общие правила управления проектами по PRINCE2 и являются основой методологии.
Семь процессов определяют этапы проектного цикла.
Семь тем - это аспекты, по которым осуществляется контроль для достижения успеха про-
PRINCE2 также рекомендует применять методологию, адаптированную для каждой организации.
PRINCE2 предлагает определить три ключевых аспекта в начале проекта:
• Бизнес-аспект.
• Потребительский аспект.
• Ресурсный аспект.
По сравнению с другими методами управления проектами, PRINCE2 имеет четко определенную структуру команды проекта. Это объясняется тем, что он ориентирован на крупные государственные проекты и большие организации.
PRINCE2 может применяться к проектам любого масштаба и в любой предметной области. Методология содержит конкретные рекомендации по изменению жизненного цикла проекта, ролевой модели и набора необходимых документов в соответствии с потребностями проекта.
Гибкий подход (или итеративно-инкрементальный) - подход, при котором команда работает короткими итерациями и фокусируется на результате, то есть сосредотачивается не на соблюдении требований, а на удовлетворении потребностей клиента. Если становится понятно, что требования не помогают удовлетворить потребности, их меняют по ходу работы.
Гибкий подход создан для разработки инновационных продуктов, творческой работы и экспериментов. Любые идеи при таком подходе можно быстро воплотить в жизнь и протестировать, а требования клиента - изменить.
Сферы, в которых используют гибкий подход:
• сфера услуг;
• инновационные проекты;
• разработка.
Для каких проектов подойдёт гибкий подход:
• Проект, сроки и бюджет которого могут меняться.
• Инновационный проект, требования к которому могут постоянно меняться.
• Проекты, на которых важно не реализовать детально описанный результат, а найти решение проблемы.
• Проект, в котором команда может самостоятельно принимать решения, организовывать работу и приоритизировать задачи.
Примеры:
Методология Agile. Agile зародился в 90-х годах прошлого века, когда эксперты-практики в области разработки программного обеспечения независимо друг от друга пришли к осознанию - нужно найти альтернативу Waterfall-подходу.
В 2001 году они собрались вместе, чтобы обменяться опытом, но в итоге достигли большего - договорились о ключевых аспектах нового подхода к разработке и оформили их в виде документа «Манифест гибкой разработки».
Вся суть Agile содержится в четырёх пунктах его манифеста:
Люди и их взаимодействие важнее процессов и инструментов проектного управления.
Рабочее программное обеспечение (результат проекта) важнее всеобъемлющей документации.
Сотрудничество с клиентами важнее переговоров по контракту.
Реагирование на изменения важнее следования плану.
Именно из-за последнего пункта семейство методологий Agile и называется гибким.
Agile предлагает полностью поменять суть отношений между участниками проекта и добиться высокой гибкости и скорости реакции на любые изменения. Для этого команде нужно перейти на неформальные, партнёрские отношения. А ещё сократить до разумного минимума проектную документацию и оставить только то, что реально нужно.
Важно понимать, что Agile не отрицает процессы, инструменты, документацию, контракты и планы, он просто максимально их упрощает, чтобы команде было проще работать. И чётко
расставляет приоритеты, уделяя больше внимания взаимодействию команды и заказчика, работающему продукту и положительной реакции на изменения, чем формальной стороне дела.
Agile включает в себя несколько методологий, в том числе Scrum, Scrumban, Kanban, Lean, XP, FDD, TDD, SoS, LeSS, SAFe и AgilePM. Все они соответствуют принципам Agile, различаются лишь отдельные инструменты и методы управления.
На практике работа по гибкой методологии означает, что команда работает небольшими циклами, в каждом из которых создается готовая функция или продукт. В следующем цикле они дорабатывают или улучшают его. Поскольку работа часто ведется параллельно и результаты видны еще до завершения проекта, новые требования (по мере их появления) могут быть легко включены в следующий цикл.
Подходящие проекты - это большинство современных ИТ-проектов, в которых определены общие рамки продукта, но нет конкретного видения результата. Такие проекты обычно требуют гибкости, быстрых изменений и способности адаптироваться к новым требованиям бизнеса и рынка, для чего идеально подходят методологии управления проектами Agile.
Методология Scrum. Метод Scrum чаще всего используют на долгосрочных проектах, где есть только наброски продукта. Этого не всегда достаточно, чтобы понять, куда должен развиваться продукт. Поэтому неправильно выбранный вектор развития может дорого стоить. Чтобы избежать этих и других проблем, компании пришли к гибкому методу разработки Scrum. Он помогает быстро адаптироваться к любым изменениям за счёт итеративности и вовлечения заказчика в процессы.
Весь процесс скрам-разработки разбивают на короткие итерации, чтобы демонстрировать результат заказчику, анализировать обратную связь и адаптироваться к внешним изменениям или новым требованиям.
Эти итерации называют спринтами - обычно они длятся от одной недели до месяца, но не больше. Один из главных принципов Scrum - работающий продукт ценнее подробной документации. Результатом каждого спринта становится инкремент продукта - то есть изменения, которые добавляют ему ценности. Поэтому заказчик сразу видит прогресс. Такое развитие продукта называют инкрементальным [4].
Структура процессов Scrum вращается вокруг 5 основных событий:
Уточнение беклога (груминг). Бэклог не статичен - функции могут добавляться или удаляться в зависимости от развития продукта. Для этого проводят уточнение бэклога, которое ещё называют грумингом. Это встреча скрам-команды, на которой обсуждают, какие ценные для продукта функции должны оставаться в бэклоге и приотритизируют их. Чем выше ценность для пользователей и заказчика, тем они приоритетнее. Благодаря грумингу команде разработчиков проще планировать спринт - в нём остаются только задачи, которые приносят максимальную ценность продукту.
Планирования спринта. Это скрам-событие, которое команда разработчиков проводит в начале каждого спринта. На планировании из бэклога продукта отбирают и оценивают функции и разделы, которые нужно взять в работу. После утверждения состава бэклогаспринта он становится неприкосновенным - никто не может добавить задачу в спринт после его начала. Такое правило гарантирует, что в финале спринта команда получит запланированный инкремент ценности продукта. Если во время спринта критически важно внести изменения, работы останавливают, спринт отменяют и планируют новый.
Ежедневные встречи (дейли скрам). Ежедневные стендап-встречи команды разработчиков длительностью до 15 минут. Они помогают быстро адаптироваться к изменениям в ходе спринта.
Обзора спринта. Демонстрация результатов работы, которая помогает понять, удалось ли достичь цели. Каждый член команды разработки рассказывает и показывает, что сделал за спринт.
Ретроспектива спринта. Событие, которое помогает повысить эффективность и качество работы скрам-команды. На ретроспективе анализируют, как прошёл спринт, ищут удачные и
неудачные решения, которые надо оставить (или наоборот). После встречи команда получает список изменений, которые нужно внести в процесс разработки.
Методология Kanban. В отличие от Scrum и других Agile-методов, изначально созданных для разработки ПО, Kanban придумали в компании Toyota в середине XX века, чтобы оптимизировать складские запасы и работу конвейера при сборке автомобилей [2].
Главные характеристики Kanban отражены в его названии:
• упор на визуализацию,
• использование информационной доски и карточек.
Kanban, в отличие от других методологий, сделан так, чтобы с его помощью можно было улучшить существующий процесс, легко и безболезненно встраиваясь в него.
Kanban основывается на нескольких главных правилах:
Визуализировать поток создания ценности. Основной инструмент визуализации в Kanban -это так называемая Kanban-доска, которая используется для визуализации выполняемых задач. Она может быть физической или виртуальной.
При работе с Kanban-доской есть два важных нюанса:
1. Крупные задачи лучше разбивать на части.
2. Если у команды несколько производственных процессов, этапы которых сильно отличаются, для каждого из них можно сделать свою доску.
Ограничивать незавершённую работу. Незавершённой называется задача, выполнение которой начато, но на данный момент ещё не завершено по любой причине. В Kanban есть правило: количество незавершённых задач в каждой колонке должно быть жёстко ограничено.
Измерять, анализировать и оптимизировать рабочий процесс. Одно из правил Kanban - измерять время, которое любая задача находится на каждом из этапов, и анализировать, что мешает работать быстрее. Это помогает оптимизировать рабочий процесс и выполнять задачи максимально быстро.
Определить критерии качества. Чтобы проводить контроль качества, для каждой задачи прописывают критерии приёмки - некоторые условия, выполнение которых означает, что задача завершена. Зная заранее критерии приёмки каждой задачи, исполнитель может проверять себя по ним самостоятельно.
«Вытягивать», а не «вталкивать» задачи. Один из принципов Kanban (как и Agile в целом) - самоорганизация команд, поэтому решение о том, кто что будет делать, принимают сами исполнители, как бы «вытягивая» задачи из общего списка.
Расставлять приоритеты как можно позже. Kanban поддерживает самоорганизацию, но не хаос. Поэтому освободившийся исполнитель берёт не просто любую задачу из списка, а ту, что имеет самый высокий приоритет. При этом приоритеты должны расставляться не заранее, а как можно позже. В идеале - непосредственно перед тем, как исполнитель возьмёт следующую задачу. Тогда он точно будет делать именно то, что важнее всего в данный момент.
Улучшаться коллективно. По принципам Kanban, сохранять конкурентоспособность возможно только в том случае, если периодически задаваться вопросом, достаточно ли эффективно работает команда, есть ли какие-то возможности для улучшения и что конкретно можно сделать для повышения эффективности и качества.
Методология Lean. Agile говорит, что проекты должны быть разбиты на небольшие управляемые блоки работ, но ничего не говорит о том, как управлять разработкой этих блоков. Scrum предлагает свои собственные процессы и процедуры. Lean, с другой стороны, добавляет к принципам Agile схему потока операций, чтобы гарантировать, что каждая итерация будет выполнена с одинаковым качеством.
В методике Lean, как и в Scrum, вся работа делится на более мелкие блоки, которые выполняются отдельно и независимо друг от друга. Однако, в Lean существует поэтапный процесс операций для разработки каждого блока.
Этапы Lean и его гибкость гарантируют, что каждая часть проекта выполняется в соответствии с требованиями. В Lean нет четких границ этапов, в отличие от Scrum, где определены
границы спринта. Кроме того, в отличие от классического управления проектами, метод Lean позволяет параллельно выполнять несколько задач на разных этапах, что повышает гибкость и ускоряет выполнение проекта.
Как и Agile, Lean - это концепция или образ мышления. Используя концепцию Lean, можно построить систему, отвечающую определенным требованиям в управлении проектами.
Методология «6 сигм» («Six Sigma»). Компания Motorola, наряду с Toyota Motor Corporation, также внесла свой вклад в развитие глобальных систем управления проектами. В 1986 году Билл Смит, инженер этой компании, создал концепцию «Six Sigma». Это более структурированная версия Lean, чем Kanban, с большим количеством планирования для экономии ресурсов, повышения качества и сокращения дефектов [6].
Конечная цель - удовлетворить клиента высококачественным продуктом, что достигается путем постоянного совершенствования всех аспектов проекта на основе тщательного анализа эффективности. В концепции «6 сигм» особое внимание уделяется устранению проблем по мере их возникновения.
Для достижения этой цели предлагается пятиэтапный процесс:
Определение. Первый шаг очень похож на начальные этапы других систем управления проектами. Он определяет проект, собирает информацию о предпосылках проекта и устанавливает цели.
Измерение. Второй шаг фокусируется на сборе и анализе количественных данных о проекте. На этом этапе определяется, какие показатели будут определять успех проекта и какие данные должны быть собраны и проанализированы.
Исследование. На этапе исследования менеджер проекта определяет, как команда может выполнить задачи и требования, уложившись в срок и рамки бюджета.
Разработка. На данном шаге планы и решения, принятые на предыдущих этапах, воплощаются в жизнь. Необходим подробный план, описывающий действия, необходимые для достижения поставленных целей. Здесь же измеряется прогресс проекта.
Контроль. Важный этап в методологии «шести сигм». На этом этапе необходимо тщательно документировать извлеченные уроки, а собранные данные анализировать и применять не только для конкретного проекта, но и для компании в целом.
«Шесть сигм» очень похожа на «Канбан», только в ней установлены этапы планирования, постановки целей и проверки качества выполнения задач. Процесс внедрения более структурирован, и у команды меньше шансов сойти с пути. Единственным строгим требованием является тщательное измерение и мониторинг метрик проекта во время его реализации. Без этого долгосрочное непрерывное совершенствование процессов проекта невозможно.
Гибридный подход - это подход, который сочетает в себе черты гибкого и классического подходов [5].
Решив использовать гибридный подход, менеджер выбирает лучшие особенности гибкого и классического подхода, которые подойдут для конкретного проекта, и совмещает их. В результате получается уникальный подход, который не ограничен никакими строгими рамками и может меняться в зависимости от условий и потребностей.
Для каких проектов подойдёт гибридный подход: проекты, которые требуют более строгого соблюдения задач и сроков, но при этом должны сохранять возможность относительно быстрой реакции на внешние изменения. Часто это ИТ-проекты для крупных или государственных компаний, которые готовы к изменениям, но должны следовать определенным процедурам.
Примеры методологий:
• Метод критического пути (Critical Path Method).
• Метод критической цепи (Critical Chain Project Managment).
Разработанные подходы отличаются друг от друга по областям применения, детализиро-ванности, самодостаточности и формализации.
Таким образом, выбор подхода или методологии зависит от конкретного проекта или его этапа, специфики разработки и ожидаемых результатов. Каждый подход может меняться под
текущие особенности и из типового и теоретического превратится в уникальный, подходящий именно данной команде.
Поэтому дальнейшего исследования требуют особенности выбора и применения наиболее рационального метода управления проектами в области обучения персонала в производственных компаниях, что будет являться темой исследования, как самого автора статьи, так и других менеджеров и исследователей.
Список литературы
1. Вейнберг Р.Р. Применение стандартов управления проектами в ИТ-индустрии: PRINCE2 и РМВоК / Р.Р. Вейнберг, Н.А. Моисеев, С.М. Сахарова // Вестник Российского экономического университета имени Г.В. Плеханова. - 2020. - № 1(109). - С. 56-66.
2. Котляр Е.В. Система управления проектами Канбан / Е. В. Котляр, Е. М. Пушкаре-ва // Бизнес-образование в экономике знаний. - 2020. - № 1(15). - С. 57-59.
3. Павлов А.Н. Эффективное управление проектами на основе стандарта PMI PMBOK 6th Edition / А.Н. Павлов. - М. : Лаборатория знаний, 2019. - 273 с.
4. Электронный курс «Менеджер проектов». Яндекс. Практикум. [https://practicum. yandex.ru/] (дата обращения 16.01.2023).
5. Методологии управления проектами. Блог Яндекс Практикума. [https://practicum. yandex.ru/blog/metodologii-upravleniya-proektami/] (дата обращения 16.01.2023).
6. Топ-7 методов управления проектами: Agile, Scrum, Kanban, PRINCE2 и другие. Проектные сервисы. [https://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/] (16.01.2023).
