*texto de Marcelo Monteiro
Na verdade esse título é apenas uma pergunta retórica. Não é garantido que investir em apenas uma ferramenta de qualidade, como uma automação de testes funcionais, por exemplo, irá ajudar, de fato, um e-commerce. Da mesma forma, não existe uma ferramenta que ofereça garantia de uma aplicação sem problemas.
Explico, então. Devemos investir em práticas e processos de qualidade. Isso sim, trará retornos satisfatórios. E esse valor investido na qualidade de uma aplicação deve ser entendido como um investimento a longo prazo. O retorno gerado pelas aplicações parece não se justificar, mas acreditem, ainda que o retorno seja baixo e lento, o investimento trará lucro e minimizará dores de cabeça futuras.
A situação inversa, ou seja, não investir em qualidade é como pagar o valor mínimo de uma fatura de cartão de crédito. Num futuro não muito distante, o valor dessa “comodidade” é cobrado com juros absurdos. Parece exagero, mas eu vou elucidar com alguns casos reais.
Vou começar com o exemplo da Knight Capital, uma empresa que foi levada à falência em menos de, literalmente, uma hora. Isso após árduos 17 anos para conseguir chegar em uma posição de referência no mercado financeiro de Wall Street. Sim, foi um bug que poderia ter sido contornado.
A SEC (U.S Security and Exchange Commission) publicou um relatório muito detalhado onde cita as violações e negligências que a empresa deveria ter ficado atenta. Entre elas, temos uma observação importante:
- Falta de gerenciamento de risco – Entre diversos pontos nesse item, temos citado a falta de processos e práticas, no desenvolvimento do software, onde ponderam:
“Uma gestão de risco prudente tem, em seu núcleo, a garantia de qualidade, melhoria contínua, teste controlado e teste de aceitação do usuário, métricas de processo, gestão e controle, revisão regular e rigorosa de conformidade com as regras e regulamentos aplicáveis, além de um processo de auditoria forte e independente. Para garantir que esses recursos básicos estejam presentes e incorporados nas operações do dia a dia, os corretores ou distribuidores devem investir recursos apropriados em sua tecnologia, no alinhamento de conformidade e na supervisão destes pontos“.
Caso tenham interesse em entender melhor o problema ocorrido, recomendo a leitura deste artigo.
Outro ponto destacado no artigo é o famigerado prazo de entrega. Os desenvolvedores tiveram somente 30 dias para desenvolver, testar e implementar a lógica necessária para se adequar ao funcionamento da RLP (Retail Liquidity Program) aprovada pela NYSE em julho de 2012. O sistema utilizado pela Knight Capital – SMARS – adequado a esse novo mecanismo, foi lançado em agosto de 2012.
Vou dar mais um exemplo, o da American Airlines, que passou por maus bocados devido a um problema no software administrativo, onde todos os pilotos puderam agendar férias durante o período das festas natalinas. Obviamente, a maioria já tinha feito isso, deixando centenas de voos sem pilotos disponíveis nas semanas das festas de fim de ano – e o RH desesperado para contornar a situação antes dessas datas.
Os pontos em comum desses problemas:
- Desgaste das imagens das companhias;
- Prejuízos financeiros muito maiores que o custo de práticas e processos que evitariam as inconformidades;
- Desgaste dos funcionários! Um marco que certamente nenhum desenvolvedor de software gostaria de ter no seu CV – “Sim! Eu trabalhava no time que desenvolvia a automação que faliu a Knight Capital! Foi louco aquele dia.”
“Entendi Marcelo, mas cadê os casos positivos?” – O Google é um deles. E excelente, por sinal, uma vez que raramente fica com os serviços fora do ar por mais de 1 minuto – e nas raras exceções, quando há algum problema, olha a notícia que veiculam: Google fora do ar? – e muitas pessoas reconhecem a qualidade dos aplicativos dessa empresa. Temos outras como Netflix e Spotify, com processos e padrões que são referências para diversas empresas do ramo tecnológico e que oferecem excelentes serviços de streaming.
É importante salientar que o hábito de se preocupar com a qualidade em uma empresa/ projeto é o mesmo quando realizamos uma atividade física. Se você é comprometido e se exercita com regularidade, provavelmente não terá problemas de saúde. Mas se já está com algum problema de saúde, não será em uma semana de treinos regulares na academia que solucionará seus problemas.
Se poucos problemas de qualidade são relatados no seu site ou empresa, provavelmente está tudo dentro de um bom padrão. Isso, é claro, quando existe a preocupação com este item, porque senão… Já vimos os tipos de surpresas que podem acontecer.
Se você está com problemas de qualidade não vá achando que existe uma ferramenta ou processo, que outra empresa já utiliza, capazes de resolver de forma miraculosa seus problemas.
Para resolver problemas de qualidade, você precisará entrar em um longo processo de adequação e troca de mentalidade, começando pelos membros dos times de desenvolvimento.
Quando cito “qualidade” quero dizer algo além dos âmbitos de uma fila de testes. Por exemplo, quer começar a ter qualidade embutida na sua aplicação? Se preocupe com os seus usuários finais e em como resolver as dores deles. Parece mais uma vez exagero, né?
A Apple faz isso e não é recente. Em uma palestra feita em 1997, Steve Jobs disse o seguinte – “Uma das práticas que sempre tive foi de desenvolver algo pensando primeiro na experiência do usuário e depois trabalhar para aplicar a tecnologia necessária, que atenderia essa demanda” – portanto, invista em UX/UI! (e invista em qualidade subsequentemente).
Seu site certamente ficará muito mais intuitivo e preparado para atender as expectativas das pessoas que o utilizam.
Me desculpem os diretores e CTO’s, mas não é para atender somente às suas demandas, tá bem?
Ao investir apenas em ferramentas, sem processos e práticas que prezam pela qualidade, você corre o risco de possuir um excelente bugômetro, onde os problemas que causam as falhas ainda não serão resolvidos. Não existe receita certa, invista nos processos que sejam resolutivos para o seu tipo de negócio. As que parecem mais óbvias, são as mais assertivas:
- Investir em UI/UX
- Expor a visão e o objetivo do seu site (ou a dor a ser resolvida) com o time de desenvolvimento, para que as expectativas sejam alcançadas;
- Investir em planejamento, detalhando regras de negócio com fluxos;
- Prefira pequenas entregas e entenda como priorizar melhor seu projeto;
- Invista em processos que ajudem a manter um bom padrão qualidade:
- Transparência e boa comunicação entre os membros dos times (da empresa toda, inclusive);
- Reforçar visão e entendimento dos objetivos, gerando comprometimento para entrega deles;
- Ferramentas de automação – Sim, elas são necessárias para acelerar o processo, mas não confie apenas nelas para manter sua qualidade num desenvolvimento.
Notem que não cito metodologias, processos prontos e ferramentas, apenas itens comuns que a maioria das empresas deveriam se preocupar.
“E quanto às métricas, Marcelo?” – Para que elas realmente funcionem, é necessário muito cuidado e planejamento. Não adianta medir pontos, que nem o próprio time consegue explicar a utilização, por exemplo.
Para uma empresa que aplica o básico e já faz a lição de casa, pensar em aplicar métricas para ajudar a melhorar processos é muito válido.
Entretanto, se nem o básico é garantido e o caos reina em seu dia a dia, é prioritário dar atenção às seguintes métricas:
- Software funcionando corretamente em produção;
- Usuários finais satisfeitos.
“E a WEBJUMP, pensa em tudo isso?” – Claro! E temos problemas, sem dúvidas! Sempre visamos a melhoria contínua.
Um dos nossos casos mais relevantes que temos é o do Parceiro Ambev, segue o depoimento de um dos P.O’s responsáveis em ajudar a aplicar e em transformar o projeto:
“Quando vimos o caos que não olhar qualidade causava no projeto, passamos a fazer um Fórum de Melhoria Contínua semanal com a liderança da WebJump e Ambev, onde traçamos juntos as estratégias relacionadas a isso. Empoderamos mais os QAs, criamos processos consistentes de Deploy e gestão de bugs e garantimos ampliar a visão do time DEV sobre o produto. Obtivemos muito mais satisfação do usuário em relação à aplicação” – Gabriel Reis Mauriz, Product Owner B2B Ambev.
Explicações: o termo QA — Quality Assurance — mencionado pelo Gabriel acima, se refere ao analista de qualidade da equipe. Times de desenvolvimento ágeis podem contar com QA’s, ou QE’s, nesse último caso a sigla para engenheiro de qualidade.
Dev — Developer — se refere ao desenvolvedor do time, os responsáveis por codificar uma funcionalidade desejada.
PO — Product Owner — atua como o responsável pelos requerimentos das funcionalidades desejadas num projeto, acompanhando de perto o desenvolvimento e validando as entregas feitas pelo o time de desenvolvimento.
Já os Deploys são os processos de upload da alterações feitas em um projeto, para o ambiente oficial, onde os usuários finais utilizam de fato a aplicação, conhecido como ambiente de produção.
Portanto, minha dica é: iniciem com pequenos passos, priorizando o básico e não cometam o erro de investir apenas em testes automatizados ou pior, não investir em qualidade como um todo! Para mais práticas e entendimento dos itens mais comuns que são ofensores da qualidade, recomendo que assistam essa excelente palestra sobre desenvolvimento de e-commerce do Fabio Akita, uma referência em desenvolvimento: Performance, anti-patterns e stacks para desenvolver e-commerce, com casos reais.
- Marcelo Monteiro é formado em Engenharia Elétrica, possui 10 anos de experiência com a área de qualidade. Atua com o desenvolvimento de testes automatizados funcionais web/mobile (Cucumber, Capybara, Appium, Ruby), testes de API’s (REST, GraphQL, Postman, Newman, HTTParty), testes de performance (Jmeter, Blazemeter, Taurus) e testes manuais, além de disseminar práticas de desenvolvimento voltados para a qualidade nos times. Hoje atua como líder da área de qualidade na WEBJUMP, onde trabalha desde 2017.