В газете «Ведомости» вышла колонка младшего научного сотрудника ИПП Алексея Кнорре и российского эксперта в области открытых данных Ивана Бегтина, посвященная разработке государственных информационных систем. Авторы анализируют проблему влияния уровня удобства существующих государственных информационных систем на скорость и качество работы сотрудников государственных ведомств, предлагая свои пути выхода из сложившейся ситуации.
IT-эксперт Иван Бегтин и социолог Алексей Кнорре о разработке государственных информационных систем.
Компьютер и набор программ на нем – неотъемлемая часть рабочего места практически в любой современной организации. Это справедливо и для всех структур государственного организма. В реестре федеральных государственных информационных систем (ГИС) до передачи его из Роскомнадзора в Министерство связи и массовых коммуникаций (на начало 2016 г.) находилось 339 ГИСа, большинство из которых были введены в 2011 г.
Эти ГИСы затрагивают жизнь каждого гражданина России и используются для работы с информацией в огромном количестве российских ведомств, начиная от налоговых и миграционных служб и заканчивая правоохранительными органами. Помимо ГИСов существуют также тысячи слабо учтенных автоматизированных систем, внедренных на федеральном и региональных уровнях власти. И хотя часто ведомства выводят часть этих систем в интернет, позволяя, например, обычному человеку узнать, есть ли у него непогашенные штрафы, основными пользователями таких систем являются государственные служащие.
ГИСы и автоматизированные системы позволяют государственным служащим использовать в работе достижения компьютерной революции и перекладывать на компьютеры ту работу, которая занимает много времени, но является примитивной: найти документы, относящиеся к определенному человеку или организации, отфильтровать их по времени, внести изменения или, наоборот, посмотреть историю документа. Кроме того, сам документооборот становится электронным и вместо печати и пересылки стопки бумаг достаточно передать ее по внутренним каналам связи или на флешке. Положительные стороны такой информатизации очевидны и для тех, кто принимает решения о разработке и внедрении систем, благодаря чему свои автоматизированные системы и ГИСы есть почти у каждого ведомства в России.
Однако при создании ГИСов и автоматизированных систем забывается критически важный этап. Система и ее компьютерный интерфейс становятся главным инструментом работы сотрудников, с которым они должны взаимодействовать ежедневно. От того, насколько такой рабочий инструмент для непосредственных пользователей удобен, зависит увеличение скорости и эффективности работы ведомства в целом. Если заказчики и разработчики не думают о том, кто будет пользователями, какие задачи эти пользователи будут решать в программе и как автоматизированная система будет встроена в бизнес-процессы организации, то исход внедрения такой разработки может быть противоположным: скорость и качество работы сотрудников и ведомства в целом упадет. Это можно заметить в любой районной поликлинике, где после заполнения электронной карты пациента сотрудник регистратуры будет дублировать все в бумажные документы.
Такие проблемы возникают из-за того, как обычно принято разрабатывать автоматизированные системы для ведомств в России:
– выделить деньги;
– написать техническое задание (в котором будет много про системную архитектуру и аппаратное обеспечение, но почти ничего про нагрузочное тестирование, изучение требований пользователей и апробацию удобства интерфейса);
– объявить тендер на разработку системы и отдать его на исполнение сторонней IT-компании.
Частично эти проблемы связаны с уже давно сложившейся в России практикой, когда техническое задание на разработку системы пишет наиболее вероятный победитель торгов «под себя» и, как следствие, оно изобилует избыточными техническими подробностями будущей системы и минимально описывает сам объект автоматизации. Побеждающая на торгах компания создает продукт, внедряет его в ведомстве, а потом – в зависимости от наличия финансов у ведомства – занимается технической поддержкой. Такая практика создает две фундаментальные проблемы в долгосрочной перспективе для ведомства.
Во-первых, низкая приспособленность системы к реальным нуждам пользователей. Программисты сами по себе не занимаются вопросами удобства программы, решаемыми ею задачами конечного пользователя и тем, как программа связана с рабочими процессами в ведомстве. Такими вопросами, ответы на которые предшествуют разработке программного продукта, занимаются бизнес-аналитики и исследователи пользовательского опыта. Эти люди приходят на рабочее место сотрудника, смотрят, чем он занимается в течение рабочего дня, проводят десятки интервью, чтобы понять, какие задачи действительно может и должна решать информационная система, а какие нет, и только после этого становится понятно, как должна выглядеть программа. Однако в тендерах таких этапов нет, а разработка информационной системы сводится к написанию кода и закупке оборудования.
Во-вторых, практика создания автоматизированных систем «раз и навсегда» сторонними компаниями приводит к долгому и болезненному внедрению, накоплению ошибок и созданию коммуникативной пропасти между пользователями и разработчиками. Оказывается, что после окончания работ по договору систему нужно основательно переделывать, потому что одной половины важных функций в ней не хватает, а вторая половина успела измениться с изменением законодательства. В результате созданный продукт долгое время приспосабливается для реальных нужд ведомства с постоянными изменениями в логике и интерфейсе и с головной болью для пользователей, которые вынуждены терпеть постоянные обновления.
Можно предложить по крайней мере два метода борьбы с такими проблемами. Первый – не отдавать разработку автоматизированных систем сторонним компаниям, а формировать отдел разработки внутри ведомства (так называемый inhouse software development), при котором программисты сфокусированы на одном проекте, по умолчанию заинтересованы в его успешном внедрении и могут быстро и постоянно реагировать на возникающие проблемы и потребности пользователей. По такому пути идут, например, правительство Великобритании, которое много лет назад создало команду Alpha Team для переработки государственного портала gov.uk, а также США, создавшие команду 18F, которая последовательно переделывают один за другим государственные порталы, адаптируя их под нужды граждан.
Второй метод – проектировать систему с учетом реальных потребностей пользователей. Для этого нужен труд бизнес-аналитиков и специалистов по user experience, без которого система может стать не эффективным инструментом для работы, а пожирающим ресурсы организации чудовищем.
Источник: Ведомости, Extra Jus.
