Web Development Project: VECTOR SOLUTIONS

#Visão geral do projeto

A Vector Solutions faz parte do grupo VECTOR, sediado em Gdynia, na ul. Krzemowa 6. O grupo opera desde 1988 e começou por fabricar amplificadores para instalações de televisão por cabo. Em 2001 trabalhava já na entrada do DOCSIS nas redes de cabo polacas e, a partir de 2007, passou a desenvolver sistemas de telemetria. Hoje reúne mais de duzentos engenheiros de software, de sistemas e de hardware. Os clientes são operadores de cabo, empresas de telecomunicações e radiodifusores de televisão, ou seja, compradores que leem uma ficha técnica antes de olharem para uma página inicial.

O projeto chegou-nos em 2017, o mesmo ano em que o grupo abriu o processo de rebranding que veio a fechar em 2019 com a criação da VECTOR BLUE HUB. A implementação demorou cerca de seis semanas. O layout e a colocação dos elementos vieram do cliente. Do nosso lado ficaram os templates, o comportamento responsivo, o modelo de conteúdos, as integrações e o trabalho de desempenho, e foi aí que o calendário foi gasto.

#Contexto do cliente

#Liderança na indústria

A posição da Vector Solutions não assenta numa campanha de marca, mas em três décadas de presença junto de quem compra infraestrutura. A atividade cobre a Polónia e vários mercados europeus, o desenvolvimento de novas soluções é contínuo e o conhecimento do setor abrange simultaneamente o mundo do cabo, o das telecomunicações e o dos media. As relações com os grandes intervenientes do mercado são de parceria prolongada, não de fornecimento pontual, e o portefólio cobre uma gama larga de tecnologias de comunicação e de infraestrutura, do equipamento à camada de software que o gere.

Esta descrição conta para o site por uma razão prática: um catálogo que cobre tantas gerações de produto não cabe num menu de cinco entradas, e um comprador que mantém um contrato há dez anos não procura a mesma informação que alguém que chega de uma pesquisa.

#O que isso significou para o site

Trinta anos no negócio do equipamento deixam marca no modelo de conteúdos. O catálogo de soluções atravessa várias gerações tecnológicas: parte continua instalada e mantida nas redes dos operadores, parte está em retirada, e a documentação de umas e de outras tem de continuar acessível lado a lado. Um site que trate isto como uma brochura com cinco cartões de serviço falha na primeira pergunta concreta que alguém lhe fizer.

Daí que o modelo tivesse de suportar uma solução com vários variantes, cada variante com a sua própria especificação, e uma especificação que por vezes só é visível a um parceiro autenticado. Não é uma escolha estética, é uma consequência direta do negócio: parte da ficha técnica está coberta por acordos de confidencialidade e não pode ficar exposta a quem apenas passa pela página.

A segunda consequência tem a ver com quem lê. Um engenheiro de um operador de cabo procura um parâmetro específico, não uma narrativa sobre inovação. Por isso a pesquisa e a filtragem por atributos técnicos ficaram acima da camada visual na ordem de prioridades, até porque o layout foi fornecido pelo cliente e não era objeto de discussão. O que ficou em aberto, e foi discutido, foi a ordem pela qual a informação aparece dentro de cada vista.

#Implementação técnica

#Arquitetura da plataforma

A pilha é WordPress com um tema dedicado, Redis para cache de objetos, Varnish à frente para cache de páginas e Cloudflare como camada de borda, junto ao visitante. Três níveis de cache na mesma instalação parecem excesso até se perceber que cada um responde a um tipo de pedido diferente. A Cloudflare entrega os recursos estáticos e as páginas anónimas sem chegar a tocar no servidor. O Varnish guarda as vistas compostas do catálogo, aquelas cuja construção custa uma dúzia de consultas à base de dados. O Redis encurta essas mesmas consultas para tudo o que, apesar de tudo, acaba por chegar ao PHP.

