Tecnologia

Construindo uma plataforma OTT escalável

Construindo uma plataforma OTT escalável

Construindo uma plataforma OTT escalável

Spicy Mango - Chris Wood

Leitura de 6 min

|

Construir uma plataforma de streaming de vídeo em direto ou de conteúdos a pedido (OTT) pode ser uma tarefa um pouco assustadora, por isso quis partilhar algumas dicas que achei que poderiam ajudar.

Normalmente, este tipo de projetos começa com uma discussão em que alguém da chefia prometeu o lançamento de uma nova proposta com um prazo louco e inamovível – ou, talvez pior, fez um acordo com um fornecedor de soluções pré-fabricadas e aceitou colocar no mercado algo que cubra todos os casos de utilização imagináveis no mais curto espaço de tempo possível. Soa familiar?

Apesar dos desafios que se avizinham, quis tentar orientá-lo sobre alguns aspetos que, esperamos, o guiem na direção certa. O objetivo? Construir uma plataforma escalável e fiável que não faça da dependência de fornecedores e da escala limitada as duas primeiras características do seu roteiro.


1. Levantamento de requisitos

Os requisitos dividem-se em algumas categorias e grupos de alto nível. Produto, negócio, tecnologia. Normalmente, tudo se enquadra de alguma forma nestas verticais. É um pouco mais fácil redigir os habituais "requisitos funcionais" orientados para o consumidor do que alguns dos requisitos frequentemente desconhecidos ou muitas vezes esquecidos, tais como a gestão fiscal.

A chave no levantamento de requisitos é garantir que todos os detalhes são cobertos. Vou dar-lhe um exemplo prático.

Um gestor de produto irá elaborar um requisito na linha de "Como utilizador, devo ser capaz de pesquisar no site". Um bom arquiteto técnico terá a capacidade de desdobrar isto em 10-15 requisitos individuais, tanto funcionais como não funcionais, que cobrirão áreas como pesquisa de conteúdos, pesquisa de dados, multi-idioma, filtragem, ordenação, persistência, notificações de resultados, resultados de pesquisa nulos, integração de analítica e BI, pesquisa preditiva, tempos de resposta para resultados, entre outros.

A mensagem aqui é que, quanto mais trabalho fizer para garantir que os requisitos sejam EXPLÍCITOS e DETALHADOS, mais dores de cabeça poupará mais tarde, quando a solução fornecida pelo fornecedor não fizer o que pensava que faria. Elimine a ambiguidade.


2. Processo de RFI/RFP e análise de fornecedores

Porque precisamos de uma RFP? Existem muitas razões – mas pense nisto principalmente como um mecanismo para comparar potenciais candidatos e fornecedores para a plataforma de streaming que vai construir.

A elaboração de uma boa documentação de RFI e RFP, juntamente com a definição do processo, são ambas igualmente importantes. (À parte – é importante saber a diferença entre RFI e RFP!) Saber estruturar corretamente um documento de requisitos que um fornecedor possa compreender e responder de uma forma que você consiga compreender, comparar e pontuar irá ajudá-lo mais do que imagina.

Um bom documento e processo de RFP irá:

  • Reduzir o tempo necessário para executar o processo de RFP

  • Permitir que os fornecedores compreendam os seus requisitos e gerem orçamentos e propostas precisos

  • Remover a ambiguidade das respostas – garantindo que os requisitos "não conformes", "conformes" e de "roteiro" sejam claros

  • Destacar aquilo de que os fornecedores são capazes e o que não são

  • Identificar lacunas e áreas de que as suas equipas de negócio, produto e tecnologia necessitam e que não são preenchidas pelo fornecedor principal ou pelo integrador de sistemas

  • Permitir uma comparação direta ("maçãs com maçãs") das respostas dos fornecedores

Para garantir a eficácia – sugerimos também selecionar alguns casos de utilização ao acaso e pedir aos seus 2 ou 3 principais fornecedores para demonstrarem como estas funcionalidades funcionam. Se responderam com "conforme" – rapidamente saberá se estão a dizer a verdade.

