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

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

Проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов [18, с. 12]. Поэтому всем проектам присущи три важные характеристики:

- наличие даты начала и завершения проекта;

- наличие результата проекта в виде уникального продукта или услуги;

- направленность проекта на достижение конкретных и определенных целей.

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

По мнению Чурилова А.А., на сегодняшний день проектное управление пока не имеет широкого распространения в РФ в силу того, что является принципиально новой организационной и профессиональной рыночной культурой для российских руководителей, управленцев и менеджеров. Однако, интерес к применению проектных методов управления в последние годы имеет актуальность, причем во всех отраслях экономики [20].

По мнению кандидата физико-математических наук, управляющего партнера и директора по консалтингу ГК «Проектная ПРАКТИКА» Михаила Козодаева: «В последние годы в России технологии проектного управления получили существенное развитие, которое связано как с использованием современных подходов в области проектного управления, так и с использованием современных автоматизированных систем управления проектами. Кроме того, остро осознается необходимость использования всех возможностей для повышения качества работ, снижения расходов, сроков, используя для этого методы организационного менеджмента, в частности методы проектного управления. Коммерческими компаниями внедряются отдельные элементы систем управления проектами, которые закладывают основу для будущего развития. Внедряются специализированные решения по программно-целевым методам управления в государственных органах власти. Расширяется теоретическая база российского проектного управления — создаются новые национальные стандарты в системе ГОСТ. Именно поэтому еще одной особенностью развития проектного управления в России последних лет является возрастающее внимание к этой сфере со стороны органов государственной власти. Причем не только регионального, но и федерального уровня» [20].

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

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

Можно выделить два уровня управления проектом:

1)    операционный,

2)    проектный.

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

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

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

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

Рисунок 1 – Существующие методологии проектного менеджмента

Традиционный последовательный менеджмент представлен двумя разновидностями – Waterfall и Critical Path Method (CPM).

Waterfall (в пер. с англ. – «водопад») – разработан в 1950-1970 годах в США основан на последовательном прохождении стадий проекта. Каждая следующая стадия начинается только по завершению предыдущей, поэтому эта методология позволяет достаточно легко управлять проектом. Благодаря её четкой структуре и жесткости сокращается время работы над ним и уже на начальном этапе она позволяет легко оценить ресурсные и временные затраты на проект. Эта методология даёт отличный результат в проектах с заранее определёнными требованиями. Она лучше всего подходит для проектов, целью которых является создание физически осязаемых предметов – зданий, сооружений, предметов бытовой и компьютерной техники и так далее. Проектные планы, созданные в данной нотации легко повторимы и воспроизводимы в будущем [8].

Critical Path Method (CPM) (в пер. с англ. – «метод критического пути») – данный проектный менеджмент разработан в 1950-х гг. в США. Он основан на концепции, что некоторые задачи возможно решать лишь тогда, когда были решены предыдущие. Важно выделить и выстроить такие задачи в некую последовательную цепочку с четким началом и концом – это и будет критический путь. Руководителям проекта необходимо сосредоточивать свое внимание только на этом критическом пути, что позволит правильно определить приоритеты и распределить ресурсы, для того, чтобы выполнить наиболее важную работу, и перераспределить или отказаться от наименее значимых задач, которые могут задерживать работу всей команды. В процессе выполнения проекта могут вносится изменения в его расписание для оптимизации критического пути и устранения задержек в работе всей проектной команды [7, 8].

Классический менеджмент по Project Management Body of Knowledge (PMBOK) (в пер. с англ. – «свод знаний по управлению проектами») – этот стандарт разработан в 1980-х гг., был первоначально принят Американским национальным институтом стандартов (ANSI) в качестве национального стандарта в США, а в настоящее время обрел мировое признание. В основе стандарта лежит процессный подход к управлению проектами [13]. По нашему мнению, PMBOK как термин в разрезе отношения его к методологии проектного менеджмента является достаточно двойственным понятием. В нем происходит смешение некоего стандарта с его практическим применением. По сути PMBOK, это набор правил и лучших практик, своеобразный стандарт, говорящий о том, как должен быть построен проектный менеджмент и, хотя многие фирмы заявляют о том, что они используют этот проектный менеджмент на самом деле это лишь означает, что их проект разделен на 5 этапов – инициирование проекта, планирование проекта, выполнение проекта, контроль проекта и закрытие проекта, предусмотренные в PMBOK [17, 18, 19]. Нам видится, что благодаря фундаментальному и всестороннему описанию, воспринимать этот вид проектного менеджмента можно и как стандарт и как методологию одновременно.