A tensão arquitetural deste projeto está exatamente no ponto onde o cache encontra a personalização. O site tem de distinguir um visitante anónimo de um parceiro autenticado e de um colaborador interno, e mostrar a cada um deles uma versão diferente do mesmo endereço. O cache de borda detesta isto por definição, porque todo o seu ganho vem de servir o mesmo byte a muita gente. A resolução passou por separar as camadas: o esqueleto da página e o catálogo são comuns e ficam em cache de forma agressiva, enquanto tudo o que depende do papel do utilizador é obtido por um pedido separado depois da autenticação e nunca entra no Varnish.

Sobre esta base assentam três componentes. O primeiro é o sistema de gestão de ofertas, que permite compor propostas a partir de módulos, aplicar tabelas de preços de vários níveis conforme o tipo de parceiro, gerar automaticamente o documento de proposta e devolver o resultado aos sistemas de faturação, de modo a que aquilo que foi proposto e aquilo que é faturado tenham a mesma origem.

O segundo é a apresentação do portefólio, com estudos de caso, uma galeria de projetos filtrável e conteúdo que carrega de forma progressiva à medida que o leitor desce a página, em vez de obrigar a trazer todo o acervo no primeiro pedido.

O terceiro é a integração de dados em tempo real, que traz para o site informação de tendências do setor e de análise de mercado a partir de APIs externas, sem obrigar ninguém a atualizar páginas à mão sempre que um valor muda.

#Experiência de frontend

O layout e a colocação dos elementos vieram do cliente, pelo que a nossa parte foi traduzi-los em templates, em comportamento responsivo e num modelo de conteúdos que se consiga manter depois do arranque. A estética não estava em causa, a ordem da informação estava.

A interface ajusta o conteúdo ao perfil de quem a consulta, permite filtrar as soluções por várias dimensões ao mesmo tempo e colocá-las lado a lado numa ferramenta de comparação. A filtragem multidimensional é precisamente o sítio onde um catálogo técnico costuma cair: cada atributo acrescentado multiplica o número de combinações possíveis, e uma implementação ingénua interroga a base de dados uma vez por cada filtro ativo. Aqui o conjunto de atributos é calculado uma vez e guardado em Redis, e mudar um filtro não recarrega a página, apenas substitui a lista de resultados.

O layout é mobile-first e cumpre a WCAG 2.1, o que num catálogo de produto significa sobretudo duas coisas concretas. As tabelas de especificação têm cabeçalhos associados às células, e os filtros funcionam com teclado. Sem essa associação, uma tabela de parâmetros técnicos é, para um leitor de ecrã, uma sequência de números sem significado, e esses números são o conteúdo principal da página.

#Sistemas de backend

Do lado da gestão de conteúdos, as soluções e os estudos de caso vivem em tipos de conteúdo próprios, com uma taxonomia que descreve família de produto, geração tecnológica e área de aplicação. O conteúdo é multilingue, passa por um fluxo de aprovação antes de ficar público e guarda histórico de versões, o que num catálogo com obrigações contratuais é menos uma comodidade editorial do que uma forma de saber o que estava escrito num determinado momento.

A gestão de utilizadores assenta em controlo de acessos baseado em papéis, com portal de parceiros, contas de cliente, acompanhamento de contactos comerciais e ligação ao CRM. A parte de integrações liga o site ao Salesforce CRM, ao HubSpot, a gateways de pagamento e aos sistemas de faturação do cliente, sempre através de um adaptador próprio por sistema em vez de ligações diretas espalhadas pelo código do tema.

#Funcionalidades avançadas

#Sistemas de ofertas dinâmicas

A configuração de ofertas trabalha por módulos: cada solução pode ser combinada com outras, os escalões de preço dependem do tipo de parceiro e do volume, e existem regras de disponibilidade geográfica porque nem todo o equipamento é oferecido em todos os mercados. Promoções e descontos são aplicados como regras sobre a oferta montada, não escritos à mão em cada documento, e a geração do contrato parte desse mesmo conjunto de dados.