Quando escrevemos documentação de RFP e gerimos processos para os nossos clientes, não é invulgar ver mais de 1500 requisitos funcionais e não funcionais definidos para uma plataforma OTT ou de streaming. Se estiver abaixo deste número – provavelmente deverá perguntar-se se cobriu tudo de forma minuciosa e correta.


3. Arquitetura e design da plataforma

Como parte deste percurso, propomo-nos a construir uma plataforma de streaming de vídeo escalável. A fase de arquitetura e design da plataforma avalia os requisitos identificados pelo negócio, compara-os com as soluções propostas pelos fornecedores e parceiros, e trabalha para construir designs escaláveis e referências de soluções que:

  • Garantam que os requisitos para o lançamento possam ser cumpridos

  • Tragam flexibilidade para incorporar requisitos em mudança – projetar a arquitetura a pensar na mudança

  • Identifiquem lacunas nas propostas e gerem soluções para as resolver

  • Reduzam ou eliminem o risco de dependência de fornecedores (vendor lock-in)

  • Suportem requisitos funcionais E não funcionais à escala

  • Permitam uma escala ilimitada de produtores e consumidores - streaming em direto para milhões

  • Garantam que as melhores práticas, padrões e abordagens sejam seguidos

  • Cumpram os critérios de conformidade para os territórios onde irão operar

  • Equilibrem os critérios de tempo, qualidade e custo

  • Cumpram as referências de segurança, desempenho e operacionais

  • E, finalmente, garantam que a solução proporcione valor de negócio

Os arquitetos de plataformas de media e streaming garantem que as soluções propostas representam a melhor forma de implementação – não se limitando apenas ao que o fornecedor ou provedor de soluções tem para oferecer.


4. Um caminho para a implementação

Com um bom trabalho de base, o caminho para a implementação tornar-se-á inevitavelmente mais simples. Independentemente disso, a implementação de plataformas OTT escaláveis, altamente eficazes, resilientes e fiáveis ainda dá trabalho – e muitas vezes requer "squads" ou equipas de indivíduos focados para assumirem o desenvolvimento e a implementação de áreas-chave como Identidade, Faturação, Subscrições, Conteúdo, Conformidade, Analítica e Dados, Aplicações e outras.

Estas equipas focadas recebem autonomia para se autogerirem, guiadas por líderes experientes que, idealmente, já implementaram serviços semelhantes anteriormente, e guiarão cada fluxo de trabalho desde o design até à produção.

Não é segredo que cada vez mais organizações empregam cada vez menos especialistas de domínio, com algumas unidades de negócio formadas unicamente por equipas de produto (desenvolvedores, gestores, designers, profissionais de marketing). O desafio? Falta o conhecimento de domínio e a experiência técnica necessária para poder exigir responsabilidades aos fornecedores quando as coisas se tornam tecnicamente difíceis.

Embora os fornecedores proponham o que são capazes de oferecer para cumprir os requisitos definidos pelo negócio, esta não é, de forma alguma, a única via, como qualquer bom arquiteto de plataformas de vídeo atestará.

As implementações mais bem-sucedidas são aquelas em que o negócio reconhece a necessidade de orientar e controlar a implementação, seja através do aproveitamento da experiência técnica interna para assumir a arquitetura, ou através do aproveitamento de experiência externa, como as equipas que fornecemos na Spicy Mango.

Repetidamente, vemos o fornecedor a representar apenas os seus próprios interesses, e não os do cliente ou do programa global. As plataformas de vídeo online modernas (OVPs) já raramente são ecossistemas tecnológicos desenvolvidos exclusivamente por uma única entidade, sendo quase todas ambientes baseados em SaaS de múltiplos fornecedores – uma coleção de muitos produtos individuais que fornecem elementos específicos da solução. Uma boa equipa de especialistas técnicos independentes funciona como um árbitro neutro para pôr fim à troca de acusações quando as coisas correm mal.

