Как выбрать софт из реестра, чтобы через год не переделывать

MAATRIX

Закупка почти всегда идёт под дедлайн: нужно закрыть требование к определённому сроку, а не выстроить архитектуру на пять лет вперёд. В итоге выбирают продукт, у которого просто есть нужная запись в реестре — и через год-два выясняется, что он не тянет нагрузку, не с кем его поддерживать или не стыкуется с остальной инфраструктурой. Переделка обходится дороже, чем изначально более вдумчивый выбор. Ниже — на что смотреть до подписания договора, чтобы не оказаться в этой ситуации.

Что на самом деле означает запись в реестре

Реестр отечественного софта — это подтверждение формального статуса продукта: происхождение прав, соответствие критериям для попадания в перечень, доступность для закупки с использованием преференций. Он не говорит ничего о том, насколько продукт зрелый, насколько активно его развивают и что будет с ним через два-три года эксплуатации.

Это принципиально разные вопросы. Реестр отвечает на вопрос «можно ли закупить это на бюджетные деньги или в рамках требования по импортозамещению». А эксплуатация отвечает на вопрос «будет ли это работать, обновляться и поддерживаться, пока вы им пользуетесь». Между этими двумя вопросами может быть большой разрыв — продукт формально в реестре уже несколько лет, но команда разработки за это время сократилась до двух человек, а последний значимый релиз вышел полтора года назад.

Практический вывод: запись в реестре — это фильтр на входе, а не критерий выбора. После того как вы отфильтровали доступные варианты по факту наличия в реестре, начинается настоящая работа — сравнение оставшихся кандидатов между собой уже по критериям зрелости, совместимости и рисков, которые реестр не проверяет. Мы уже разбирали похожую тему с другого угла — что для вас как клиента практически означает статус в реестре у самого хостинг-провайдера — в статье хостинг-провайдер в реестре: что это меняет; логика та же: формальный статус и практическая готовность — не одно и то же.

Зрелость продукта: разработка, команда поддержки, темп релизов

Зрелость продукта — самый недооценённый критерий на этапе закупки, потому что её сложнее всего проверить по документам. Вот что реально стоит выяснить перед тем, как остановиться на конкретном варианте.

История релизов. Попросите у вендора changelog за последние год-два, а не только маркетинговую презентацию с roadmap на будущее. Разница между продуктом, который выпускает патчи безопасности раз в месяц, и продуктом, где последний релиз был десять месяцев назад, — это разница между «живым» и «замороженным» софтом. Замороженный продукт может формально работать, но накапливающиеся уязвимости никто не закрывает.

Размер и структура команды поддержки. У вендора с двумя разработчиками на весь продукт и у вендора с отдельной командой поддержки, отдельной командой разработки и SLA на инциденты — принципиально разная устойчивость. Прямо спросите на переговорах: сколько человек в команде поддержки, какой у них регламент реакции на критичный инцидент, есть ли эскалация за пределами первой линии. Честный вендор ответит конкретно; уклончивый ответ — сам по себе сигнал.

Финансовая устойчивость компании-разработчика. Небольшой стартап может делать отличный продукт, но если у него нет диверсифицированной выручки и один крупный контракт формирует половину дохода, риск ухода с рынка выше, чем у зрелой компании с десятками клиентов. Проверить это напрямую сложно, но косвенные признаки есть: сколько лет компания на рынке, растёт ли штат по открытым вакансиям, упоминается ли она в открытых новостях о финансировании или, наоборот, о сокращениях.

Открытые баг-трекеры и форумы сообщества. Если у продукта есть публичный трекер задач или форум, посмотрите на него не как на рекламу, а как на диагностику: сколько открытых issue висит без ответа месяцами, отвечают ли разработчики сами или это делает community, есть ли живое обсуждение реальных проблем эксплуатации, а не только вопросы новичков.

Совместимость с вашим стеком: где чаще всего рвётся

Продукт может быть отличным сам по себе и при этом плохо стыковаться с тем, что у вас уже развёрнуто. Совместимость проверяется не по списку поддерживаемых ОС на сайте вендора, а по конкретным сценариям использования.