Para clientes com contrato próprio há tabelas de preços dedicadas, cálculo de desconto por volume, opções white-label e acesso por API para quem prefere consumir a informação a partir dos seus próprios sistemas em vez de a ler no ecrã. A razão pela qual tudo isto tem de partir de uma única fonte é simples: no momento em que a proposta impressa e o sistema de faturação deixam de concordar, é sempre a página que é acusada de estar errada.

#Painel em tempo real

O painel apresenta tendências do setor, indicadores de adoção tecnológica e de desempenho de mercado, com vistas filtráveis, comparações ao longo do tempo, leitura por região e exportação dos dados para quem precisa de os trabalhar fora do site. Há também relatórios gerados de forma agendada e alertas configuráveis, para que a informação vá ao encontro de quem a usa em vez de esperar que alguém se lembre de abrir o painel.

#Experiência de utilizador personalizada

A personalização assenta num perfil construído a partir do setor, da função e dos interesses demonstrados, e usa o comportamento registado no site para sugerir conteúdo relacionado e montar painéis diferentes conforme o tipo de utilizador. A comunicação de seguimento parte do mesmo perfil. O limite desta abordagem é conhecido e foi respeitado: quanto mais uma página depende de quem a está a ver, menos pode ser servida a partir de cache, e por isso a personalização foi mantida em blocos identificáveis, carregados à parte, em vez de espalhada por toda a página.

#Desempenho e escalabilidade

#Otimização técnica

Do lado da velocidade, o conteúdo essencial é renderizado no servidor para que a primeira visualização não dependa de JavaScript, o conteúdo abaixo da dobra carrega de forma diferida, as imagens são otimizadas e servidas em formatos modernos, o CSS crítico segue embutido no documento e as consultas à base de dados foram revistas uma a uma, com atenção particular às que crescem com o tamanho do catálogo.

A estratégia de cache é a descrita acima, com uma nota importante sobre a invalidação: cada camada tem de saber quando deixar de acreditar no que guardou. Publicar uma alteração de preço e continuar a servir a versão anterior durante horas é pior do que não ter cache nenhum, porque o erro é silencioso. Por isso a publicação de conteúdo dispara a limpeza das entradas afetadas nas várias camadas, e as respostas de API são guardadas com tempos de vida diferentes consoante a rapidez com que a informação de origem muda.

Em termos de escalabilidade, a infraestrutura acompanha a carga, o tráfego é distribuído e as operações não críticas saem do pedido do utilizador. Quando alguma dependência externa não responde, a página degrada-se de forma controlada: falta a secção que dependia dessa fonte, não falta o site.

#Medidas de segurança

A ligação é cifrada de ponta a ponta, existe firewall de aplicação web e proteção contra ataques de negação de serviço, o Wordfence trata a deteção de intrusão ao nível da aplicação e são feitas auditorias e testes de intrusão com regularidade. Do lado dos dados, há conformidade com o RGPD, cifra em repouso e em trânsito, registo dos acessos, cópias de segurança regulares e um plano de recuperação testado, não apenas escrito.

Num site com portal de parceiros isto tem um aspeto que se esquece com facilidade: a superfície de risco não é a página institucional, é a área autenticada e a documentação que ela protege. É por isso que a verificação de permissões descrita mais à frente pesa mais, neste projeto, do que qualquer camada de proteção colocada à entrada.

#SEO e marketing digital

#Otimização para motores de busca

Do lado técnico, a organização e os serviços são descritos em dados estruturados, o mapa XML reflete a hierarquia real do catálogo, os endereços são legíveis e estáveis, as etiquetas canónicas resolvem a duplicação inevitável que a filtragem gera, e as ligações internas seguem a estrutura do catálogo em vez de serem colocadas a gosto.

