O mercado está aquecido e os investimentos em projetos digitais cresceram. Segundo dados do estudo Digital Transformation Investment 2020, publicado em julho no portal CIO, 70% das empresas aumentaram ou mantiveram gastos com transformação digital durante a pandemia. Este estudo confirma que muitas companhias estão usando este momento de crise global para direcionar recursos para a renovação e inovação tecnológica. Contudo, dentro dos orçamentos voltados para a tecnologia e inovação, a parcela de investimento em Qualidade é, muitas vezes, inexistente ou muito subestimada.
No título deste artigo, trago um exemplo de um desenho totalmente desproporcional, porém real: uma grande empresa que recentemente investiu em mais de 60 Devs e não contratou nenhum QA (Quality Assurance). Este é um movimento de contratação muito comum. Uma busca rápida no Linkedin me mostrou mais de 8.700 vagas para o termo "desenvolvedor" no Brasil. Já a busca por "Quality Assurance" no Brasil, mostra apenas 338 vagas. Além disso, a Catho relatou que em plena pandemia, entre março e agosto de 2020, a procura por programadores de algumas especialidades aumentou mais de 100%.
Estes números e muitos outros que me deparo no mercado todos os dias me fizeram colocar em pauta algumas considerações:
A TI das empresas não está totalmente comprometida em garantir a qualidade de seus produtos digitais porque consideram isso um gasto e não um investimento;
Não existe uma Cultura de Qualidade bem estabelecida, pois ações que vão nesta direção ainda são vistas como opositoras à inovação;
Muitas empresas podem entender que mais pessoas desenvolvendo um sistema pode significar mais produtividade e agilidade nos processos, o que nem sempre é real;
Os testes são uma etapa considerada somente no final do processo de desenvolvimento. Sem uma cultura da qualidade disseminada, as empresas acabam optando por contratar parceiros que oferecem somente testes em vez de soluções completas de qualidade.
Porque há dificuldade em se olhar para a qualidade?
Companhias que não possuem processos bem definidos ou que burocratizam o desenvolvimento apresentam maior dificuldade em olhar para a qualidade de maneira estratégica. Falando mais das que burocratizam, ainda é bastante comum encontrar times que tomam decisões simplesmente porque a metodologia ágil XPTO indica tal ação, deixando de lado todo o contexto de negócio e operacional. Mesmo quando existe um profissional com o papel de QA num time, é comum a qualidade ser reduzida à apenas uma etapa do processo, que em geral é a realização de testes (manuais ou automatizados) apenas no fim do processo de desenvolvimento.
Muitos gestores e líderes enxergam a questão da qualidade como uma barreira para que seus produtos digitais sejam colocados no ar. Muitas dessas lideranças acabam delegando 100% da responsabilidade para o desenvolvedor, sem oferecer ferramentas e técnicas adequadas para que este profissional possa investir parte do seu tempo em verificar a qualidade de suas entregas. E por falar em tempo, existem muitas lideranças que demandam que o desenvolvedor entregue código com teste pronto (os testes unitários), mas sem prever tempo para que este profissional realize esta atividade. Isso acontece principalmente porque separar tempo para que desenvolvedor crie testes resultará em menos entregas relacionadas à evolução do produto.
É verdade que dificilmente iremos encontrar vagas relacionadas com QA ou testes em gigantes de tecnologia como Microsoft, Facebook ou Apple, pois todas elas de alguma forma acreditam que todos devem se responsabilizar pela qualidade e, por isso, não seria necessário um profissional especializado para fazê-lo. Não há nada de errado na mentalidade dessas empresas que sempre acabam sendo referência para nós, o problema está no fato de adotar apenas parte dessa realidade (não ter QAs), esperar que a qualidade venha apenas do desenvolvedor ou de outras frentes e estas pessoas não serem orientadas/apoiadas para tal.
É possível sim que alguns times não contem com um QA, mas, além de uma suíte de automatização de testes robusta, isso exige um alto nível de maturidade. Neste caso, é preciso que alguém de dentro da equipe esteja disseminando conhecimento para os Devs, Product Designers, Product Managers, etc. Uma equipe pode ser composta por um profissional denominado QA, mas de Quality Assistance e não Assurance, para auxiliar em todo processo. Este profissional estará olhando para a qualidade o tempo todo e provocando a equipe no sentido de trazer questionamentos internos e ajudar a obter entregas, em cada etapa do ciclo de desenvolvimento, com cada vez mais qualidade, prevenindo bugs e retrabalho.
Mas, com base no nível de maturidade que vejo no Brasil, a maioria das equipes precisaria ainda investir no Quality Assurance e fazer a transição aos poucos. Neste artigo da Atlassian é possível ver que mudar o processo de qualidade de uma equipe exige tempo e esforço, pois todo o time será responsável pela qualidade da produção. Neste caso, todos os desenvolvedores devem ter um nível suficiente de treinamento para que saibam como testar com eficácia. Colocar repentinamente os desenvolvedores como responsáveis pelos testes sem uma transição e uma implementação de mentalidade pode ter resultados incrivelmente negativos.
Inovação a qualquer custo
O poder de decisão relacionado à TI das companhias está muito nas mãos de áreas como Negócios e Produtos, ou seja, daqueles que estão olhando para o mercado e sentindo as necessidades dos clientes. Muitas destas áreas possuem forte influência nas tomadas de decisão relacionadas ao trabalho do time de TI, e como estão olhando constantemente para o mercado e querem inovar com velocidade, estas sentem a necessidade de contratar desenvolvedores com a ideia de que assim cumprirão com os prazos e entregarão mais valor aos usuários antes da concorrência. Neste contexto, o entendimento costuma ser que olhar para a qualidade é "perda de tempo"; é um gasto e não um investimento. Realmente, se não houver uma estratégia bem definida, será um gasto. Mas, por outro lado, a busca desenfreada por inovação faz com que mais bugs e problemas sejam inseridos nos produtos digitais, e o que era para adicionar mais valor ao usuário, resultará em frustração e quebra de confiança.
Muitas vezes a falta de processos, de tarefas e de uma cultura da qualidade bem definida e disseminada, traz a ilusão de entregas rápidas e inovação com velocidade. Produtos são entregues em um curto prazo que nem sempre consideram as melhores práticas de desenvolvimento. Esse padrão gera o risco de, após um tempo, o backlog do time se voltar somente para a solução de problemas e retrabalho, o que coloca a eficiência dos times de TI em cheque e ocasiona a perda de credibilidade com os executivos e as áreas de negócios.
Com um número cada vez maior de entregas e com os prazos cada vez mais curtos, a TI fica pressionada. As entregas continuam acontecendo, porém, como as melhores práticas não estão sendo utilizadas, as equipes acabam deixando muito débito técnico e uma hora essa "conta" vai chegar. E o que era para ser um backlog de inovação acaba se tornando um backlog interminável de débitos técnicos.
É preciso olhar para os problemas
Uma boa maneira de se dar o primeiro passo em direção à qualidade é entender onde é possível extrair mais resultados no curto prazo. Olhar para as métricas internas que indicam o surgimento de crises, como reclamações, e analisar quantas delas são causadas por problemas técnicos. Todas as empresas possuem problemas, sejam eles de maior ou menor ordem. Por isso, entender a origem destes problemas é essencial para visualizar o negócio como um todo e entender por onde começar.
Com esta análise em mãos, é preciso se questionar: algum desses problemas poderia ser solucionado ou evitado com práticas de qualidade? A minha empresa já está perdendo receita, mas não quero ter uma pessoa voltada para a qualidade a longo prazo. Será que este profissional poderia me ajudar a resolver problemas de curto prazo? Ou até mesmo, se eu já tenho um time de QA, mas está impossível continuar somente com testes manuais, preciso investir na criação de testes automatizados?
É necessário entender minimamente a dor do negócio para tirar conclusões e pensar em como a qualidade pode se tornar estratégica. Este é um grande desafio, especialmente se os gestores não tiverem este olhar. No entanto, começar com esta análise de KPIs mais aprofundada e direcionada pode demonstrar que investir em qualidade é estratégico para o negócio da sua companhia.
Grace Libânio, head de negócios na Sofist.