Первое, что стоит проверить, — интеграции через открытые протоколы и API, а не только через проприетарные коннекторы самого вендора. Если продукт умеет отдавать данные по стандартному протоколу (например, LDAP для каталога пользователей, SMTP/IMAP для почты, стандартный SQL-диалект для СУБД), у вас остаётся пространство для манёвра — можно менять соседние системы, не переписывая интеграцию с нуля. Если единственный путь интеграции — закрытый API конкретного вендора, вы привязываетесь не только к продукту, но и к темпам развития именно этого API.

Второе — реальное тестирование на копии рабочей нагрузки, а не на демо-стенде вендора. Демо-стенды почти всегда показывают продукт в идеальных условиях: чистая база, немного пользователей, стандартный сценарий. Разверните продукт в тестовом контуре, залейте туда копию реальных данных (с обезличиванием, если это персональные данные) и прогоните типичные для вашей компании операции — не «работает ли вход в систему», а «отрабатывает ли отчёт, который у вас строится каждый месяц и раньше занимал три минуты».

Третье — совместимость по железу и виртуализации. Если у вас уже стоит определённая система виртуализации, стоит заранее уточнить, официально ли продукт её поддерживает или работает «как получится». То же самое с архитектурой процессора: часть отечественного софта разрабатывалась и тестировалась в первую очередь под определённые платформы, и производительность на других может ощутимо отличаться — это стоит проверить бенчмарком на своей нагрузке, а не поверить характеристикам из презентации.

Четвёртое — совместимость по времени, а не только по факту на сегодня. У вас наверняка есть план обновления соседних систем на ближайшие год-два — переход на новую версию СУБД, смену почтового сервера, обновление ОС. Спросите у вендора, тестировал ли он совместимость со следующими мажорными версиями смежных систем или хотя бы декларирует ли такие планы в roadmap. Если нет — закладывайте риск, что через полгода после вашего апдейта соседней системы продукт может перестать работать штатно.

Кадры: сколько стоит найти и удержать специалиста под конкретный продукт

Даже отличный продукт бесполезен, если его некому администрировать. Этот пункт due diligence часто пропускают на этапе закупки, а расплачиваются за него уже в эксплуатации, когда специалист увольняется и замену найти не получается месяцами.

Практический способ оценить доступность специалистов — посмотреть открытые вакансии на рынке труда по названию продукта или платформы за последние несколько месяцев. Если вакансий системно нет или их единицы на всю страну — это сигнал, что при уходе текущего администратора вы либо переплатите за редкого специалиста, либо будете обучать нового человека с нуля за свой счёт и время. Второй способ — прикинуть стоимость обучения: у вендора часто есть официальная сертификация или курсы, и стоимость такого обучения — это тоже часть совокупной стоимости владения продуктом, которую редко считают на этапе закупки.

Отдельно стоит оценить документацию — не маркетинговую, а техническую. Хорошая техническая документация с описанием архитектуры, вариантов конфигурации и типичных проблем эксплуатации снижает зависимость от конкретного человека: новый администратор может разобраться сам, а не только через звонок в поддержку вендора. Если документация состоит из десятка PDF-страниц с описанием интерфейса и всё остальное «узнаётся у менеджера вендора» — это дополнительная зависимость, которую вы явно не увидите в договоре, но ощутите в первый же критичный инцидент в нерабочее время.

Держите в голове и обратную сторону: чем более нишевый продукт, тем выше стоимость специалиста, но и тем меньше конкуренция за него — иногда это может быть аргументом в пользу компании, а не против неё, если вы готовы инвестировать в удержание одного-двух ключевых людей. Это управленческое решение, а не универсальное правило, но оно должно приниматься осознанно, а не как побочный эффект закупки.

Вендор-лок без права на манёвр: как не остаться с одним поставщиком

Вендор-лок — это не сам факт зависимости от конкретного продукта (в какой-то мере она есть всегда), а отсутствие реалистичного пути выхода, если продукт перестанет вас устраивать. Стоит различать два уровня риска.

