Проблемы и решения ГосAgile в РФ

Б.1 ОБЗОР ОГРАНИЧЕНИЙ ГОСAGILE В РФ

Гибкая разработка продуктов и управление проектами с применением гибких подходов в ряде случаев могут вступать в противоречие с устоявшимися нормами и подходами, закрепленными в нормативно-правовых актах (НПА), особенно в части, относящейся к изменению сроков, стоимости и состава проекта (продукта). Это связано с тем, что в НПА уже закреплены подходы и практики, характерные для классических подходов к управлению и устаревающие с каждым днем. В тех государствах, где бизнес давно использует гибкие подходы и они показывают высокую эффективность, была внедрена практика гибкого управления проектами и в государственном секторе. Соответственно, законодательство этих стран постепенно адаптируется к специфике гибких подходов, как мы видим на примере Великобритании, США и Австралии (см. А.1 Великобритания; А.2 США; А.3 Австралия)

Время чтения: 1 мин.

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

Время чтения: 1 мин.

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

Законодательные ограничения применения гибких подходов и возможные пути решения сводятся к тому, что они связаны:

с процессом разработки продуктов (систем);
с закупками и, соответственно, с бюджетированием и контрактованием гибкой разработки.

Б.2 ЗАКОНОДАТЕЛЬНЫЕ ОГРАНИЧЕНИЯ

Авторы раздела:

Бутвина Н. Л., Потапова Е. Г.

Ограничения, связанные с процессом разработки продуктов (систем), в основном продиктованы стандартами серий ГОСТ 34 и ГОСТ 19. В данном разделе представлен список этих документов и приведены основные ограничения.

Время чтения: 5 мин.

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

Время чтения: 5 мин.

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

Таблица 8. НПА и стандарты по разработке цифровых продуктов

1. Постановление Правительства Р Ф от 06.07.2015 № 676 (ред. от 11.04.2019) «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» // КонсультантПлюс. URL:http://www.consultant.ru/document/cons_doc_LAW182….

2. Постановление Госстандарта СССР от 28.12.1988 № 4622 «РД-50−680−88. Методические указания. Автоматизированные системы. Основные положения» // КонсультантПлюс.
URL: http://www.consultant.ru/cons/cgi/online.cgi?req=d….

3. [Письмо Федерального агентства по техническому регулированию и метрологии от 08.05.2019 № 8262-ИК-03] // Normacs.
URL: https://www.normacs.info/uploads/ckeditor/attachments/4267/Росстандарт_8262.pdf; Приказ Росстандарта от 12.02.2019 № 216 «О признании недействующими на территории Российской Федерации актов, изданных государственными органами, правопреемником которых является Федеральное агентство по техническому регулированию и метрологии» // КонсультантПлюс.
URL: http://www.consultant.ru/cons/cgi/online.cgi?rnd=6….

4. Постановление Госстандарта СССР от 27.12.1990 № 3380 «РД 50−34.698−90. Методические указания. Информационная технология. Автоматизированные системы. Требования к содержанию документов» // КонсультантПлюс. URL: http://www.consultant.ru/cons/cgi/online.

5. Постановление Госстандарта СССР от 29.12.1990 № 3508 «Р 50−34.119−90. Рекомендации. Информационная технология. Комплекс стандартов на автоматизированные системы. Архитектура локальных вычислительных сетей в системах промышленной автоматизации. Общие положения» // КонсультантПлюс. URL:
http://www.consultant.ru/cons/cgi/online.cgi?req=doc&base=OTN&n=838#3 107 441 671 779 021.

Формально все эти НПА скорее поддерживают водопадную разработку, стандарты серии ГОСТ 34 не противоречат гибкой разработке полностью, но и не обеспечивают разработчикам удобную среду для ее реализации. Среди лучших практик ГосAgile в РФ есть многочисленные примеры эффективной работы в рамках ограничений, задаваемых этим стандартом. Все эти практики предполагают использование стандартов серии ГОСТ 34 (и ТЗ по ГОСТ 34 в частности) как рамочных стандартов и документов, которые определяют требования к системе (продукту) в целом, на самом общем уровне, в то время как на уровне отдельных блоков позволяется гибкая разработка, изменение и адаптация требований и т. д.

Б.3 ГИБКАЯ РАЗРАБОТКА ПО ГОСТ

Авторы раздела:

Смирнов С. В.

Весь комплект стандартов серии ГОСТ 34 сам по себе достаточно универсален, он описывает набор стадий, которые должен пройти проект, и документы, которые должны быть сформированы на определенных стадиях. ГОСТ 34 традиционно считается одним из главных препятствий на пути применения Agile, но с некоторыми оговорками он совместим с гибкой разработкой. Ниже приведены рекомендации, как совместить гибкую разработку с ГОСТ 34 152.

Время чтения: 6 мин.

Сложности, возникающие при сочетании работы по ГОСТ 34 и по Agile, во многом связаны не с содержанием, а с некорректной трактовкой ГОСТ 34 и ГОСТ 19 заказчиком и/или исполнителем при формировании государственных контрактов. Основные мифы о несовместимости ГОСТ 34 и гибкой разработки приведены в таблице 9.

Время чтения: 6 мин.

Сложности, возникающие при сочетании работы по ГОСТ 34 и по Agile, во многом связаны не с содержанием, а с некорректной трактовкой ГОСТ 34 и ГОСТ 19 заказчиком и/или исполнителем при формировании государственных контрактов. Основные мифы о несовместимости ГОСТ 34 и гибкой разработки приведены в таблице 9.

Таблица 9. Мифы о несовместимости ГОСТ 34 и гибкой разработки

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

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

