O elemento mais lento da sua aplicação pode ser... uma pessoa.
Quando uma empresa diz que a sua aplicação é lenta, a primeira reação costuma ser muito técnica. É preciso verificar o servidor. O banco de dados. A API. As consultas SQL. O cache. A infraestrutura. O tamanho dos arquivos. JavaScript. O tempo de resposta de cada serviço.
E isso é totalmente correto. O desempenho técnico tem enorme importância.
Só que, às vezes, todos os gráficos parecem bons, o servidor responde rapidamente, a aplicação carrega em um tempo razoável, e os utilizadores ainda dizem: "Isso demora demais."
E então surge uma pergunta mais interessante. Talvez a aplicação nem seja lenta. Talvez ela simplesmente obrigue a pessoa a esperar.
2 segundos de resposta, 20 minutos de trabalho
Imaginemos um colaborador que precisa preparar uma proposta para um cliente.
O sistema funciona bem. Cada tela abre rapidamente. Não há erros. O servidor responde quase de imediato.
Só que, para preparar a proposta, o colaborador precisa: abrir o cliente, ir até o pedido, copiar o número do produto, abrir um segundo módulo, pesquisar o produto, reescrever os dados, voltar à primeira tela, escolher a categoria, passar para a aba seguinte, obter os preços, verificar manualmente o desconto, copiar o resultado para o Excel e, depois, reescrevê-lo novamente no sistema.
Cada operação individual pode levar alguns segundos.
Tecnicamente, tudo funciona muito bem. Só que todo o processo leva 20 minutos.
E é justamente aqui que a compreensão clássica de desempenho deixa de ser suficiente.
Porque o utilizador não se interessa principalmente pelo tempo de resposta da API. Ele se interessa pelo tempo necessário para concluir a tarefa.
O desempenho técnico é apenas o começo
O desempenho do sistema pode ser medido de muitas formas.
Podemos analisar o tempo de resposta do servidor, o tempo de carregamento da vista, as consultas ao banco de dados, o uso de memória, a carga do processador ou os atrasos entre serviços.
Essas são métricas muito importantes. Mas existe ainda uma segunda camada.
Perceived performance, ou seja, o desempenho percebido pelo utilizador.
E, num sentido ainda mais amplo, podemos olhar para o operational performance - ou seja, quão rapidamente e com quanta fluidez uma pessoa consegue concluir uma tarefa real usando o sistema.
E é precisamente nesta última camada que as empresas perdem mais tempo com frequência. Porque é possível construir uma aplicação extremamente rápida, que ainda assim será uma ferramenta de trabalho lenta.
Às vezes, o sistema mais lento é uma sequência de sete telas
Suponhamos que um colaborador trate de uma reclamação.
O sistema exige sete passos.
Primeiro, abrir o cliente.
Depois, o pedido.
Em seguida, o produto.
Depois, o formulário de reclamação.
Depois, a categoria do problema.
Em seguida, a decisão.
No final, a confirmação.
Cada tela carrega em 0,5 segundo.
Do ponto de vista do desenvolvedor, tudo pode parecer muito bom. Mas o utilizador fez sete transições, mudou de contexto sete vezes e teve de pensar sete vezes no que fazer a seguir.
Se esse tipo de operação é executado dezenas de vezes por dia, o problema deixa de ser uma questão de conveniência. Torna-se um custo. E não se trata apenas do tempo gasto em frente ao ecrã. Há também o cansaço, o número de erros, a necessidade de corrigir dados, tarefas interrompidas e a carga crescente sobre o colaborador.
Um formulário com 40 campos não é rápido só porque abre depressa
Esse é um dos exemplos clássicos.
O formulário abre num instante. - Ótimo.
Só que o utilizador precisa preencher 40 campos.
Parte das informações a empresa já possui.
Parte pode ser obtida no CRM.
Parte pode ser calculada.
Parte depende de respostas anteriores.
E, mesmo assim, o sistema pergunta tudo novamente à pessoa.
Nesse caso, o problema não é o desempenho da aplicação.
O problema é o desenho do processo e da interface.
Um bom sistema deve usar os dados que já possui.
Se o cliente informou o endereço de entrega no pedido anterior, por que o colaborador deve digitá-lo novamente? Se o sistema conhece a empresa do cliente, por que o utilizador precisa selecionar esses dados outra vez? Se a resposta à primeira pergunta elimina metade dos campos seguintes, por que todos eles estão visíveis desde o início?
Às vezes, a melhor forma de acelerar uma aplicação não é otimizar o código. É eliminar o trabalho que o utilizador não deveria fazer.
O tempo humano multiplicado pela escala é o mais caro
Um minuto extra pode parecer nada.
O colaborador executa a operação 5 vezes por dia. - 5 minutos.
Ao longo de um mês, isso já passa de 1,5 hora.
Mas e se forem 20 pessoas? E se a operação ocorrer 30 vezes por dia? E se envolver todo o departamento? E se o sistema for usado pelos próximos cinco anos?
Nesse caso, um único minuto deixa de ser apenas um minuto. Torna-se um custo operacional.
Por isso, ao projetar um sistema para uma empresa, vale a pena perguntar não só: "Quanto tempo leva a resposta do servidor?"
mas também: "Quanto tempo uma pessoa precisa para concluir a tarefa?"
São duas perguntas completamente diferentes.
O sistema pode ser rápido e o processo, lento
Este é um problema ainda mais amplo.
Imaginemos um processo de compras numa empresa.
- O colaborador submete uma solicitação.
- O sistema grava-a imediatamente.
- Mas depois ele precisa esperar pela aprovação do superior.
- O superior recebe uma mensagem.
- Abre o sistema.
- Verifica o documento.
- Encaminha-o para as finanças.
- As finanças verificam o orçamento.
- Depois, alguém precisa aprovar o pedido.
Tecnicamente, a aplicação pode funcionar na perfeição. E o processo leva três dias.
Podemos dizer que a aplicação é rápida?
Tecnicamente - talvez.
Do ponto de vista do negócio - o colaborador espera três dias.
E é precisamente por isso que o design de sistemas empresariais exige olhar para além da interface. É preciso ver todo o fluxo de trabalho.
"Por favor, aguarde" também é um elemento de UX
Há ainda outro caso interessante.
Às vezes, o sistema realmente executa uma operação longa.
Gera um relatório.
Processa um arquivo grande.
Sincroniza dados.
Envia vários registos para uma API externa.
Inicia um processo complexo.
Nem sempre é possível fazer com que isso dure apenas um segundo. Mas é possível fazer com que o utilizador saiba o que está a acontecer.
Isso faz uma enorme diferença.
A mensagem: "A carregar..."
é algo completamente diferente de: "Estamos a preparar o relatório. 72% dos dados foram processados. Pode fechar a janela - o relatório ficará pronto em segundo plano."
No segundo caso, o usuário recebe informação, controlo e previsibilidade.
É exatamente um dos elementos da perceived performance.
O sistema pode continuar a executar a mesma operação por 20 segundos. Mas a experiência do utilizador é completamente diferente.
O pior é esperar sem informação
Uma pessoa percebe muito pior a espera quando não sabe se o sistema está sequer a fazer alguma coisa.
Clicamos. - Nada.
Clicamos uma segunda vez. - Ainda nada.
O sistema está a funcionar?
Bloqueou?
É preciso atualizar?
O formulário foi enviado?
Podemos fechar a janela?
É o momento em que o utilizador começa a lutar com a aplicação.
E quando o utilizador começa a lutar com o sistema, surgem novos problemas.
Atualização da página.
Reenvio do formulário.
Duplicados.
Chamadas para o suporte.
Erros.
Pedidos desnecessários.
E o tempo de trabalho de outras pessoas...
Por isso, informar o utilizador sobre o estado da operação não é um detalhe cosmético. É parte do design de um sistema eficiente.
E às vezes a aplicação espera pelo ser humano
Provavelmente este é o caso mais interessante.
O sistema exige que a pessoa faça uma ação que a tecnologia poderia executar automaticamente.
O colaborador extrai dados de um sistema.
Transfere-os para outro.
Verifica uma condição.
Copia o resultado.
Envia uma mensagem.
Altera o estado.
Espera.
Confirma.
Transfere os dados adiante.
E faz isto dezenas de vezes por dia.
Não há avaria.
Não há erro.
O sistema funciona de acordo com o previsto.
Só que o previsto estava errado.
Automatização não precisa significar inteligência artificial.
Às vezes, a maior automatização é simplesmente fazer com que os sistemas deixem de exigir que uma pessoa transfira manualmente informação entre eles.
A arquitetura tem um impacto direto em quanto tempo o utilizador espera
Nesta fase, chegamos às questões técnicas.
Se a aplicação é composta por vários serviços, cada chamada pode introduzir atraso. Se o sistema vai buscar sempre os mesmos dados a uma API externa, pode considerar-se cache. Se o relatório recalcula milhões de registos do zero de cada vez, talvez seja necessária outra estratégia de geração de dados. Se o utilizador tem de esperar por uma operação que não precisa ser executada imediatamente, pode considerar-se processamento assíncrono. Se vários processos executam o mesmo trabalho, talvez o problema esteja na arquitetura.
É precisamente aqui que UX, performance e software architecture começam a ligar-se entre si.
O designer vê o problema do utilizador.
O analista vê o processo.
O programador vê o código.
O arquiteto vê as dependências.
Um bom sistema deve reunir todas as quatro perspetivas.
Nem toda a operação precisa de ser acelerada
Isto também é importante.
Às vezes, a empresa investe muito dinheiro na otimização de uma operação que acontece uma vez por dia.
Entretanto, outra tarefa, executada por 50 pessoas dezenas de vezes por dia, permanece praticamente intocada.
Por isso, antes de otimizar, vale a pena saber: o que estamos realmente a otimizar e para quem?
Não se trata de fazer com que cada ecrã abra em 100 milissegundos.
Trata-se de o sistema ser rápido onde a rapidez tem importância para o negócio.
Se o relatório financeiro pode ser gerado em 15 segundos uma vez por dia, talvez não seja um problema. Se a pesquisa de clientes responde em 4 segundos em cada operação do comercial, a situação é completamente diferente.
A performance deve ser avaliada no contexto da frequência, criticidade e custo de determinada ação.
Como encontrar o verdadeiro gargalo?
Em vez de perguntar apenas aos programadores: "Porque é que a aplicação está lenta?"
vale a pena começar pelos utilizadores: "Mostra-me como fazes o teu trabalho."
Não: "O que é incómodo para ti?"
Apenas:
"Mostra-me como preparas uma proposta."
"Mostra-me como tratas uma reclamação."
"Mostra-me como inseres um novo cliente."
"Mostra-me como fechas uma encomenda."
E depois, muitas vezes, surgem coisas que não se veem no código.
Excel.
Bloco de notas.
Segundo monitor.
Cópia de dados.
Verificação manual.
Chamadas telefónicas.
Abrir cinco separadores.
Atualizar a página.
Esperar por um e-mail.
Perguntar a um colega.
É precisamente aí que muitas vezes está o verdadeiro gargalo.
Uma boa aplicação não responde apenas depressa
Uma boa aplicação permite executar o trabalho rapidamente.
É uma diferença subtil, mas fundamental.
É possível ter uma aplicação tecnicamente muito eficiente, que exige ao utilizador uma dúzia de cliques. É possível ter uma interface bonita que esconde um processo complexo. É possível ter uma ótima arquitetura que não resolve o verdadeiro problema de negócio. E é possível ter um sistema que, tecnicamente, não é um recordista de performance, mas permite ao colaborador fazer em cinco minutos algo que antes demorava meia hora.
É precisamente por isso que uma software house não deve olhar para a aplicação apenas através da lente do código.
O código é um meio. O objetivo é um negócio a funcionar bem.
Antes de otimizar o servidor, mede a pessoa
Vale a pena memorizar esta frase.
Se os utilizadores se queixam de que a aplicação é lenta, não comeces automaticamente por aumentar a potência do servidor.
Primeiro, verifica todo o processo.
Quanto tempo demora a tarefa?
Por quantos ecrãs é preciso passar?
Que quantidade de dados o utilizador introduz manualmente?
Quantas vezes reescreve as mesmas informações?
Entre quantos sistemas precisa de alternar?
Quantas vezes espera?
À espera de quê?
Sabe que o sistema continua a trabalhar?
Parte do trabalho pode ser executada automaticamente?
Os dados que já possuímos estão a ser novamente solicitados à pessoa?
Só então vale a pena descer um nível e verificar a API, a base de dados, a infraestrutura, o cache, as filas ou a arquitetura da aplicação.
Porque às vezes o problema está realmente no código.
Mas às vezes está entre o ecrã e a cadeira.
E então a melhor otimização não é um servidor mais rápido.
É um sistema melhor desenhado.
O elemento mais lento da tua aplicação pode ser uma pessoa.
E a função de uma boa software house não é fazer com que a pessoa clique mais depressa.
A função de uma boa software house é fazer com que tenha de clicar menos.
