Портал госуслуг (gosuslugi.ru) — крупнейший государственный портал и один из крупнейших в Рунете вообще (12-е место по месячной аудитории). На нем зарегистрировано 77 млн пользователей — почти все совершеннолетние граждане страны, имеющие доступ к Интернету. Как всякая действующая система, портал должен непрерывно развиваться и совершенствоваться, при этом оставаясь постоянно доступным. О том, как порталу удается изменяться, работая при этом в режиме 24х7х365, рассказывает Дмитрий Матвеев, руководитель проектов развития Портала государственных услуг Российской Федерации и мобильного приложения «Госуслуги», а также один из докладчиков практической конференции «Agile, DevOps, ITSM 2018», которую издательство «Открытые системы» проведет 23 октября.

Дмитрий Матвеев, руководитель проектов развития Портала государственных услуг Российской Федерации и мобильного приложения «Госуслуги»:  «Наше развитие, скорее всего, будет связано с созданием национальной платформы, на которой другие государственные и коммерческие организации смогут получать сервисы от государства и предлагать свои собственные»

Для пользователей портал госуслуг — представительство государства в Интернете, сотни услуг и обилие информации. А что там, «за фасадом»?

За фасадом большая работа по переделке портала, в результате которой он стал таким, какой есть. Эту работу ведет большая команда, почти 900 человек. Из них около 300 работают над развитием портала и 600 человек обеспечивают его эксплуатацию. Под эксплуатацией понимается не только работа с релизами ПО, поддержка баз данных, системного ПО и аппаратной части, но и ответы на телефонные звонки, консультации в чатах и т. д.

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

Что мешало сделать это раньше?

Есть формальные процедуры государственных информационных систем, где четко прописано, что, перед тем как ввести какое-то новшество в эксплуатацию, его нужно очень долго тестировать, подписывать акт о вводе в эксплуатацию, другие бумаги…

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

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

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

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

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

Мы смогли сформулировать в нашей работе несколько интересных правил, внесли их в государственные контракты, сделав легитимными, и в соответствии с ними начали ускорять нашу разработку. Мы назвали это «госagile»

Упомянутые восемь изменений в день — они действительно нужны? Вряд ли за день появится столько новых услуг или изменений в интерфейсе. Не могут получиться изменения ради изменения?

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

Чтобы такого не происходило, мы вносим улучшения маленькими порциями. Это помогает избежать конфликта команд, работающих над одними и теми же модулями. А когда конфликтов меньше, то снижается длина цикла получения стабильной ветки кода. Если у нас есть несколько команд, то каждая из них должна результат своего труда имплементировать в основную ветку независимо от других команд. Иначе на стадии интеграционного тестирования возникает бутылочное горлышко — приходится выбирать, чей код «важнее», кого протолкнуть первым. И наша задача — перейти к восьми релизам в день, чтобы дать командам дополнительную степень свободы — управляемость датой релизов для их задач, ликвидировать узкое горлышко.

Вы смогли создать концепцию госagile, продавить ее через госструктуры. Как это удалось, какие вопросы возникали?

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

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

Таким образом мы разрываем порочный круг. Почему исполнители госконтрактов часто боятся внедрять Agile? Если «сырой» код попадает в рабочую систему и случается авария, возникает их ответственность по второму контракту — на поддержку. Чтобы убрать это противоречие, мы сказали, что ошибки в «сыром» коде не подлежат штрафам по эксплуатации. Код с новым функционалом находится в опытной эксплуатации в промышленном контуре, и к нему предъявляются соответствующие, пониженные, требования по отказоустойчивости. Тем самым мы убрали противоречие между теми, кто развивает код, и теми, кто его должен поддерживать.

Но у вас же одна команда и на разработке, и на поддержке?

Это для внешнего мира — одна команда. Но наши 900 человек не монолит. Внутри это множество структур, расположенных еще и в разных регионах России: программисты, тестировщики, юзабилисты, аналитики… У разных микрокоманд — разные интересы. И нужно постоянное взаимодействие, чтобы все эти люди разговаривали друг с другом, понимали, что у них общая цель. Сделать так, чтобы тем, кто создает продукт, было не все равно, что с общим продуктом происходит. Это была одна из важнейших задач прошедших лет.

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

А в больших негосударственных структурах как решаются эти вопросы? Там ведь тоже все «по уставу».

По-разному. В «Яндексе» решается максимально автономными продуктовыми командами. Компании типа Сбербанка и «Альфа-банка» выделяли свои Agile-инновации в отдельную структуру, и там устанавливались другие корпоративные правила.

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

В каком направлении портал будет развиваться дальше?

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

Какие проблемы тут могут возникнуть?

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

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

Потому что от портала госуслуг ждут значительно больше, чем просто «госуслуги».

Амбициозная задача…

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

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

Оператор системы «Платон» также прорабатывает возможность, как через нас осуществлять оплату штрафов за неоплаченный проезд грузовиков по дорогам федерального значения, подобно тому, как это сделано с ГИБДД.

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

Мы также разработали концепцию «Госвеб» и в рамках этой концепции начинаем прорабатывать вопросы, какие должны быть стандарты, как может выглядеть сайт органов власти, как должны выглядеть новости на сайте органов власти, сервисы органов власти и т. д. У нас открыто бета-тестирование на ­beta.gov.ru,­ где мы сейчас представляем решения, имеющиеся у нас в этой области. В нынешнем году мы наконец попробуем выйти за рамки классических госуслуг.