Статьи

Разработка vs покупка: руководство для продуктовых команд

Инструменты
Тим Кук о подходе Apple к выбору между созданием и покупкой:
«Мы считаем, что должны владеть и контролировать ключевые технологии, лежащие в основе наших продуктов, и участвовать только в тех рынках, где можем внести значительный вклад».
Джефф Безос о AWS и выборе в пользу покупки:
«Мы делаем грязную работу, чтобы вам не пришлось».
Менеджеры продуктов и продуктовые лидеры часто сталкиваются с критическим решением: разрабатывать решение внутри компании или покупать готовое, а если разрабатывать — то в какой степени. Это распространённая дилемма, с которой сталкиваются многие профессионалы на разных этапах своей карьеры.
Создание чего-то нового часто вызывает заметное волнение в команде: это удовольствие от работы с чистого листа и экспериментов. Однако это ощущение нередко усиливается эффектом Даннинга-Крюгера, когда люди переоценивают свои способности, пребывая в состоянии радостного невежества и недооценивая масштабы и (скрытые) затраты на разработку. Как и в случае со стратегией, выбор между созданием и покупкой требует внимательного подхода.
Не существует универсального решения, которое гарантировало бы правильный выбор между покупкой и разработкой, но есть несколько факторов, которые стоит учитывать:

Факторы принятия решения

Затраты на инвестиции
Какова стоимость готового решения? Как она соотносится с затратами на внутреннюю разработку? При анализе рыночных цен мы должны учитывать как текущие затраты на разработку, так и будущие, включая расходы на поддержание и обслуживание решения.
Упущенные возможности
Существует также проблема упущенной выгоды, когда выбор одного варианта исключает другой. Что мы не сможем сделать, если решим разрабатывать решение? Учитывайте скорость выхода на рынок и возможные упущенные возможности, если вы выберете разработку.
Дифференцированная ценность
Есть ли у нас право участвовать в этом рынке? Можем ли мы добиться успеха? Чтобы ответить на эти вопросы, необходимо понять наше основное ценностное предложение и ключевые компетенции. Укрепит ли собственная разработка наше предложение? Поможет ли она выделиться на рынке?
Сроки
Насколько быстро нам нужно решение? Сможем ли мы уложиться в сроки, если займёмся разработкой? Скорость выхода на рынок — одно из ключевых преимуществ покупки, но не стоит недооценивать трудозатраты на интеграцию готового решения или его адаптацию к вашим потребностям.
Контроль
Планируем ли мы в будущем добавлять уникальные функции в это решение? Насколько важен для нас полный контроль над функциональностью и технологиями? Покупка готового решения обычно означает зависимость от поставщика в вопросах обновлений, обслуживания и добавления новых функций. Избежание такой зависимости — одна из причин, почему компании часто рассматривают открытые программные решения в рамках анализа.

Когда решение очевидно

Покупка кажется очевидной, если:
  • Решение, которое вы ищете, не связано с ключевыми компетенциями вашей компании.
  • Эта задача уже решена многими другими, и вы можете воспользоваться чужими наработками и улучшениями.
  • У вас нет ресурсов для полной поддержки и обновления решения на протяжении всего его жизненного цикла (особенно если существуют SaaS-решения, которые предлагают автоматические обновления).
Разработка кажется очевидной, если:
  • Вы уверены, что сможете выделиться за счёт уникального решения, которое является ключевой частью вашего ценностного предложения.
  • Разработка будет дешевле и быстрее, чем интеграция готового решения.
  • Вы убеждены, что никто не предлагает решение, соответствующее вашим уникальным требованиям, и вам действительно нужно собственное.

Основной вывод

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