Desarrolla el tuyo propio o compra uno listo para usar: Cómo evitar cometer un error en el deseo de ahorrar dinero

November 26, 2020

7minutos de lectura

vkfest-and-transcoder

Ahora estamos en el proceso de desarrollar nuestro propio transcodificador de hardware y, por lo tanto, nos enfrentamos a muchos problemas difíciles. La pregunta principal es cuál debería ser el precio de un producto tan integrado, teniendo en cuenta todas las dificultades de su desarrollo y el costo de su mantenimiento.

Nosotros, como proveedor, intentamos que nuestros productos sean económicos, pero la mayoría de las veces, cualquiera que sea el precio que cobramos, algunos clientes pueden decir: “es caro, es más barato desarrollarlo nosotros mismos”. Este enfoque es un gran error y explicaremos por qué.

El desarrollo y el soporte de un producto complejo crece invariablemente debido a las necesidades de personal

Los desarrolladores internos de la empresa se proporcionan un empleo de por vida. Esto se debe a que es imposible desarrollar un transcodificador o transmisor una vez y congelar un proyecto operando el producto creado sin cambios. Los protocolos, dispositivos de reproducción, códecs y otros componentes cambian constantemente. Necesitas adaptarte constantemente a los requisitos del mercado.

Somos conscientes de las amplias y ricas capacidades del software de procesamiento de video de código abierto FFmpeg y GStreamer. Usando estos programas y lenguajes de scripting, es bastante fácil crear un sistema de prueba de concepto que transcodifique varios programas con parámetros fijos e incluso produzca flujos de buena calidad utilizando la salida HLS. La simplicidad de crear conceptos de productos a menudo lleva a los gerentes a tomar decisiones apresuradas sobre el inicio del desarrollo interno. Desafortunadamente, el siguiente paso es comenzar a tener en cuenta la naturaleza cambiante del tráfico de video. Por ejemplo, las emisoras pueden cambiar la señal a las estaciones locales varias veces al día. La señal de las estaciones regionales y locales puede diferir en la resolución de la imagen, la configuración de las estructuras GOP, los códecs usados ​​y tales cambios en la configuración de la señal harán que FFmpeg se congele. Este es solo un ejemplo de lo que debe tener en cuenta un ingeniero calificado involucrado en dicho desarrollo.

vkfest-and-transcoder

Entonces, la primera y más importante tarea es contratar a un ingeniero calificado. Encontrarlos no es suficiente, también hay que darles trabajo. Después de un año, de repente puede resultar que las tareas de FFmpeg no tienen fin: Las condiciones externas están cambiando, se agregan constantemente nuevos datos de entrada. Y luego comienza la temporada de vacaciones y, como una persona normal y saludable, nuestro ingeniero querrá tomarse un descanso. Podemos esperar que durante las vacaciones estén codificando frenéticamente con una computadora portátil bajo el sol abrasador, pero tienen todo el derecho a no hacerlo.

Aparece así una nueva tarea: Encontrar otro ingeniero que releve al principal. Para administrar estos dos ingenieros, necesitamos un gerente o incluso un líder de equipo. Mediante cálculos simples, basados ​​únicamente en los salarios de los empleados, nuestro producto que usa FFmpeg nos costará alrededor de $100,000. Sin mencionar las nimiedades de la vida, ya que el costo de las computadoras de escritorio, las computadoras y los organizadores de la oficina simplemente se va a un segundo plano.

Solo estamos hablando del primer año de nuestro hipotético nuevo equipo.

  • Qué pasará cuando el proyecto llegue a su fin?
  • El equipo va a desaparecer de alguna manera junto con todos los gastos?
  • Dirá el director del equipo: Hicimos todo lo que pudimos, ya no nos necesitan aquí?

Por supuesto que no, necesitas soporte para un producto existente que consumirá dinero constantemente. Es este tipo de trabajo realmente necesario? No lo creemos.

La imposibilidad de vender lo desarrollado para las necesidades de la empresa.

En la primavera, se llevó VK Fest, a gran escala, un festival de música en línea que reunió a 40 millones de espectadores. No lo transmitimos, no proporcionamos el CDN, pero fue nuestro software el que se eligió para garantizar la entrega de las transmisiones de video. ¿Por qué los organizadores del festival no recurrieron a la infraestructura existente? No sabemos la respuesta exacta, pero cuando una empresa prefiere recurrir a un proveedor externo, en lugar de asumir una tarea interna de desarrollo, es muy común y lógico.