Em termos de conteúdo, existem páginas dedicadas a cada segmento do setor, um glossário de termos tecnológicos, estudos de caso otimizados e uma biblioteca de documentos técnicos. Num mercado onde a pesquisa é feita com vocabulário de especialidade, o glossário não é um adorno: é frequentemente a página por onde alguém entra antes de chegar ao produto.

Sendo o site multilingue, o hreflang liga as versões entre si, há variações de conteúdo por país e o alojamento e a entrega foram pensados para servir vários mercados sem penalizar os mais distantes.

#Análise e insights

A analítica não ficou parada desde o arranque. A implementação de 2017 começou com o Universal Analytics, porque o Google Analytics 4 só surgiu em 2020 e não podia estar presente no início. A migração veio mais tarde, já no âmbito da manutenção. Vale a pena dizê-lo de forma explícita, porque os estudos de caso apresentam habitualmente a pilha de hoje como aquela com que o projeto arrancou, e nesse caso deixa de ser possível distinguir uma decisão de projeto de uma substituição imposta pelo fornecedor anos depois.

Para lá da ferramenta, a medição cobre eventos personalizados, análise de funil e o percurso do utilizador. Num catálogo técnico, o evento mais valioso não é o envio de um formulário, é a transferência de uma ficha de especificação: mostra que variante de produto prende de facto a atenção de um engenheiro, muito antes de alguém escrever um pedido de proposta. O painel de relatórios acompanha o tráfego, a origem dos contactos comerciais, o desempenho de cada conteúdo e a posição nas pesquisas.

#Resultados e impacto

Esta secção costumava trazer uma série de percentagens. Nenhuma delas sobrevive a uma verificação contra os nossos próprios registos: o projeto entrou em produção em 2017 e as medições, se alguma vez foram feitas, ficaram numa caixa de correio a que já não temos acesso. Um número apresentado como medição e incapaz de nomear a sua fonte é pior do que não haver número nenhum, por isso fica aqui o que pode ser dito com honestidade.

Do lado do negócio, a plataforma passou a ser o sítio onde a oferta é montada e apresentada, em vez de a proposta nascer numa troca de mensagens e só depois ser copiada para um documento. O portal de parceiros trouxe para autosserviço um conjunto de pedidos que antes passavam pelo suporte, e a integração de dados em tempo real eliminou atualizações manuais que, por serem manuais, ficavam desatualizadas.

Do lado operacional, o ganho está na origem única dos dados. A ficha técnica, o preço aplicável a um parceiro e o documento de proposta deixaram de ser três versões independentes da mesma informação, o que reduz o trabalho de revisão e, sobretudo, reduz a probabilidade de alguém enviar a versão errada.

O trabalho de desempenho teve três alvos declarados. O peso das páginas, mantendo as vistas do catálogo fora do PHP através da camada Varnish. O tempo até ao primeiro byte, encurtando o trabalho de base de dados nas vistas que não podem ser guardadas em cache. E a taxa de acerto do cache, que num site com esta forma é o fator que decide se os outros dois importam, porque uma falha de cache faz o pedido percorrer todo o caminho até à origem, por muito afinada que a origem esteja.

A fiabilidade assenta no comportamento de recurso descrito a seguir e não num valor de disponibilidade: uma avaria num sistema externo degrada uma secção e não a página, e a carga do dia a dia fica suficientemente abaixo do limite testado para que um lançamento não exija uma resposta de emergência.

#Desafios e soluções

#Desafio 1: requisitos de integração complexos

Problema: integrar vários sistemas externos, do CRM à faturação, mantendo o desempenho da página.

Solução: uma camada intermédia, na qual o WordPress nunca fala diretamente com um sistema do cliente, mas sim através do seu próprio adaptador para cada um. A obtenção de dados é assíncrona, pelo que um CRM inacessível não impede a página de ser construída, e as respostas são guardadas em cache com um tempo de vida por fonte, porque uma tabela de preços muda uma vez por trimestre e um estado de disponibilidade muda dentro da hora.

