Версия для печати 3517 Материалы по теме
Вопреки регулированию. Как развивается agile в российском госсекторе

Как можно применять scrum, когда Закон № 44‑ФЗ прямо закрепляет противоположные, «жесткие» методы? Когда agile в российских реалиях имеет смысл, а когда лучше использовать классический подход? Как можно использовать гибкие подходы в законодательном процессе? Об этом мы поговорили с Иваном Сергеевичем ДУБРОВИНЫМ — управляющим партнером и коучем компании ScrumTrek, бывшим заместителем руководителя подгруппы по применению гибких подходов в госсекторе, человеком, который внедрял agile и в бизнесе, и на госслужбе.

О федеральном запросе на agile

— Давайте начнем с подгруппы по применению гибких подходов, где вы занимали руководящую должность. Она была создана в 2017 году при президиуме Совета по стратегическому развитию. После смены правительства произошло реформирование совета, и подгруппа была упразднена. Кто стал ее правопреемником?

— Пока такой структуры нет. Во время реформы совета был взят курс на национальные проекты, и работа некоторых подгрупп оказалась не востребована. Хотя раньше запрос на agile был, и у нас были большие планы. Теперь со стороны федеральной власти нет заказчика по гибким подходам.

— Ситуация может измениться?

— Скорее всего. Это следует из логики, в которой сейчас развивается проектное управление. Если раньше agile считался параллельной веткой, то сейчас он стал частью обязательного инструментария менеджеров по управлению проектами. В том числе в государственном секторе. Так, четвертый пункт британского Digital Service Standard (стандарт содержит набор принципов, по которым разрабатываются государственные информационные продукты) закрепляет agile в качестве основного метода работы.

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

Конечно, следует помнить, что в некоторых сферах agile незаменим, но в других использовать гибкие подходы не имеет смысла.

— Как вы оцениваете: выросла ли популярность agile-методов в государственном секторе в течение последних нескольких лет?

— Да, востребованность гибких методик выросла. В качестве доказательства я могу привести статистику конкурса «Проектный Олимп» (проводит Аналитический центр при Правительстве РФ). Число заявок в номинации по гибким подходам в управлении проектами растет с каждым годом. Всегда есть энтузиасты, которые ищут что-то новое, переживают за эффективность, не хотят быть простыми винтиками и «перекладывателями бумаг».

О нормативных ограничениях

— Верно ли, что в России для государственных проектов законодательно закреплен водопадный подход, несмотря на эффективность agile?

— Да, это верно для проектов, которые требуют привлечь внешнего подрядчика. Даже если мы говорим только про ИТ: любой продукт должен разрабатываться по классическому подходу. Это закреплено ГОСТ34, который регламентирует разработку автоматизированных систем. Фактически мы работаем по государственному стандарту 1991 года.

— Какие еще законодательные нормы препятствуют внедрению гибких подходов в госсектор? Позволяет ли 44‑ФЗ использовать agile?

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

Если подрядчика выбирают на конкурсной основе по 44‑ФЗ, то использовать гибкие подходы очень тяжело. Вся идеология закона о госзакупках и планирование бюджета не предполагают частых корректировок, смены приоритетов и других необходимых в гибких подходах изменений. Наиболее подходящий с точки зрения закона метод — водопадная модель. Тем не менее пробовать можно.

Когда я работал в Департаменте информатизации Тюменской области, стандартная схема для нас не была удобной: нам не нравились годовые «забеги» с одной приемкой работ в конечной точке. Кроме того, федеральный регулятор в сфере связи постоянно поставлял новые идеи, инициативы и проекты. Приоритеты по уже начатым проектам постоянно менялись. Тогда мы научились изобретать своеобразные agile-конфигурации (правда, мы еще не знали таких слов), которые не противоречили требованиям 44‑ФЗ и успешно проходили проверки прокуратуры и Счетной палаты.

Несмотря на этот успешный опыт, он локален и его не получится тиражировать. В целом гибкие подходы при работе по 44‑ФЗ — рискованные.

— Что значит рискованные?

— Я объясню на примере. К нам на Agile Days (профильная конференция. — Прим. ред.) приходит заявка от одного крупного федерального министерства. Классная команда, компетентный подрядчик, интересный проект. Заказчик — в ранге замминистра. Ребята все делают по scrum, организованы спринты, есть работа с пользователями. Установлены правильные продуктовые метрики. Полноценный agile-проект, реализованный через 44‑ФЗ.

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

— Я правильно понимаю, что по факту они работают короткими спринтами, а по бумагам принимают работы один раз в конце года?

— Да, к тому же документы содержат обтекаемые формулировки и абстрактные требования. Когда спросил представителей команды, как они будут отвечать на вопросы из зала, они начали сомневаться и отказались выступать.

— Возможно ли применение гибких подходов при постановке задач через госзадание?

— Я бы назвал это вторым уровнем сложности: проще, чем по 44‑ФЗ, но все равно трудно. Условия госзаданий нужно прописывать достаточно жестко, но есть возможность менять их. Не так просто, как хотелось бы, но механизмы есть. Другое дело, когда проект реализуют сотрудники за зарплату.

— Внутри органа государственной власти?

— Да. Это самый простой сегмент: можно прямо сейчас брать и делать. Например, вы можете собрать команду из служащих пяти государственных департаментов. У них есть понимание, что нужно сделать, но пока не совсем понятно как. Они будут делать несколько гипотез и наконец найдут правильный способ решения задачи. Это очень близко к принципам agile.

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

Поделиться