На протяжении нескольких последних лет в отделе разработки СанктПетербургского аналитического центра успешно применяются гибкие подходы при исполнении государственных контрактов. Руководитель отдела Сергей Смирнов дает рекомендации в отношении формирования требований и создания календарного плана, применение к которым ГОСТ 34 и 19 вызывает максимальное количество споров.

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

На этапе выполнения работ согласно ГОСТ вы можете разрабатывать дополнение к ТЗ на каждом этапе и уточнять эти требования. Также в ГОСТ разрешается сформировать ТЗ не на всю систему в целом, а на отдельные ее части, согласно указаниям ГОСТ 34, приведенным ниже.

ГОСТ 34.602−89 «Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы» Пункт 1.2. «…Могут быть разработаны ТЗ на части АС; на подсистемы АС, комплексы задач АС и т. п. …» Пункт 1.7. «…Изменения к ТЗ на АС оформляют дополнением или подписанным заказчиком и разработчиком протоколом…»

В таком случае требования будут составлены согласно примеру:

Пример требований, сформулированных для государственного контракта
1. Развитие подсистемы «Подсистема 1» в части создания новых КЗ «Комплекс задач 1», «Комплекс задач 2», развития существующих КЗ «Комплекс задач 3», «Комплекс задач 4».
1.1. Создание К З «Комплекс задач 1»: «…высокоуровневые требования…». 1.4. Развитие К З «Комплекс задач 3»: «…высокоуровневые требования…».
2. Развитие подсистемы «Подсистема 2» в части…
3. Развитие подсистемы «Подсистема 3» в части.

При формировании календарного плана работ рекомендуется соотнести его с этапами выполнения работ, где каждый этап, который включает в себя все стадии из ГОСТ 34, — это реализация определенного законченного функционала. Тогда будет возможность уточнять требования на каждом этапе и в конце этапа вводить этот функционал в действие. Вполне возможно, что потребуется обосновать необходимость ввода поэтапного календарного плана для заказчика, поэтому во врезке ниже приведены соответствующие рекомендации ГОСТ 34. Соответственно, на этапе исполнения работ даже требования календарного плана можно некоторым образом изменять, так как в ГОСТ 34 разрешаются дополнения к ТЗ.

ГОСТ 34.601−90 «Автоматизированные системы. Стадии создания» Пункт 2.2. «Стадии этапы, выполняемые организациями — участниками работ по созданию АС, устанавливаются в договорах и техническом задании на основе настоящего стандарта… В зависимости от специфики создаваемых АС и условий их создания допускается выполнять отдельные этапы работ до завершения предшествующих стадий, параллельное во времени выполнение этапов работ, включение новых этапов работ». ГОСТ 34.603−92 «Виды испытаний автоматизированных систем» Пункт 1.6. «Допускается последовательное проведение испытаний и сдача частей АС в опытную и постоянную эксплуатацию при соблюдении установленной в ТЗ очередности ввода АС в действие».

Из вышеприведенного фрагмента следует, что, согласно ГОСТ 34, допускается выполнять отдельные этапы работ до завершения предшествующей стадии, параллельно, во время выполнения этапов работ, возможно включение в работу новых этапов. При вводе в промышленную эксплуатацию допускается последовательное проведение испытаний и сдача частей АС в опытную и постоянную эксплуатацию при соблюдении установленной в ТЗ очередности ввода АС в действие. Такой подход позволяет обеспечить многократную поставку ценностей потребителю в течение года (или другого периода), собирать быструю обратную связь и, соответственно, достигать целей, поставленных заказчиком.

Б.4 ПРОБЛЕМЫ ЗАКУПОК И БЮДЖЕТИРОВАНИЯ

Авторы раздела:

Бутвина Н. Л., Потапова Е. Г.

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

Время чтения: 4 мин.

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

Время чтения: 4 мин.

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

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

Таблица 10. Ограничения применения гибких методов в основных НПА, регулирующих госзакупки

1. Федеральный закон от 18.07.2011 № 223-ФЗ «О закупках товаров, работ, услуг отдельными видами юридических лиц» // КонсультантПлюс.
URL: http://www.consultant.ru/document/cons_doc_LAW_116 964/

2. Федеральный закон от 05.04.2013 № 44-ФЗ «О контрактной системе в сфере закупок товаров, работ, услуг для обеспечения государственных и муниципальных нужд» // КонсультантПлюс.
URL: http://www.consultant.ru/document/cons_doc_LAW144…

Б.5 КАК «ГОСУСЛУГИ» СПРАВЛЯЮТСЯ С ЗАКУПКАМИ

Авторы раздела:

Матвеев Д. А.

Календарь контракта, гибкость при работе по методу водопада, ранние релизы и особые правила формулирования ТЗ — это секреты команды, работающей над порталом «Госуслуги», у которого посещаемость больше, чем у любого другого государственного портала в мире.

Время чтения: 8 мин.

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

Время чтения: 8 мин.

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

Первое правило — соблюдение календаря контракта. Контракт должен быть годовым. Маленькие контракты сильно увеличивают накладные расходы обеих сторон, как исполнителя, так и заказчика. Стоит разбивать оплату контракта на части. В контрактах, где есть только «аванс» и «расчет в декабре», участники разработки начинают думать не о том, как принять хороший продукт, а о том, как заплатить оставшиеся деньги, освоить выделенный бюджет. Чтобы этого избежать, нужно оплачивать сделанное по ходу исполнения контракта, тогда в конце останется выплатить сумму за последний этап (рисунок 11).

Рисунок 11. Поэтапная оплата в рамках годового контракта: а — аванс и финальная оплата; б — поэтапная оплата

Куда дальше?