Портал госуслуг (gosuslugi.ru) — крупнейший государственный портал и один из крупнейших в Рунете вообще (12-е место по месячной аудитории). На нем зарегистрировано 77 млн пользователей — почти все совершеннолетние граждане страны, имеющие доступ к Интернету. Как всякая действующая система, портал должен непрерывно развиваться и совершенствоваться, при этом оставаясь постоянно доступным. О том, как порталу удается изменяться, работая при этом в режиме 24х7х365, рассказывает Дмитрий Матвеев, руководитель проектов развития Портала государственных услуг Российской Федерации и мобильного приложения «Госуслуги», а также один из докладчиков практической конференции «Agile, DevOps, ITSM 2018», которую издательство «Открытые системы» проведет 23 октября.
— Для пользователей портал госуслуг — представительство государства в Интернете, сотни услуг и обилие информации. А что там, «за фасадом»?
За фасадом большая работа по переделке портала, в результате которой он стал таким, какой есть. Эту работу ведет большая команда, почти 900 человек. Из них около 300 работают над развитием портала и 600 человек обеспечивают его эксплуатацию. Под эксплуатацией понимается не только работа с релизами ПО, поддержка баз данных, системного ПО и аппаратной части, но и ответы на телефонные звонки, консультации в чатах и т. д.
На первых порах портал изменялся четыре раза в год, а сейчас — почти каждый рабочий день. Но нам сегодня и этой скорости мало, мы думаем над тем, как выпускать до восьми релизов в день разными командами, независимо друг от друга. Это был бы следующий уровень скорости, который нам нужен.
— Что мешало сделать это раньше?
Есть формальные процедуры государственных информационных систем, где четко прописано, что, перед тем как ввести какое-то новшество в эксплуатацию, его нужно очень долго тестировать, подписывать акт о вводе в эксплуатацию, другие бумаги...
То есть интернет-ресурсу приходилось руководствоваться теми же регламентами, которые действуют в системах ERP-класса, где перемены очень редки, — скажем, в системе выдачи паспортов или межведомственного документооборота. Примерно с такой же скоростью и по таким же канонам развивался наш портал госуслуг до 2014 года. И что мы в корне начали переделывать — это то, как нужно воспринимать изменения на портале и в коде, чтобы в разы ускорить цикл выпуска релизов.
— Как удалось изменить ситуацию, что для этого потребовалось?
Потребовалось перестроить всё: и межличностные, и организационные, и контрактные взаимодействия. И нормативные документы перечитать, чтобы доказать, что разрабатывать все по-новому можно, не нарушая их. И в головах у людей изменить подход к тому, что такое продукт и почему можно не бояться так часто его изменять.
У заказчика и исполнителя заведомо разные роли, они хотят разного, порой прямо противоположного. И нам надо было искать точки соприкосновения с противоположной стороной, причем не теряя своей идентичности, своей роли, помня, за что мы отвечаем. Это очень важный момент в государственных контрактах и в государственных проектах, потому что почти везде в государственных проектах малый выбор исполнителей. Иногда исполнитель предопределен, как в нашем случае, либо его выбирают из малого количества конкурентов. И нужно уметь выстраивать продуктивные отношения.
В итоге мы смогли сформулировать в нашей работе несколько интересных правил, внесли их в государственные контракты, сделав легитимными, и в соответствии с ними начали ускорять нашу разработку. Мы назвали это ГосAgile. Такой подход может быть интересн, причем не только для госструктур, но и для крупных частных компаний, в которых тоже много строгих административных процедур для проектов и контрактов.
— Упомянутые восемь изменений в день — они действительно нужны? Изменений чего? Вряд ли за день появится столько новых услуг или изменений в интерфейсе. Не могут получиться изменения ради изменения?
Изменение в данном случае — это часть кода, который протестирован и может быть имплементирован в основную ветку. Чтобы последствия изменений были менее сокрушительными, сами изменения должны быть небольшими. Если делать один очень большой релиз, то все начинают бояться его внедрять, откладывают, тестируют снова и снова, в нем накапливается еще больше изменений, и в итоге он парализует всю работу. Пока его не выпустят, больше нельзя выпустить вообще ничего.
Чтобы такого не происходило, мы вносим улучшения маленькими порциями. Это помогает избежать конфликта команд, работающих над одними и теми же модулями. А когда конфликтов меньше, то снижается длина цикла получения стабильной ветки кода. Если у нас есть несколько команд, то каждая из них должна результат своего труда имплементировать в основную ветку независимо от других команд. Иначе на стадии интеграционного тестирования возникает бутылочное горлышко — приходится выбирать, чей код «важнее», кого протолкнуть первым. И наша задача — перейти к восьми релизам в день, чтобы дать командам дополнительную степень свободы – управляемость датой релизов для их задач, ликвидировать узкое горлышко.
— Вы смогли создать концепцию ГосAgile, продавить ее через госструктуры. Как это удалось, какие вопросы возникали?
Основная проблема — боязнь нарушить какой-либо норматив. Поэтому самым главным было найти как принципы Agile укладываются в схему госконтрактования. Конечно, в перспективе, очень хотелось бы изменить и сам процесс госконтрактования, чтобы и ИТ-проекты можно было запускать как Agile-проекты, но этому мешают борьба за прозрачность госзакупок, установка на «наименьшую фиксированную цену», состав работ должен быть описан заранее и т. д.
Поэтому мы работаем в текущих правилах. Есть годовая цель, годовой бюджет, просто внутри контракта мы закладываем принципы Agile — итеративность процесса разработки, ранние демонстрации, деление разработчиков на микрокоманды, прописываем, что у нас могут быть релизы, доступные ограниченному количеству пользователей, и т. д.
Таким образом мы разрываем порочный круг. Почему исполнители госконтрактов часто боятся внедрять Agile? Если «сырой» код попадает в рабочую систему и случается авария, возникает их ответственность по второму контракту — на поддержку. Чтобы убрать это противоречие, мы сказали, что ошибки в «сыром» коде не подлежат штрафам по эксплуатации. Код с новым функционалом находится в опытной эксплуатации в промышленном контуре и к нему предъявляются соответствующие, пониженные, требования по отказоустойчивости. Тем самым мы убрали противоречие между теми, кто развивает код, и теми, кто его должен поддерживать.
- В каком направлении портал будет развиваться дальше?
Наше развитие, скорее всего, будет связано с созданием национальной платформы, на которой другие государственные и коммерческие организации смогут получать сервисы от государства и предлагать свои собственные — государству, гражданам и друг другу. Чтобы это получилось нужно, чтобы это стало проще и дешевле, чем создавать собственные решения.
Первое, с чем надо разобраться при разработке модели «госуслуги как платформы», — это с нормативной базой. С кем, как и на каких основаниях мы можем вступать в партнерство. Надо выработать общие правила игры: как подключиться к платформе, что платформа может предоставлять, кому бесплатно, а кому платно.
Сейчас таких правил не существует. Этот подход нужно изменить, централизованно разработать интерфейсы и процессы подключения и проверки услуг. Организовать все приблизительно так, как устроено для разработчиков в магазинах мобильных приложений.
Потому что от портала госуслуг ждут значительно больше, чем просто «госуслуги».
Мы также разработали концепцию «Госвеб» и в рамках этой концепции начинаем прорабатывать вопросы, какие должны быть стандарты, как может выглядеть сайт органов власти, как должны выглядеть новости на сайте органов власти, сервисы органов власти и т. д. У нас открыто бета-тестирование на beta.gov.ru, где мы сейчас представляем решения, имеющиеся у нас в этой области. В нынешнем году мы наконец попробуем выйти за рамки классических госуслуг.
— О чем вы будете рассказывать на конференции и о чем вы сами хотите услышать на конференции?
Расскажу о том, как внедрить Agile в госструктурах, как примирить заказчика и исполнителя, разработчиков и эксплуатационщиков, заставить их работать вместе. О наших дальнейших планах, после достижения показателя по аудитории в 70% от всех пользователей госуслуг.
Хочется услышать, с какими сложностями сталкиваются люди, которые ведут Agile-разработку в крупных компаниях, когда возникают негативные эффекты, обусловленные масштабом команды. Когда микрокоманды не взаимодействуют друг с другом должным образом, когда над ними нужна дополнительная структура для обеспечения взаимодействия, оркестровка. Интересны конкретные кейсы: с чем сталкивались, какие инструменты использовали — и методологические, и технические. Потому что я думаю, что такая оркестровка — следующий этап нашего развития, и хочется, чтобы она требовала меньше расходов.
