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

ВОЗМОЖНОСТИ ПРИМЕНЕНИЯ ГИБКОЙ МЕТОДОЛОГИИ РАЗРАБОТКИ ПРИ ПРОЕКТИРОВАНИИ СЛОЖНЫХ ИНЖЕНЕРНЫХ ОБЪЕКТОВ

Балашов Сергей Вадимович

студент, ФГБОУ ВО Нижегородский государственный технический университет им. Р.Е. Алексеева,

РФ, г. Нижний Новгород

POSSIBILITIES OF APPLICATION OF FLEXIBLE DEVELOPMENT METHODOLOGY IN THE DESIGN OF COMPLEX ENGINEERING FACILITIES

Sergey Balashov

student, Nizhny Novgorod State Technical University n.a. R.E. Alekseev,

Russia, Nizhny Novgorod

АННОТАЦИЯ

В статье рассматривается гибкая методология управления (Agile) при проектировании сложных инженерных объектов, определены преимущества и недостатки методологии и её отличительные особенности от традиционной методики управления проектами в строительстве – каскадной модели. В статье приведён краткий обзор каскадной модели управления проектами в строительстве в целом и возможностей применения гибкой методологии разработки в проектировании сложных инженерных объектов, таких, как атомная электростанция. Рассмотрен опыт применения Agile при проектировании АЭС «Ханхикиви-1» в Финляндии силами специалистами проектного блока Госкоропорации по атомной энергетике «Росатом», перечислены выводы из результатов внедрения гибких методик, произведён анализ достоинств и недостатков интеграции методологии Agile и отдельного инструмента Scrum. С целью получения пользы для компании дано предложение по реализации инструмента взаимодействия с заказчиком, который применяется в современных компаниях вне строительной отрасли и может быть применён в области проектирования сложных инженерных объектов.

ABSTRACT

The article discusses the flexible management methodology (Agile) in the design of complex engineering objects, identifies the advantages and disadvantages of the methodology and its distinctive features from the traditional method of project management in construction - the cascade model. The article provides a brief overview of the waterfall project management model in construction in general and the possibilities of using agile development methodology in the design of complex engineering facilities, such as a nuclear power plant. Application experience considered Agile in the design of the Hanhikivi-1 NPP in Finland by the specialists of the design unit of the State Nuclear Energy Corporation Rosatom, conclusions from the results of the introduction of flexible methods are listed, an analysis of the advantages and disadvantages of integrating the Agile methodology and a separate Scrum tool is made. In order to benefit the company, a proposal was made to implement a tool for interacting with the customer, which is used in modern companies outside the construction industry and can be applied in the design of complex engineering objects.

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

Keywords: nuclear power, flexible project management, Agile, flexible building design management, cascade management model, building design

1 Каскадная модель

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

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

Рисунок 1. Каскадный метод в проектировании

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

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

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

Рисунок 2. Степень полноты информации о проекте в зависимости от этапа при планировании методом набегающей волны

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

2 SCRUM-фреймворк

В настоящее время меняются не только внешняя и внутренняя среды организации как на макро-, так и на отраслевом уровне, но и системы управления, формы организации рабочих мест, форматы работ, люди, их ожидания от работы, представления о продукте, качестве и форме взаимодействия, дополнительных сервисах и предпочтениях заказчиков. Эти изменения нашли прямое отражение в «Манифесте гибкой разработки программного обеспечения» [1], акцент в котором делается на человеческом капитале, продукте, потребности заказчика и взаимодействии с ним, готовности к изменениям.

Несмотря на то что изначально agile-подход был ориентирован на разработку программного обеспечения, впоследствии его ценности и принципы были распространены и на другие отрасли. Параллельно agile появился Scrum-фреймворк, который в общем поддерживает ценности и принципы «Манифеста» и в XXI веке стал активно использоваться в различных бизнес-отраслях, в том числе в производственной сфере. Более того, информационные технологии, для которых изначально разрабатывались все гибкие методики, имеют очевидные параллели с современным строительным CAD- и BIM-проектированием, и им в меньшей степени присущи те барьеры, которые препятствуют внедрению гибких и гибридных методик в строительной отрасли вообще [2].

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

Работа над проектом в Scrum выполняется в виде коротких спринтов — итераций, результатом которых является некий готовый продукт. Любой спринт начинается с разработки требований к нему, основанных на более общих требованиях к продукту проекта (Product Backlog). Определением требований к продукту занимается владелец продукта (Product Owner, в проектировании это обычно главный инженер или главный архитектор проекта), планирование спринта осуществляет команда при участии владельца проекта и Scrum-мастера. Руководство Scrum [3] определяет, что состав рабочей команды должен быть в пределах от трех до девяти человек.

После того как требования к спринту (Sprint Backlog) и его цель (Sprint Goal) определены, начинается выполнение — ключевой процесс в Scrum, который может длиться не более календарного месяца, в результате которого создается промежуточный или конечный продукт проекта. Во время выполнения спринта команда собирается на ежедневные короткие совещания-планерки (Daily Scrum / Daily Standup), где рассматривается, что было сделано вчера и что предстоит сделать сегодня, какие препятствия существуют на пути к достижению цели спринта. Основной смысл этих совещаний — понимание того, насколько команда продвинулась по пути к достижению цели спринта.

Полученный после выполнения спринта результат обсуждается на обзоре спринта (Sprint Review). Здесь особую роль играет оценка того, что было сделано и как это отвечает четким критериям готовности (Definition of Done — DoD). При необходимости на данном этапе могут быть изменены требования к продукту проекта. По результатам обзора спринта инкрементный результат (Increment) может быть передан заказчику либо отправлен на доработку. Под инкрементным результатом подразумевается результат работы, который полностью соответствует заявленным требованиям в Sprint Backlog и уже может быть использован по назначению заказчиком проекта, который на основании полученных результатов может вносить новые требования к продукту или исключать старые требования на следующих спринтах в зависимости от требуемых результатов в долгосрочной перспективе.

Ретроспективное совещание (Sprint Retrospective) позволяет оценить результативность спринта, эффективность работы команды и отдельных ее членов, рациональность использованных процессов и инструментов, рассмотреть возможные механизмы улучшения работы. На рисунке 4 показаны обсуждавшиеся выше процессы Scrum и их взаимосвязь.

Рисунок 2. Фреймворк Scrum

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

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

1) команда работает короткими этапами, на каждом из которых определяет цели и пути их достижения, что ускоряет процесс работы;

2) команда работает над разными задачами проекта одновременно, что позволяет быстрее достичь желаемой цели;

3) большие задачи разделяют на мелкие, поэтому внести корректировки прямо в процессе работы намного проще, чем в каскадном подходе;

4) сокращается время на поиск ошибок и объяснение проблем;

5) минимизация финансовых рисков благодаря оперативной реакции на изменения и устранение ошибок;

6) каждый член команды четко знает свою задачу, следовательно, повышается уровень ответственности к работе;

7) присутствует открытый обмен информацией, что делает процесс работы максимально прозрачным;

8) поддержание высокого уровня мотивации в команде благодаря ежедневной видимости достижений.

Недостатки:

1. успех проекта во многом зависит от Scrum-мастера (организатор процесса), квалификации команды и их приверженности своему делу;
2. далеко не всегда можно адаптировать метод Scrum под сферу деятельности, поскольку есть проекты, требующие исключительно планового подхода в работе;
3. требует регулярной коммуникации с заказчиком, что порой тормозит процесс из-за невозможности получения обратной связи;
4. сложность внедрения в масштабных и сложных проектах, так как больше подходит для малых и средних.

3 SWOT-анализ внедрения гибкой методологии разработки атомных станций

Таблица 1.

SWOT-анализ внедрения гибкой методологии разработки атомных станций

Оценивая результаты SWOT-анализа гибкой методологии разработки атомных станций, описанного выше, можно сделать вывод, что сильные стороны применения методик agile при проектировании сложных инженерных объектов по своему количеству преобладают над слабыми сторонами, однако стоит учитывать угрозы, что мешают внедрению гибкой разработки в условиях крупного строительства. Методология agile не является идеальной и наиболее надёжно зарекомендовала себя лишь в IT-сегменте рынка. При этом вполне очевидны преимущества, которые может принести agile в строительный рынок, в частности, в сферу проектирования атомных электростанций и других сложных инженерных объектов.

4 Опыт применения гибкой методологии в проектировании АЭС

В атомной отрасли России впервые Agile-методология управления проектами была применена в 2016 году при проектировании ядерного острова АЭС «Ханхикиви-1» в Финляндии [4].

Сотрудничество с финским заказчиком требовало учёта всех требований, выдвигаемых к проектированию и строительству АЭС на территории Финляндии. В ходе эскизного проектирования стало понятно, что станция содержит много больше зданий, сооружений и систем, чем другие аналоги за авторством российских специалистов. Разрастание АЭС, а соответственно увеличение его стоимости, стало весомой причиной для руководства ГК Росатом поставить задачу предоставить заказчику предложения по снижению объёма зданий ядерного острова АЭС «Ханхикиви-1» за три месяца. Впервые было решено провести попытку применения гибкой методологии Agile для выполнения задачи.