Construir uma plataforma de streaming de vídeo em direto ou de conteúdos a pedido (OTT) pode ser uma tarefa um pouco assustadora, por isso quis partilhar algumas dicas que achei que poderiam ajudar.

Normalmente, este tipo de projetos começa com uma discussão em que alguém da chefia prometeu o lançamento de uma nova proposta com um prazo louco e inamovível – ou, talvez pior, fez um acordo com um fornecedor de soluções pré-fabricadas e aceitou colocar no mercado algo que cubra todos os casos de utilização imagináveis no mais curto espaço de tempo possível. Soa familiar?

Apesar dos desafios que se avizinham, quis tentar orientá-lo sobre alguns aspetos que, esperamos, o guiem na direção certa. O objetivo? Construir uma plataforma escalável e fiável que não faça da dependência de fornecedores e da escala limitada as duas primeiras características do seu roteiro.


1. Levantamento de requisitos

Os requisitos dividem-se em algumas categorias e grupos de alto nível. Produto, negócio, tecnologia. Normalmente, tudo se enquadra de alguma forma nestas verticais. É um pouco mais fácil redigir os habituais "requisitos funcionais" orientados para o consumidor do que alguns dos requisitos frequentemente desconhecidos ou muitas vezes esquecidos, tais como a gestão fiscal.

A chave no levantamento de requisitos é garantir que todos os detalhes são cobertos. Vou dar-lhe um exemplo prático.

Um gestor de produto irá elaborar um requisito na linha de "Como utilizador, devo ser capaz de pesquisar no site". Um bom arquiteto técnico terá a capacidade de desdobrar isto em 10-15 requisitos individuais, tanto funcionais como não funcionais, que cobrirão áreas como pesquisa de conteúdos, pesquisa de dados, multi-idioma, filtragem, ordenação, persistência, notificações de resultados, resultados de pesquisa nulos, integração de analítica e BI, pesquisa preditiva, tempos de resposta para resultados, entre outros.

A mensagem aqui é que, quanto mais trabalho fizer para garantir que os requisitos sejam EXPLÍCITOS e DETALHADOS, mais dores de cabeça poupará mais tarde, quando a solução fornecida pelo fornecedor não fizer o que pensava que faria. Elimine a ambiguidade.


2. Processo de RFI/RFP e análise de fornecedores

Porque precisamos de uma RFP? Existem muitas razões – mas pense nisto principalmente como um mecanismo para comparar potenciais candidatos e fornecedores para a plataforma de streaming que vai construir.

A elaboração de uma boa documentação de RFI e RFP, juntamente com a definição do processo, são ambas igualmente importantes. (À parte – é importante saber a diferença entre RFI e RFP!) Saber estruturar corretamente um documento de requisitos que um fornecedor possa compreender e responder de uma forma que você consiga compreender, comparar e pontuar irá ajudá-lo mais do que imagina.

Um bom documento e processo de RFP irá:

  • Reduzir o tempo necessário para executar o processo de RFP

  • Permitir que os fornecedores compreendam os seus requisitos e gerem orçamentos e propostas precisos

  • Remover a ambiguidade das respostas – garantindo que os requisitos "não conformes", "conformes" e de "roteiro" sejam claros

  • Destacar aquilo de que os fornecedores são capazes e o que não são

  • Identificar lacunas e áreas de que as suas equipas de negócio, produto e tecnologia necessitam e que não são preenchidas pelo fornecedor principal ou pelo integrador de sistemas

  • Permitir uma comparação direta ("maçãs com maçãs") das respostas dos fornecedores

Para garantir a eficácia – sugerimos também selecionar alguns casos de utilização ao acaso e pedir aos seus 2 ou 3 principais fornecedores para demonstrarem como estas funcionalidades funcionam. Se responderam com "conforme" – rapidamente saberá se estão a dizer a verdade.