Гибкий менеджмент включает пять разновидностей – Agile, Scrum, Kanban, Extreme Programming, Adaptive Project Framework.

Agile (в пер. с англ. – «гибкий») – относится к семейству гибких подходов к управлению проектами и продуктами. Манифест Agile был выпущен и опубликован в 2001 году в США. Особенностью этой методологии является то, что проект разбивается не на последовательные этапы, а на маленькие подэтапы, результаты работы которых затем «складываются» в готовый проект. Таким образом, инициация и глобальное планирование проводятся для всего проекта, а последующие этапы, такие как разработка, тестирование и прочие проводятся для каждого подпроекта отдельно [9]. По нашему мнению, это позволяет передавать результаты этих подпроектов быстрее, что приводя к тому, что, приступая к новому подпроекту, в него можно внести изменения без больших затрат и влияния на остальные части проекта. Цели проекта всегда четко определены заказчиком, но результат проекта может изменяться. Проектная команда работает в итерационных циклах, и по окончании каждого из них делается оценка и формируется вывод, который может повлиять на конечный результат проекта, чтобы он наиболее полно удовлетворил потребности клиента. Во время работы над проектом происходит постоянное сотрудничество и взаимодействие членов команды и представителя заказчика [3].

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

Kanban (в пер. с япон. – «вывеска») – это разновидность гибкого проектного менеджмента, который был разработан на заводах Toyota в Японии в 1940-x гг. Он похож на промышленное конвейерное производство: на входе поступает задача, которая проходит по разным участкам конвейера, где над ней производится работа, а на выходе получается готовый продукт. Другой важной частью этого подхода по мнению Адлера Ю.П., является идея, позаимствованная из работы супермаркетов, – «держи на полках лишь то, что нужно клиенту». Она трансформировалась в разрешение оставлять незаконченную задачу на одном из её этапов, в случае изменения приоритетов и появления более важных задач. Проектная группа создает для каждой задачи визуальные карточки (вывески), которые перемещаются после завершения определённых этапов, тем самым прогресс в работе визуализируется и становится наглядным, позволяя вовремя выявлять заторы в работе [12].

Extreme Programming (XP) (в пер. с англ. – «экстремальное программирование») – это разновидность гибкого проектного менеджмента, которая разработана в 1999 году в США для повышения качества и простоты адаптации проектной команды к требованиям заказчика. Многое здесь заимствовано из Agile, однако сами «спринты» очень короткие, с частыми итерациями и постоянным взаимодействием с представителем заказчика. Изменения могут касаться даже самого «спринта», например, если работа над какой-то задачей внутри «спринта» еще не начата, то эта задача может быть выгружена в отдельный «спринт» [14].

Adaptive Project Framework (APF) (в пер. с англ. – «адаптивный проектный менеджмент») – возник в 2010-х гг. в США из осознания того, что большинство ИТ-проектов не могут управляться традиционными методами, так как требования к таким проектам часто чётко не могут быть сформулированы на начальном этапе, к тому же сами требования могут сильно изменяться в процессе работы над проектом. Поэтому адаптивный проектный менеджмент всегда начинается с определения стратегических целей проекта на основе требований к продукции, её функционалу и возможностям. Проект также проходит итерационные этапы как в других гибких системах проектного менеджмента, в конце каждого такого этапа члены команды оценивают работу и её результаты в целях дальнейшей повышения своей эффективности. Все заинтересованные стороны могут изменять масштабность проекта перед началом каждого этапа, чтобы данный этап принёс максимальную отдачу для проекта в целом [11].

Изменяемый менеджмент – это группа методологий, которая занимается управлением проектом, делая акцент прежде всего на управлении им в случае воздействия на него, например, рисковых ситуаций. К этой группе относятся:

Event Chain Methodology (ECM) (в пер. с англ. – «методология моделирования событий») – создана в 2000-х гг. в США и базируется на том, что существуют потенциальные риски для проекта, которые находятся вне его сферы. Очень важно быть готовым к таким рискам и иметь план действий на случай, если они произойдут, ведь такие события в конечном итоге повлияют на график работы и результат всего проекта в целом [10].

Extreme Project Management (XPM) (в пер. с англ. – «экстремальное управление проектами») – методология, созданная в 2000-х гг. в США и применяемая для управления очень сложными и очень неопределенными проектами. Основное внимание сосредоточено на человеческом факторе, а не на планировании и формализме. Данный подход позволяет двигаться вперед по проекту, не смотря ни на какие массовые изменения в проекте. Разрешается изменять план, бюджет и сроки завершения проекта. Главное соответствовать изменившимся потребностям в какой бы точке проекта вы не находились. По мнению Ashley Coolman, этот способ идеально подходит для кротких проектов, длительностью от нескольких недель до нескольких дней [3].

Процессный менеджмент представлен тремя разновидностями:

Lean (в пер. с англ. – «бережливый») – методология проектного менеджмента, разработанная в 1950-х гг. в Японии, нацеленная на упорядочивание и избавление от всего лишнего. Цель данного подхода – сделать больше, но с наименьшими затратами, то есть достигнуть цель проекта, используя меньше трудовых ресурсов, меньше денег и меньше времени [4].

Lean Six Sigma (в пер. с англ. – «шесть бережливых сигм») – данный подход проектного менеджмента разработан в 2000-х гг. в США, агрегирует в себе минимализм Lean и отсутствие дефектов подхода Six Sigma. Здесь основное внимание уделяется ликвидации всего лишнего таким образом, чтобы проекты стали более эффективными и по-настоящему отвечали нуждам заказчика [2].

Process-Based Project Management (в пер. с англ. – «проектный менеджмент на основе процессов») – данная методология появилась в 2000-х гг. в США, приводит проектные задачи в соответствие с миссией компании и ее корпоративным ценностям.  Таким образом, все цели и задачи проекта становятся стратегическими и должны дорасти до общекорпоративных целей. Фактическими этапами этого подхода являются: определение процесса, создание метрики, измерение процессов, корректировка целей, планирование улучшений и их применение [1].

Другие виды проектного менеджмента:

PRojects IN Controlled Environments 2 (PRINCE2) (в пер. с англ. – «проект в контролируемой среде») – методология разработана в 2009 году для правительства Великобритании, её особенностью является то, что подход к планированию проекта основан на типе создаваемого продукта. В PRINCE2 мероприятия высокого уровня управляют настройкой бизнес-оборудования и распределением ресурсов, они находятся в компетенции структурированного совета проекта, руководитель же проекта заботится о более низком уровне – ежедневное планирование и осуществление каждодневных мероприятий [5]. Эта методика, по нашему мнению, позволяет эффективно контролировать ресурсы и максимально снижать рисковость проекта.

PRojects integrating Sustainable Methods (PRiSM) (в пер. с англ. – «устойчивые методы для интеграции проектов») – является проектным менеджментом, который был создан в 2000-х гг. в США для того, чтобы проектировать и создавать насыщенные, гибкие и легко поддерживаемые приложения. В его основу заложены шаблоны проектирования, которые воплощают важные принципы архитектурного дизайна, такие как разделение ответственности и слабая связанность. Prism позволяет проектировать и писать приложения со слабо связанными компонентами, которые могут независимо развиваться и потом объединяться в одно целое с минимальными затратами [8].

Benefits Realization (в пер. с англ. – «реализация преимуществ») – данная методология разработана в конце 1990-х гг. в США, ставит во главу угла преимущества, которые получает заказчик от реализуемого для него проекта, а не срок выполнения и бюджет проекта. Этот подход гарантирует, что проект принесет реальную ценность для заказчика [6].

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