В комплексе работ по оптимизации были установлены следующие принципы Agile:

− основной фокус на оптимизацию;

− генерация и отработка всех технических идей и вариантов оптимизации, их анализ и приоритезация;

− создание в Scrum команде ролей Администратора (Scrum мастера), представителя заказчика, Технического лидера (Product Owner);

− формирование автономных групп специалистов по 5-ти направлениям оптимизации;

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

− продолжительность спринта – 2 недели;

− быстрое введение и приоритезация необходимых изменений.

В состав 5 рабочих групп по приоритетным направлениям вошли специалисты из Санкт-Петербургского, Московского и Нижегородского проектных институтов, а также АО «Русатом Энерго Интернешнл». Каждая группа имела численность от 4 до 10 человек и работала в течение всей оптимизации в едином помещении. Направления групп определены следующие:

Группа 1 – Нормативы и требования. Специалисты этой группы сравнивали российскую и финскую нормативную документацию и контролировали соответствие принимаемых решений законодательству станы-заказчика;

Группа 2 – Специалисты проектирования архитектурно-строительных решений;

Группа 3 - Специалисты проектирования компоновочных решений территории АЭС, технологи и электрики;

Группа 4 - Специалисты проектирования решений отопления, вентиляции и кондиционирования;

Группа 5 - Специалисты по защите территории АЭС и её объектов от террористических угроз.

В каждой группе были определены роли Администратора (Scrum мастера) и Технического лидера группы (Product Owner).

Таким образом, была создана динамичная и достаточно малочисленная, по сравнению с проектными институтами, структура, применявшая в своей работе гибкие подходы, активно взаимодействующая с Заказчиком и всеми заинтересованными сторонами проекта, оперативно реагирующая на изменения. В результате выполнения комплекса работ по оптимизации точно в срок была достигнута основная цель проекта - объем зданий ядерного острова АЭС «Ханхикиви-1» был снижен на 26%. Было сокращено количество технологических систем и оборудования, оптимизирована компоновка помещений и структура генплана, предложены новые меры по физической защите зданий. При этом указанный результат был достигнут без снижения надёжности и безопасности АЭС.

Таким образом, было показаны широкие возможности применения гибких подходов в рамках оптимизационных работ.

Ключевыми преимуществами использования Agile для проекта оптимизации явились:

1) оперативное решение административных вопросов проекта;

2) совместная работа специалистов высокой экспертной квалификации из различных проектных институтов;

3) возможность непосредственного взаимодействия со всеми заинтересованными сторонами проекта;

4) дисциплинирующая, динамичная структура рабочих процессов (спринты, отчеты, обзоры, инструменты Scrum) [5].

Исходя из опыта применения гибкой методологии разработки на проекте АЭС "Ханхикиви-1" можно выделить следующие рекомендации:

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

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

- во многом продуктивность команды зависит от навыков взаимодействия администратора с командой;

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

− требуется уделять большое внимание предпроектным мероприятиям, в том числе организовать проведение 0-го спринта с написание краткого варианта паспорта проекта;

− необходимо обеспечить 100% вовлечение ключевых специалистов и внедрить эффективный механизм мотивации сотрудников;

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

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

5 Предлагаемый инструмент взаимодействия с заказчиком

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

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

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

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

Выводы

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

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

1. Manifesto for Agile Software Development. – http://agilemanifesto.org. (Дата обращения: 10.04.2022)
2. Owen R.L., Koskela L. (2006). «Agile construction project management». In: 6th International Postgraduate Research Conference in the Built and Human Environment 6/7 April 2006 Delft, Netherlands. Salford: Research Institute for the Built and Human Environment, P. 22-33.
3. Schwaber K., Sutherland J. The Scrum Guide. – https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-US.pdf. (Дата обращения: 10.04.2022)
4. Парамонов Д.В., Фунтов В.Н., Малоземов С.Н., Прусова Ж.В. Agile в проектировании АЭС: эффективнее, дешевле, безопаснее // Доклад с конференции Agile Business Conference 2017. http://www.innov-rosatom.ru/network/vertical/niaep (Дата обращения: 10.05.2022)
5. Парамонов Д.В., Фунтов В.Н., Малоземов С.Н. Гибкое управление в негибкой отрасли // Научные исследования и разработки. Российский журнал управления проектами. – 2017. - № 1(18)/2017. – С. 25-36.