Последние годы советской эпохи. Я, молодой, перспективный, только что защитившийся начлаб, веду крупную государственную тему в одном НИИ. Разрабатываемая информационная система охватывает несколько союзных республик. Приближается срок сдачи работы. На приемку приедет сам министр.
Как всегда, что-то работает, что-то не очень. Но время подошло — сдавать надо. Система большая, сложная, с множеством контрагентов, включая разные НИИ и Академию наук. Как все это хорошо представить за несколько минут?
Моя жена бесплатно за пару дней пишет на Си оболочку, запускающую разработанную контрагентами систему. А главное, находит в своем НИИ хорошего дизайнера, который делает для нее потрясающе красивую заставку.
В день сдачи заставка с названием интегрированной системы висела на всех мониторах демонстрационной комнаты. Министр был в полном восторге. Тогда еще вообще глубина цвета в 16 бит только появилась. А тут еще такой фотошедевр. Дизайнеру удалось найти очень красивый пейзаж западного фотографа. Проблема импортозамещения тогда не была актуальной. Впрочем, и дизайнер не упоминал о заимствовании картинки. Во всяком случае до получения гонорара. Все были довольны, тема сдана, хотя дальше картинки и обвязки, написанной моей женой, министр и не заходил.
Времена меняются, но некоторые вещи меняются не сильно. Да, теперь
Но картинка — картинкой, но ведь на всем этом надо еще работать. А как отличить рекламную шелуху от реальности? Действительно ли предлагаемая система так хороша? Действительно ли созданный по госзаказу ИТ-продукт соответствует техзаданию и современному уровню развития ИТ?
Новые вызовы
Особенно обострилась эта проблема в настоящее время. Денег стало меньше. На круглом столе «Качество и эффективность применения ИТ в органах власти: проблемы и способы решения», который прошел 27 мая в Московской областной думе, Кирилл Жигарев, заместитель председателя Комитета Мособлдумы по вопросам транспортной инфраструктуры, связи и информатизации привел пример. В 2014 г. победителями конкурса Минкомсвязи был 61 субъект и сумма составила 1,15 млрд. руб., а в этом году уже 30 субъектов и всего 550 млн. руб. И все это в условиях выполнения программы импортозамещения, которая никак не способствует задаче снижения издержек.
А ведь никто не отменял хорошо известный принцип автоматизации. Быстро — дешево — качественно: верными утверждениями могут быть только два из этих трех. И если сроки никто не продлял, а финансирование сокращено, то логично предположить, что снизится качество ИТ-разработок.
И, как правильно отметил Кирилл Жигарев, — «обострение борьбы за контракты приводит не только к росту коррупционной составляющей, но и к снижению качества ИТ-продуктов». И с этим надо что-то делать.
На контроле у депутатов
Контроль эффективности расходов государственных бюджетов — предмет пристального внимания депутатов. И их, конечно, волнует вопрос, как правильно оценить качество предлагаемых государству ИТ-оборудования и ПО.
На круглом столе прозвучали разные предложения. Алексей Хромов, ведущий научный сотрудник ГУ «Российская Академия ракетных и артиллерийских наук», рассказал, в чем проявляются типовые проблемы качества и эффективности ИТ-решений в госструктурах.
Во-первых, в том, что разработчики делают не то ИТ-решение, о котором их просят. ИТ-решение может просто не соответствовать потребностям госзаказчика. Причин этого несколько — заказчик и исполнитель неправильно поняли друг друга, требования изменились во время разработки, заказчик сделал так, как умеет, а не как требовалось.
Кроме того, характеристики разработанного ИТ-продукта могут отличаться от требуемых. Или в полученном продукте реализована неправильная логика процессов, отличающаяся от существующей на практике.
Другая типичная проблема — разработчики сделали, что их просили, но на практике все плохо работает и фактически не используется. Например, не были учтены особенности ландшафта инфраструктуры организации, потому программы работают крайне медленно. Или у программного средства неудобный интерфейс и поверхностная, плохо написанная документация. Или информационная система работает нестабильно и с ошибками.
Иногда это проявляется в том, что служащий просто не понимает, зачем ему переходить на новую систему, если переход сопровождается дополнительными затратами его времени и никакого выигрыша не дает. И саботирует работы.
Проблемы качества и эффективности применения ИТ
Существует ряд проблем, ведущих к плохому качеству и низкой эффективности применения ИТ в госструктурах. Хорошо известно, что нет программ без ошибок. Как шутят программисты — каждая последняя ошибка является предпоследней. Так что ошибки всегда есть, вопрос только в том, насколько они критичны.
Сейчас нет общепринятой системы оценки качества предлагаемых госорганам ИТ-продуктов. Развитие национальных стандартов оценки качества программных продуктов закончилось в далеких
Вместо этого при приемке чаще всего используется экспертный метод. Собирается группа экспертов, в течение ограниченного времени исследует продукт и дает свое заключение. Но когда решение доходит до конечного потребителя, зачастую все оказывается не так гладко и хорошо, как это представлялось экспертам.
Существующие отечественные стандарты не развиваются и во многом устарели, а слепое копирование зарубежных не всегда эффективно. За рубежом другая культура производства, часто зарубежные стандарты не адаптированы под наши условия, а то и просто плохо переведены.
Причиной многих проблем эффективного использования ИТ-решений в госструктурах является и недостаточная квалификация и низкая мотивация персонала учреждений. И совсем новая тенденция — отсутствие высокой заинтересованности в качественном продукте как со стороны заказчика, так и разработчика.
С разработчиком все понятно. Как шутят врачи — хорошего в финансовом плане больного никогда нельзя лечить до конца. Разработчик заинтересован в том, чтобы получать финансирование на доработку его продукта и дальше.
Для заказчика это справедливо не всегда и не везде. Это, скорее, не относится к критически важным областям, например напрямую связанную с финансами, или к системам управления технологическим процессом, т. е. системам, где ошибки будут видны сразу. А вот для систем организационного управления это вполне актуально. Если такой софт успешно внедряют и он начинает хорошо работать, то у чиновника пропадает статья финансирования на следующий год. Что ему может не понравиться.
Причины возникновения проблем
Существует ряд причин возникновения проблем. Например, объективной причиной являются быстро меняющиеся потребности заказчика, отражающие быстрые перемены в окружающем мире. Примером может служить неожиданно возникшая проблема импортозамещения, которая оказала значительное влияние на тенденции развития государственных ИТ.
Другая частая причина возникновения проблем — отсутствие научных проработок проектов. Хорошо известно, что делать дешевле, чем переделывать. В советское время такими вопросами занимались НИИ. Проведение научно-исследовательских работ на стадии проектирования системы значительно снижало возникновение проблем на стадии эксплуатации. Сейчас же все проще. У госучреждения возникает потребность, кто-то читает в прессе или Интернете, что эту проблему можно решить с помощью информационных технологий, делают заказ, получают продукт и с удивлением выясняют, что получили не то, что хотели.
К этой же причине относятся абстрактные технические задания. Нет нормальной проработки вопроса — трудно сформулировать то, что нужно заказчику. А когда заказчик в общих чертах все же формулирует задачу, то он не понимает трудоемкость ее решения и вообще — возможно ли ее решение. А исполнитель возьмется за любую работу, даже если он не знает, как ее сделать. Лишь бы деньги платили.
Необходимо отметить слабое взаимодействие госорганов и команд разработчиков на этапе разработки информационных комплексов, что часто связано с недостатком квалификации заказчика, который хотя бы в общих чертах должен понимать, что делает разработчик и взаимодействовать с ним в течение всего периода разработки, когда все исправить намного проще, чем после запуска системы.
Сказывается и отсутствие системы контроля качества, а сам заказчик просто не может все проверить в силу недостаточной компетентности. Ее часто не хватает даже на примерную оценку компетентности самого исполнителя, не говоря уже о культуре организации производственных процессов по созданию, развитию и применению ИТ-решений, которая у разработчика может быть довольно низкой.
Одна из типичных для органов государственной власти проблем — заказчиками и потребителями ИТ-продукции выступают разные подразделения. Когда работу принимают не те люди, которые будут непосредственно эксплуатировать систему. Например, систему принимают в Москве, спускают для использования в регионы, где она не может быть использована из-за местной специфики.
Остается проблема доступности проектов, которые уже были сделаны за бюджетные деньги другими разработчиками. Идея национального фонда алгоритмов и программ по-прежнему не работает .
Ну и по-прежнему, как я уже отметил в начале статьи, красивая «картинка» часто важнее содержания. Все фирмы соревнуются в пиаре и заказчику очень трудно выбрать действительно лучший вариант. Ведь он не может быть экспертом во всем.
Направления решения проблем качества ИТ-решений
Что же делать? Свои рекомендации дал на заседании круглого стола Алексей Хромов. С ним трудно не согласиться.
Если рассматривать вопрос управления процессом создания ИТ-решений, то нужно внедрять программно-целевые методы и проектное управление. Внедрение их через какое-то время даст эффект и качество ИТ-продуктов повысится. Все эти вещи не новые и хорошо известные.
Нужно повышать квалификацию специалистов. Повышать культуру производства, чтобы специалисты относились к работе не формально, а задумывались о конечном результате.
Учить людей. Чтобы представитель заказчика мог понимать, что делает разработчик, правильно расставлять приоритеты в процессе разработки и иметь компетенцию для приемки результатов. И в этом ему надо помогать. Причем не только учебой. Нужно «оживить» отечественные стандарты оценки качества ИТ-решений и адаптировать лучшие зарубежные.
Нужно обеспечить возможность создания и проведения по-настоящему независимых экспертиз ИТ-продуктов, поставляемых госсектору. «Сейчас у нас независимость экспертиз ИТ-продуктов просто потрясает своим цинизмом», — заявил Алексей Хромов. Он полностью поддержал инициативу ведущего Кирилла Жигарева о «создании в каждом федеральном округе независимых центров экспертизы для оценки качества внедряемого и закупаемого оборудования и софта».
Решения круглого стола
Ну и в конце кратко изложу основные решения круглого стола.
— Сформировать принципы аккумулирования ИТ-решений для последующего использования в регионах.
— Выработать рекомендации по разработке критериев качества внедренных ИТ-продуктов.
— Разработать предложения по методологиям оценки и экспертизы ИТ-продуктов.
— Разработать предложения по развитию системы национальных стандартов РФ.
— Создать экспертную группу по вопросам концепции создания пилотного проекта «Центра независимой экспертизы ИТ-решений в Центральном Федеральном округе».
В целом подход, конечно, правильный. Вопрос тольков том, насколько все это удастся реализовать, и не останется ли все на уровне одних разговоров. Но хорошо, что хоть вопросы ставятся и какие-то работы ведутся. А насколько они будут эффективными — покажет время.
