В чем особенности реализации ИТ-проектов в госсекторе
Александр Морлок, директор по разработке программного обеспечения, исполнительный вице-президент группы компаний ЛАНИТ, рассказал о том, какие сложности возникают при реализации ИТ-проектов в госсекторе
У государства самая большая доля на рынке информационных технологий в России. Проекты для государственного сектора, как правило, очень масштабны. Над созданием информационной системы зачастую работают сотни программистов, а потом ею пользуются сотни тысяч и даже миллионы человек.
Однако реализация крупных проектов для государственных заказчиков связана с рядом сложностей, специальными условиями и ограничениями.
Нехватка ресурсов
Рынок труда в ИТ-отрасли перегрет. Людей не хватает. Особенность госпроектов состоит в том, что они очень интересны для менеджмента компаний-исполнителей. Но те, кто непосредственно пишет код, относятся к таким проектам с осторожностью. Молодые специалисты, которые только окончили вуз, больше хотят заниматься сервисной и продуктовой разработкой. Поэтому перед руководителями стоит задача заинтересовать их проектами для госзаказчиков. Нужно донести значимость работы в подобных проектах, чтобы ИТ-специалисты чувствовали свой вклад в важное государственное дело: как их строчки кода помогают создать сложнейшие системы, нужные стране.
Современное молодое поколение (а в ИТ работает много молодежи) невозможно привлечь и удержать только финансовой мотивацией. Поэтому необходимо показывать социальную значимость проектов, возможности профессионального и карьерного роста в них, а также социальную ответственность работодателя.
Еще молодым сотрудникам не нравится, что сроки в проектах для госзаказчиков зачастую первичны над качеством. Действительно, когда ты имеешь дело с системой для государства, как правило, есть нормативно установленная дата окончания работ по проекту, и здесь, к сожалению, часто работает правило «лучше сделать семь раз вовремя, чем один раз правильно». Чтобы избавиться от моральных мучений, нужно сделать одну простую вещь — включить понятие «сроки» в понятие «качество» наравне с эффективностью архитектурного решения, удобством интерфейса, отсутствием ошибок.
Догоняющая роль законодательства
Речь идет не о законодательстве прямого действия, которое определяет работу самой системы, а об «обвязке», смежном законодательстве. Например, облака позволяют за счет совместного использования инфраструктурных ресурсов разными системами сократить суммарную потребность в оборудовании. Но если рассматривать государственные системы, то каждая система должна быть аттестована отдельно. Соответственно, получаем проблему — мы не можем использовать публичные облака, что наиболее эффективно с точки зрения затрат.
Еще пример. Государственная система должна быть аттестована, и для этого все средства защиты должны быть сертифицированы. Не всегда получается обойтись только внешними средствами (межсетевые экраны, системы обнаружения вторжений и т.д.), поэтому приходится сертифицировать часть программного кода самой системы. На сертификацию уходит примерно год. Для внесения изменений в уже сертифицированный код есть более простая процедура, но она все равно занимает два-три месяца.
Компании — исполнителю госпроектов постоянно приходится лавировать между требованиями по информационной безопасности в части использования сертифицированного программного обеспечения и необходимостью привлечения современных технологий разработки. Например, hibernite, докерконтейнеры, с которыми хотят работать программисты, — хорошее средство для повышения эффективности их работы, но раз в две недели выпускается новая версия системы. Соответственно, возникает вопрос с сертификацией.
Поэтому ты либо используешь сертифицированную версию, в которой нашли уязвимость, и не можешь обновить ее, либо ты должен обновляться и тем самым можешь нарушить требования сертификата. Все международные лидеры (Google, Amazon и другие) выбирают более короткий путь, чтобы без остановки системы можно было вносить в нее изменения. Рынок меняется, запросы меняются, технологии разработки систем и принципы управления проектами меняются. Но законодательство не всегда позволяет использовать новые возможности.
Повышенные требования к системе
Разрабатывать систему, функциональность которой определяется законодательством, не то же самое, что разрабатывать обычный софт, который должен просто автоматизировать какие-то процессы и нравиться пользователям. Например, функциональность Единой информационной системы в сфере закупок (ЕИС), которую многие эксперты признают одной из самых крупных государственных систем, определяют свыше 300 нормативно-правовых актов. Пользователям, конечно, нужны современные сервисы, помощники, гибкость системы, ее удобный интерфейс. Поэтому даже микрозадачи ЕИС необходимо проектировать с учетом всей имеющейся нормативно-правовой базы, делать предметом не просто ручного ввода, а сопоставления со всеми ранее запущенными функциями (а это, к слову, больше 20 млн строк кода).
Я уже не говорю о тех случаях, когда нормативный акт выходит сегодня, а работать должен уже завтра. Все это многократно усложняет доработку системы и предъявляет повышенные требования ко всей проектной команде: обязательна серьезная юридическая квалификация у каждого аналитика, нужны особые подходы к отслеживанию требований, необходимы гибкие методологии и автоматизированные проверки всей функциональности перед ее выпуском.
У проектов, связанных с госзаказом, есть еще ряд особенностей.
Цикличность проектов
ИТ-проекты для государства регулируются законодательством по госзакупкам. Длительных контрактов мало, и разработчики каждый год участвуют в конкурсах на одну и ту же систему, которую создали. Это приводит к тому, что итоговая стоимость проекта увеличивается, так как у исполнителя нет мотивации вкладываться в тему, которую на следующий год он может не выиграть.
На мой взгляд, более эффективная схема — это когда создание системы от самого начала (разработки концепции и архитектуры) и до ее ввода в эксплуатацию осуществляет один исполнитель. Уйти от классического «водопада» к гибким практикам реализации проектов можно — для этого я бы предусмотрел, чтобы в техническом задании на систему была определена ее основная часть (ядро) и плюс что-то вроде калькулятора. С его помощью можно было бы рассчитывать бюджеты на изменения системы. В этом случае заказчику не нужно было бы «переигрывать» конкурсы.
Практическая невозможность использования готовых коробочных решений
В мировой практике процессы подстраивают под правильно созданный софт, под то, что умеет система. В России же для крупных государственных заказчиков софт всегда подстраивается под существующие процессы или требования законодательства. Поэтому готовое решение приходится сильно переписывать, и все его преимущества теряются.
Требования по импортозамещению
Активное импортозамещение в сфере ИТ в России началось около пяти лет назад. Все новые системы для госсектора разрабатываются исключительно с таким подходом — чтобы в базовом программном обеспечении отсутствовали продукты иностранного производства.
Большой разрыв между лидерами и отстающими
Разрыв наблюдается между крупными федеральными органами исполнительной власти, столичными центрами и небольшими госпредприятиями, удаленными муниципалитетами. Инноваторы говорят о внедрении искусственного интеллекта в госсекторе, а кто-то только перешел к учету в Excel.
Существенные проблемы в базовых информационных ресурсах
Без базовых информационных ресурсов невозможно сделать крупный проект для государства. Зачастую, чтобы получить данные от органов власти, можно потратить полтора года на согласования. Сами данные между собой не синхронизированы.
На что нужно делать упор при реализации проектов в государственном секторе
- В больших и сложных проектах по созданию государственных информационных систем должна быть единая команда исполнителя (разработчика), функционального заказчика и тех, кто готовит нормативно-правовой акт. Принцип «тебе сказали — ты сделал» здесь приводит к плохим последствиям. Должен быть диалог, чтобы вместе формулировать и искать пути, как можно реализовать задачу. В процессе создания информационной системы разработчику нужно быть как можно ближе к тому, кто выпускает подзаконную нормативно-правовую базу. Все хотят гибкости, а требования на бумаге меняются достаточно часто. Разработчик должен как можно быстрее узнавать об изменениях, чтобы адаптировать под них систему.
- По государственным контрактам гибкий подход в госпроектах у нас практически невозможен (применяется только схема «водопада», этапность), но жизнь настоятельно диктует необходимость применения гибких методологий. Поэтому по договору проект выполняется по принципу «водопада», а по жизни — по Agile. Появилась в системе функция регистрации пользователей, нужно ее выдавать, чтобы пользователи начали регистрироваться, даже если, кроме этого, им в системе больше делать нечего. Появился другой сервис, пусть даже незаконченный, нужно его выдавать, чтобы его начинали тестировать, подключаться к нему. «Маленькими шажками» проекты всегда случаются.
- Нужно уделять внимание PR. В крупном государственном проекте обязательно должен быть человек, который занимается коммуникациями со всеми заинтересованными сторонами, отслеживает новости, готовит пресс-релизы, проводит мероприятия для целевых аудиторий.
- Важнейшая тема — безопасность. Если брать интернет-системы, то мы выделяем три момента, которые нас больше всего волнуют. Во-первых, дефейс: на внешней странице не должно случайно оказаться того, чего там быть не должно. Во-вторых, вопросы, связанные с DDoS-атакой. Поскольку речь идет о государственной системе, важно, чтобы она работала на территории Российской Федерации. В-третьих, утечка данных. В государственных системах могут храниться сотни миллионов персональных данных, поэтому необходимо принимать меры предосторожности против утечек.
