Очередной скандал, связанный с размытостью трактовок государственного задания и ответственностью исполнителя, возник в отрасли информационных технологий. На этот раз претензии к разработчикам софта имеются не у крупной компании, а у самого Министерства финансов Российской Федерации. Сообщается, что поставка в Минфин «заведомо неработоспособного программного обеспечения» стала причиной возбуждения уголовного дела.
Дело о мошенничестве при поставке ведомству недействующего ПО открыто Следственным комитетом России. Об этом ТАСС сообщил источник в правоохранительных органах. По версии следствия, исполнитель при заключении госконтракта знал, что не сможет создать требуемое ПО, однако ввел заказчика в заблуждение, чтобы получить основную долю оплаты.
Подробности сделки и сумма ущерба не раскрываются, однако сама формулировка «заведомо неработоспособное ПО» содержит интригу. На протяжении последних лет эксперты самых разных уровней говорят о фактической неподотчетности софта, который за огромные деньги закупает и потребляет государство.
Принципы ценообразования в отрасли оторваны от реальности. Их попросту не существует. Так же как не существует предквалификации исполнителей, внятных целевых показателей и персональной ответственности за созданные продукты. Многие системы приходится создавать повторно или достраивать.
Контракты жизненного цикла вылечат IT
На этом фоне все чаще звучит точка зрения, что программное обеспечение должно быть бесплатным, а платными – только обновление и техподдержка. Таким образом, разработка софта в России была бы завязана на контракты жизненного цикла, а заказчики и разработчики будут заинтересованы в отчетливых критериях эффективности продукта.
Нет техподдержки и заранее оговоренных KPI – значит нет и прибыли для разработчика. Такой подход работал бы и против многочисленных фейковых «информационных систем-однодневок», создаваемых только для «освоения» щедрых бюджетных потоков. Напомним, что на строительство цифровой инфраструктуры с 2019 по 2024 год государство направило почти 1,7 млрд рублей. Но как проверить эффективность этих инвестиций?..
Весьма востребованной является и практика проверки закупаемых государством IT-продуктов на признаки дублируемости. Скажем, если администрация условного города N закупила систему за 20 млн рублей, а администрация еще какого-то условного Крыжополя закупила за 25 млн рублей систему с идентичными функциями и аналогичной архитектурой, то вполне правомерным является вопрос об эффективности расходования бюджетных средств. Совершенно непонятно, почему и город N, и город Крыжополь не могут пользоваться одной системой по сниженной оптовой цене и отчитываться правительству об эффективности ее применения.
Последний вопрос для госзакупок в IT является животрепещущим. В России вообще отсутствуют критерии эффективности программных продуктов – никаких KPI, КПД, которые хотя бы в общих чертах позволяли понять, пригодился ли закупленный софт муниципалитету, региону, министерству или подведомственной организации.
Контракт считается исполненным после поставки ПО, а дальше хоть трава не расти. Никому не интересно, полезным ли оказался приобретенный продукт для конечного потребителя (гражданина РФ, сотрудника госпредпредприятия, социальной среды, экологии). Скажем, для сферы социальных услуг таким критерием могло бы быть число граждан обратившихся за услугой или стоимость одной услуги в единичном исполнении. Для иных систем – соответствующие реальным требованиям экономики отраслевые показатели.
Одним словом, вопрос техподдержки – это гораздо больше, чем дежурная проверка работоспособности соединений. Это средство оценки эффективности информационной системы в действии, возможность контролировать выполнение ключевых показателей государственного задания. Сам факт закупки софта – еще ни о чем не говорит. Ведь софт закупается под конкретную цель – поставленную государством.
ТЗ о двух концах
Скандал с поставками ПО для Минфина – проливает свет на еще одну неотвратимую проблему. Внятность технического задания для разработчиков. Зачастую в ТЗ заказчик ограничивается невразумительными формулировками, заставляющими сомневаться в том, что заказчик сам понимает, чего именно хотел.
Вот характерный свежий пример такого рыхлого ТЗ от Департамента финансов одного из субъектов РФ: «Личный кабинет должен содержать информацию о пользователе мобильного приложения, необходимую для полноценного использования функционала мобильного приложения». Примечательно, что далее в техническом задании про личный кабинет ни слова не говорится. То есть разработчик должен изобретать его на свой страх и риск в надежде, что заказчик впоследствии не станет назначать виноватых.
Опыт контрактных отношений в области информационных технологий научил поставщиков по-разному обходить такие подводные камни. Практически везде в лицензионных соглашениях стоит пункт, что разработчик ПО не несет материальной ответственности за возможный причиненный ущерб. Однако эффективности государственным закупкам это не добавляет.
С точки зрения поставщика ситуация выглядит следующим образом: в закупке заявлен базовый функционал и он должен работать. Все остальное – это вечные доработки «хотелок», о которых в контракте не сообщается. Более того, практически всегда новый функционал несет новые проблемы, связанные с ошибками в программировании и сложностями интеграции одного ПО с другим.
В идеале – техническое задание на создание пользовательского интерфейса должно описывать исполняемую последовательность работы пользователя, – что позволило бы разработчику просто двигаться по пунктам при исполнении контракта. Однако написать такое ТЗ – тяжелый многомесячный труд, подразумевающий глубокое понимание процесса его автором. Такого погружения в тему у заказчика может не быть априори.
Комментируя новость о проблемах с софтом для Минфина, специалисты подтверждают: составить четкое исчерпывающее ТЗ – равносильно тому, чтобы выполнить 50% работы разработчика. Продумать логику работы ПО, учесть все нюансы и тонкости, причем денег за такую детализацию никто составителю ТЗ не платит. Как следствие – получаются провальные контракты.
Если речь идет о сложном ПО, то компетенции заказчика, как правило, недостаточно, чтобы составить качественное техзадание. А значит, для составления качественного ТЗ заказчик должен иметь возможность абсолютно легально обратиться к помощи со стороны. Как это давно происходит в иных отраслях экономики – например, в строительстве. Для этого логично предусмотреть выделение средств не только на закупку/разработку ПО, но и на закупку услуг по составлению ТЗ.
Для всех очевидно, что заказчик не должен сам разрабатывать смету на строительство объекта, большинство заказывают смету у сторонних фирм. Аналогичная практика востребована и в области разработки софта, где техническое задание зачастую бывает намного сложнее, чем строительная смета.
Кассовое неведение – бюджетная слепота
Отдельный вопрос – адекватность финансовых обоснований проектов в IT.
В других отраслях российской экономики применяются методики расчета начальной максимальной цены (НМЦК). К этим методикам имеется масса вопросов и претензий. Но, по крайней мере, они существуют и выполняют свою функцию. В сфере информационных технологий ничего похожего на нормирование не предполагается даже в перспективе. И это также связано с отсутствием отчетливых требований к техническим описаниям, с отсутствием четких KPI. В IT не существует целевых продуктов, поэтому невозможно рассчитать референтную стоимость работ по их созданию.
Москва – единственный субъект РФ, где попытались унифицировать подходы к созданию ПО, чтобы сделать эту область более подотчетной для оценки целевого расходования государственных средств.
У каждой информационной системы, закупаемой в столице на деньги бюджета, в обязательном порядке должен быть Паспорт, содержащий Методику эксплуатации системы, а также детализацию расходов на ее содержание (в день, в месяц, в год). Такие формальные рамки, априори выставленные и к заказчикам, и к разработчикам помогают избежать неясностей с пользой закупки, в том числе и кривых толкований ТЗ. Конечно, они не являются панацеей от коррупционных сделок, но это шаг к дальнейшей стандартизации в IT. Что, безусловно, скажется и на качестве контрактов.
Автор: Андрей Троянский
Комментариев пока нет