Трудности, с которыми столкнулись российские специалисты в рамках импортозамещения в сегменте инфраструктурного программного обеспечения, не являются уникальными. Опыт решения подобных задач есть в других странах. Участники заочного круглого стола обращают внимание на основные тенденции в этой сфере и анализируют риски, преимущества и недостатки возможных моделей, стимулирующих инструментов и вариантов поддержки отечественных разработчиков. При всем разнообразии точек зрения эксперты единодушны в том, что при выборе подходов к замещению импорта необходимо учитывать уровень технологического развития государства, общества и бизнеса.
В круглом столе принимают участие:
 Валерий БОРДЮЖЕ, председатель Координационного совета по информационным технологиям предприятий оборонно-промышленного комплекса |
 Юрий КУЗЬМЕНКО, руководитель отдела исследований и разработки, «Энвижн Груп» |
 Илья БЕЛОВ, ведущий менеджер по развитию департамента инфраструктурных решений ГК Softlin |
 Александр ЗАЦАРИННЫЙ, заместитель директора ФИЦ ИУ РАН, д. т. н., профессор, член КС ИТ ОПК |
 Александр ГОЛИКОВ, председатель совета директоров ГК «АСКОН», основатель компании, председатель правления АРПП «Отечественный софт» |
 Виталий МАКСИМОВ, заместитель генерального директора по маркетингу, Группа компаний «Релэкс» |
 Алексей КАЗАРЕЗОВ, директор ЦИТК «Парус» |
 Ольга ТЫРНОВСКАЯ, вице-президент по работе с вендорами, группа «Астерос» |
