Как можно применять scrum, когда Закон № 44‑ФЗ прямо закрепляет противоположные, «жесткие» методы? Когда agile в российских реалиях имеет смысл, а когда лучше использовать классический подход? Как можно использовать гибкие подходы в законодательном процессе? Об этом мы поговорили с Иваном Сергеевичем ДУБРОВИНЫМ — управляющим партнером и коучем компании ScrumTrek, бывшим заместителем руководителя подгруппы по применению гибких подходов в госсекторе, человеком, который внедрял agile и в бизнесе, и на госслужбе.
О федеральном запросе на agile
— Давайте начнем с подгруппы по применению гибких подходов, где вы занимали руководящую должность. Она была создана в 2017 году при президиуме Совета по стратегическому развитию. После смены правительства произошло реформирование совета, и подгруппа была упразднена. Кто стал ее правопреемником?
— Пока такой структуры нет. Во время реформы совета был взят курс на национальные проекты, и работа некоторых подгрупп оказалась не востребована. Хотя раньше запрос на agile был, и у нас были большие планы. Теперь со стороны федеральной власти нет заказчика по гибким подходам.
— Ситуация может измениться?
— Скорее всего. Это следует из логики, в которой сейчас развивается проектное управление. Если раньше agile считался параллельной веткой, то сейчас он стал частью обязательного инструментария менеджеров по управлению проектами. В том числе в государственном секторе. Так, четвертый пункт британского Digital Service Standard (стандарт содержит набор принципов, по которым разрабатываются государственные информационные продукты) закрепляет agile в качестве основного метода работы.
Гибкие подходы доказали свою эффективность: они позволяют запустить проект быстрее и сэкономить бюджет. На протяжении долгого времени в государственных структурах развитых стран, например в США или в Великобритании, можно было использовать как классическую водопадную модель, так и agile. Можно было создать техническое задание, детальное описание проекта и предусмотреть его сдачу через два года. А можно было действовать гибко: короткие циклы, корректировка требований на ходу, регулярные встречи с исполнителем. В результате вторая модель показала лучшие результаты.
Конечно, следует помнить, что в некоторых сферах agile незаменим, но в других использовать гибкие подходы не имеет смысла.
— Как вы оцениваете: выросла ли популярность agile-методов в государственном секторе в течение последних нескольких лет?
— Да, востребованность гибких методик выросла. В качестве доказательства я могу привести статистику конкурса «Проектный Олимп» (проводит Аналитический центр при Правительстве РФ). Число заявок в номинации по гибким подходам в управлении проектами растет с каждым годом. Всегда есть энтузиасты, которые ищут что-то новое, переживают за эффективность, не хотят быть простыми винтиками и «перекладывателями бумаг».
О нормативных ограничениях
— Верно ли, что в России для государственных проектов законодательно закреплен водопадный подход, несмотря на эффективность agile?
— Да, это верно для проектов, которые требуют привлечь внешнего подрядчика. Даже если мы говорим только про ИТ: любой продукт должен разрабатываться по классическому подходу. Это закреплено ГОСТ34, который регламентирует разработку автоматизированных систем. Фактически мы работаем по государственному стандарту 1991 года.
— Какие еще законодательные нормы препятствуют внедрению гибких подходов в госсектор? Позволяет ли 44‑ФЗ использовать agile?
— При современной контрактной системе это трудно. Когда мы разрабатывали Методические рекомендации по применению гибких подходов в государственных проектах, мы увидели, что иногда очень тяжело использовать agile даже несмотря на то, что именно этот подход является подходящим для конкретной ситуации.
Если подрядчика выбирают на конкурсной основе по 44‑ФЗ, то использовать гибкие подходы очень тяжело. Вся идеология закона о госзакупках и планирование бюджета не предполагают частых корректировок, смены приоритетов и других необходимых в гибких подходах изменений. Наиболее подходящий с точки зрения закона метод — водопадная модель. Тем не менее пробовать можно.
Для эффективной работы кросс-функциональной гибкой команды ее нужно собрать в одном месте. В Сбербанке, пионере agile в российском госсекторе, для этого оборудовали 16-этажный agile homeКогда я работал в Департаменте информатизации Тюменской области, стандартная схема для нас не была удобной: нам не нравились годовые «забеги» с одной приемкой работ в конечной точке. Кроме того, федеральный регулятор в сфере связи постоянно поставлял новые идеи, инициативы и проекты. Приоритеты по уже начатым проектам постоянно менялись. Тогда мы научились изобретать своеобразные agile-конфигурации (правда, мы еще не знали таких слов), которые не противоречили требованиям 44‑ФЗ и успешно проходили проверки прокуратуры и Счетной палаты.
Несмотря на этот успешный опыт, он локален и его не получится тиражировать. В целом гибкие подходы при работе по 44‑ФЗ — рискованные.
— Что значит рискованные?
— Я объясню на примере. К нам на Agile Days (профильная конференция. — Прим. ред.) приходит заявка от одного крупного федерального министерства. Классная команда, компетентный подрядчик, интересный проект. Заказчик — в ранге замминистра. Ребята все делают по scrum, организованы спринты, есть работа с пользователями. Установлены правильные продуктовые метрики. Полноценный agile-проект, реализованный через 44‑ФЗ.
В чем проблема? Оказывается, формальная «история» в виде технического задания и фактическое исполнение существуют параллельно и друг друга не дублируют. Это что-то вроде серой схемы: документы не закрепляют те методы, по которым работают по факту. На это пошли не потому, что хотят нарушить закон, а потому, что гибкие подходы, например, предполагают смену приоритетов, а это невозможно предусмотреть в техническом задании.
— Я правильно понимаю, что по факту они работают короткими спринтами, а по бумагам принимают работы один раз в конце года?
— Да, к тому же документы содержат обтекаемые формулировки и абстрактные требования. Когда спросил представителей команды, как они будут отвечать на вопросы из зала, они начали сомневаться и отказались выступать.
— Возможно ли применение гибких подходов при постановке задач через госзадание?
— Я бы назвал это вторым уровнем сложности: проще, чем по 44‑ФЗ, но все равно трудно. Условия госзаданий нужно прописывать достаточно жестко, но есть возможность менять их. Не так просто, как хотелось бы, но механизмы есть. Другое дело, когда проект реализуют сотрудники за зарплату.
— Внутри органа государственной власти?
— Да. Это самый простой сегмент: можно прямо сейчас брать и делать. Например, вы можете собрать команду из служащих пяти государственных департаментов. У них есть понимание, что нужно сделать, но пока не совсем понятно как. Они будут делать несколько гипотез и наконец найдут правильный способ решения задачи. Это очень близко к принципам agile.
В методических рекомендациях, которые мы разработали, мы ограничили применение гибких методов случаями, когда проект реализуют государственные служащие за зарплату, без контрактных отношений с поставщиками.
О специфике гибких подходов в госсекторе
— Вы упомянули методические рекомендации, разработанные подгруппой по гибким подходам. Какова была их судьба?
— Сообщество приняло документ позитивно, но официально он не вышел. Мы не успели пройти все необходимые бюрократические согласования. Тем не менее все, кому нужны руководство и набор лучших практик, активно используют наши методики. Например, финалисты номинации по гибким подходам конкурса «Проектный Олимп» часто отмечают, что использовали методические рекомендации.
— Кроме законодательных ограничений, что можно сказать о специфике применения гибких подходов в госсекторе?
— Мы пришли к выводу, что особой специфики просто нет. Наши методические рекомендации некоторые критиковали за то, что в них как раз не хватает особенностей госсектора. Я бы сказал, что в госуправлении есть ограничения, но не специфика.
Многие крупные корпорации, такие как «Газпром», «Роснефть» или Сбербанк, также имеют много ограничений во внутренних процессах. Принятие решений часто сосредоточено наверху, и задачи спускаются вниз по иерархической лестнице. Тем не менее они реализуют agile-подходы. Например, проекты обкатываются сначала в «песочницах», а уже потом их масштабируют на всю структуру. Что мешает делать так же в госсекторе? Например, провести эксперимент в двух ФОИВ… Тем не менее у нас часто решения сразу масштабируют на всю страну.
— Некоторые из этих решений потом приходится отменять: оказывается, что они неэффективны.
— Да, это еще один из пунктов специфики, по крайней мере российской. Низкая толерантность к риску. Например, как разрабатывают новые продуты в британском государственном ИТ-агентстве Government digital service? Они создают команду, которая сначала проводит исследования, ищет варианты решения задачи, потом выбирают лучший вариант продукта, делают альфа-прототип, бэта-прототип, и так до конечного результата. На каждой стадии команда обосновывает свои решения и получает финансирование для следующего этапа.
Допустим, после изготовления прототипа стало понятно, что команда пошла по неверному пути. Тогда агентство соглашается с уже понесенными потерями и курс меняют. Это я и называю толерантностью к риску: лучше на старте потерять несколько миллионов рублей, чем сделать проект стоимостью, например, 30 миллионов и понять, что он в таком виде не нужен.
В России, если ты решишь изменить всю концепцию проекта, когда он выполнен на 20 процентов, возникнет неосвоение средств. Это создает проблемы. Поэтому часто госструктуры вынуждены заканчивать проекты, даже если уже вскоре после старта понятно, что в таком виде они не нужны.
— Agile пришел из программирования. И примеры, которые мы обсудили в интервью, также касались ИТ. На какие еще отрасли госсектора можно масштабировать эту философию?
— Мы не рекомендуем делить по отраслям. Главный критерий — степень неопределенности. Если вы на старте можете описать задачу так, что она не изменится с течением времени, есть доступная технология, которая однозначно может решить задачу, и у вас есть время, то agile не нужен. Если же задание может меняться или не совсем понятно, как его выполнить, лучше использовать гибкий подход.
Мировой опыт показывает, что гибкие подходы хорошо ложатся на нормотворчество. Например, как у нас принимают законопроект? Заинтересованное ведомство внутри себя пишет законопроект или нормативный акт и пропускает его через пятнадцать кругов внутреннего согласования. После этого появляется версия, которую не стыдно показать миру. Это уже практически чистовик, который еще ни одно другое ведомство не видело. Документ отправляют в смежные структуры на согласование, которым, конечно, многое не нравится. После длительных межведомственных утверждений документ уходит в правительство.
Как можно пересмотреть этот процесс в философии agile? Сначала можно договориться со всеми смежными ведомствами и курирующими правительственными департаментами по ключевым тезисам. Это можно сделать даже в формате презентации в Power point. Когда есть договоренность о ключевых тезисах — оформлять черновик. Его даже необязательно обсуждать официально, достаточно рабочих совещаний. Когда черновик согласован с ключевыми участниками — выносить чистовик на одобрение. Как мне кажется, такой подход мог бы в несколько раз сократить сроки разработки законопроектов.
Сейчас такое не практикуется — никто всерьез не будет рассматривать презентацию с ключевыми тезисами. Многие госслужащие занимают такую позицию: «Пришлете официальный документ — будет официальный ответ».
О старте в agile
— Предположим, я региональный или муниципальный госменеджер и хочу попробовать гибкие методы в своей системе. Как выглядит алгоритм моих действий? Как стартовать?
— Во-первых, вам нужно понять, зачем вы это делаете. Например, иногда случается следующее. Губернатор после встречи с главой Сбербанка Германом Оскаровичем Грефом возвращается к себе в регион, собирает подчиненных и приказывает: «Внедрить scrum. Через неделю приду и проверю». Так не работает. Для внедрения agile у этой затеи должны быть четкие цели.
Что мы хотим изменить? У нас долгие процессы, а мы хотим сделать их быстрыми? Это хорошая цель. Или, например, наши потребители — граждане — недовольны нашими сервисами. Мы хотим, чтобы они были довольны. Тоже отличная цель.
Теперь мы определяем метрики. Так, это может быть скорость — тогда мы прописываем формулы, по которым мы ее рассчитываем.
Agile подходит для того, чтобы переделать некую госуслугу или сервис. Либо это некоторая постоянная деятельность, по которой мы составляем аналитический отчет. Важно учитывать, что все такие задачи должна отличать высокая степень неопределенности. Хороший пример — регулярное обновление стратегии регионального развития.
На следующем этапе мы создаем первую пилотную команду или несколько таких команд. Например, это будет команда, которая пишет стратегии. Для такой сложной аналитической работы agile подходит.
Мы уже знаем, по каким метрикам мы оценим успешность пилотного проекта, который можно потом тиражировать. Команды нам нужно обучить и правильно запустить. Для участников нужно прописать роли, определиться, как команды будут работать. Где-то полгода команды нужно вести «за ручку»: им нужен внешний или внутренний консультант. Ну а дальше говорить о стандартной схеме уже нельзя — все уникально. Поэтому это и называется — гибкое управление проектами.
Подготовил К. В. СУГРОБОВ
Интервью из журнала «Метод» (№ 1 за 2019 год)
