Разрабатывать самим или покупать готовое: как не допустить ошибку в стремлении сэкономить

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

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

Разработка и поддержка сложного продукта неизменно обрастает командой

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

Мы отлично осведомлены о широких и богатых возможностях программного обеспечения для обработки видео с открытым исходным кодом ffmpeg и gstreamer. С помощью этих программ и скриптовых языков достаточно легко сделать Proof of Concept систему, которая будет транскодировать несколько программ с фиксированными параметрами и даже выдавать на выходе HLS потоки хорошего качества. Такая простота создания концептов продуктов часто заставляет руководителей принимать поспешные решения о начале внутренней разработки. К сожалению, дальше нужно начинать учитывать меняющуюся природу видеотрафика. Например, вещатели могут переключать сигнал на локальные станции несколько раз в день. Сигнал региональных и локальных станций может отличаться по разрешению картинки, настройке GOP структур, используемым кодекам; и такая смена настроек сигнала приведет к тому что ffmpeg зависнет. Это только один пример того, что должен учитывать квалифицированный инженер, занятый в подобной разработке.

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

Соответственно, появляется новая задача: найти ещё одного инженера, который будет замещать основного. Чтобы управлять работой этих двух инженеров, нам потребуется менеджер, а то и team lead. Путём несложных расчётов, мы получаем такой результат: только лишь по зарплатам сотрудников наш продукт на базе ffmpeg обойдётся нам в 7,000,000 ₽. На этом фоне такие мелочи жизни, как рабочие столы, компьютеры и органайзеры для канцелярии, просто теряются.

Невозможность продать вовне то, что разрабатывалось для нужд компании

Весной прошёл масштабный - музыкальный фестиваль, который собрал 40 миллионов зрителей онлайн. Не мы занимались вещанием, не мы предоставляли CDN, но именно наше программное обеспечение взяли, чтобы обеспечить доставку видео. Почему организаторы фестиваля не обратились к имеющейся инфраструктуре? Мы не знаем точного ответа, но ситуация, когда компания предпочитает обратиться к стороннему вендору, вместо того, чтобы занять внутреннюю разработку нетипичной для себя задачей, очень распространена и даже логична.

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

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

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

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

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

Одно решение на всех = у всех всё одинаково?

С этим разобрались. Но помимо мнимой дороговизны готового решения, у клиентов возникают и другие доводы в пользу того, чтобы не покупать готовое и делать своё, а именно: “Если мы купим у вас, конкуренты тоже купят, и у всех всё будет одинаково”. Если мы говорим о такой задаче, как транскодирование (а именно этим мы и занимаемся), то ничего страшного нет в том, что у всех будет одинаково. Кроме того, всегда есть возможность более высокоуровневой постановки задач и разработки расширенного решения для каждого отдельно взятого клиента, чтобы помочь им быть впереди своих конкурентов.

Автор:

Максим Лапшин

CTO и основатель Flussonic

Профессионал в области разработки высоконагруженных систем. Лауреат премии HighLoad ++