Quando escrevemos documentação de RFP e gerimos processos para os nossos clientes, não é invulgar ver mais de 1500 requisitos funcionais e não funcionais definidos para uma plataforma OTT ou de streaming. Se estiver abaixo deste número – provavelmente deverá perguntar-se se cobriu tudo de forma minuciosa e correta.


3. Arquitetura e design da plataforma

Como parte deste percurso, propomo-nos a construir uma plataforma de streaming de vídeo escalável. A fase de arquitetura e design da plataforma avalia os requisitos identificados pelo negócio, compara-os com as soluções propostas pelos fornecedores e parceiros, e trabalha para construir designs escaláveis e referências de soluções que:

  • Garantam que os requisitos para o lançamento possam ser cumpridos

  • Tragam flexibilidade para incorporar requisitos em mudança – projetar a arquitetura a pensar na mudança

  • Identifiquem lacunas nas propostas e gerem soluções para as resolver

  • Reduzam ou eliminem o risco de dependência de fornecedores (vendor lock-in)

  • Suportem requisitos funcionais E não funcionais à escala

  • Permitam uma escala ilimitada de produtores e consumidores - streaming em direto para milhões

  • Garantam que as melhores práticas, padrões e abordagens sejam seguidos

  • Cumpram os critérios de conformidade para os territórios onde irão operar

  • Equilibrem os critérios de tempo, qualidade e custo

  • Cumpram as referências de segurança, desempenho e operacionais

  • E, finalmente, garantam que a solução proporcione valor de negócio

Os arquitetos de plataformas de media e streaming garantem que as soluções propostas representam a melhor forma de implementação – não se limitando apenas ao que o fornecedor ou provedor de soluções tem para oferecer.


4. Um caminho para a implementação

Com um bom trabalho de base, o caminho para a implementação tornar-se-á inevitavelmente mais simples. Independentemente disso, a implementação de plataformas OTT escaláveis, altamente eficazes, resilientes e fiáveis ainda dá trabalho – e muitas vezes requer "squads" ou equipas de indivíduos focados para assumirem o desenvolvimento e a implementação de áreas-chave como Identidade, Faturação, Subscrições, Conteúdo, Conformidade, Analítica e Dados, Aplicações e outras.

Estas equipas focadas recebem autonomia para se autogerirem, guiadas por líderes experientes que, idealmente, já implementaram serviços semelhantes anteriormente, e guiarão cada fluxo de trabalho desde o design até à produção.

Não é segredo que cada vez mais organizações empregam cada vez menos especialistas de domínio, com algumas unidades de negócio formadas unicamente por equipas de produto (desenvolvedores, gestores, designers, profissionais de marketing). O desafio? Falta o conhecimento de domínio e a experiência técnica necessária para poder exigir responsabilidades aos fornecedores quando as coisas se tornam tecnicamente difíceis.

Embora os fornecedores proponham o que são capazes de oferecer para cumprir os requisitos definidos pelo negócio, esta não é, de forma alguma, a única via, como qualquer bom arquiteto de plataformas de vídeo atestará.

As implementações mais bem-sucedidas são aquelas em que o negócio reconhece a necessidade de orientar e controlar a implementação, seja através do aproveitamento da experiência técnica interna para assumir a arquitetura, ou através do aproveitamento de experiência externa, como as equipas que fornecemos na Spicy Mango.

Repetidamente, vemos o fornecedor a representar apenas os seus próprios interesses, e não os do cliente ou do programa global. As plataformas de vídeo online modernas (OVPs) já raramente são ecossistemas tecnológicos desenvolvidos exclusivamente por uma única entidade, sendo quase todas ambientes baseados em SaaS de múltiplos fornecedores – uma coleção de muitos produtos individuais que fornecem elementos específicos da solução. Uma boa equipa de especialistas técnicos independentes funciona como um árbitro neutro para pôr fim à troca de acusações quando as coisas correm mal.