Некоторые эксперты сегодня критикуют Реестр отечественного ПО, указывая, в частности, на тот факт, что большинство продуктов, внесенных в список, можно использовать только на Windows и с базами данных SQL и Oracle. Насколько обоснована такая критика?
Илья БЕЛОВ
Небезосновательна. Существуют разработки под Windows, но это более старые продукты. Новые системы дорабатываются так, чтобы уйти от этого. Также в Реестр попадают решения, производительность которых не рассчитана на enterprise-сегмент.
Валерий БОРДЮЖЕ
Критика обоснована. Из более чем трех тысяч единиц зарегистрированного отечественного ПО большая часть функционирует на иностранном системном обеспечении. Вместе с тем факт существования реестра позитивен, так как может служить хорошей базой для отбора программных продуктов с повышенными требованиями к информационной безопасности. Например, потребители, представляющие интересы предприятий ОПК, критически важных объектов и другие специализированные структуры, вполне могут повысить ведомственные требования к ПО по безопасности и закупать только те продукты, которые полностью их устраивают.
Александр ЗАЦАРИННЫЙ
Действительно, по нашим данным, не просто большинство, а подавляющее большинство программных продуктов, зарегистрированных в Реестре отечественного ПО, разработано на платформе Windows с СУБД SQL и Oracle. И такое положение объективно отражает реальное состояние дел, поскольку указанное базовое ПО предоставляет разработчикам прикладного ПО наилучшие условия для выполнения необходимых этапов разработки, тестирования, документирования, проверки и сертификации. Нельзя не учитывать и накопленный опыт работы информационных систем в программной среде Windows во многих ФОИВ и коммерческих структурах. Поэтому вопрос по поводу обоснованности критики Реестра не совсем корректен; более актуальным является вопрос о степени доверенности программных продуктов, зарегистрированных в Реестре, которая должна подтверждаться документами от соответствующих экспертных организаций. Регистрация должна проводиться только при наличии таких документов в соответствии с требованиями к конкретному программному продукту, включая требования по информационной безопасности.
Александр ГОЛИКОВ
Что тогда, по мнению указанных экспертов, использовать? Отечественных ОС и СУБД такого класса сегодня нет. Для построения коммерческих высокотиражных продуктов важны не просто наличие отечественных ОС и СУБД, а их надежность, быстродействие, способность работать под большой нагрузкой, удобные инструменты разработчиков ПО и многое другое. Никто не мешает вкладываться в развитие того же Postgre, формируя мощный центр компетенции, постепенно переводя на него критичные с точки зрения инфобезопасности задачи.
Алексей КАЗАРЕЗОВ
Наверное, разные эксперты по-разному представляют цели создания Реестра отечественного ПО. Вероятно, есть эксперты, считающие, что в Реестр должно быть включено ПО, использующее только непроприетарные компоненты либо компоненты отечественной разработки и желательно поддерживающее отечественные аппаратные платформы. Да, такие эксперты могут быть не удовлетворены. Мы же придерживаемся более прагматичной позиции: Реестр должен способствовать приоритетному применению отечественного ПО в госкомпаниях и предотвращать немотивированное использование зарубежных аналогов. Этой цели Реестр отечественного ПО соответствует. Вероятно, со временем требования по включению ПО в Реестр могут пересматриваться.
Юрий КУЗЬМЕНКО
И да, и нет. С одной стороны, в России широко распространена система Windows. Именно эта система используется как основная на большинстве государственных и коммерческих предприятий. По этой причине большая часть ПО разрабатывалась под эту систему. С другой стороны, в Реестре также представлено и кроссплатформенное ПО, что в последнее время является трендом.
По поводу баз данных можно сказать, что часть ПО использует ORM и, как следствие, может работать с базами данных, отличными от Oracle и MS SQL. В Реестре, кстати, представлена Postgres Pro, российская ветка популярной базы данных PostgreSQL, которая составляет достойную конкуренцию реляционным СУБД от Oracle и Microsoft. Также необходимо отметить, что в последнее время все большую популярность приобретают базы данных NoSQL, которые преимущественно являются проектами open sourсе.
Виталий МАКСИМОВ
Прежде чем отвечать на этот вопрос, нужно задать другой: с какой целью создавался этот Реестр? Если целью было зафиксировать все написанные российскими разработчиками программы – это одно. Если же целью было обеспечить технологическую независимость от иностранного ПО – совсем другое. Можно ли говорить о кибербезопасности страны, когда государственные информационные системы работают на иностранных СУБД, которые официально спонсируются Минобороны США? Может ли считаться отечественной операционная система, исходный код которой заимствован у того же Linux? Чтобы система была признана по-настоящему отечественной, она не только должна быть написана с нуля нашими разработчиками, но и вся инфраструктура (аппаратно-программная среда) должна быть отечественной и безопасной. Только так крупнейшие государственные компании могут спокойно работать, не боясь иностранных программных закладок и уязвимостей. Мы в «Релэксе» считаем, что только проприетарное ПО может быть безопасным, потому что мы как налоговый резидент РФ несем ответственность перед заказчиками и государством за каждую строчку кода в нашей СУБД.
Ольга ТЫРНОВСКАЯ
Реестр формируется по определенным правилам, его цель – поддержка отечественных программных продуктов. Если есть нарушения, то необходимо их устранять, если нет, то вопросы надо задавать разработчикам, почему они выбирают те или иные платформы. Реестр будет полезен при наличии конкурентоспособных продуктов. Если российские разработки не будут отвечать требованиям заказчиков, сам факт существования Реестра никого не спасет.
Какие сложности возникают при портировании наиболее популярных в России бизнес-приложений на отечественные/открытые ОС и СУБД?
Илья БЕЛОВ
Основная сложность – совместимость с бизнес-критичными приложениями заказчика и техническая поддержка. SAP ERP Business Suite, Siemens PLM и другие решения, аналогов которых нет в России, требуют Oracle или IBM DB2 как СУБД. Соответственно, если мигрировать их на отечественные СУБД, то даже при сохранности функциональности приложения не будет поддержки от вендора. А чтобы обеспечивать бесперебойное функционирование таких сложных высоконагруженных систем, важно своевременно получать консультации разработчиков.
Отмечу, что если перед заказчиком стоит реальная, а не формальная задача по импортозамещению, то нельзя хаотично подходить к вопросу, менять отдельные решения и компоненты. Нужно подготовить подробный план, а перед этим провести аудит. Прописать архитектуру решений (серверы, СХД, ПО), а потом спроектировать ее на отечественном программном обеспечении. При этом критичные системы, например Siemens SAP, не затрагиваются. В итоге заказчик получает отчет, в котором отражены сведения об имеющемся оборудовании, план перехода на другие решения, возможные риски. При наличии четкого плана развития инфраструктуры можно сделать процесс более эффективным.
Александр ЗАЦАРИННЫЙ
Принципиальных технических сложностей нет. Но! Часто портирование трактуется как некий перенос уже разработанного в среде Windows программного продукта в среду открытого ПО (варианты Linux). При этом понимания того, что такой перенос – по существу, трудоемкий процесс создания нового программного продукта со всеми вытекающими последствиями (трудозатраты, сроки и финансирование), как правило, не проявляется. Если называть вещи своими именами, портирование – это разработка программного комплекса, которая должна определяться тремя классическими параметрами: заданием, сроками и деньгами. Новое задание потому, что со временем у заказчика, естественно, появляются потребности в новых приложениях, а в некоторых прежних необходимость отпадает. Очевидно, что разработчик исходного программного продукта выполнит такую работу более качественно, быстрее и, может быть, дешевле, чем новый исполнитель. А технических трудностей, действительно нет. Не хватает истинного понимания существа портирования ПО.
Александр ГОЛИКОВ
Риск потери быстродействия. Хотя все зависит от задачи. Но самое главное: зачастую архитектура построения системы может не позволить просто портировать приложения – может потребоваться серьезная переработка программного продукта. Также надо понимать, что во время работы над портированием бизнес-приложений на отечественные/открытые ОС и СУБД разработчик не занимается наращиванием их пользовательской функциональности.
Юрий КУЗЬМЕНКО
При портировании на открытые ОС бизнес-приложений, написанных на Java, таких сложностей не возникает. Это касается и приложений, написанных на скриптовых языках (JavaScript, Python и т. д.). Причем большинство приложений, написанных на этих языках, уже портированы на Linux-системы.
Что касается приложений, написанных на C#, то в последнее время одной из приоритетных задач разработчиков платформы .Net компании Microsoft является именно кроссплатформенность. К сожалению, не все так быстро, как хотелось бы. На данный момент .Net Core является кроссплатформенной системой с открытым исходным кодом. Существуют соответствующие рекомендации от вендора по миграции на .Net Core, пользуясь которыми наши Net-разработчики уже перевели часть приложений на .Net Core, и теперь эти приложения могут работать на Linux-системах. Правда, нельзя сказать, что это был простой и гладкий процесс.
Основной проблемой при портировании приложений, написанных на C++, является использование библиотек, которые работают исключительно под Windows. В некоторых случаях возникает необходимость писать отдельное приложение для другой платформы, переходить на другую среду разработки, например Qt, или смотреть в сторону Java, если быстродействие не является настолько критичным.
Что касается портирования на открытые СУБД, то часть приложений взаимодействует с базой данных посредством ORM. В таких случаях портирование на открытые СУБД не вызывает особых проблем, а скорее является легкой настройкой. Другая же часть приложений не использует ORM, так как применение ORM в некоторых случаях – дополнительная нагрузка на приложение и причина потери быстродействия. Кроме того, ORM не позволяют использовать специфические возможности, которые существуют в определенной СУБД и являются причиной ее выбора при разработке. В подобных случаях при портировании приходится отказываться от этих возможностей, искать новые пути решения, возможно, менять логику, переписывать хранимые процедуры, функции, триггеры и т. д. Этот вопрос особенно актуален, когда большая часть логики приложения находится в СУБД.
Помимо технических существуют вопросы, связанные с формированием новой экспертизы, переподготовкой специалистов. Процесс обучения и адаптации занимает месяцы.
Виталий МАКСИМОВ
Понятные технические проблемы связаны с переносом больших объемов данных, переписыванием исходного кода приложений, неизбежностью остановки бизнес-процессов клиента в период внедрения и т. д. Немаловажен и фактор времени: далеко не все заказчики понимают, что миграция приложений – сложная техническая задача, решение которой может длиться несколько лет. Все эти проблемы вполне решаемы, другое дело – убедить заказчика в том, что весь функционал и производительность импортных продуктов нужны далеко не всегда. Например, пользователи привыкли к моментальному отклику приложений на их действия и не готовы к снижению производительности, даже если оно будет временным и не отразится на бизнесе. Следует признать, что отечественных продуктов, которые могут обеспечить аналогичные иностранному ПО скорость и функциональность, сегодня нет. Для их появления необходимо партнерство другого порядка: когда заказчик готов обеспечивать разработчика задачами, которые дают развитие продукту. У нас есть многолетний опыт сотрудничества с ОАО «Сургутнефтегаз». Начинали с относительно небольших задач, в процессе работы получали обратную связь и дорабатывали нашу СУБД под требования заказчика. В итоге выиграли все стороны.
Стоит отметить также, что много времени отнимает перенос значительного объема данных, больших затрат требуют ручное переписывание кода, необходимость внесения изменений в бизнес-приложения для работы с другой СУБД. Нельзя не учитывать возможные высокие издержки простоя, устаревание системы в процессе разработки.
Ольга ТЫРНОВСКАЯ
На данный момент мы не наблюдаем у наших заказчиков массовых смен платформ и решений, на основании которых можно было бы сделать выводы. Каждый случай является уникальным – со своими задачами и проблемами.
Может ли Россия использовать опыт отдельных европейских стран? Например, во Франции существует система жестких запретов на использование государственными органами зарубежных ОС и СУБД. В Германии и Италии государство субсидирует миграцию муниципальных органов власти на открытое ПО (OS Linux).
Илья БЕЛОВ
Помощь государства была бы своего рода толчком для развития технологий: процесс создания решений может стать более эффективным, это будет одним из способов стимулирования спроса на них. Например, разработок на Linux очень много, но мало инсталляций, а система эволюционирует только тогда, когда она активно используется.
Валерий БОРДЮЖЕ
Должна использовать. И не только европейских стран. В Китае еще в 2014 г. создали национальную ОС, базирующуюся на Linux, и заменили ею Windows на всех компьютерах в правительстве Китая. Для внутреннего рынка в рамках сотрудничества с оборонным научно-техническим университетом Китая также создана операционная система Ubuntu Kylin.
Поскольку ИТ уже давно стали продукцией двойного назначения и приобрели все признаки оружия массового поражения сознания граждан, инфраструктуры государств и технологических объектов, а кибервойны становятся все масштабнее, России, безусловно, следует иметь собственное национальное системное программное обеспечение.
Александр ЗАЦАРИННЫЙ
В России вполне может быть внедрен подобный подход. Дело за малым: ограничить функционал и для него спланировать целевое субсидирование.
Александр ГОЛИКОВ
Разумное решение. У нас серьезным препятствием является то, что основным инвестором создания отечественных ОС и СУБД пока является государство. Это приводит к доминированию подхода: раз государство что-либо финансирует, то права на продукт также должны принадлежать государству. А как, на какие средства дальше будут развиваться созданные ОС, СУБД или программный продукт? Кто будет оплачивать развитие? С нашей точки зрения, это одно из главных препятствий для импортозамещения.
Юрий КУЗЬМЕНКО
В России можно было бы запретить использование государственными органами зарубежных ОС, если бы имелись собственные разработки уровня ведущих мировых аналогов (у нас уже есть неудачный опыт попытки пересадить государственных служащих на отечественные автомобили).
Системы с открытым исходным кодом, на мой взгляд, выглядят предпочтительнее, но уровень экспертизы на сегодняшний день оставляет желать лучшего. Большинство российских средних и высших учебных заведений продолжает использовать и продвигать систему Windows. Крупные российские компании не торопятся спонсировать open source-проекты или как-либо в них участвовать и, что еще хуже, не поощряют, а порой запрещают своим сотрудникам участвовать в таких проектах. Ведущие зарубежные компании, напротив, приветствуют участие своих сотрудников в open source-проектах и сами пытаются поддержать эти проекты, чтобы повысить контроль и уменьшить собственные риски.
В любом случае процесс перехода на open source-системы должен быть плавным, постепенным. Нельзя всех в приказном порядке перевести на open source с завтрашнего дня. Сначала нужно нарастить экспертизу и вовлечь российский бизнес в open source-проекты.
Если говорить о создании государственного ПО в целом, то разработку новых проектов нужно начинать на open source, если его уровень соответствует уровню коммерческих систем. Нужно понимать, что open source-проект сам по себе не является панацеей, важна собственная экспертиза. Как показывает опыт, любой open source-проект так или иначе может быть поглощен крупной компанией или просто перестать существовать, например, open source-проект Titan (графовая база данных) перестал развиваться, а дальнейшее продолжение получил в коммерческой версии DataStax.
Ольга ТЫРНОВСКАЯ
Конечно, может. Именно этим Россия занималась много лет в области ИТ: в результате здесь у нас не самая плохая ситуация. Тем не менее опираться на мировой опыт следует осторожно и избирательно: далеко не всегда нужно следовать зарубежным моделям, тратя ресурсы взамен их развития и не учитывая рисков, заложенных в правила игры зарубежных партнеров. Санкционная политика в отношении России показала, что необходимо искать собственные решения, учитывающие текущий уровень технологического развития государства, общества и бизнеса.
В какой форме осуществляется или будет осуществляться поддержка работы открытых ОС и СУБД? Кто несет или будет нести ответственность за проблемы совместимости? Кто отвечает или будет отвечать за безопасность ОС и СУБД?
Илья БЕЛОВ
Существуют разработки, основанные на открытых дистрибутивах. Специалисты дорабатывают решения, добавляют новые функции, коммерциализируют продукт и продают лицензии. В этом случае ответственность несет вендор. Если заказчик выбирает вариант работы на открытом ПО, то есть два пути развития событий. Первый – внедрять может партнер или заказчик своими силами. А поддерживают систему, если это крупный проект, интеграторы в рамках консалтинга. Заказчик подписывает с подрядчиком многолетний контракт. Здесь важно выбрать надежную компанию с богатой экспертизой. Второй вариант – заказчик сам занимается внедрением и поддержкой. В этом случае он берет на себя ответственность за корректную работу системы и несет все сопутствующие риски.
Александр ЗАЦАРИННЫЙ
Вопрос очень правильный и актуальный. Действительно, проблема не в том, чтобы разработать открытое ПО, которое прибрело бы статус отечественного и стало бы основой для импортозамещения; такую задачу способны выполнить десятки фирм. Проблема в том, как внедрить и, главное, в дальнейшем поддерживать это ПО, и не только поддерживать, но и постоянно развивать с учетом растущих требований самых разных пользователей. Так, как эти процессы организованы в Microsoft, в IBM, в Oracle и ведущих мировых фирмах-лидерах.
У нас подобных коммерческих структур нет. Но поскольку проблема импортозамещения действительно актуальна и поставлена на государственном уровне, то и решаться она должна на соответствующем уровне – организационно и финансово. Тогда и вопросы безопасности будут решены адекватно. Вместе с тем вопрос настолько многогранен, что требует весьма подробного обсуждения с привлечением всех заинтересованных сторон: ФОИВ (прежде всего Минпромторга, Минкомсвязи), корпораций («Росатома», «Ростеха», «Роскосмоса», ОАК и др.), ведущих научных организаций.
Александр ГОЛИКОВ
Необходимо не просто использовать наработки зарубежного репозитория, важно, как минимум, участвовать на равных в развитии продукта, накапливать самостоятельные компетенции для его развития. Еще лучше – создавать отечественные репозитории, что невозможно без решения первого вопроса. Создание отечественного репозитория открытого ПО, а также появление мощного отечественного центра компетенций, занимающегося разработкой, сборкой, тестированием и поддержкой, позволят решить все вопросы, связанные с развитием продукта по подобной модели.
Юрий КУЗЬМЕНКО
Вне зависимости от того, открытая система или коммерческая, разрабатывается и поддерживается она специалистами-разработчиками. Вопрос скорее в наличии таких специалистов. Если смотреть на проблему глобально, то государству необходимо поддержать подготовку/переподготовку кадров. Вопрос на самом деле шире. Он касается не только ОС и СУБД, но и среды разработки, фреймворков, библиотек и т. д.
Что касается проблемы совместимости, то это технический вопрос, который полностью находится в компетенции разработчиков независимо от того, открытая система или коммерческая. Некоторые open source-проекты имеют платную коммерческую поддержку, некоторые – серьезное комьюнити с большим количеством высококвалифицированных специалистов, готовых помочь своим коллегам.
Если говорить про безопасность, то у государства есть службы, отвечающие за безопасность, они и будут отвечать за безопасность ОС и СУБД. Соответствующие кадры у них имеются, а при необходимости они будут привлекать подрядчиков, занимающих ведущие позиции в отрасли.
Ольга ТЫРНОВСКАЯ
Вся полнота ответственности всегда лежит на заказчике системы, и только в рамках договоров она может перекладываться на плечи вендоров и поставщиков. Конкретный производитель и заказчик есть и у ПО с открытым кодом. Вопрос только в том, как производитель будет поддерживать свой программный продукт и хватит ли ему для этого ресурсов.
Существуют две противоположные точки зрения на финансирование разработок ПО. Сторонники одной считают, что лучший вариант процесса импортозамещения следующий: промышленные корпорации получают средства из бюджета, объединяются в пулы и заказывают разработчикам ПО с жестким контролем за выполнением. Сторонники другой предлагают целенаправленно (на уровне государственных проектов) финансировать проекты разработки отечественного ПО, выбранные в силу их важности для решения проблемы импортозамещения. Какая позиция вам ближе и почему? Какая позиция (не обязательно из указанных выше) представляется наиболее реалистичной?
Илья БЕЛОВ
Первая позиция логична, если речь идет о крупном заказчике со специфическими процессами. Например, оборонная промышленность. Но дело в том, что для этой отрасли уже разрабатывается специализированное ПО, которое продается только таким предприятиям и не имеет коммерческой лицензии. Это подход для решения внутренних критичных задач. Во всех остальных случаях мне ближе вторая точка зрения: нужно поддерживать разработчиков, привлекая их к участию в государственных проектах создания отечественного ПО. При наличии таких решений на российском рынке будет формироваться спрос на них, в том числе и у госструктур. Думаю, при целенаправленном финансировании этот процесс будет запущен.
Валерий БОРДЮЖЕ
Оба варианта хороши и реалистичны, но применять их нужно под разные программные продукты. На уровне федеральных целевых программ следует обеспечить финансирование и организовать разработку системного ПО и стратегического прикладного, например, инженерного ПО. Для разработки остального отечественного прикладного ПО вполне приемлем вариант создания пулов заказчиков и формирования государственно-частных партнерств с разработчиками.
Александр ЗАЦАРИННЫЙ
На основании изменений в Федеральный закон «Об информации, информационных технологиях и о защите информации» в апреле 2015 г. Минкомсвязи России утвердило приказ об отраслевом плане замещения импортного программного обеспечения. Документ определяет, каковы к 2025 г. должны быть максимальные доли импорта в различных сегментах программных продуктов. Для импортозамещения программного обеспечения в изделиях специального назначения необходимо открыть ряд работ по развитию программного обеспечения, входящего в состав базовых защищенных информационно-компьютерных технологий (БЗИКТ). На сегодняшний день ряд программных продуктов, входящих в состав БЗИКТ, не соответствуют современным требованиям, а в некоторых областях отсутствуют аналоги ПО.
Александр ГОЛИКОВ
Первая стратегия наиболее близка рыночным компаниям, разработчикам тиражного программного обеспечения. Этот подход разделяет и Консорциум компаний-разработчиков инженерного ПО, куда входят компании «АСКОН», АДЕМ, НТЦ АПМ, «Тесис», «Эремекс». Подобная стратегия позволяет развивать продукты, оставляя их в рынке. Вторую стратегию считаем неработоспособной – она будет генерировать нерыночные продукты со всеми вытекающими последствиями (низкое качество, дороговизна, слабая конкурентоспособность, невозможность жизни в рынке и т. д.). Они будут существовать только в условиях диктата потребителю, а монополизм и конкурентоспособность не живут вместе. Инженерный софт – это не инфраструктурное ПО, «Платон» с ЕГАИС, когда у потребителей нет выбора.
Государство опасается финансировать коммерческие компании, разработчиков тиражного ПО, обладающих как раз максимальным опытом создания рыночных, коммерчески успешных продуктов. Попытки создания госсистем в высококонкурентных сегментах обречены на вечное бюджетное финансирование с принуждением потребителей использовать продукт, который они не выбирали.
Алексей КАЗАРЕЗОВ
Для успеха продвижения любой продукции прежде всего должен быть сформирован целевой рынок, готовый эту продукцию потреблять. Бессмысленно финансировать проекты разработки отечественного ПО без должной мотивации промышленных корпораций к его потреблению. Таким образом, подход, когда промышленные корпорации получают средства из бюджета, объединяются в пулы и заказывают разработчикам ПО, кажется более рациональным.
Юрий КУЗЬМЕНКО
На мой взгляд, на государственном уровне необходимо целенаправленно финансировать разработку отечественного ПО. Промышленные корпорации должны формировать задания на проекты и в конечном счете получать качественное отечественное ПО, полностью удовлетворяющие их нужды.
Заказы необходимо объединять в пулы, чтобы 100 компаний-разработчиков не разрабатывали одно и то же для 100 заказчиков. Должно быть создано одно или несколько типовых решений с самым высоким качеством, а не по самой низкой цене и растиражировано на всю сотню компаний-заказчиков.
Ольга ТЫРНОВСКАЯ
Действительно, эти два подхода наиболее очевидны. Первый («под заказ») основывается на целенаправленном финансировании конкретных разработок. Второй предполагает ориентацию на производителя ПО, который видит потребности рынка, и на привлеченные инвестиционные средства разрабатывает программный продукт.
Но есть и третий вариант, представляющий собой комбинацию первых двух: так или иначе по этому пути пошли все мировые софтверные лидеры. В его основе лежит технологическое лидерство, ведь лидеры – это не только те, кто имеет большую долю рынка, а еще и те, кто наиболее полно может удовлетворить требования заказчиков. Догнать и перегнать лидеров – весьма затратная задача, как по ресурсам, так и по времени. Объединение корпораций в пулы будет малоэффективным, так как неясно, кто именно заказчик и сможет ли разрабатываемое решение удовлетворить потребности каждого из участников. Вызывает сомнение и то, насколько эффективно такой коллективный заказчик сможет ставить задачи и контролировать их выполнение.
По моему мнению, победят энтузиасты из числа разработчиков, и не в разрезе продуктов-аналогов, а в разрезе совершенно новых решений, подходов и инструментов. При этом в краткосрочной и среднесрочной перспективах основные заказчики останутся на продуктах лидеров рынка, если это будет возможно и выгодно для них.
