УДК 004.413

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

Купцов Владимир Андреевич – магистрант Балтийского государственного технического университета «Военмех» им. Д.Ф. Устинова

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

Ключевые слова: разработка программного обеспечения, Agile, гибкие методологии разработки, развитие информационных технологий в России, проблемы разработки программного обеспечения.

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

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

Текущие основы деятельности государства в области комплексного развития отрасли информационных технологий были заложены в принятой распоряжением Правительства Российской Федерации от 1 ноября 2013 года № 2036-р «Стратегии развития отрасли информационных технологий в Российской Федерации на 2014 – 2020 года и на перспективу до 2025 года». Целью данной Стратегии является формирование единого системного подхода государства к развитию отрасли информационных технологий, что позволит заложить основы дальнейшей деятельности государства в области её комплексного развития, за счёт взаимодействия её участников [1].

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

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

В соответствии с нормами действующего законодательства поставка готовой и производство новой продукции для государственных нужд, в том числе и программных продуктов, в Российской Федерации осуществляется на основании Федерального закона «О закупках товаров, работ, услуг отдельными видами юридических лиц» от 18.07.2011
№ 223-ФЗ – для государственных компаний и Федерального закона
«О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» от 05.04.2013
№ 44-ФЗ – для государственных учреждений (муниципальных и федеральных).

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

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

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

Основываясь на каскадной методологии процесс разработки обретает характерные черты:

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

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

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

Каскадная методология разработки впервые была предложена и описана в 1970 году в статье Уинстона Уолкера Ройса, американского ученого, на тот момент директора Lockheed Software Technology Center, предлагая линейную модель жизненного цикла программного продукта [3]. В зависимости от сложности разрабатываемого программного продукта или его характера, предлагалось добавление дополнительных промежуточных этапов или напротив – их сокращение, но их количество, как и порядок их выполнения должны определяться на стадии планирования разработки.

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

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

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

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

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

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

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

Кроме того, существует гипотетическая вероятность того, что в следующем, так называемом «подпроекте», исполнитель может не выиграть в конкурсе (закупке), что может породить отсутствие должной мотивации с его стороны. Подобная ситуация может быть решаема путём «превращения» такого исполнителя в единственного поставщика, но это не всегда возможно, а нарушения закона «О защите конкуренции» от 26.07.2006 № 135-ФЗ может привести к заморозке работ и очередной потере времени. Важным также является и то, что соблюдения норм данного закона вправе требовать не только уполномоченные органы, но также и другие потенциальные исполнители, считающие, что их права за «здоровую» конкуренцию были нарушены [5] – в условиях стремительного роста количества заказов на программные продукты со стороны государства также растёт конкуренция среди исполнителей за право стать разработчиком программного продукта.

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

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

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

Ещё в 2017 году была создана подгруппа по Agile при Президиуме Совета при президенте РФ с целью обеспечить повышение эффективности работы органов власти за счёт применения гибких подходов, в первую очередь, в проектах информационных технологий, и это дало свои плоды.

К примеру, Центральный Банк России использовал Agile-подходы в создании Национальной системы платежных карт, что на 50% повысило скорость достижения результатов. Гибкие методологии также применяет Управление ПФР в Кировском и Промышленном районах г. Самары при разработке программных продуктов. Среди преимуществ нового подхода специалисты отметили возможность быстро отследить ошибку и исправить её, постоянную обратную связь от заказчика и быструю поставку [6].

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

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

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

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

  • люди и взаимодействие важнее процессов и инструментов;
  • работающий продукт важнее исчерпывающей документации;
  • сотрудничество с заказчиком важнее согласования условий контракта;
  • готовность к изменениям важнее следования первоначальному плану [7], что не всегда осуществимо.

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

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

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

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

  1. Стратегия развития отрасли информационных технологий в Российской Федерации на 2014 - 2020 годы и на перспективу до 2025 года от 1 ноября 2013 № 2036-р Министерства цифрового развития, связи и массовых коммуникаций Российской Федерации, URL: https://digital.gov.ru/ru/documents/4084/ (дата обращения: 10.07.2023).
  2. Федеральный закон «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» от 05.04.2013 № 44-ФЗ. URL: https://www.consultant.ru/document/cons_doc_
    LAW_144624/?ysclid=lk9u65pimf409912367     (дата обращения: 09.05.20223).
  3. Winston W. Royce Managing the development of large software systems. The Institute of Electrical and Electronics Engineers WESCON, Aug 1970. URL: https://web.archive.org/web/20160318002949/http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf (дата обращения: 26.06.2023).
  4. Александр Морлок. В чем особенности реализации ИТ-проектов в госсекторе. URL: https://www.lanit.ru/press/smi/v-chem-osobennosti-realizatsii-it-proektov-v-gossektore/ (дата обращения: 05.07.2023).
  5. Федеральный закон «О защите конкуренции» от 26.07.2006 № 135-ФЗ. URL: https://www.consultant.ru/document/cons_doc_LAW_61763/?ysclid=lk9
    ucwtzyp104066247     (дата обращения: 05.07.2023).
  6. Agile в управлении государственными проектами URL: https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:Agile_%D0%B2_%D1%83%D0%BF%D1%80%D0%B0%D0%B2%D0%BB%D0%B5%D0%BD%D0%B8%D0%B8_%D0%B3%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B5%D0%BD%D0%BD%D1%8B%D0%BC%D0%B8_%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%D0%BC%D0%B8?ysclid=lk8bvh86ju534519769 (дата обращения: 06.07.2023).
  7. Agile-манифест разработки программного обеспечения. URL: https://agilemanifesto.org/iso/ru/manifesto.html (дата обращения: 01.05.2023).

Интересная статья? Поделись ей с другими: