En el desarrollo de plataformas OTT, ¿qué queremos decir realmente con el término "producto básico"? ¿Estamos todos de acuerdo con el concepto de lo que es "valioso", y deberíamos cambiar nuestra forma de pensar?
In los proyectos de diseño y construcción de OTT, uno de los temas que surge con frecuencia se relaciona con las partes del sistema que los clientes quieren poseer, frente a las que no, a menudo descritas como "básicas" o "comunes". Si algo he aprendido en mis 20 años en OTT, es que el término básico es en gran medida un punto de medida subjetivo y no objetivo. Permítanme intentar explicarlo.
La lógica de las partes de la cadena que se perciben con un mayor valor (las "partes no básicas"), y de las que los proveedores de servicios quieren tener la propiedad, son los puntos de contacto directo que el consumidor tiene con el servicio: la experiencia, el aspecto y la sensación. Es lógico que las aplicaciones y los sitios web puedan ser primordiales para el éxito o el fracaso de la oferta.
Por el contrario, casi nadie suele querer "poseer" muchos servicios backend como la gestión de vídeo y contenidos, la sindicación o el procesamiento de metadatos. ¿Por qué? A pesar de que ahí es donde reside toda la inteligencia y de que son complicados, costosos de desarrollar y mantener, y requieren una gran experiencia para funcionar correctamente, se siguen considerando "componentes básicos de bajo valor". Quiero decir, es muy fácil ir al mercado y comprar un CMS estándar "listo para usar" que sirva para todo, ¿verdad?
El resultado es que la mayoría de los proveedores de servicios hoy en día compran componentes básicos listos para usar, pero utilizan equipos de personal interno para desarrollar y poseer el frontend. Parece sensato, ¿verdad? Bueno, yo no estoy tan seguro.
Cualquier buena aplicación o plataforma frontend solo puede ser tan buena como los servicios backend que la alimentan. Ya se trate de artículos editoriales, vídeo, audio, imágenes y material gráfico o datos. Hasta la fecha, a pesar de haberlo intentado mucho, nunca he podido diseñar una experiencia que un buen equipo de desarrollo frontend no fuera capaz de construir. Sin embargo, en comparación, he vivido una cantidad ENORME de proyectos cuyos presupuestos de tiempo y dinero se han disparado debido a la incapacidad de hacer algo sencillo en el "CMS básico". ¿Por qué ocurre esto? Es fácil de responder, pero a menudo es el tema tabú del que nadie habla. Fundamentalmente, una falta de diligencia debida o de validación de los requisitos tecnológicos, de producto o de negocio en estos componentes "básicos".
A pesar de que el mercado de los medios de comunicación y de OTT está totalmente plagado de desarrolladores de aplicaciones y empresas de desarrollo que pueden crear aplicaciones de alta calidad para casi cualquier diseño imaginable, todavía no me entra en la cabeza que estos componentes frontend se sigan considerando los elementos fundamentales que hay que poseer, a pesar del hecho subyacente de que las características y capacidades que llegan al frontend dependen y confían totalmente en las partes que se encuentran entre bastidores.
Lo que ocurre a continuación es una situación que todos hemos vivido de primera mano. Estos componentes básicos que eran tan fáciles de comprar listos para usar y que no justificaban una inversión de tiempo porque no tienen valor o "todos hacen lo mismo", de repente bloquean las hojas de ruta, generando un aumento de los costes de desarrollo y de la deuda técnica, a medida que los equipos intentan eludir y resolver lo sencillo que intentan hacer en el frontend.
Este comportamiento se agrava con el tiempo y empieza a constituir la mayor parte de la razón por la que la Calidad de la Experiencia (QoE) se convierte en un reto. Proxies, abstracciones e ingeniería pesada en el lado del cliente, en lugar de que se imponga la lógica en el lado del servidor. Se utilizan todos los medios posibles para sortear las limitaciones de los servicios backend. La deuda técnica crece y crece.
¿Cómo concluimos? Yo siempre soy el que defiende que el componente básico de bajo valor no es la plataforma backend, sino la parte frontend que se construye tan fácilmente para cualquier diseño imaginable con cualquier equipo de desarrollo o socio medianamente capacitado. Es, fundamentalmente, la parte que nunca bloqueará realmente tu capacidad de hacer algo genial para tus fans o tu público.
El argumento de dedicar más tiempo, cuidado y atención (tal vez incluso tener que "poseer") a partes de la plataforma backend, empieza a tener más sentido. Por experiencia, un CMS, por ejemplo, es uno de los componentes individuales de mayor impacto en tu solución, y uno que fundamentalmente impulsa todo lo que haces o querrás hacer en tu hoja de ruta con lo que el consumidor o fan interactuará.
Lo que hagas hoy, mañana y dentro de tres años se decide por las decisiones que tomes sobre la plataforma que hay detrás de esas brillantes aplicaciones.
¿Quizás merezca la pena pensar un poco más en darle la vuelta al modelo de producto básico?
En el desarrollo de plataformas OTT, ¿qué queremos decir realmente con el término "producto básico"? ¿Estamos todos de acuerdo con el concepto de lo que es "valioso", y deberíamos cambiar nuestra forma de pensar?
In los proyectos de diseño y construcción de OTT, uno de los temas que surge con frecuencia se relaciona con las partes del sistema que los clientes quieren poseer, frente a las que no, a menudo descritas como "básicas" o "comunes". Si algo he aprendido en mis 20 años en OTT, es que el término básico es en gran medida un punto de medida subjetivo y no objetivo. Permítanme intentar explicarlo.
La lógica de las partes de la cadena que se perciben con un mayor valor (las "partes no básicas"), y de las que los proveedores de servicios quieren tener la propiedad, son los puntos de contacto directo que el consumidor tiene con el servicio: la experiencia, el aspecto y la sensación. Es lógico que las aplicaciones y los sitios web puedan ser primordiales para el éxito o el fracaso de la oferta.
Por el contrario, casi nadie suele querer "poseer" muchos servicios backend como la gestión de vídeo y contenidos, la sindicación o el procesamiento de metadatos. ¿Por qué? A pesar de que ahí es donde reside toda la inteligencia y de que son complicados, costosos de desarrollar y mantener, y requieren una gran experiencia para funcionar correctamente, se siguen considerando "componentes básicos de bajo valor". Quiero decir, es muy fácil ir al mercado y comprar un CMS estándar "listo para usar" que sirva para todo, ¿verdad?
El resultado es que la mayoría de los proveedores de servicios hoy en día compran componentes básicos listos para usar, pero utilizan equipos de personal interno para desarrollar y poseer el frontend. Parece sensato, ¿verdad? Bueno, yo no estoy tan seguro.
Cualquier buena aplicación o plataforma frontend solo puede ser tan buena como los servicios backend que la alimentan. Ya se trate de artículos editoriales, vídeo, audio, imágenes y material gráfico o datos. Hasta la fecha, a pesar de haberlo intentado mucho, nunca he podido diseñar una experiencia que un buen equipo de desarrollo frontend no fuera capaz de construir. Sin embargo, en comparación, he vivido una cantidad ENORME de proyectos cuyos presupuestos de tiempo y dinero se han disparado debido a la incapacidad de hacer algo sencillo en el "CMS básico". ¿Por qué ocurre esto? Es fácil de responder, pero a menudo es el tema tabú del que nadie habla. Fundamentalmente, una falta de diligencia debida o de validación de los requisitos tecnológicos, de producto o de negocio en estos componentes "básicos".
A pesar de que el mercado de los medios de comunicación y de OTT está totalmente plagado de desarrolladores de aplicaciones y empresas de desarrollo que pueden crear aplicaciones de alta calidad para casi cualquier diseño imaginable, todavía no me entra en la cabeza que estos componentes frontend se sigan considerando los elementos fundamentales que hay que poseer, a pesar del hecho subyacente de que las características y capacidades que llegan al frontend dependen y confían totalmente en las partes que se encuentran entre bastidores.
Lo que ocurre a continuación es una situación que todos hemos vivido de primera mano. Estos componentes básicos que eran tan fáciles de comprar listos para usar y que no justificaban una inversión de tiempo porque no tienen valor o "todos hacen lo mismo", de repente bloquean las hojas de ruta, generando un aumento de los costes de desarrollo y de la deuda técnica, a medida que los equipos intentan eludir y resolver lo sencillo que intentan hacer en el frontend.
Este comportamiento se agrava con el tiempo y empieza a constituir la mayor parte de la razón por la que la Calidad de la Experiencia (QoE) se convierte en un reto. Proxies, abstracciones e ingeniería pesada en el lado del cliente, en lugar de que se imponga la lógica en el lado del servidor. Se utilizan todos los medios posibles para sortear las limitaciones de los servicios backend. La deuda técnica crece y crece.
¿Cómo concluimos? Yo siempre soy el que defiende que el componente básico de bajo valor no es la plataforma backend, sino la parte frontend que se construye tan fácilmente para cualquier diseño imaginable con cualquier equipo de desarrollo o socio medianamente capacitado. Es, fundamentalmente, la parte que nunca bloqueará realmente tu capacidad de hacer algo genial para tus fans o tu público.
El argumento de dedicar más tiempo, cuidado y atención (tal vez incluso tener que "poseer") a partes de la plataforma backend, empieza a tener más sentido. Por experiencia, un CMS, por ejemplo, es uno de los componentes individuales de mayor impacto en tu solución, y uno que fundamentalmente impulsa todo lo que haces o querrás hacer en tu hoja de ruta con lo que el consumidor o fan interactuará.
Lo que hagas hoy, mañana y dentro de tres años se decide por las decisiones que tomes sobre la plataforma que hay detrás de esas brillantes aplicaciones.
¿Quizás merezca la pena pensar un poco más en darle la vuelta al modelo de producto básico?
En el desarrollo de plataformas OTT, ¿qué queremos decir realmente con el término "producto básico"? ¿Estamos todos de acuerdo con el concepto de lo que es "valioso", y deberíamos cambiar nuestra forma de pensar?
In los proyectos de diseño y construcción de OTT, uno de los temas que surge con frecuencia se relaciona con las partes del sistema que los clientes quieren poseer, frente a las que no, a menudo descritas como "básicas" o "comunes". Si algo he aprendido en mis 20 años en OTT, es que el término básico es en gran medida un punto de medida subjetivo y no objetivo. Permítanme intentar explicarlo.
La lógica de las partes de la cadena que se perciben con un mayor valor (las "partes no básicas"), y de las que los proveedores de servicios quieren tener la propiedad, son los puntos de contacto directo que el consumidor tiene con el servicio: la experiencia, el aspecto y la sensación. Es lógico que las aplicaciones y los sitios web puedan ser primordiales para el éxito o el fracaso de la oferta.
Por el contrario, casi nadie suele querer "poseer" muchos servicios backend como la gestión de vídeo y contenidos, la sindicación o el procesamiento de metadatos. ¿Por qué? A pesar de que ahí es donde reside toda la inteligencia y de que son complicados, costosos de desarrollar y mantener, y requieren una gran experiencia para funcionar correctamente, se siguen considerando "componentes básicos de bajo valor". Quiero decir, es muy fácil ir al mercado y comprar un CMS estándar "listo para usar" que sirva para todo, ¿verdad?
El resultado es que la mayoría de los proveedores de servicios hoy en día compran componentes básicos listos para usar, pero utilizan equipos de personal interno para desarrollar y poseer el frontend. Parece sensato, ¿verdad? Bueno, yo no estoy tan seguro.
Cualquier buena aplicación o plataforma frontend solo puede ser tan buena como los servicios backend que la alimentan. Ya se trate de artículos editoriales, vídeo, audio, imágenes y material gráfico o datos. Hasta la fecha, a pesar de haberlo intentado mucho, nunca he podido diseñar una experiencia que un buen equipo de desarrollo frontend no fuera capaz de construir. Sin embargo, en comparación, he vivido una cantidad ENORME de proyectos cuyos presupuestos de tiempo y dinero se han disparado debido a la incapacidad de hacer algo sencillo en el "CMS básico". ¿Por qué ocurre esto? Es fácil de responder, pero a menudo es el tema tabú del que nadie habla. Fundamentalmente, una falta de diligencia debida o de validación de los requisitos tecnológicos, de producto o de negocio en estos componentes "básicos".
A pesar de que el mercado de los medios de comunicación y de OTT está totalmente plagado de desarrolladores de aplicaciones y empresas de desarrollo que pueden crear aplicaciones de alta calidad para casi cualquier diseño imaginable, todavía no me entra en la cabeza que estos componentes frontend se sigan considerando los elementos fundamentales que hay que poseer, a pesar del hecho subyacente de que las características y capacidades que llegan al frontend dependen y confían totalmente en las partes que se encuentran entre bastidores.
Lo que ocurre a continuación es una situación que todos hemos vivido de primera mano. Estos componentes básicos que eran tan fáciles de comprar listos para usar y que no justificaban una inversión de tiempo porque no tienen valor o "todos hacen lo mismo", de repente bloquean las hojas de ruta, generando un aumento de los costes de desarrollo y de la deuda técnica, a medida que los equipos intentan eludir y resolver lo sencillo que intentan hacer en el frontend.
Este comportamiento se agrava con el tiempo y empieza a constituir la mayor parte de la razón por la que la Calidad de la Experiencia (QoE) se convierte en un reto. Proxies, abstracciones e ingeniería pesada en el lado del cliente, en lugar de que se imponga la lógica en el lado del servidor. Se utilizan todos los medios posibles para sortear las limitaciones de los servicios backend. La deuda técnica crece y crece.
¿Cómo concluimos? Yo siempre soy el que defiende que el componente básico de bajo valor no es la plataforma backend, sino la parte frontend que se construye tan fácilmente para cualquier diseño imaginable con cualquier equipo de desarrollo o socio medianamente capacitado. Es, fundamentalmente, la parte que nunca bloqueará realmente tu capacidad de hacer algo genial para tus fans o tu público.
El argumento de dedicar más tiempo, cuidado y atención (tal vez incluso tener que "poseer") a partes de la plataforma backend, empieza a tener más sentido. Por experiencia, un CMS, por ejemplo, es uno de los componentes individuales de mayor impacto en tu solución, y uno que fundamentalmente impulsa todo lo que haces o querrás hacer en tu hoja de ruta con lo que el consumidor o fan interactuará.
Lo que hagas hoy, mañana y dentro de tres años se decide por las decisiones que tomes sobre la plataforma que hay detrás de esas brillantes aplicaciones.
¿Quizás merezca la pena pensar un poco más en darle la vuelta al modelo de producto básico?
Para saber más sobre cualquiera de los temas que ha leído aquí, o para conocer cómo Spicy Mango podría ayudarle, escríbanos a hello@spicymango.co.uk, llámenos o envíenos un mensaje utilizando nuestro formulario de contacto y nos pondremos en contacto con usted.
Para saber más sobre cualquiera de los temas que ha leído aquí, o para conocer cómo Spicy Mango podría ayudarle, escríbanos a hello@spicymango.co.uk, llámenos o envíenos un mensaje utilizando nuestro formulario de contacto y nos pondremos en contacto con usted.
Para saber más sobre cualquiera de los temas que ha leído aquí, o para conocer cómo Spicy Mango podría ayudarle, escríbanos a hello@spicymango.co.uk, llámenos o envíenos un mensaje utilizando nuestro formulario de contacto y nos pondremos en contacto con usted.
