Размещено на http://www.allbest.ru/

Применение Agile в проектном управлении исполнительных органов государственной власти

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

Agile - это гибкий подход к созданию и управлению проектом или продуктом.

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

Теперь Agile постепенно из программной инженерии переходит в системную инженерию. В России первым крупным первопроходцем по внедрению Agile стал Сбербанк, который на протяжении последнего года активно внедряет Agile в свою деятельность. В первую очередь для IT проектов, связанных с разработкой программного обеспечения. Но уже сейчас становится ясно, что необходима реформация всей организации в комплексе, чтобы возможно было применять Agile во всех проектах [2]. В государственном секторе тоже имеются яркие примеры применения Agile, но только для реализации IT проектов. Это пенсионный фонд города Самары, департамент ЖКХ Тюменской области и Санкт-Петербургский информационно-аналитический центр [3].

Вдохновившись успешным опытом правительств зарубежных стран (Великобритании, Австралии, Норвегии и т.д.) и впечатляющими мероприятиями Сбербанка, первые лица государства всерьёз задумались о необходимости применения Agile в проектной деятельности исполнительных органов государственной власти (далее ИОГВ) и указали на необходимость постепенного его внедрения [4][5]. И здесь возникла довольно большая проблема. А как собственно Agile в проектном управлении ИОГВ применить? Ведь орган власти это высокоформальное и рутинное подразделение государственного аппарата, а в данный момент нормативно-правовые акты, на которые ИОГВ опираются в своей деятельности не предполагают использование Agile, который наоборот стремится к минимизации документов и творчеству, с целью ускорения процессов. Само собой, отсутствует и методология, по внедрению и использованию гибких технологий в органах власти. Поэтому ИОГВ сейчас находятся в некотором затруднении, когда не то что методологии, но и какого-либо ГОСТа по применению гибких технологий в органах власти не существует. Отсюда вытекает и цель данной статьи - необходимо определить где и как возможно применить Agile в проектном управлении ИОГВ, ведь адаптация нормативно-правовой базы произойдёт ещё нескоро, а применять Agile руководители ИОГВ хотят уже сейчас, особенно в регионах, где системы проектного управления уже внедрены.

Говоря о гибких технологиях довольно сложно пока понять где и как, для каких объектов и продуктов они могут подойти. Прежде всего стоит уточнить, что Agile - это не новая технология проектного управления, как многие заблуждаются, а новая технология организации работы внутри проекта. К сожалению, очень часто приходится видеть и слышать, как противопоставляют друг другу два подхода. Подход «Waterfall» (т.е. «Водопад» - классические последовательные этапы реализации проекта) и подход «Agile» (итеративные этапы: Scrum и т.д.). Но если взять, например, американский стандарт PMbok - он говорит, что основной (обобщённый) жизненный цикл он всё равно водопад и нужно действовать неким образом последовательно. И только в комментариях к последней версии PMbok появилось, что фазы все-таки могут друг на друга наложиться, а некоторые из фаз могут даже выполняться итерационно. Но нет ухода от водопадной технологии до конца.

Что мы и видим в проектном управлении, яркий пример классического Waterfall: есть четыре последовательных, чётко разграниченных этапа (инициация, планирование, реализация, завершение).

Рассмотрим пример из практики по жизненным циклам проекта крупного медицинского дистрибьютера (рисунок 1).

Рисунок 1. Жизненные циклы различных объектов в проекте

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

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

– он не «жизненный», потому что он когда-то закончится и продукт (проект, продажа)

«умрёт»;

– он не цикл - потому что чаще всего следующий проект будет реально другой.

А вот когда мы рассматриваем методологию Agile, то можно увидеть цикл, изображённый на рисунке 2.

Рисунок 2. Agile в проектном управлении

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

Например, Павел Шестопалов - один из ведущих специалистов в проектом управлении, в том числе в ИОГВ, на всех классических курсах по управлению проектами всегда говорит: «Коллеги, если хотите проверить, вот то что вы делаете это проект или не проект, спросите себя «А когда закончится?» и если вы сможете дать ответ на этот вопрос, значит это верный признак того, что это проект».

Но как мы видим по рисунку 2, в Agile нет окончания. Здесь всё крутится внутри и сложно назвать это жизненным циклом проекта. Это скорее всего схема какого-то процесса. А если это процесс, то заглядывая в стандарт PMbok можно увидеть, что действительно при реализации проекта руководитель организует исполнение не просто процесса, а даже нескольких групп процессов и эти группы процессов распределены по так называемым областям знаний или функциональным областям. В таком случае встает вопрос, а где эти гибкие технологии имеют место быть, какие области знаний они покрывают? Тогда, если мы хотим какое-то действо назвать проектом, то у него должно быть начало и должно быть окончание. Окончание может быть выражено конкретным сроком, а может быть выражено достижением конкретного результата. Да есть такие проекты, у которых срок не так жёстко определен. Но тем не менее у всех проектов должна быть та точка, на которой мы говорим: «Так, стоп, хватит. Мы достигли того, о чём говорили на старте».

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

Вот мы и подошли к тому моменту, где следует сделать оговорку, что на данный момент существует 2 лагеря сторонников Agile:

– Agile может заменять Waterfall;

– Agile не может заменять Waterfall, но их можно скомбинировать в некоторых местах.

Итак, применительно к ИОГВ, принимаем сторону второго лагеря. Будем исходить из простого правила, как уже было сказано выше, «у проекта должно быть своё начало и своё окончание».

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

Рисунок 3. Варианты интеграции Agile в проектное управление ИОГВ

Многие наверно покритикуют первый вариант, скажут: «Ну как же так, проектная заявка - это что-то такое важное, разовое, то с чего мы начинаем. Как можно многоразово её менять».

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

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

Чтобы разумно, грамотно и сбалансированно совместить Agile с проектным управлением, необходимо рассмотреть функциональные области и стандарты по управлению проектами, которые во всём мире содержат матрицу, изображённую на рисунке 4. Где по вертикали группы процессов, а по горизонтали, то чем управляет руководитель проекта [6].

Рисунок 4 - Возможности применения Agile в процессах проектного управления

Итак, рассмотрим где же в этой матрице Agile целесообразен.

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

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

– мониторинг и контроль рисков. Так как мы делаем маленькие шаги, то рисками проще управлять;

– работа с командой и развитие команды проекта. Потому что команды выполняют итерационные этапы;

– управление стейкхолдерами (конечными пользователями) и распространение информации управления ожиданиями;

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

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

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

Если перенести все процессы проектного управления, к которым применим Agile, на жизненный цикл проекта, то можно заметить, что в основном они охватывают этап планирования и этап реализации. К тому же извлечение уроков происходит постепенно на стадиях планирования и реализации. Таким образом, для внедрения в проектное управление ИОГВ подойдёт второй вариант интеграции - на стадии планирования и реализации (рисунок 3).

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

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

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

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

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

Можно предложить следующую методологию трансформации органа власти:

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

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

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

– обучение персонала;

– доведение IT структуры до нужного уровня (адаптация). Т.е. преобразования инфраструктурные;

– определение пилотных проектов;

– подтверждение правильности выбора. Для высшего руководства, на основании замеров и метрик, продемонстрировать целесообразность и эффективность Agile подхода; - тираж на все проекты, где есть возможность применения Agile.

Заключительный пункт звучит так не случайно: «где есть возможность применения Agile». Место Agile в процессах проекта было разобрано выше. Теперь необходимо выяснить область применения Agile в госсекторе по видам проектов. Можно разделить все проекты на 2 блока: IT и не IT. Таким образом получается следующая таблица 1, с разбиением по ценности и необходимости Agile в различных проектах.

управление проект исполнительный власть

Таблица 1. Возможность применения Agile в различных проектах

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

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

Подводя итог под всем вышесказанным можно сделать несколько заключительных выводов о применении Agile в проектном управлении ИОГВ:

– неправильно противопоставлять классические подходы проектного управления (Waterfall) и гибкие технологии (Agile);

– Agile может быть органично встроен в какую-то схему, но всё-таки в основную схему жизненного цикла проекта;

– так как Agile не покрывает все функциональные области управления проектами, он не может быть самостоятельной технологией реализации проекта;

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

– Agile позволит экономить бюджетные средства и время, обеспечить готовность участников проекта к любым изменениям, а также снизить риски;

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

– отсутствует методология по внедрению и использованию Agile в органах власти. Это не отменяет возможность использования Agile, примеры в РФ имеются. Но все они так или иначе связаны с IT-сферой. Широкое распространение, а особенно в не IT проектах, без официальной методологии невозможно.

Список литературы

1.Agile-манифест // официальный сайт [Электронный ресурс]. - Режим доступа: http://agilemanifesto.org/iso/ru/manifesto.html (дата обращения: 23.06.2017).

2.Сбербанк РФ (Agile трансформация) // TAdvister - портал выбора технологий и поставщиков. Электронный ресурс].

3.Гибкие подходы в государственном секторе РФ // официальный сайт конкурса «Проектный олимп» [Электронный ресурс]. - Режим доступа: http://pmolimp.ru/files/content/1218/3-dubrovin-i-spervye-rezultaty-primeneniya-gibkih-podhodov-v-gosudarstvennom-sektore-pdf.pdf (дата обращения:

23.06.2017).

4.Как Agile используют в правительстве Норвегии, Новой Зеландии и США // Блог издательства «МИФ». [Электронный ресурс]. - Режим доступа: http://blog.mann-ivanov-

ferber.ru/2016/05/24/kak-agile-ispolzuyut-v-pravitelstve-norvegii-novoj-zelandii-i-ssha-ili-o-vazhnostiizmenenij/ (дата обращения: 23.06.2017).

5.Выступление Д.А. Медведева на пленарном заседании российского инвестиционного форума «Сочи-2017» // Сайт правительства РФ [Электронный ресурс]. - Режим доступа: http://government.ru/news/26566/ (дата обращения: 23.06.2017).

6.Руководство к Своду знаний по управлению проектами. - 5-е изд. - Newtown Squere, Pennsylvania: PMI inc, 2013. - 586 с.

Размещено на Allbest.ru