Construir uma plataforma de streaming de vídeo em direto ou de conteúdos a pedido (OTT) pode ser uma tarefa um pouco assustadora, por isso quis partilhar algumas dicas que achei que poderiam ajudar.

Normalmente, este tipo de projetos começa com uma discussão em que alguém da chefia prometeu o lançamento de uma nova proposta com um prazo louco e inamovível – ou, talvez pior, fez um acordo com um fornecedor de soluções pré-fabricadas e aceitou colocar no mercado algo que cubra todos os casos de utilização imagináveis no mais curto espaço de tempo possível. Soa familiar?

Apesar dos desafios que se avizinham, quis tentar orientá-lo sobre alguns aspetos que, esperamos, o guiem na direção certa. O objetivo? Construir uma plataforma escalável e fiável que não faça da dependência de fornecedores e da escala limitada as duas primeiras características do seu roteiro.


1. Levantamento de requisitos

Os requisitos dividem-se em algumas categorias e grupos de alto nível. Produto, negócio, tecnologia. Normalmente, tudo se enquadra de alguma forma nestas verticais. É um pouco mais fácil redigir os habituais "requisitos funcionais" orientados para o consumidor do que alguns dos requisitos frequentemente desconhecidos ou muitas vezes esquecidos, tais como a gestão fiscal.

A chave no levantamento de requisitos é garantir que todos os detalhes são cobertos. Vou dar-lhe um exemplo prático.

Um gestor de produto irá elaborar um requisito na linha de "Como utilizador, devo ser capaz de pesquisar no site". Um bom arquiteto técnico terá a capacidade de desdobrar isto em 10-15 requisitos individuais, tanto funcionais como não funcionais, que cobrirão áreas como pesquisa de conteúdos, pesquisa de dados, multi-idioma, filtragem, ordenação, persistência, notificações de resultados, resultados de pesquisa nulos, integração de analítica e BI, pesquisa preditiva, tempos de resposta para resultados, entre outros.

A mensagem aqui é que, quanto mais trabalho fizer para garantir que os requisitos sejam EXPLÍCITOS e DETALHADOS, mais dores de cabeça poupará mais tarde, quando a solução fornecida pelo fornecedor não fizer o que pensava que faria. Elimine a ambiguidade.


2. Processo de RFI/RFP e análise de fornecedores

Porque precisamos de uma RFP? Existem muitas razões – mas pense nisto principalmente como um mecanismo para comparar potenciais candidatos e fornecedores para a plataforma de streaming que vai construir.

A elaboração de uma boa documentação de RFI e RFP, juntamente com a definição do processo, são ambas igualmente importantes. (À parte – é importante saber a diferença entre RFI e RFP!) Saber estruturar corretamente um documento de requisitos que um fornecedor possa compreender e responder de uma forma que você consiga compreender, comparar e pontuar irá ajudá-lo mais do que imagina.

Um bom documento e processo de RFP irá:

  • Reduzir o tempo necessário para executar o processo de RFP

  • Permitir que os fornecedores compreendam os seus requisitos e gerem orçamentos e propostas precisos

  • Remover a ambiguidade das respostas – garantindo que os requisitos "não conformes", "conformes" e de "roteiro" sejam claros

  • Destacar aquilo de que os fornecedores são capazes e o que não são

  • Identificar lacunas e áreas de que as suas equipas de negócio, produto e tecnologia necessitam e que não são preenchidas pelo fornecedor principal ou pelo integrador de sistemas

  • Permitir uma comparação direta ("maçãs com maçãs") das respostas dos fornecedores

Para garantir a eficácia – sugerimos também selecionar alguns casos de utilização ao acaso e pedir aos seus 2 ou 3 principais fornecedores para demonstrarem como estas funcionalidades funcionam. Se responderam com "conforme" – rapidamente saberá se estão a dizer a verdade.