A decisão que mais pesou foi o que acontece quando uma integração falha. O comportamento habitual é mostrar um erro ou uma secção vazia, o que numa página comercial se lê como se o site inteiro estivesse avariado. Aqui cada adaptador tem um valor de recurso: a última resposta conhecida, guardada em cache, e quando nem essa existe, uma variante estática da secção. O visitante vê então uma página sem o painel de dados em direto, e não uma mensagem de erro. A indisponibilidade de um sistema externo passa a ser um acontecimento para a monitorização, não para quem está a ler.

#Desafio 2: desempenho de dados em tempo real

Problema: mostrar dados em direto sem penalizar o tempo de carregamento das páginas.

Solução: os dados em direto nunca bloqueiam a primeira renderização. A página chega completa sem eles e o painel é preenchido depois, através de pontos de acesso separados entre os críticos e os que podem esperar. Os dados de referência, que raramente mudam, ficam do lado do navegador, pelo que uma segunda visita não volta a fazer a mesma pergunta ao servidor.

A frequência de atualização é ajustada à velocidade a que cada valor se move, em vez de ser definida com um único intervalo para o painel inteiro. Essa distinção decide a fatura: interrogar tudo de poucos em poucos segundos impressiona numa demonstração e gera tráfego que alguém paga durante anos, sem dar ao leitor um único facto que ele não tivesse um minuto depois.

#Desafio 3: complexidade de múltiplas funções de utilizador

Problema: servir parceiros, clientes, potenciais clientes e pessoal interno, com necessidades e permissões diferentes.

Solução: controlo de acessos baseado em papéis, com vistas de painel distintas para o parceiro, o cliente e o colaborador interno, e um menu que esconde aquilo a que um papel não chega, em vez de o conduzir a um ecrã de recusa.

A armadilha destes sistemas é sempre a mesma: verificar permissões na interface e não junto aos dados. Uma ligação escondida no menu não protege ninguém de escrever o endereço à mão, e num catálogo em que parte da especificação está sujeita a acordo de confidencialidade isso não é um detalhe cosmético. A verificação do papel vive por isso onde o conteúdo é obtido, e a camada de apresentação limita-se a refletir o que já foi decidido abaixo. O mesmo mecanismo entra na chave de cache, de modo que um parceiro nunca recebe uma página construída para alguém com outras permissões.

#Desafio 4: picos de tráfego em grandes eventos

Problema: os anúncios de produto concentram numa janela curta um volume de visitas muito acima do dia normal.

Solução: os recursos estáticos são servidos pela CDN, as consultas à base de dados foram revistas à procura das que crescem com o tamanho do catálogo, e as operações não críticas, como o envio de notificações ou a reconstrução do índice de pesquisa, passaram para uma fila e acontecem fora do pedido do utilizador.

Os testes de carga antes de um anúncio correram sobre uma cópia da produção, não sobre uma instalação vazia, e esta é a frase importante da secção. O desempenho do WordPress com um catálogo de milhares de variantes e uma dúzia de integrações não tem relação nenhuma com o desempenho de uma instalação acabada de criar com um tema de demonstração. O estrangulamento não estava no PHP, estava na eficácia do cache: num lançamento, o tráfego cai sobre um endereço que ninguém visitou antes, pelo que a onda inteira chega ao backend ao mesmo tempo. Aquecer o cache antes de publicar o anúncio sai mais barato do que acrescentar capacidade que fica parada o resto do trimestre.

#Suporte e evolução contínuos

#Programa de manutenção

O acompanhamento técnico assenta em monitorização com alertas, atualizações de segurança regulares, revisões periódicas de desempenho e testes de carga antes dos anúncios de produto maiores. Esta última linha não é uma formalidade: é exatamente o cenário em que o cache não ajuda, porque o tráfego entra em endereços novos.

