Decidir que browsers, dispositivos e versões uma aplicação suporta parece uma tarefa técnica, mas as suas consequências afetam o produto, o negócio e as operações. Uma lista demasiado abrangente pode consumir capacidade de desenvolvimento e testes; uma lista demasiado restritiva pode excluir utilizadores importantes ou incumprir compromissos com clientes.
A resposta não consiste em acompanhar todos os lançamentos nem em escolher uma versão por hábito. Consiste em documentar os ambientes suportados, o nível de garantia oferecido e as condições em que a decisão será revista. Esta matriz transforma uma discussão recorrente num critério partilhado.
A compatibilidade é uma decisão de produto e de operações
Um ambiente compatível não é simplesmente aquele em que a aplicação abre. Também importa saber se as principais funcionalidades funcionam corretamente, se a experiência é aceitável e se a equipa consegue detetar e resolver problemas. Por isso, a decisão deve refletir a utilização real e a capacidade de manutenção, e não apenas uma preferência técnica.
Comece por identificar as consequências de uma falha. Numa ferramenta interna, poderá ser razoável disponibilizar uma alternativa temporária; num processo de compra ou numa aplicação essencial para o trabalho, o impacto poderá ser maior. Também podem existir compromissos contratuais, políticas de segurança ou requisitos de acessibilidade que condicionem os ambientes a considerar.
Defina quem propõe, quem valida e quem aprova a matriz. A equipa de produto pode priorizar necessidades e segmentos; a equipa de tecnologia pode avaliar a viabilidade e os riscos; o suporte e a área de negócio podem contribuir com incidentes e compromissos assumidos com os utilizadores. Sem um responsável pela decisão, as exceções tendem a multiplicar-se sem que ninguém assuma o respetivo custo.
Reúna evidências antes de escolher versões
A primeira fonte de informação é o contexto de utilização. Apure que browsers e dispositivos os utilizadores empregam em tarefas relevantes, e não apenas quais surgem com maior frequência no tráfego geral. Distinga, por exemplo, o início de sessão, a conclusão de uma operação crítica e a consulta de conteúdos. Um ambiente pouco frequente pode ser indispensável para um cliente ou processo específico.
Compare vários indicadores:
- Analítica de utilização: identifique os browsers, sistemas operativos, dimensões de ecrã e padrões de utilização disponíveis. Interprete os dados com prudência: podem não incluir utilizadores que não autorizam a medição ou que não concluem o carregamento.
- Suporte e vendas: reveja problemas recorrentes, necessidades declaradas pelos clientes e acordos existentes. Distinga um pedido isolado de um requisito sustentado por evidências.
- Requisitos técnicos: registe as dependências do produto, as funcionalidades do browser necessárias, as políticas de segurança e as restrições dos dispositivos geridos.
- Capacidade da equipa: estime o esforço de desenvolvimento, testes, diagnóstico e manutenção. Acrescentar um ambiente implica mais do que incluí-lo numa lista.
Se não houver dados suficientes, registe essa incerteza. Pode validar a necessidade através de entrevistas, registos de suporte ou um teste delimitado. Não transforme a falta de evidências numa afirmação de que ninguém utiliza esse ambiente.
Defina critérios e níveis de suporte
Estabeleça critérios que possam ser aplicados de forma consistente. Podem incluir a proporção e a relevância da utilização, a criticidade das tarefas, a compatibilidade com as tecnologias necessárias, o risco de segurança, os requisitos dos clientes e o custo de manter os testes. Não é necessário reduzi-los a uma única pontuação: uma obrigação contratual, por exemplo, pode sobrepor-se ao volume de utilização.
É útil distinguir três níveis:
- Suporte garantido: o ambiente faz parte do compromisso publicado. As principais funcionalidades são testadas e os defeitos reproduzíveis são tratados de acordo com o processo normal do produto.
- Validado: a equipa verificou um conjunto definido de fluxos, mas não garante cobertura completa nem uma prioridade equivalente para todos os problemas. Especifique o que foi validado e os limites conhecidos.
- Não suportado: a equipa não testa nem garante o funcionamento. Se a aplicação permitir o acesso, indique-o sem sugerir que a experiência está coberta.
Evite expressões ambíguas como «compatível com todos os browsers modernos». Indique nomes e versões ou um critério verificável para determinar as versões suportadas. Se o suporte se basear em versões recentes, defina como se calcula esse período e onde é publicado. A precisão evita interpretações diferentes da mesma promessa por parte de utilizadores e equipas.
Equilibre o custo de manter ambientes antigos
O suporte de versões antigas pode exigir soluções alternativas, mais combinações de teste e atenção a defeitos que não surgem em ambientes atuais. Mas também tem custos retirar esse suporte: utilizadores afetados, operações interrompidas, perda de acesso e trabalho de comunicação ou migração. A decisão deve comparar ambos os lados, em vez de tratar a redução da manutenção como um benefício automático.
Entre os sinais que justificam reavaliar um ambiente estão uma utilização persistentemente baixa, a inexistência de requisitos conhecidos, falhas de segurança relevantes, limitações que impedem alterações necessárias ou uma carga de testes desproporcionada. Nenhum destes sinais é suficiente por si só. Confirme se os dados representam a população afetada e se existe uma alternativa viável, como atualizar o dispositivo, utilizar outro browser ou acordar uma transição com o cliente.
Antes de retirar o suporte, identifique as tarefas que poderão deixar de funcionar, o número e o tipo de utilizadores potencialmente afetados, as dependências internas e a data da alteração. Defina se haverá um período de aviso, um canal de esclarecimento ou uma exceção temporária. Cada exceção deve ter um responsável, uma justificação, um âmbito e uma data de revisão; caso contrário, pode transformar-se facilmente em suporte por tempo indeterminado.
Valide a matriz e comunique-a com clareza
A matriz deve corresponder a testes reais. Para cada ambiente com suporte garantido, decida que fluxos críticos serão verificados e em que momento: antes da publicação, através de testes automatizados quando forem adequados e por meio de verificações manuais para comportamentos que o exijam. Não é necessário testar todas as combinações possíveis de dispositivo, versão e configuração, mas é importante explicar a cobertura escolhida e os riscos que ficam de fora.
Priorize os percursos que afetam resultados importantes: acesso, operação principal, formulários, pagamentos, se existirem, e recuperação de erros. Verifique também a apresentação em dimensões de ecrã relevantes, a navegação por teclado e as mensagens apresentadas quando uma funcionalidade não está disponível. As ferramentas de analítica e desempenho podem fornecer indicadores, mas não substituem os testes funcionais nem a investigação de incidentes.
Publique a matriz num local acessível aos utilizadores e às equipas internas. Inclua a data de atualização, os níveis de suporte, as limitações conhecidas, as alternativas recomendadas e um canal para comunicar problemas. Se um ambiente não suportado conseguir aceder à aplicação, explique que o funcionamento não é garantido; não apresente um aviso como se fosse uma validação.
Modelo prático e ciclo de revisão
Uma matriz útil pode ser mantida numa tabela interna e resumida na documentação para os utilizadores. Registe, pelo menos:
- Ambiente: browser ou aplicação, sistema operativo, dispositivo e versão ou regra de atualização.
- Nível de suporte: garantido, validado ou não suportado.
- Evidências e risco: utilização observada, requisitos conhecidos, limitações e fluxos testados.
- Responsável: pessoa ou equipa que mantém a decisão e coordena os incidentes.
- Condição de revisão: data acordada ou alteração que obriga a reavaliar a decisão, como uma nova dependência, um incidente ou um requisito de cliente.
Reveja a matriz com uma periodicidade acordada e também quando ocorrerem alterações relevantes; não é necessário modificá-la sempre que surge uma nova versão. Antes de a atualizar, avalie o impacto, os testes necessários, a comunicação e as alternativas. Depois, registe a justificação da decisão, para que o ciclo seguinte não recomece do zero.
O resultado não é uma promessa de funcionamento perfeito em qualquer equipamento. É uma definição explícita dos ambientes em que a equipa investe na validação e manutenção do produto, da incerteza que aceita e da forma como responderá se as necessidades mudarem. Esta clareza permite tomar decisões proporcionais e revê-las com menos surpresas.