Quando escrevemos documentação de RFP e gerimos processos para os nossos clientes, não é invulgar ver mais de 1500 requisitos funcionais e não funcionais definidos para uma plataforma OTT ou de streaming. Se estiver abaixo deste número – provavelmente deverá perguntar-se se cobriu tudo de forma minuciosa e correta.


3. Arquitetura e design da plataforma

Como parte deste percurso, propomo-nos a construir uma plataforma de streaming de vídeo escalável. A fase de arquitetura e design da plataforma avalia os requisitos identificados pelo negócio, compara-os com as soluções propostas pelos fornecedores e parceiros, e trabalha para construir designs escaláveis e referências de soluções que:

  • Garantam que os requisitos para o lançamento possam ser cumpridos

  • Tragam flexibilidade para incorporar requisitos em mudança – projetar a arquitetura a pensar na mudança

  • Identifiquem lacunas nas propostas e gerem soluções para as resolver

  • Reduzam ou eliminem o risco de dependência de fornecedores (vendor lock-in)

  • Suportem requisitos funcionais E não funcionais à escala

  • Permitam uma escala ilimitada de produtores e consumidores - streaming em direto para milhões

  • Garantam que as melhores práticas, padrões e abordagens sejam seguidos

  • Cumpram os critérios de conformidade para os territórios onde irão operar

  • Equilibrem os critérios de tempo, qualidade e custo

  • Cumpram as referências de segurança, desempenho e operacionais

  • E, finalmente, garantam que a solução proporcione valor de negócio

Os arquitetos de plataformas de media e streaming garantem que as soluções propostas representam a melhor forma de implementação – não se limitando apenas ao que o fornecedor ou provedor de soluções tem para oferecer.


4. Um caminho para a implementação

Com um bom trabalho de base, o caminho para a implementação tornar-se-á inevitavelmente mais simples. Independentemente disso, a implementação de plataformas OTT escaláveis, altamente eficazes, resilientes e fiáveis ainda dá trabalho – e muitas vezes requer "squads" ou equipas de indivíduos focados para assumirem o desenvolvimento e a implementação de áreas-chave como Identidade, Faturação, Subscrições, Conteúdo, Conformidade, Analítica e Dados, Aplicações e outras.

Estas equipas focadas recebem autonomia para se autogerirem, guiadas por líderes experientes que, idealmente, já implementaram serviços semelhantes anteriormente, e guiarão cada fluxo de trabalho desde o design até à produção.

Não é segredo que cada vez mais organizações empregam cada vez menos especialistas de domínio, com algumas unidades de negócio formadas unicamente por equipas de produto (desenvolvedores, gestores, designers, profissionais de marketing). O desafio? Falta o conhecimento de domínio e a experiência técnica necessária para poder exigir responsabilidades aos fornecedores quando as coisas se tornam tecnicamente difíceis.

Embora os fornecedores proponham o que são capazes de oferecer para cumprir os requisitos definidos pelo negócio, esta não é, de forma alguma, a única via, como qualquer bom arquiteto de plataformas de vídeo atestará.

As implementações mais bem-sucedidas são aquelas em que o negócio reconhece a necessidade de orientar e controlar a implementação, seja através do aproveitamento da experiência técnica interna para assumir a arquitetura, ou através do aproveitamento de experiência externa, como as equipas que fornecemos na Spicy Mango.

Repetidamente, vemos o fornecedor a representar apenas os seus próprios interesses, e não os do cliente ou do programa global. As plataformas de vídeo online modernas (OVPs) já raramente são ecossistemas tecnológicos desenvolvidos exclusivamente por uma única entidade, sendo quase todas ambientes baseados em SaaS de múltiplos fornecedores – uma coleção de muitos produtos individuais que fornecem elementos específicos da solução. Uma boa equipa de especialistas técnicos independentes funciona como um árbitro neutro para pôr fim à troca de acusações quando as coisas correm mal.

Construir uma plataforma de streaming de vídeo em direto ou de conteúdos a pedido (OTT) pode ser uma tarefa um pouco assustadora, por isso quis partilhar algumas dicas que achei que poderiam ajudar.