Do lado editorial, o trabalho corrente é acrescentar estudos de caso, atualizar o portefólio de produtos, integrar notícias do setor, manter a otimização para pesquisa e produzir relatórios de análise que digam alguma coisa a quem os recebe.

#Melhoria contínua

O desenvolvimento de funcionalidades segue um planeamento por trimestres, alimentado pelos comentários de quem usa a plataforma e pelas iterações de otimização de desempenho e de reforço de segurança. A parte de consultoria consiste em manter o alinhamento entre a estratégia digital e o que o site consegue fazer, acompanhar a evolução tecnológica do setor e propor melhorias de conversão e de experiência de utilização quando os dados as justificam.

#Resumo da pilha tecnológica

#Plataforma central

WordPress com tema dedicado à Vector Solutions, Advanced Custom Fields Pro para o modelo de conteúdos, um conjunto de plugins próprios para as funcionalidades específicas deste projeto e WPML para o suporte multilingue.

#Desempenho e segurança

Redis para cache de objetos, Varnish para cache de páginas, Cloudflare como camada de borda e de proteção, Wordfence para a segurança ao nível da aplicação e WP Rocket na otimização do lado do frontend.

#Integrações

Salesforce CRM, HubSpot, gateways de pagamento e os sistemas de faturação do cliente. A analítica arrancou em Universal Analytics em 2017 e o Google Analytics 4 entrou mais tarde, já em manutenção.

#Ferramentas de desenvolvimento

Git para controlo de versões, Docker para o ambiente local, GitHub Actions para o fluxo de integração e entrega, e um ambiente de testes separado por onde passa tudo antes da produção.

#Percurso da implementação

O conjunto demorou cerca de seis semanas, contando da análise de âmbito até à publicação. O layout e a colocação dos elementos vieram do cliente, pelo que a fase que noutros projetos consome a maior parte do calendário desapareceu aqui. Esse tempo foi para o modelo de conteúdos e para as integrações, isto é, para as partes que não se veem numa maqueta e que decidem se o site se consegue manter depois do arranque.

A decisão determinante surgiu na fase de testes. Os caminhos por onde o tráfego passa foram verificados sobre uma cópia da produção, e não sobre uma instalação limpa com dados de demonstração. Num catálogo desta dimensão a diferença é estrutural: uma consulta que devolve resultados em poucos milissegundos com vinte produtos pode crescer duas ordens de grandeza com milhares de variantes, e numa instalação vazia ninguém chega a ver o problema. O mesmo vale para o cache, cuja eficácia só é mensurável sobre uma distribuição real de pontos de entrada.

Depois do arranque, o projeto entrou em manutenção: monitorização e alertas, atualizações de segurança regulares, revisões periódicas de desempenho e testes de carga antes dos anúncios de produto de maior dimensão. Este ritmo é o que mantém válidas as decisões tomadas durante as seis semanas iniciais, porque um catálogo que continua a crescer altera, com o tempo, as premissas em que assentaram.

#Conclusão

O projeto da Vector Solutions mostra como uma implementação exigente em WordPress pode servir de espinha dorsal digital a uma empresa tecnológica que trabalha na primeira linha das telecomunicações europeias. Ao juntar integração de dados externos, conteúdo ajustado ao perfil de quem lê e um trabalho sério de cache e desempenho, ficou uma plataforma que apresenta o catálogo da Vector Solutions e, ao mesmo tempo, suporta o processo comercial que vive à volta dele.

O que decide o resultado de um projeto assim é perceber que, para uma empresa tecnológica B2B, o site não é uma brochura: é uma ferramenta de trabalho que tem de suportar processos complexos, ligar-se aos sistemas já em uso e manter-se compreensível para quem o atualiza anos depois. É também por isso que este texto prefere descrever mecanismos e compromissos a exibir percentagens que ninguém consegue já verificar.