Заказная или самостоятельная разработка ПО: что выгоднее крупным российским компаниям

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

У самостоятельной и заказной разработки ПО есть свои минусы и плюсы. Нередко компании совмещают эти подходы: базу разрабатывают внутри, а отдельные модули или интерфейсы заказывают на стороне.

Директор по дата-стратегии Arenadata Наджим Мохаммад согласен, что гибридная модель для крупных компаний является оптимальной при разработке ПО.

Наджим Мохаммад

Директор по дата-стратегии Arenadata

«Часть задач, особенно тех, где есть внутренняя экспертиза, можно делать своими силами. А то, что требует скорости, стабильности или специфических компетенций, — отдавать вендору. Это позволяет гибко управлять затратами и снижать риски. Важно только не воспринимать вендора как кого-то “внешнего”. Это должен быть партнёр, с которым вы синхронизируетесь по целям и качеству. Такой подход позволяет быстрее выходить на рынок и эффективнее использовать ресурсы».

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

Есть три ключевые метрики, которые я считаю базой для принятия решения в парадигме Build vs Buy — построить самому или купить.

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

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

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