Суть первого способа заключается в том, что необходимо оценить конечные цели и задачи проекта, а также тот результат, который необходимо получить и, исходя из этих сведений, выбрать подходящий проектный менеджмент. Например, если в результате выполнения проекта необходимо получить физически осязаемый объект с конкретными характеристиками и определенной спецификацией понятной для всех заинтересованных сторон, то подойдут методологии традиционного последовательного менеджмента, такие как Waterfall и Critical Path Method. Если проектным результатом является программный продукт, который еще до конца не определен, то подходящим решением, по нашему мнению, может стать гибкий менеджмент в в виде Agile, Scrum, Kanban, XP, APF. Если же для продукта важным является простота поддержки и дальнейшее развитие, гибкость, а также возможность объединять различные независимые блоки в единую экосистему и обеспечивать ее простое развертывание и обновление, то наиболее подходящим будет подход ввиде PRiSM. Однако, если важно обеспечить максимально быстрое развитие минимально жизнеспособного продукта, то правильным будет использовать процессный менеджмент такой как Lean, Lean Six Sigma [4, 10].

Суть второго способа, по нашему мнению, заключается в том, что необходимо изучить и проанализировать прошлый успех проектной команды и определить, что именно помогло ей его достичь. Важно понять, какой рабочий процесс делает команду наиболее продуктивной. Если команда раскрывается посредством сотрудничества, обмена идеями, а задачи проекта могут меняться вплоть до последней минуты работы над ним, то правильным, по нашему мнению, будет использовать Agile, Scrum, Kanban, XP, APF. Однако, если проектная команда предпочитает упорядоченный и четко структурированный стиль работы по понятному плану в строгой последовательности, то ей лучше подойдут следующие методологии проектного менеджмента, такие как Waterfall и CPM.

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

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

1. Alexander Moira How to pick a project management methodology [Электронный ресурс]. – URL. – http://www.cio.com/article/2950579/project-manager/how-to-pick-a-project￾management-methodology.html (дата обращения: 9.11.2016).
2. Ashley Coolman What is Extreme Project Management and is it Right for Your Team? [Электронный ресурс]. – URL. – https://www.wrike.com/blog/extreme-project-management (дата обращения: 05.11.2016).
3. Bonnie Emily 5 Lessons in Lean Product Development from the Wright Brothers (Infographic) [Электронный ресурс]. – URL. – https://www.wrike.com/blog/5-lessons-in-lean￾product-development-from-the-wright-brothers-infographic (дата обращения: 07.11.2016).
4. Bonnie Emily Project Management Basics: PRINCE2 Explained [Электронный ресурс]. – URL. – https://www.wrike.com/blog/project-management-basics-prince2-explained (дата обращения: 07.11.2016).
5. Filev Andrew Project Management Critical Path is Easy as 1,2,3 [Электронный ресурс]. – URL. – https://www.wrike.com/blog/critical-path-is-easy-as-123 (дата обращения: 13.11.2016).
6. Katcherovski Vadim 5 Effective Project Management Methodologies and When to Use Them [Электронный ресурс]. – URL. – http://explore.easyprojects.net/blog/2012/08/23/project-management-methodologies (дата обращения: 8.11.2016).
7. Manifesto for Agile Software Development [Электронный ресурс]. – URL. – http://agilemanifesto.org (дата обращения: 08.11.2016).
8. Адлер Ю.П. Канбан и “точно вовремя” на Toyota. Менеджмент начинается на рабочем месте [Текст]/ Ю.П. Адлер. – М.: Альпина-Паблишер, 2016. – с. 214
9. Балашов, А. И. Управление проектами [Текст]: учебник для бакалавров / А. И. Балашов, Е. М. Рогова, М. В. Тихонова, Е. А. Ткаченко.– М.: Юрай, 2013. – 383 с.
10. Кирилкин Дмитрий Управление проектами: операционный vs. проектный подход [Электронный ресурс]. – URL. – https://habrahabr.ru/post/223525 (дата обращения: 11.11.2016).
11. Майк Кон Scrum. Гибкая разработка ПО: пер. с англ. Красиков И. [Текст] / Кон Майк. – М.: Вильямс, 2015. – с. 576
12. Павлов А. Управление проектами на основе стандарта PMI РМВОК. Изложение методологии и опыт применения. – Бином. Лаборатория знаний, 2014 – 272с.
13. Рогова, Е. М. Управление проектами [Текст]: учебник для бакалавров / Е. М. Рогова. – М.: Юрайт, 2013 – 193 с.
14. Руководство к своду знаний по управлению проектами [Текст]: руководство PMBOK. – 5-е изд., изд. Project Management Institute, 2013. – 496 с.

Все статьи автора «Полушкин Денис Павлович»