Юридические и организационные проблемы
Знакомство с юридическими и организационными неувязками в ходе исполнения госконтрактов вновь ставит перед нами вопрос: чего здесь больше – злого умысла или неаккуратности г-на Осина? Обозначим только некоторые из проблем.
О разделении «законодательной» и «судебной» власти
В конкурсах, посвященных воплощению в жизнь концепции ОМС, постоянно воспроизводится юридически крайне сомнительная практика. Г-н Осин выступает в трех ипостасях одновременно:
- Законодатель, который пишет концепцию и технические спецификации;
- Судья, решающий, соответствует ли то или иное исполнение контракта его представлениям и не стесняющийся на ходу менять правила игры;
- Участник конкурса, якобы в честной борьбе соревнующийся с остальными.
Налицо очевидное нарушение принципов честной конкуренции, которым г-н Осин пользуется без лишнего смущения:
Мы видим, как участник конкурса пишет техническое задание под себя, заведомо обеспечивая себе преимущество – можно не требовать того, что делать не умеешь, и, наоборот, акцентировать работы на тех областях, которые тебе ближе. При написании техзадания можно не только помогать своей организации, но и выставлять искусственные препятствия «чужим». «Искусственные» – значит не оправданные с точки зрения поставленной задачи (обеспечить интерактивность, мультимедийность и т.д.), а то и прямо вредящие достижению декларируемой цели. Разработчик не может воспринимать контракт так, как это полагается по закону – как четкое руководство к действию. Даже если все работы будут выполнены в соответствии с условиями технического задания, «научный консультант» может в любой момент «изменить трактовку» и усилить запреты, объявив какие-то действия другого участника конкурса незаконными. Можно также поступить и наоборот – уже после подписания контракта «изменить трактовку» и ослабить запреты, объявив действия, противоречащие УТР, корректными.
Наглядный пример – разобранная выше трактовка категории «открытость», полностью дезавуирующая грозные слова о запрете на использование закрытого кода, изложенные в техническом задании конкурса. Наконец, для усиления драматического эффекта, вносимые изменения совсем не обязательно не то что обсуждать с разработчиками, но даже просто доводить до всех участников конкурса на равных основаниях.
Наглядный пример – о существовании некоторых «разъясняющих документов» (например, упомянутого изменения определения «открытости» или пояснений к трактовке уровня интерактивности) некоторые разработчики узнали только на этапе сдачи готовых модулей.
Полезно один раз увидеть, как г-н Осин с видом римского императора торжественно объявляет: «УТР – это закон!», а затем, ничуть не смущаясь, добавляет «но возможны его толкования». Сразу становится понятно, что закон – это сам г-н Осин, а подписанные контракты – не более чем его тень.
Технические спецификации не обеспечивают высокого качества работ
Г-н Осин приводит следующие цифры: из 10.000 ЭУМов, сданных в 2006-2007 гг., 65% выполнены с нарушением «Унифицированных требований». Почему так получилось? Александр Васильевич склонен во всем винить недобросовестных разработчиков и невнимательных экспертов, принимавших работу. Мы же склоняемся к мысли, что в числе основных причин некачественного выполнения работ следует выделить следующие:
Унифицированные требования содержат целый ряд непродуманных базовых принципов. В частности, г-н Осин не предусмотрел требований по кроссплатформенности (и это в 2006 году!) – в результате не менее трети уже готовых модулей придется переделывать.
Не будем повторяться о несовместимости модулей с интернет и международными стандартами – эту проблему нам еще предстоит расхлебывать через несколько лет, когда г-н Осин окончательно заведет ситуацию в тупик. Техническое задание написано слабо, многие положения неконкретны и допускают различные трактовки – что путает разработчиков и экспертов, но зато позволяет «научному консультанту» регулярно вмешиваться в процесс и доказывать свою незаменимость как толкователя сакральных смыслов. Многие технологические требования технического задания обусловлены не необходимостью достижения поставленных потребительских свойств продукта, а субъективными предпочтениями и низкой технологической компетентностью г-на Осина – и поэтому менее эффективны, чем предлагаемые разработчиками. Необходимое для эффективной работы программное обеспечение создается со значительным опозданием и работает с ошибками. Прежде всего это касается основного инструмента – ОМС-плеера, который не избавлен от ошибок и сейчас, три года спустя. Кроме того, до сих пор не реализован функционал сохранения оценок, создания образовательных траекторий и т.п. – вообще ничего из обещанных возможностей системы управления контентом.
В целом же, претензии г-на Осина к «недобросовестным разработчикам» (которые смогли удовлетворить формальным требованиям технического задания, но при этом как-то «извратили идею») или к экспертам (которые мучительно пытаются выделить четкий алгоритм оценки из невнятных положений техзадания) следует вернуть автору унифицированных требований. Составляйте детальные и продуманные технические задания, предоставляйте качественные образцовые примеры, обеспечивайте нормальное функционирование базовых программных компонент – или будете обречены на постоянное латание дыр и неубедительные результаты.
Читать дальше >>
|
