CC BY
661
КРЕАТИВНАЯ ЭКОНОМИКА
Том 12 • Номер 6 • июнь 2018 ISSN 1994-6929 Journal of Creative Economy
издательство
Креативная экономика
критерии применения Agile-методологии для управления проектом
Локтионов Д.А}, Масловский В.П.2
1 Маркетинговое агентство «ProMarket», Россия
2 Сибирский федеральный университет, Красноярск, Россия
АННОТАЦИЯ:_
Данная статья предлагает критерии, позволяющие определить, возможно ли использование AgiLe-подхода к управлению тем или иным проектом. Рассматривается возможность применения популярного инструментария вне породившей его ^-сферы. Показаны основные особенности «гибкого» проектного управления и продемонстрировано развитие проектной методологии, где на данный момент сосуществует традиционный подход и «гибкий» инструментарий. Выявлены и обоснованы характеристики проектов, к которым может быть успешно применен AgiLe-подход. На основании исследования специфики проектов, а также изучения развития методологии проектного менеджмента автором предложен подход, позволяющий отнести проект к традиционному или гибкому способу проектного управления. Полученная модель позволяет соотнести любой проект с представленными характеристиками и понять, насколько уместно применение AgiLe-подхода вне зависимости от сферы проекта.
КЛЮЧЕВЫЕ СЛОВА: Agile, управление проектами, гибкое управление проектами..
Criteria for applying the Agile methodology for project management
Loktionov D.A.1, Maslovskiy V.P.2
1 Marketing agency «ProMarket», Russia
2 Siberian Federal University, Russia
введение
Вошедший в классические учебники по менеджменту пример устройства завода Toyota, где каждый сотрудник имел право остановить конвейер, чтобы устранить дефект или внести рационализаторское предложение, составляет основу философии Agile.
Agile, появившийся как метод разработки программного обеспечения в небольших командах, сегодня становится новой культурой управления большими компаниями.
В IT-сфере этот революционный подход позволил многим компаниям достичь успеха в бизнесе посредством применения мультидис-циплинарных команд из разработчиков, маркетологов и других лиц, которые совместно разрабатывают продукт высокого качества, максимально удовлетворяющий требованиям рынка, подстраиваясь под
изменяющуюся среду, а затем постепенно дорабатывают его, добавляя все больше функций, создающих ценность.
Agile-подход к управлению проектами зародился в начале XXI века в сфере IT и с тех пор набирает все большую популярность и применяется по всему миру. Согласно данным отчета State Of Agile от 2016 года [1], 98% команд признали успешность предпринимаемых Agile-проектов. 88% опрошенных признают, что гибкое управление проектами позволило лучше реагировать на изменения. 69% признались, что смогли ускорить поставки продукта при помощи Agile. Подход очевидно доказал свою эффективность, причем не только в сфере IT. Лишь 23% участников указанного опроса работают в сфере разработки программного обеспечения; остальные - в тех или иных сферах услуг: телекоммуникация, финансы, страхование, интернет услуги и др. 3% респондентов вовсе относится к сфере производства. Учитывая специфику гибкого подхода, зачастую кардинально отличающуюся от традиционного проектного менеджмента, данные результаты могут показаться удивительными. Для компании или команды, реализующей новый проект, становится актуальным вопрос: насколько методология Agile может увеличить ценность проекта?
С точки зрения методологии проектного менеджмента, активно трансформирующейся в последние десятилетия, Agile, как противоположность привычному подходу, также является поводом для дискуссий. Устарела ли «негибкая» традиционная методология управления проектами? Насколько можно объединить традиционный подход и Agile? Как адаптировать существующий инструментарий с «гибкими» практиками?
ABSTRACT:_
This article offers criteria for determining whether the Agile approach can be used to manage the particular project. The possibility of using the popular toolkit outside the IT-sphere that generated it is considered. The main features of the "flexible" project management are shown and the development of the project methodology is demonstrated, where the traditional approach and the "flexible" toolkit coexist at the moment. Identified and justified the characteristics of projects to which the Agile approach can be successfully applied. Based on a study of the specifics of IT projects, as well as studying the development of the methodology of project management, the author suggests the approach that allows the project to be classified as a traditional or flexible method of project management. The obtained model allows to correlate any project with the presented characteristics and understand how appropriate the application of the Agile-approach, regardless of the scope of the project.
KEYWORDS: Agile, project management, flexible project management
JEL Classification: H40, H43, H49 Received: 06.06.2018 / Published: 30.06.2018
© Author(s) / Publication: CREATIVE ECONOMY Publishers For correspondence: Loktionov D.A. (loktionov.david0gmail.com)
CITATION:_
Loktionov D.A., Maslovskiy V.P. (2018) Kriterii primeneniya Agile-metodologii dlya upravleniya proektom [Criteria for applying the Agile methodology for project management]. Kreativnaya ekonomika. 12. (6). - 839-854. doi: 10.18334/ce.12.6.39179
Представляет интерес понять, насколько методология Agile универсальна, и в каких проектах она может применяться для увеличения ценности результатов проекта; а где ее инструментарий может стать губительным и опасным для проекта. Целью данной работы является выявление критериев, на основании которых можно определить, какая методология управления будет наиболее эффективна и актуальна для рассматриваемого проекта. Алгоритм исследования предполагал следующие этапы: анализ Agile-подхода, а также особенностей наиболее гибких IT проектов; оценка текущей ситуации в проектной методологии, выявление особенностей каждого из подходов и поиск возможностей комбинирования гибких и традиционных подходов; формирование критериев для выбора инструментария управления проектом и представления рекомендаций.
Agile-подход к управлению проектами
В XXI веке все больше компаний занимаются разработкой проектов в сфере IT. IT проекты, полностью вписываясь в традиционные характеристики проекта, отличаются тем, что их продукт практически невозможно комплексно описать заранее.
В начале 2000-ых сообщество представителей сферы IT выпустило [3] (Stellman, Grin, 2017) свой Аgile-манифест: свод правил и принципов, позволяющих добиваться успехов в разработке проектов в сфере IT.
Приведем Agile-манифест полностью:
«Мы постоянно открываем для себя более совершенные методы разработки программного обеспечения, занимаясь разработкой непосредственно и помогая в этом другим. Благодаря проделанной работе мы смогли осознать, что:
• люди и взаимодействие важнее процессов и инструментов;
• работающий продукт важнее исчерпывающей документации;
• сотрудничество с заказчиком важнее согласования условий контракта;
• готовность к изменениям важнее следования первоначальному плану».
Также идеологи Agile предлагают 12 принципов «гибких» проектов [3].
1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется даже на поздних стадиях разработки.
ОБ АВТОРАХ:_
Локтионов Давид Альбертович, руководитель (Loktionov.david0gmaiL.com)
Масловский Владимир Петрович, кандидат технических наук, доцент, доцент кафедры экономики и управления бизнес-процессами (vmasLovskij0maiL.ru)
ЦИТИРОВАТЬ СТАТЬЮ:_
Локтионов Д.А., Масловский В.П. Критерии применения Ад^е-методологии для управления проектом // Креативная экономика. - 2018. - Том 12. - № 6. - С. 839-854. doi: 10.18334/се.12.6.39179
3. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
4. Работающий продукт следует выпускать как можно чаще с периодичностью от пары недель до пары месяцев.
5. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
6. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
7. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
8. Работающий продукт - основной показатель прогресса.
9. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
10. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
11. Простота - искусство минимизации лишней работы - крайне необходима.
12. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Основным инструментом Agile является методика Scrum [4] (Sazerlend, 2016). Не раскрывая детально этот инструментарий, отметим лишь, что основой Scrum является построение мультидисциплинарных самоорганизующихся небольших (оптимально: 7 человек) команд, которые планируют работу на короткий срок - спринт, итогом которого должен послужить некий продукт, готовый к демонстрации заказчику или другим заинтересованным лицам.
Также в Scrum важен бэклог - список тех или иных требуемых характеристик продукта, формируемый по ходу всей продолжительности работы над проектом. Команда выбирает ту или иную характеристику в соответствии с приоритетом и внедряет ее в продукт в течение одного спринта. Визуализация этапов работы традиционного «водопадного» планирования и итеративного Scrum-подхода представлены на рисунках 1 и 2 соответственно.
Основные составляющие методологии Agile и Scrum в частности представлены в таблице 1.
Таким образом, «гибкий» подход к управлению проектами позволяет оставаться лояльным к изменениям, максимально упростить коммуникацию внутри команды, а также интегрировать заказчика в процесс работы над проектом, чтобы максимально достигать бизнес-ценностей.
Agile подход зародился в IT и применим в первую очередь к высокотехнологичным сферам. Однако в современном мире IT-проекты очень часто становятся важнейшей
Рисунок 1. Схема работы над традиционным проектом Источник: составлено авторами
Формирование требований к проекту
Спринт 1 —
О
Планирование
Реализация Мониторинг
Завершение (передача функции заказчику)
Спринт 2
О
Реализация
I
Мониторинг
Завершение (передача функции заказчику)
► Спринт 3 — □
Планирование 1
Реализация
I
Мониторинг
Завершение (передача функции заказчику)
► Спринт 4 —
/и
Планирование
Реализация Мониторинг
Завершение (передача функции заказчику)
Поддержка ► нз стадии эксплуатации
Рисунок 2. Схема работы над IT проектом в философии Agile Источник: составлено авторами
частью даже при традиционном проектном менеджменте: проектирование сложных архитектурных объектов; производство инновационных способов обработки в тяжелой промышленности; НИОКР на предприятиях; реализация внутренних проектов и т. д.
Бытует мнение, что Agile - это философия современного проектного мышления, котор ая несомненно интегрируется во все ключевые стандарты проектного менеджмента и ст анет неотъемлемой частью управления любыми проектами в весьма неотдаленной перспективе. Исследуем возможность подобной интеграции Agile-инструментов вне IT-сферы.
Особенности «гибких» проектов
Описанная методология родилась в сфере IT для решения проблем, регулярно встающих перед представителями данной отрасли. Определим основные черты гибких IT-проектов, которые соответствуют инструментам Agile.
Проект в сфере IT - это когда результатом деятельности является некий программный продукт или же решение в сфере информационных технологий. Зачастую заказчику подобного проекта известна лишь проблема, которая должна быть решена, а способ ее решения передается в ведение команды проекта.
Таблица 1
Основные элементы методологии Agile
Элемент Agile Описание
Пользовательские истории и бэклог Составляется набор «историй» - вариантов использования готового продукта. Истории дробятся на задачи для реализации и помещаются в отдельный список - бэклог продукта
Планирование итерации Команда выбирает задачи из бэклога, которые она может осуществить за один спринт (2-4 недели)
Serum-доска Доска с графами «Запланировано на спринт», «В Работе», «Завершено» (и дополнительными), куда в открытом доступе помещаются все задачи команды
Ежедневный standup Каждый день команда собирается на 10 минут возле доски задач, обсуждая выполненные и запланированные задачи, а также делясь возникшими проблемами
Ретроспективы Собрания команды, где обсуждается ход выполненных работ за несколько прошедших спринтов
Демонстрация MVP Демонстрация полностью готовой к использованию функции продукта в конце каждого спринта, получение обратной связи
Выделенный владелец продукта и scrum-мастер В команде добавляются роли вегит-мастера - следящего за методологией и владельца продукта - отвечающего за донесение до команды мнения стейкхолдеров
Диаграмма выгорания В общем доступе имеется график, где отображается отношение выполненных задач по спринту к оставшимся
Источник: составлено авторами
1Т-проект можно сравнить с перемещением автомобиля в пространстве - имеется понимание о конечной точке маршрута, но способ его достижения может меняться в зависимости от сложившихся условий. Традиционный инвестиционный проект же больше похож на движение электропоезда по проложенному пути. Запуск поезда требует длительной подготовки: пути, электросеть и т. д.
Обозначим основные отличительные черты 1Т-проектов, вытекающие из их специфики:
• неопределенность финального результата;
• преобладающая доля стоимости человеческих ресурсов в структуре себестоимости продукта;
• высокая динамика изменений внешней среды;
• команда, работающая над проектом, продолжает свою работу над продуктом после сдачи в формате поддержки и доработки продукта;
• возможен поэтапный (модульный) запуск.
Рассмотрим каждую из особенностей отдельно.
Неопределенность финального результата
В отличие от проекта строительства здания, где финальный результат проекта и требования к нему становятся понятными на этапе проектирования - все
дальнейшие шаги лишь позволяют реализовать планируемый результат, в 1Т проектах требования могут сводиться к приблизительному набору требуемых функций программного продукта. Интерфейс программы и итоговый функционал может меняться по ходу проекта в зависимости от сложившихся условий (появление новых технологий, появление новых конкурентов, запросы будущих потребителей и т. д.).
Важнейший критерий - это содержание проекта. Мы отметили, что 1Т проект имеет неопределенное, «Гибкое» содержание, трансформирующееся по ходу работ. Однако подобный подход не всегда применим. Например, возведение такой сложной инженерной конструкции, как атомная электростанция, - проект со строжайшим регламентированием до мельчайших деталей. Содержание такого проекта жестко ограничено по технологическим требованиям и требованиям безопасности. Строительство ни на шаг не может отклоняться от имеющегося плана, а изменения могут вноситься лишь на этапе инициации проекта.
Рассмотрим другой пример - запуск крупного интернет-магазина розничной торговли, предпринятый федеральной сетью магазинов одежды. Здесь инициатор проекта может поставить задачу: создать интернет-площадку для торговли и обеспечить логистическую сеть для доставки по всей стране. Конкретные же шаги: платформа интернет-магазина, его продвижение, города для размещения логистических центров и создание курьерской сети - это «гибкие» пункты проекта - они могут изменяться в зависимости от множества внешних факторов.
Таким образом, все проекты можно сгруппировать по степени «гибкости» содержания - насколько оно может видоизмениться по ходу работы в зависимости от влияния внешних факторов. С одного полюса будут 1Т-проекты - наиболее гибкие; другая полярность - сложные высокорегламентируемые инженерные сооружения. Между ними можно разместить различные проекты в зависимости от гибкости их содержания.
Под гибкостью содержания можно понимать толерантность проекта к внесению изменений. Насколько изменения технически возможны и какова будет их стоимость. 1Т-проекты, где стоимость работ складывается в основном из стоимости работы специалистов, изменения вносятся лишь увеличивая количество трудовых часов. В строениях и сооружениях же изменения по ходу зачастую вовсе невозможны и требуют полного демонтажа конструкции и возведения ее вновь.
Между описанными полярностями можно поместить различные проекты, связанные с запуском нового бизнеса или нового продукта, проекты организационных преобразований. Инновационные проекты даже в самых консервативных сферах также могут относиться к группе с «гибким» содержанием - ведь результат работы над инновационными продуктами никогда не известен заранее.
Преобладающая доля стоимости человеческих ресурсов в структуре себестоимости продукта.
В традиционном инвестиционном проекте преобладающую долю затрат обычно составляют расходы на материалы, строительство, оборудование и другие материальные ресурсы. В 1Т-проектах же стоимость складывается в первую очередь из стоимости труда программистов и других участников команды. Остальные затраты: рабочие места, компьютеры и программное обеспечение - составляют меньшую долю в структуре затрат.
высокая динамика изменений внешней среды
1Т - наиболее динамично развивающаяся сфера. Опоздание с продуктом на несколько месяцев может стать фатальным. Жизненный цикл продуктов чрезвычайно короток, а для поддержания жизнеспособности продукта, требуются постоянные совершенствования и дополнения (обновления программы, новые версии продукта, новые функции в старых продуктах или же совершенно новые версии продуктов).
команда, работающая над проектом, продолжает свою работу
над продуктом после сдачи в формате поддержки и доработки продукта
Потребность в постоянной поддержке и доработке продукта после его «сдачи» требует участия команды программистов на этапе эксплуатации результатов проекта. Привлечение новой другой команды нецелесообразно, так как затраты на «погружение» в уже готовый программный продукт будут чрезвычайно высоки. Иногда участие команды сводится к устранению мелких проблем, возникших при эксплуатации; в других случаях - команда работает на полную мощность, продолжая развивать текущий программный продукт.
возможен поэтапный (модульный) запуск и ранний выход на рынок
Программное обеспечение электронной книги, в первую очередь, должно позволять воспроизводить файлы электронных книг. Функция подключения к онлайн-ката-логу, доступ к офисным программам и калькулятор можно добавить позднее, когда основной функционал будет опробован пользователями и протестирован. Работа над программным обеспечением позволяет привносить пользователю новый функционал «по облаку», посредством обновлений. Однако стоит отметить, что подобные доработки так или иначе ограничены техническими характеристиками устройства: невозможно «научить» смартфон работать в диапазоне спутниковой связи, если в нем не установлен соответствующий модуль передачи данных.
высокий уровень вовлеченности и влияния стейкхолдеров
В зависимости от специфики проекта может варьироваться количество заинтересованных сторон, их степень влияния на проект, а также уровень пересечения и конфликтов интересов.
Методика Agile подразумевает обособленную роль: владелец продукта - человек, который в итоге будет эксплуатировать готовый продукт. Ему команда проекта представляет тот или иной продукт по итогу спринта и получает обратную связь. Однако помимо владельца продукта существует множество других потенциальных заинтересованных сторон: непосредственные потребители, поставщики, держатели акций, государственные органы, местный социум и так далее. Чем сложнее и запутаннее взаимосвязь интересов стейкхолдеров, тем сложнее будет организовать демонстрацию продукта проекта в ходе работ и получить обратную связь.
Владелец продукта - роль, которая должна интегрировать в себе все интересы стейкхолдеров, чтобы достичь гармонии их интересов. Требуется постоянная актуализация их позиций по вопросу проекта и проведение дополнительных предварительных демонстраций продукта ключевым стейкхолдерам с определенной регулярностью.
В гибких IT-проектах мнение стейхолдеров обычно является очень важным и предпринимается максимум усилий для внесения изменения в продукт, если того требует их воля. Таким образом, уровень влияния заинтересованных сторон в гибких проектах очень высок.
Традиционные же индустриальные проекты ввиду своей специфики и сложности могут работать либо на узкую группу стейкхолдеров, чьи ожидания понятны, либо на широкую группу, не оказывающую на проект большого влияния. Например, строители микрорайона могут не принимать во внимание интересы будущих жильцов, ориентируясь лишь на технологические и законодательные требования возведения многоэтажных зданий и на полученное от заказчика задание.
Основными отличительными чертами IT-проектов, таким образом, можно назвать нацеленность на изменения с целью максимального удовлетворения продуктом запросов рынка и стейкхолдеров. Нельзя сказать, что в современном проектном менеджменте в любых, даже самых консервативных сферах, нет потребности к способности быстро реагировать на изменения и удовлетворять интересы заинтересованных сторон.
«Гибким» к изменениям, например, необходимо быть при внедрении инноваций, перестроении системы управления, управленческих и маркетинговых изменениях. Данные сферы отличаются большой неопределенностью в сравнении с отработанными производственными процессами, где основная последовательность действий определена.
Трансформация подходов к управлению проектами
Появление Agile в методологии проектного управление стало чрезвычайно знаковым событием. Какие-то компании перешли в Agile и достигли результатов, другие продолжали работать в традиционной системе проектного менеджмента. Концепции сосуществовали, и даже в популярнейшем стандарте проектного менеджмента PMBOK редакции 2013 года [5] Agile упоминался лишь вскользь. Но в данный момент
ситуация меняется, и специалисты говорят [2, 6] (Tanaka, 0; Soolyatte, 0) о концепции гибридного проектного управления 4.0. Проследим основные этапы изменения парадигмы проектного мышления.
С момента своего зарождения проектный менеджмент базировался на классической парадигме управления тремя категориями проекта: стоимостью, сроками и содержанием. В данную концепцию отлично вписывались традиционные проекты с жестко определенным технологически порядком действий и каскадной методологией разработки. Четко структурированные и стандартизированные подходы к управлению проектами обеспечивали устойчивую конструкцию для проектов, реализуемых в условиях достаточно высокой определенности с горизонтами планирования от 1 года до 20-25 лет. Однако в конце 1990-х годов этот подход начал давать сбои. Последующие кризисы в экономике усугубили этот процесс.
Проектный менеджмент требовал изменений: возросший фактор неопределенности и нестабильности окружающей среды совпал со структурными изменениями в экономике. Было невозможно решить проблему негибкости проектного управления совершенствованием имеющейся методологии, базирующейся на устаревшей парадигме, требовался кардинально другой подход.
Ответом на данный запрос стала японская парадигма проектного управления уровня 2, описанная в стандарте P2M [7] в начале 2000-ых. Основными факторами для инновационных проектов стали «Сложность - Ценность - Сопротивление» (Complexity, Value and Resistance). Чем сложнее бизнес-проблема, тем большую ценность имеет ее решение и тем меньшее число людей способны это понять и не оказывать сопротивления внедрению предлагаемой инновации.
В саму же парадигму была внедрена ориентация проекта на миссию компании как предпосылку для создания проекта. Целью же любого проекта стало создание ценности: интегральный показатель приобретенных материальных ресурсов, новых знаний, технологий, авторских прав и так далее. Важнейшим понятием в данной парадигме проектного управления стало понятие ценности. Ценность проекта - это гармонизация интересов стейкхолдеров.
Этот подход был нацелен на инновационные проекты, позволяя выстраивать компаниям отделы новых разработок, проводить НИОКР, работать над развитием новых технологий.
Примерно в то же время зародился и так называемый проектный менеджмент 3 уровня. В феврале 2001 года 17 независимыми практиками в области разработки программного обеспечения, входящих в Agile Alliance, был разработан и принят Agile Manifesto - манифест гибкого управления проектами.
Основными категориями в этой новой парадигме управления проектами являются: «Скорость — Ценность — Эффективность». Теперь важны не сроки проекта сами по себе, а скорость с которой будут создаваться и предоставляться для опробования заказчику ценные результаты - сначала «минимально жизнеспособный продукт»
(minimum viable product - MVP), а затем конкурентоспособные версии или отдельные модули этого продукта, доработанные с учетом осмысленных заказчиком требований в ходе тестирования MVP. Продукт в рамках рассматриваемой парадигмы должен быть создан и доработан с минимальными или с оптимальными для заказчика затратами и сприемлемым уровнем риска.
Продукты начали выводиться на рынок быстрее, а проектные команды стали более гибкими к изменениям. Болеы 15 лет методология Agile применяется в IT-отделах множества различных сфер: финансовый сектор, телекоммуникация, розничная торговля и даже атомный инжиниринг [8]. Иногда гибкий подход к управлению проектами выходит за рамки IT-отделов и применяется при разработке продуктов и решений в крупных и небольших компаниях, в частном и государственном сдкторе. Связано это в значительной степени с необходимостью более частой, чем еще несколько лет назад, адаптации стратегии, портфелей, программ, крупных проектов под быстро изменяющуюся ситуацию в конкретных отраслях, в национальной и мировой экономике.
Все три концепции и основные категории представлены на рисунке 3. Отметим, что данные концепции продолжают сосуществовать. Они могут применяться на разных уровнях работы над проектами или же использоваться для решения конкретных задач по имеющемуся проекту.
Проектный менеджмент 4.0 - это гибридная модель, где традиционный менеджмент 1 и 2 уровня соседствует с гибкими методами. Философия Agile, цееностное ориентирование наслаивается на прописанные в традиционных стандартах инструменты и методики. В 2017 году опубликована [9] новая редакция стандарта PMBOK,
Ценность
Сроми Содержание Спорость Эффективность
Рисунок;?. Концепции методслогоипроектного менеджмента Источник: [6]
сопровождаемая руководством внедрения гибких методик «Agile practice guide». Двумя годами ранее собственным руководством по Agile обзавелся и британский стандарт PRINCE2 [10].
Предложенные руководства помогают компаниям, работающим по данному стандарту, внедрить те или иные гибкие практики в свою деятельность, не перестраивая систему управления проектами «с нуля».
Создание гибридных моделей управления проектами практикуется проектными командами в различных сферах бизнеса. Анжела Вик, руководитель консалтинговой компании BA-Squared [11], призывает компании отделять средства от цели и подбирать под необходимую задачу определенный наиболее подходящий инструмент. «Не стоит отказываться от инструмента, просто потому, что он часть другой методологии. Будьте открыты к использованию и адаптации методов из других стандартов и методик. Карты историй и пользовательские истории используются в Agile, но могут быть полезны и в каскадных методологиях, а процессное моделирование подойдет для обоих подходов» [11].
Применение гибких методологий на практике возможно даже в строительстве [12]. Комбинирование методологий и переход к гибридной модели, где Спринты превращаются в Еженедельные планы, Пользовательские истории - в Наборы работ, Демонстрации заказчику - в Инспекцию площадки, График выгорания задач - в S-кривую расходования бюджета и времени. Подобный гибридный подход позволяет команде фокусироваться на ценности, следовать изменениям, при этом используя привычные инструменты управления временем, стоимостью и характеристиками проекта.
Директор проектного офиса T-Mobile Лори Бингам говорит [13], что в компании на данный момент реализуется около 500 различных проектов одновременно. Однако проекты, реализуемые в 100% Agile в меньшинстве: лишь порядка 200 команд выбрали данный инструментарий для осуществления проектов. При этом в T-Mobile менеджмент среднего звена обязательно проходит курс по Agile-практикам и имеет свободу применения полученных знаний на практике. Таким образом, большая часть команд применяют гибридную методологию.
Все проекты начинаются с «водопадной» модели: определяется бюджет, сроки и характеристики продукта. Последующая работа может происходить в гибкой форме - команда реагирует на изменения и создает продукт с упором на ценность. Чтобы подобный гибридный подход был возможен, необходимо внедрить Agile в корпоративную культуру, чтобы гибкая философия стала частью духа организации - утверждает Л. Бингам.
критерии выбора методологии управления проектами
Ранее мы определили, что существует 3 основных подхода к организации работы над проектом: традиционный проектный менеджмент, гибкое управление проектами
Рисунок 4. Модель определения «гибкости» проекта Источник: составлено авторами
и гибридная модель. Практический вопрос выбора одного из данных вариантов все еще остается актуальным.
Сформируем критерии и графическую модель на основе данных критериев, позволяющую отнести проект к той или иной форме управления проектами (рис. 4). В правой части модели представлены критерии «гибких» проектов, на основе критериев сформированных нами ранее во 2 части данной статьи. Слева - характеристики наименее гибких проектов, относящихся, например, к инженерным сооружениям с высоким уровнем регламентации и низкой толерантностью к изменениям. Между данными полярностями представлена условная шкала, где позиция справа соответствует совершенно «гибкому» проекту, позиция слева - наименее «гибкому». Все промежуточные состояния относят проект к гибридным моделям, где будет уместно применение комбинации из одних и других методик.
Предложенная модель может послужить основой для составления более прора-
ботанных опросных листов, а в данной работе приводится в качестве демонстрации основных отличий подходов к управлению проектами.
Для интерпретации результатов можно воспользоваться представленными характеристиками в зависимости от расположения параметров по всем критериям:
• больше параметров в левой части: к таким проектам минимально подходят Agile-практики - лучше использовать традиционный проектный инструментарий;
• больше параметров в середине схемы: возможно применение гибридных моделей проектного управления;
• больше параметров в правой части: такие проекты могут управляться стопроцентными Agile-инструментами: Scrum, Kanban, XP и др.
Заключение
1. Традиционная модель управления проектами, основанная на «водопадном» методе планирования, не всегда в полной мере может учесть изменения, происходящие в сфере окружения проекта.
2. Гибкие методы управления Agile зародились и развивались в сфере IT, однако сейчас, в наиболее современной концепции проектного менеджмента 4.0, становятся фактически общепринятыми. Анализ этой методологии свидетельствует, что Agile как инструмент повышения ценности проекта, его конкурентоспособности, скорости выхода на рынок и готовности к изменениям может быть использован не во всех проектах.
3. В практике управления проектами все большую популярность набирают «гибридные» технологии, основанные на удачном использовании плюсов каждого их подходов.
В данной работе предложены критерии, в соответствии с которыми можно определить насколько рассматриваемый проект соответствует критериям «гибких» проектов и насколько в связи с этим будет уместно применение Agile-практик, гибридных моделей, или же стоит управлять проектом в традиционном стиле.
4. Дальнейшее развитие предложенного инструментария возможно на основе анализа существующей практики успешных проектов, где был применен Agile, или какая-то гибридная модель, что позволит уточнить критерии, расширить их и более качественно интерпретировать результаты модели определения «гибкости».
ИСТОЧНИКИ:
1. State of agile 11-ый ежегодный отчет VersionOne. ScrumTrek. [Электронный ресурс].
URL: https://scrumtrek.ru/blog/11-j-ezhegodnyj-otchet-state-of-agile ( дата обращения: 05.05.2018 ).
2. Hiroshi Tanaka Growing Paradigm of Project Management. IPMA 2017 30th world
congress. [Электронный ресурс]. URL: http://csit.lp.edu.ua/presentation/hiroshi%20
tanaka.pdf.
3. Стеллман Э., Грин Д. Постигая Agile. Ценности, принципы, методологии. - М.:
Манн, Иванов и Фербер, 2017.
4. Сазерленд Д. Scrum. Революционный метод управления проектами. - М.: Манн,
Иванов и Фербер, 2016.
5. Руководство к Своду знаний по управлению проектами (Руководство PMBOK) -
Пятое издание. Project Management Institute. [Электронный ресурс]. URL: http://pm-files.com/sites/default/files/file/C/C-1/C-1-1/pmbok_5th_2013_rus.pdf.
6. Сооляттэ А. Изменение парадигмы: Управление проектами 4.0. ООО «ВРМ Консалтинг Групп». [Электронный ресурс]. URL: http://bpm-cg.ru/?page_id=5842.
7. A Guidebook of Project & Program Management for Enterprise Innovation (P2M),
Volume I Revision 3, Project Management Association of Japan (PMAJ), October 2005
8. Материалы конференции «AgileDays 2018». ScrumTrek. [Электронный ресурс].
URL: https://agiledays.ru/wp-content/uploads/sites/3/2018/02/AgileDays2018-Program. pdf.
9. PMBOK® Guide - Sixth Edition. Project Management Institute. [Электронный ресурс].
URL: https://www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition.
10. PRINCE2 Agile™. Axelos. [Электронный ресурс]. URL: https:// axelos.com.
11. Can You Develop Standards That Embrace Both Agile And Traditional Approaches? by Angela Wick. BAtimes. [Электронный ресурс]. URL: https://www.batimes.com/angela-wick/can-you-develop-standards-that-embrace-both-agile-and-traditional-approaches. html.
12. Agile and Lean Applied to Construction by A. Smith. Ennova. [Электронный ресурс]. URL: http://ennova.com.au/blog/2011/09/agile-lean-compared-applied-construction.
13. Agile Ways on "Projectified" by Lauri Bingham. Ps. [Электронный ресурс]. URL: https:// www.pmi.org/learning/training-development/projectified-podcast/agile-journey.
references:
Agile Ways on "Projectified" by Lauri BinghamPs. Retrieved from https://www.pmi.
org/learning/training-development/projectified-podcast/agile-journey Agile and Lean Applied to Construction by A. SmithEnnova. Retrieved from http://
ennova.com.au/blog/2011/09/agile-lean-compared-applied-construction Can You Develop Standards That Embrace Both Agile And Traditional Approaches? by Angela WickBAtimes. Retrieved from https://www.batimes.com/angela-wick/can-you-develop-standards-that-embrace-both-agile-and-traditional-approaches.html Hiroshi Tanaka Growing Paradigm of Project ManagementIPMA 2017 30th world
congress. Retrieved from http://csit.lp.edu.ua/presentation/hiroshi%20tanaka.pdf PMBOK® Guide - Sixth EditionProject Management Institute. Retrieved from https:// www.pmi.org/pmbok-guide-standards/foundational/pmbok/sixth-edition
PRINCE2 Agile™Axelos. Retrieved from https:// axelos.com
Sazerlend D. (2016). Scrum. Revolyutsionnyy metod upravleniya proektami [Scrum. The revolutionary method of project management] M.: Mann, Ivanov i Ferber. (in Russian).
State of agile 11-ый ежегодный отчет VersionOneScrumTrek. Retrieved May 05, 2018, from https://scrumtrek.ru/blog/11-j-ezhegodnyj-otchet-state-of-agile
Stellman E., Grin D. (2017). Postigaya Agile. Tsennosti, printsipy, metodologii [Comprehending Agile. Values, principles, methodologies] M.: Mann, Ivanov i Ferber. (in Russian).
