Сделать аналог — только начало: считаем TCO решения

В МГТУ им. Баумана, где я учился, есть галерея инженеров и изобретателей. Она напоминает о ценности собственного инженерного решения. Но в реальном продукте создавать всё с нуля было бы не зрелостью, а дорогой крайностью.

Переиспользование, совместимость и адаптация — нормальные стратегии. Ошибка начинается, когда стоимость решения считают только до первого релиза и не различают продукт, форк, совместимую реализацию и новую разработку.

Четыре разных стратегии

Использовать готовый продукт

Команда принимает архитектуру и roadmap поставщика или open-source проекта, получает документацию, обновления и экосистему. Главные вопросы — лицензия, поддержка, цепочка поставки, требования к инфраструктуре и план выхода.

Поддерживать форк

Исходный код остаётся узнаваемым, но локальные изменения расходятся с upstream — исходным проектом, от которого сделано ответвление. Форк оправдан, когда дельта невелика, у неё есть владелец и команда умеет регулярно переносить исправления из основной ветки.

Построить совместимую реализацию

Новый продукт сохраняет внешний протокол, API или формат данных. Это уменьшает стоимость миграции потребителей, но переносит на команду ответственность за все наблюдаемые особенности контракта, включая пограничные случаи.

Спроектировать новое решение

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

Эти стратегии нельзя честно сравнить одной строкой «сделать или купить».

Что входит в TCO

Я раскладываю полную стоимость владения на пять частей:

TCO = запуск + эксплуатация + изменения + риски + выход

Это не бухгалтерская формула до рубля, а структура решения.

1. Запуск

• лицензии и закупка;
• разработка или адаптация;
• миграция данных и интеграций;
• инфраструктура, тестирование и обучение;
• прохождение требований безопасности и compliance.

2. Эксплуатация

• вычислительные ресурсы и хранение;
• мониторинг, резервное копирование и recovery;
• дежурство и поддержка пользователей;
• устранение уязвимостей и обновление зависимостей;
• воспроизводимая сборка и supply-chain controls.

3. Изменения

• перенос исправлений из upstream;
• развитие локальных функций;
• совместимость с новыми версиями клиентов;
• обновление коннекторов, SDK и документации;
• регрессионное и нагрузочное тестирование.

4. Риски

• зависимость от поставщика или нескольких ключевых инженеров;
• лицензирование и право распространять производные;
• отставание по security fixes;
• несовместимость с целевой инфраструктурой;
• расхождение локального поведения с исходным продуктом.

5. Выход

• возможность выгрузить данные в открытом формате;
• стоимость замены API и интеграций;
• срок параллельной эксплуатации;
• наличие компетенций для миграции;
• обратимость архитектурных решений.

Последний блок часто забывают, хотя именно он определяет будущую свободу выбора.

Почему форк дорожает незаметно

Локальный патч легко принять, но каждый следующий upgrade должен ответить на три вопроса:

1. Сохранилась ли причина патча?
2. Не решил ли upstream проблему иначе?
3. Не конфликтует ли изменение с новой архитектурой продукта?

Без реестра локальных изменений команда постепенно теряет ответы. Новый специалист знает исходный продукт, но сначала изучает отличия форка. Security fix нельзя перенести автоматически. Коннектор формально совместим, но ломается на локальном поведении.

Управляемый форк поэтому требует:

• владельца и понятного lifecycle;
• реестра патчей с причиной и тестом;
• регулярной синхронизации с upstream;
• по возможности возврата общих исправлений в upstream;
• автоматических compatibility и regression tests;
• срока реакции на критические уязвимости;
• плана сокращения локальной дельты.

Если этих практик нет, первоначальная экономия превращается в скрытый backlog сопровождения.

Совместимость тоже имеет цену

Совместимая реализация должна повторять не только happy path. Потребители могут зависеть от порядка полей, кодов ошибок, поведения при повторе, ограничений размера и даже давно не документированного edge case.

Поэтому «поддерживаем тот же API» — проверяемое требование. Нужны:

• формализованный контракт;
• набор эталонных запросов и ответов;
• тесты негативных сценариев;
• правила версионирования;
• перечень осознанных отличий;
• миграционный режим для реальных потребителей.

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

Когда собственная разработка оправдана

Я бы рассматривал её, если одновременно выполняются несколько условий:

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

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

Как я формулирую решение руководителю

Вместо «мы сделали свой аналог» полезнее сказать точнее:

• адаптировали продукт и сохранили совместимость с upstream;
• поддерживаем форк с такой-то локальной дельтой;
• реализовали совместимый контракт и проверили миграцию потребителей;
• создали новый компонент ради конкретного ограничения;
• снизили зависимость за счёт открытого формата и плана выхода.

Такая формулировка не уменьшает достижение. Она показывает, чем команда действительно владеет и какой счёт останется после запуска.

Технологическая независимость для меня — не процент собственного кода. Это способность эксплуатировать, защищать, развивать и при необходимости заменять решение без потери продукта.

---

Впервые опубликовано в моём Telegram-канале @it_underside.

Ваш ДПУПП