No desenvolvimento de plataformas OTT, o que realmente queremos dizer com o termo "commodity"? Estaremos todos na mesma página com o conceito do que é "valioso" e deveríamos mudar a nossa forma de pensar?
Em projetos de design e criação de OTT, um dos tópicos que surge frequentemente relaciona-se com partes da pilha tecnológica que os clientes querem possuir, em oposição às partes que não querem - frequentemente descritas como "commodity". Se aprendi alguma coisa nos meus 20 anos em OTT, foi que o termo commodity é muito mais um ponto de medida subjetivo e não objetivo. Deixe-me tentar explicar.
A lógica das partes da cadeia com maior valor percebido (as "partes não-commodity"), e que os prestadores de serviços querem possuir, são os pontos de contacto diretos que o consumidor tem com o serviço - a experiência, o visual e a sensação. É evidente que as aplicações e os websites podem ser fundamentais para o sucesso ou fracasso da oferta.
Em total contraste, muitos serviços de back-end, como a gestão de vídeo e conteúdos, a partilha de conteúdos ou o processamento de metadados - ninguém normalmente quer "possuir". Porquê? Apesar de ser onde reside toda a inteligência e de serem complexos, dispendiosos de desenvolver e manter e exigirem muita experiência para acertar, continuam a ser vistos como "componentes de commodity de baixo valor". Quero dizer, é tão fácil ir ao mercado e comprar um CMS padrão pronto a usar que "faz tudo", certo?
O resultado é que a maioria dos prestadores de serviços de hoje compra componentes de commodity prontos a usar - mas utiliza equipas internas para desenvolver e possuir o front-end. Parece sensato, certo? Bem, não tenho tanta certeza.
Qualquer boa aplicação ou plataforma de front-end só pode ser tão boa quanto os serviços de back-end que a alimentam. Quer se trate de artigos editoriais, vídeo, áudio, imagens e ilustrações ou dados. Até à data, apesar de muitas tentativas, eu nunca fui capaz de desenhar uma experiência que uma boa equipa de desenvolvimento de front-end não fosse capaz de criar. No entanto, por comparação, vivi um número ENORME de projetos cujos orçamentos de tempo e custos foram ultrapassados devido à incapacidade de fazer algo simples no "CMS de commodity". Porque é que isto acontece? A resposta é simples, mas muitas vezes ignorada. Fundamentalmente, uma falta de devida diligência ou validação dos requisitos tecnológicos, de produto ou de negócio nestes componentes de "commodity".
Apesar de um mercado de media e OTT completamente repleto de programadores de aplicações e empresas de desenvolvimento que conseguem criar aplicações de alta qualidade para quase todos os designs imagináveis, continuo sem compreender o facto de estes componentes de front-end continuarem a ser vistos como as coisas que é crítico possuir - apesar do facto subjacente de que as funcionalidades e capacidades que chegam ao front-end dependem e confiam inteiramente nas partes que estão nos bastidores.
O que acontece a seguir é uma situação que todos nós já vivemos em primeira mão. Estes componentes de commodity que eram tão fáceis de comprar prontos a usar e que não justificavam o investimento de tempo porque não têm valor ou "fazem todos o mesmo", estão de repente a bloquear os roteiros de desenvolvimento, gerando custos de desenvolvimento crescentes e dívida técnica - à medida que as equipas tentam contornar e resolver a coisa simples que estão a tentar fazer no front-end.
Este comportamento agrava-se ao longo do tempo e começa a constituir a maior parte da razão pela qual a Qualidade de Experiência (QoE) se torna um desafio. Proxies, abstrações e engenharia focada no cliente, em vez de a lógica do lado do servidor vencer. Todos e quaisquer meios são utilizados para contornar limitações nos serviços de back-end. A dívida técnica cresce cada vez mais.
Como concluímos? Sou sempre o tipo de pessoa que defende que o componente de commodity de baixo valor não é a plataforma de back-end, mas sim a parte do front-end que é tão facilmente construída para qualquer design imaginável com qualquer equipa de desenvolvimento ou parceiro minimamente capaz. É, fundamentalmente, a parte que nunca irá realmente bloquear a sua capacidade de fazer algo espetacular para os seus fãs ou público.
O argumento sobre dedicar mais tempo, cuidado e atenção (talvez até ter de "possuir") a partes da plataforma de back-end começa a fazer mais sentido. Por experiência, um CMS, por exemplo, é um dos componentes com maior impacto individual na sua solução - e um que fundamentalmente impulsiona tudo o que faz ou quererá fazer no seu roteiro com o qual o consumidor ou fã irá interagir.
O que faz hoje, amanhã e daqui a três anos é decidido pelas decisões que toma em relação à plataforma que está por trás dessas aplicações brilhantes.
Talvez virar o modelo de commodity de cabeça para baixo mereça uma reflexão extra?
No desenvolvimento de plataformas OTT, o que realmente queremos dizer com o termo "commodity"? Estaremos todos na mesma página com o conceito do que é "valioso" e deveríamos mudar a nossa forma de pensar?
Em projetos de design e criação de OTT, um dos tópicos que surge frequentemente relaciona-se com partes da pilha tecnológica que os clientes querem possuir, em oposição às partes que não querem - frequentemente descritas como "commodity". Se aprendi alguma coisa nos meus 20 anos em OTT, foi que o termo commodity é muito mais um ponto de medida subjetivo e não objetivo. Deixe-me tentar explicar.
A lógica das partes da cadeia com maior valor percebido (as "partes não-commodity"), e que os prestadores de serviços querem possuir, são os pontos de contacto diretos que o consumidor tem com o serviço - a experiência, o visual e a sensação. É evidente que as aplicações e os websites podem ser fundamentais para o sucesso ou fracasso da oferta.
Em total contraste, muitos serviços de back-end, como a gestão de vídeo e conteúdos, a partilha de conteúdos ou o processamento de metadados - ninguém normalmente quer "possuir". Porquê? Apesar de ser onde reside toda a inteligência e de serem complexos, dispendiosos de desenvolver e manter e exigirem muita experiência para acertar, continuam a ser vistos como "componentes de commodity de baixo valor". Quero dizer, é tão fácil ir ao mercado e comprar um CMS padrão pronto a usar que "faz tudo", certo?
O resultado é que a maioria dos prestadores de serviços de hoje compra componentes de commodity prontos a usar - mas utiliza equipas internas para desenvolver e possuir o front-end. Parece sensato, certo? Bem, não tenho tanta certeza.
Qualquer boa aplicação ou plataforma de front-end só pode ser tão boa quanto os serviços de back-end que a alimentam. Quer se trate de artigos editoriais, vídeo, áudio, imagens e ilustrações ou dados. Até à data, apesar de muitas tentativas, eu nunca fui capaz de desenhar uma experiência que uma boa equipa de desenvolvimento de front-end não fosse capaz de criar. No entanto, por comparação, vivi um número ENORME de projetos cujos orçamentos de tempo e custos foram ultrapassados devido à incapacidade de fazer algo simples no "CMS de commodity". Porque é que isto acontece? A resposta é simples, mas muitas vezes ignorada. Fundamentalmente, uma falta de devida diligência ou validação dos requisitos tecnológicos, de produto ou de negócio nestes componentes de "commodity".
Apesar de um mercado de media e OTT completamente repleto de programadores de aplicações e empresas de desenvolvimento que conseguem criar aplicações de alta qualidade para quase todos os designs imagináveis, continuo sem compreender o facto de estes componentes de front-end continuarem a ser vistos como as coisas que é crítico possuir - apesar do facto subjacente de que as funcionalidades e capacidades que chegam ao front-end dependem e confiam inteiramente nas partes que estão nos bastidores.
O que acontece a seguir é uma situação que todos nós já vivemos em primeira mão. Estes componentes de commodity que eram tão fáceis de comprar prontos a usar e que não justificavam o investimento de tempo porque não têm valor ou "fazem todos o mesmo", estão de repente a bloquear os roteiros de desenvolvimento, gerando custos de desenvolvimento crescentes e dívida técnica - à medida que as equipas tentam contornar e resolver a coisa simples que estão a tentar fazer no front-end.
Este comportamento agrava-se ao longo do tempo e começa a constituir a maior parte da razão pela qual a Qualidade de Experiência (QoE) se torna um desafio. Proxies, abstrações e engenharia focada no cliente, em vez de a lógica do lado do servidor vencer. Todos e quaisquer meios são utilizados para contornar limitações nos serviços de back-end. A dívida técnica cresce cada vez mais.
Como concluímos? Sou sempre o tipo de pessoa que defende que o componente de commodity de baixo valor não é a plataforma de back-end, mas sim a parte do front-end que é tão facilmente construída para qualquer design imaginável com qualquer equipa de desenvolvimento ou parceiro minimamente capaz. É, fundamentalmente, a parte que nunca irá realmente bloquear a sua capacidade de fazer algo espetacular para os seus fãs ou público.
O argumento sobre dedicar mais tempo, cuidado e atenção (talvez até ter de "possuir") a partes da plataforma de back-end começa a fazer mais sentido. Por experiência, um CMS, por exemplo, é um dos componentes com maior impacto individual na sua solução - e um que fundamentalmente impulsiona tudo o que faz ou quererá fazer no seu roteiro com o qual o consumidor ou fã irá interagir.
O que faz hoje, amanhã e daqui a três anos é decidido pelas decisões que toma em relação à plataforma que está por trás dessas aplicações brilhantes.
Talvez virar o modelo de commodity de cabeça para baixo mereça uma reflexão extra?
No desenvolvimento de plataformas OTT, o que realmente queremos dizer com o termo "commodity"? Estaremos todos na mesma página com o conceito do que é "valioso" e deveríamos mudar a nossa forma de pensar?
Em projetos de design e criação de OTT, um dos tópicos que surge frequentemente relaciona-se com partes da pilha tecnológica que os clientes querem possuir, em oposição às partes que não querem - frequentemente descritas como "commodity". Se aprendi alguma coisa nos meus 20 anos em OTT, foi que o termo commodity é muito mais um ponto de medida subjetivo e não objetivo. Deixe-me tentar explicar.
A lógica das partes da cadeia com maior valor percebido (as "partes não-commodity"), e que os prestadores de serviços querem possuir, são os pontos de contacto diretos que o consumidor tem com o serviço - a experiência, o visual e a sensação. É evidente que as aplicações e os websites podem ser fundamentais para o sucesso ou fracasso da oferta.
Em total contraste, muitos serviços de back-end, como a gestão de vídeo e conteúdos, a partilha de conteúdos ou o processamento de metadados - ninguém normalmente quer "possuir". Porquê? Apesar de ser onde reside toda a inteligência e de serem complexos, dispendiosos de desenvolver e manter e exigirem muita experiência para acertar, continuam a ser vistos como "componentes de commodity de baixo valor". Quero dizer, é tão fácil ir ao mercado e comprar um CMS padrão pronto a usar que "faz tudo", certo?
O resultado é que a maioria dos prestadores de serviços de hoje compra componentes de commodity prontos a usar - mas utiliza equipas internas para desenvolver e possuir o front-end. Parece sensato, certo? Bem, não tenho tanta certeza.
Qualquer boa aplicação ou plataforma de front-end só pode ser tão boa quanto os serviços de back-end que a alimentam. Quer se trate de artigos editoriais, vídeo, áudio, imagens e ilustrações ou dados. Até à data, apesar de muitas tentativas, eu nunca fui capaz de desenhar uma experiência que uma boa equipa de desenvolvimento de front-end não fosse capaz de criar. No entanto, por comparação, vivi um número ENORME de projetos cujos orçamentos de tempo e custos foram ultrapassados devido à incapacidade de fazer algo simples no "CMS de commodity". Porque é que isto acontece? A resposta é simples, mas muitas vezes ignorada. Fundamentalmente, uma falta de devida diligência ou validação dos requisitos tecnológicos, de produto ou de negócio nestes componentes de "commodity".
Apesar de um mercado de media e OTT completamente repleto de programadores de aplicações e empresas de desenvolvimento que conseguem criar aplicações de alta qualidade para quase todos os designs imagináveis, continuo sem compreender o facto de estes componentes de front-end continuarem a ser vistos como as coisas que é crítico possuir - apesar do facto subjacente de que as funcionalidades e capacidades que chegam ao front-end dependem e confiam inteiramente nas partes que estão nos bastidores.
O que acontece a seguir é uma situação que todos nós já vivemos em primeira mão. Estes componentes de commodity que eram tão fáceis de comprar prontos a usar e que não justificavam o investimento de tempo porque não têm valor ou "fazem todos o mesmo", estão de repente a bloquear os roteiros de desenvolvimento, gerando custos de desenvolvimento crescentes e dívida técnica - à medida que as equipas tentam contornar e resolver a coisa simples que estão a tentar fazer no front-end.
Este comportamento agrava-se ao longo do tempo e começa a constituir a maior parte da razão pela qual a Qualidade de Experiência (QoE) se torna um desafio. Proxies, abstrações e engenharia focada no cliente, em vez de a lógica do lado do servidor vencer. Todos e quaisquer meios são utilizados para contornar limitações nos serviços de back-end. A dívida técnica cresce cada vez mais.
Como concluímos? Sou sempre o tipo de pessoa que defende que o componente de commodity de baixo valor não é a plataforma de back-end, mas sim a parte do front-end que é tão facilmente construída para qualquer design imaginável com qualquer equipa de desenvolvimento ou parceiro minimamente capaz. É, fundamentalmente, a parte que nunca irá realmente bloquear a sua capacidade de fazer algo espetacular para os seus fãs ou público.
O argumento sobre dedicar mais tempo, cuidado e atenção (talvez até ter de "possuir") a partes da plataforma de back-end começa a fazer mais sentido. Por experiência, um CMS, por exemplo, é um dos componentes com maior impacto individual na sua solução - e um que fundamentalmente impulsiona tudo o que faz ou quererá fazer no seu roteiro com o qual o consumidor ou fã irá interagir.
O que faz hoje, amanhã e daqui a três anos é decidido pelas decisões que toma em relação à plataforma que está por trás dessas aplicações brilhantes.
Talvez virar o modelo de commodity de cabeça para baixo mereça uma reflexão extra?
Para saber mais sobre o que leu aqui, ou para saber como a Spicy Mango pode ajudar, envie-nos uma nota para hello@spicymango.co.uk, ligue-nos ou envie-nos uma mensagem usando o nosso formulário de contacto e entraremos em contacto consigo.
Para saber mais sobre o que leu aqui, ou para saber como a Spicy Mango pode ajudar, envie-nos uma nota para hello@spicymango.co.uk, ligue-nos ou envie-nos uma mensagem usando o nosso formulário de contacto e entraremos em contacto consigo.
Para saber mais sobre o que leu aqui, ou para saber como a Spicy Mango pode ajudar, envie-nos uma nota para hello@spicymango.co.uk, ligue-nos ou envie-nos uma mensagem usando o nosso formulário de contacto e entraremos em contacto consigo.