Лок на уровне продукта. Если продукт хранит данные в закрытом формате без экспорта, использует нестандартные протоколы для всего стека и не даёт полного дампа данных без участия вендора — переход на альтернативу превращается в отдельный проект с непредсказуемой стоимостью. Перед покупкой прямо спросите: как выглядит процедура экспорта всех данных в открытом формате, есть ли это в документации или только на словах у менеджера по продажам. Попросите продемонстрировать экспорт на тестовом стенде — это можно сделать до подписания договора, и добросовестный вендор не будет от этого уклоняться.

Лок на уровне рынка. Даже если у продукта нет технических барьеров для миграции, проблема возникает, если в вашей категории на рынке реально доступен только один зрелый вариант в реестре. Тогда переход теоретически возможен, но практически некуда — вы либо остаётесь с текущим вендором на любых условиях, которые он выставит при продлении, либо мигрируете на продукт, который сам ещё не прошёл проверку зрелостью. Это стоит явно проговаривать на этапе выбора: сколько реальных, а не формальных, альтернатив есть в этой категории прямо сейчас, и что произойдёт с вашими условиями договора, если единственный конкурент вендора уйдёт с рынка или тоже прекратит развитие.

Отдельная история — риск исчезновения продукта из реестра как такового: критерии включения периодически пересматриваются, и продукт, который сегодня формально в перечне, через год может из него выпасть по формальным причинам, даже продолжая физически работать у вас. Мы разбирали похожий сценарий на примере пакета, который убрали из репозитория и это остановило сборку прод-окружения, — в статье пакет удалили из реестра, и прод перестал собираться. Логика переносится и сюда: закладывайте план на случай, если формальный статус продукта изменится, а не только на случай технической поломки.

Практическая мера снижения риска — не завязывать архитектуру полностью на один продукт там, где это возможно. Например, если продукт закрывает узкую функцию (антивирусная защита, документооборот, резервное копирование) и есть возможность держать интеграцию через стандартный протокол или формат, а не через глубокую проприетарную привязку — выбирайте этот путь, даже если он на старте немного менее удобен. Это прямая инвестиция в возможность смены поставщика без переписывания половины инфраструктуры.

Чек-лист due diligence перед выбором

Соберите ответы на эти пункты до подписания договора, а не после первого инцидента в проде.

Зрелость продукта:

• [ ] Есть changelog за последние 12–24 месяца с регулярными релизами, включая патчи безопасности
• [ ] Известен размер и структура команды поддержки, есть письменный SLA на реакцию по инцидентам
• [ ] Компания-разработчик на рынке от нескольких лет, нет явных признаков ухода ключевых людей
• [ ] Публичный баг-трекер или форум показывает живую активность, а не заброшенные обсуждения

Совместимость:

• [ ] Продукт протестирован на копии реальной нагрузки, а не только на демо-стенде вендора
• [ ] Поддерживаются открытые протоколы интеграции, а не только закрытый API вендора
• [ ] Официально подтверждена совместимость с текущей системой виртуализации и архитектурой процессора
• [ ] У вендора есть публичный или хотя бы озвученный план поддержки следующих версий смежных систем

Кадры:

• [ ] На рынке труда за последние месяцы реально встречаются вакансии по этому продукту или платформе
• [ ] Есть официальная программа обучения или сертификации с понятной стоимостью
• [ ] Техническая документация покрывает архитектуру и типичные проблемы эксплуатации, а не только интерфейс

Вендор-лок:

• [ ] Есть подтверждённая на тестовом стенде процедура полного экспорта данных в открытом формате
• [ ] В этой категории на рынке есть минимум ещё один зрелый вариант в реестре — не только формально, но и по факту готовности
• [ ] Продукт не является единственной точкой отказа для критичной функции без резервного плана

Если по итогам чек-листа продукт набирает много незакрытых пунктов, но формально подходит под требование — это повод обсудить с закупкой не отказ от требования, а более осознанный выбор среди доступных в реестре вариантов, а не первого попавшегося.

Частые вопросы