Normalmente, este tipo de projetos começa com uma discussão em que alguém da chefia prometeu o lançamento de uma nova proposta com um prazo louco e inamovível – ou, talvez pior, fez um acordo com um fornecedor de soluções pré-fabricadas e aceitou colocar no mercado algo que cubra todos os casos de utilização imagináveis no mais curto espaço de tempo possível. Soa familiar?

Apesar dos desafios que se avizinham, quis tentar orientá-lo sobre alguns aspetos que, esperamos, o guiem na direção certa. O objetivo? Construir uma plataforma escalável e fiável que não faça da dependência de fornecedores e da escala limitada as duas primeiras características do seu roteiro.


1. Levantamento de requisitos

Os requisitos dividem-se em algumas categorias e grupos de alto nível. Produto, negócio, tecnologia. Normalmente, tudo se enquadra de alguma forma nestas verticais. É um pouco mais fácil redigir os habituais "requisitos funcionais" orientados para o consumidor do que alguns dos requisitos frequentemente desconhecidos ou muitas vezes esquecidos, tais como a gestão fiscal.

A chave no levantamento de requisitos é garantir que todos os detalhes são cobertos. Vou dar-lhe um exemplo prático.

Um gestor de produto irá elaborar um requisito na linha de "Como utilizador, devo ser capaz de pesquisar no site". Um bom arquiteto técnico terá a capacidade de desdobrar isto em 10-15 requisitos individuais, tanto funcionais como não funcionais, que cobrirão áreas como pesquisa de conteúdos, pesquisa de dados, multi-idioma, filtragem, ordenação, persistência, notificações de resultados, resultados de pesquisa nulos, integração de analítica e BI, pesquisa preditiva, tempos de resposta para resultados, entre outros.

A mensagem aqui é que, quanto mais trabalho fizer para garantir que os requisitos sejam EXPLÍCITOS e DETALHADOS, mais dores de cabeça poupará mais tarde, quando a solução fornecida pelo fornecedor não fizer o que pensava que faria. Elimine a ambiguidade.


2. Processo de RFI/RFP e análise de fornecedores

Porque precisamos de uma RFP? Existem muitas razões – mas pense nisto principalmente como um mecanismo para comparar potenciais candidatos e fornecedores para a plataforma de streaming que vai construir.

A elaboração de uma boa documentação de RFI e RFP, juntamente com a definição do processo, são ambas igualmente importantes. (À parte – é importante saber a diferença entre RFI e RFP!) Saber estruturar corretamente um documento de requisitos que um fornecedor possa compreender e responder de uma forma que você consiga compreender, comparar e pontuar irá ajudá-lo mais do que imagina.

Um bom documento e processo de RFP irá:

  • Reduzir o tempo necessário para executar o processo de RFP

  • Permitir que os fornecedores compreendam os seus requisitos e gerem orçamentos e propostas precisos

  • Remover a ambiguidade das respostas – garantindo que os requisitos "não conformes", "conformes" e de "roteiro" sejam claros

  • Destacar aquilo de que os fornecedores são capazes e o que não são

  • Identificar lacunas e áreas de que as suas equipas de negócio, produto e tecnologia necessitam e que não são preenchidas pelo fornecedor principal ou pelo integrador de sistemas

  • Permitir uma comparação direta ("maçãs com maçãs") das respostas dos fornecedores

Para garantir a eficácia – sugerimos também selecionar alguns casos de utilização ao acaso e pedir aos seus 2 ou 3 principais fornecedores para demonstrarem como estas funcionalidades funcionam. Se responderam com "conforme" – rapidamente saberá se estão a dizer a verdade.

Quando escrevemos documentação de RFP e gerimos processos para os nossos clientes, não é invulgar ver mais de 1500 requisitos funcionais e não funcionais definidos para uma plataforma OTT ou de streaming. Se estiver abaixo deste número – provavelmente deverá perguntar-se se cobriu tudo de forma minuciosa e correta.