VK Fest

Dado que la infraestructura es interna, solo resuelve aquellas tareas que surgen específicamente para una empresa. Los proveedores B2B están involucrados en cientos de industrias diversas y su variabilidad es enorme. Esto es lo que le permite vender su producto y amortizar el coste de su desarrollo: Es utilizado por un gran número de clientes con diferentes tareas, cada una de las cuales enriquece una solución compartida.

Es muy difícil validar la relevancia y la rentabilidad de los equipos de soluciones de infraestructura interna. Es difícil para la gerencia comprender y evaluar la eficacia con la que el personal resuelve las tareas.

Al desarrollar un producto interno, la atención se centra en la funcionalidad básica; las interfaces de usuario, la usabilidad, los sistemas de monitoreo, la documentación se deja “para más adelante” y casi nunca llega a un estado en el que pueda venderse a otra persona o al menos liberarse como código abierto. Al mismo tiempo, algunas organizaciones están tan profundamente involucradas en el proceso de desarrollo de un producto interno y gastan tanto tiempo y dinero en este proyecto que con el tiempo este sistema se vuelve completamente operativo, o al menos cubre las necesidades del negocio. En este punto, la cantidad de inversión en el sistema se está volviendo tan grande que la gerencia puede decidir intentar vendérselo a alguien. Y comienza de nuevo el ciclo de infusión de fondos, ahora para llevar el producto al mercado.

Una empresa que decide gastar recursos significativos en el desarrollo interno de herramientas atípicas puede encontrarse fácilmente en una situación en la que simplemente no hay nadie a quien vender. En consecuencia, una solución que ya es costosa simplemente será insoportable y surgirá una situación triste. La compañía está involucrada en otra cosa, pero en el fondo, hay un departamento que está demasiado financiado para ser disuelto y demasiado insuficiente para volverse financieramente independiente.

Pocas empresas se atreven a vender su producto interno. Entonces, tiene un ejemplo como Amazon, que logró convertirse en la plataforma de comercio electrónico más grande del mundo y al mismo tiempo en el creador y principal proveedor de infraestructura en la nube. Esto sucedió precisamente porque pusieron su infraestructura interna a disposición de otros, lo que permitió que incluso otras tiendas lanzaran ventas en sus servidores. Hacer esto requiere tremenda fortaleza y costo.

“Una solución para todos” no es igual a “todos son iguales”

Entonces, lo descubrimos. Pero además del alto costo de la solución prefabricada, los clientes también tienen otras razones a favor de no comprar la prefabricada y hacer la suya propia, a saber: “Si te compramos a ti, los competidores también comprarán, y todo ser igual para todos". Si estamos hablando de una tarea como la transcodificación (es decir, esto es lo que estamos haciendo), entonces no hay nada de malo en el hecho de que todos tendrán lo mismo. Además, siempre existe la posibilidad de una configuración de tareas de nivel superior y el desarrollo de una solución avanzada para cada cliente individual para ayudarlos a estar por delante de sus competidores.

En conclusión

El desarrollo interno de productos que están lejos de las actividades principales de una empresa es costoso y no hay garantía de que funcionen bien. Entre otras cosas, el producto desarrollado internamente servirá exclusivamente a la empresa que lo creó. Al final, el deseo inicial de ahorrar dinero resulta ser el resultado opuesto.

Existe una diferencia entre una buena herramienta y una buena solución. Una buena solución es diferente porque con ella la empresa tiene un problema menos. Si desarrolla en un par de semanas lo que un proveedor especializado ha estado desarrollando durante años, habrá muchos más problemas de los que había originalmente.

img
Author:
Max Lapshin
CTO and Founder at Flussonic
Seasoned professional in the field of high-load systems. Winner of High Load++ Award

Flussonic Media Server trial

Al enviar tu solicitud, aceptas nuestros términos y condiciones. terms and conditions

Our experts will contact you shortly, offer tech advice and consultation, and send you a trial license..

Completa el formulario para recibir una clave de prueba gratuita de Flussonic Media Server.

Si no recibes un correo electrónico nuestro en una hora, verifica tu carpeta de correo no deseado y agregua a Flussonic a tu lista de contactos de confianza.

Email: support@flussonic.com Phone: +1 (778) 716-2080 (United States)