3. Arquitetura e design da plataforma

Como parte deste percurso, propomo-nos a construir uma plataforma de streaming de vídeo escalável. A fase de arquitetura e design da plataforma avalia os requisitos identificados pelo negócio, compara-os com as soluções propostas pelos fornecedores e parceiros, e trabalha para construir designs escaláveis e referências de soluções que:

  • Garantam que os requisitos para o lançamento possam ser cumpridos

  • Tragam flexibilidade para incorporar requisitos em mudança – projetar a arquitetura a pensar na mudança

  • Identifiquem lacunas nas propostas e gerem soluções para as resolver

  • Reduzam ou eliminem o risco de dependência de fornecedores (vendor lock-in)

  • Suportem requisitos funcionais E não funcionais à escala

  • Permitam uma escala ilimitada de produtores e consumidores - streaming em direto para milhões

  • Garantam que as melhores práticas, padrões e abordagens sejam seguidos

  • Cumpram os critérios de conformidade para os territórios onde irão operar

  • Equilibrem os critérios de tempo, qualidade e custo

  • Cumpram as referências de segurança, desempenho e operacionais

  • E, finalmente, garantam que a solução proporcione valor de negócio

Os arquitetos de plataformas de media e streaming garantem que as soluções propostas representam a melhor forma de implementação – não se limitando apenas ao que o fornecedor ou provedor de soluções tem para oferecer.


4. Um caminho para a implementação

Com um bom trabalho de base, o caminho para a implementação tornar-se-á inevitavelmente mais simples. Independentemente disso, a implementação de plataformas OTT escaláveis, altamente eficazes, resilientes e fiáveis ainda dá trabalho – e muitas vezes requer "squads" ou equipas de indivíduos focados para assumirem o desenvolvimento e a implementação de áreas-chave como Identidade, Faturação, Subscrições, Conteúdo, Conformidade, Analítica e Dados, Aplicações e outras.

Estas equipas focadas recebem autonomia para se autogerirem, guiadas por líderes experientes que, idealmente, já implementaram serviços semelhantes anteriormente, e guiarão cada fluxo de trabalho desde o design até à produção.

Não é segredo que cada vez mais organizações empregam cada vez menos especialistas de domínio, com algumas unidades de negócio formadas unicamente por equipas de produto (desenvolvedores, gestores, designers, profissionais de marketing). O desafio? Falta o conhecimento de domínio e a experiência técnica necessária para poder exigir responsabilidades aos fornecedores quando as coisas se tornam tecnicamente difíceis.

Embora os fornecedores proponham o que são capazes de oferecer para cumprir os requisitos definidos pelo negócio, esta não é, de forma alguma, a única via, como qualquer bom arquiteto de plataformas de vídeo atestará.

As implementações mais bem-sucedidas são aquelas em que o negócio reconhece a necessidade de orientar e controlar a implementação, seja através do aproveitamento da experiência técnica interna para assumir a arquitetura, ou através do aproveitamento de experiência externa, como as equipas que fornecemos na Spicy Mango.

Repetidamente, vemos o fornecedor a representar apenas os seus próprios interesses, e não os do cliente ou do programa global. As plataformas de vídeo online modernas (OVPs) já raramente são ecossistemas tecnológicos desenvolvidos exclusivamente por uma única entidade, sendo quase todas ambientes baseados em SaaS de múltiplos fornecedores – uma coleção de muitos produtos individuais que fornecem elementos específicos da solução. Uma boa equipa de especialistas técnicos independentes funciona como um árbitro neutro para pôr fim à troca de acusações quando as coisas correm mal.

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.

Mais insights que você pode gostar

Mais insights que você pode gostar

Mais insights que você pode gostar

Continue a jornada - com mais algumas informações relacionadas que achamos que você pode gostar.

Continue a jornada - com mais algumas informações relacionadas que achamos que você pode gostar.