A realidade morde
É possível, por vezes até de forma proveitosa, abordar questões fundamentais do processo de QA, das ferramentas, da mentalidade, do espírito e da experiência. O que é ótimo. Estes temas exigem um esforço intelectual significativo e necessário para qualquer verdadeiro profissional de QA ou profissional em formação. Também dão boas palestras TED, o que joga a seu favor. Porque pode publicar esses vídeos nas suas redes sociais até ao fim dos tempos.
Mas, por vezes, também é necessário abordar as realidades minuciosas da montanha-russa do QA, mesmo que abordar essas realidades seja simplesmente um exercício de pragmatismo puro, que não exige saltos quânticos na compreensão do processo nem pensar fora da caixa.
Mas é precisamente o contrário: Mergulhar na lama e no drama daquilo de que essa caixa está demasiado cheia não pode ser evitado pensando fora dela. Porque, para começar, não é uma caixa. É uma Cúpula do Trovão.
É disso que trata este artigo. Não tem nada de novo ou que “mude o jogo” para oferecer, apenas reflexões e conselhos muito práticos baseados nas minhas próprias experiências de cortar a respiração como líder de QA ao longo de várias décadas, bem como nas lições que delas retirei. A minha própria realidade executiva no QA, por assim dizer. Lições que, evidentemente, é livre de ignorar/contradizer/gozar, conforme entender.
É evidente para qualquer pessoa que tenha estado na liderança de QA durante algum tempo que o trauma central dessa experiência é negociar a famosa reunião de “lançar-não lançar”. E sobreviver a ela.
Porque é aqui que tudo chega ao auge, o QA é interrogado como um suspeito de homicídio e os detetives são todos os outros “interessados” (um eufemismo, se é que alguma vez houve um). E, como todos os detetives, tudo o que querem de si é que assine a confissão.
Mas não tem de ser assim. Tudo o que precisa é de um álibi incontestável. Estou a escrever este artigo para lhe dar um.
Hora da história
O maior erro que os líderes de QA cometem ao entrar numa reunião de “lançar-não lançar” é a falta de preparação. Ou melhor, a falta de uma preparação eficaz.
A maioria dos responsáveis ou gestores de QA entra nesta reunião “preparada” sobretudo, e muitas vezes exclusivamente, com métricas de erros. Um determinado número de problemas em aberto, o número de problemas de Categoria A em aberto, o número de problemas de Categoria B em aberto, etc., etc. Por vezes, se o resto da equipa tiver sorte, o responsável de QA consegue transmitir uma noção vaga e impressionista da cobertura de testes que o QA alcançou até esse momento. Embora, normalmente, os dados utilizados para isso sejam simplesmente um inventário dos testes e dos guiões de teste executados. O que não é de todo uma medição da cobertura real dos testes. Estas são métricas de esforço, não verdadeiras métricas de qualidade.
A falácia subjacente a esta estratégia vai além da utilização de métricas ambíguas ou sem significado para apresentar (algum tipo de?) argumento a favor ou contra o lançamento. O erro cometido aqui é muito mais fundamental.
Porque a estratégia de decisão de QA descrita acima se baseia num erro categorial evidente. A liderança de QA, neste cenário, está a assumir que o objetivo da reunião de “lançar-não lançar” é apresentar dados para que outros os analisem e tomem uma decisão por si próprios. Nada poderia estar mais longe da verdade, nem ser mais prejudicial para a autoridade do QA.
O que o resto da equipa de produto espera da liderança de QA nesta reunião não são ainda mais dados. Espera um veredicto claro e autoritário sobre lançar ou não o produto. Agora. Hoje.
É claro que os dados de testes e de defeitos serão necessários para defender e obter apoio para o veredicto especializado do QA, seja ele qual for. Mas o QA tem de apresentar um veredicto autoritário.
Caso contrário, o QA está a abdicar da sua responsabilidade e autoridade únicas dentro da organização de entrega do produto. É inerentemente evasivo e passivo-agressivo. O que em nada contribui para melhorar a posição do QA dentro dessa mesma organização.
Com o passar do tempo, é uma espiral descendente para as possibilidades de o QA se tornar uma voz com o mesmo peso dentro do processo de desenvolvimento. Uma situação de que o QA se queixa incessantemente, embora muitas vezes seja, precisamente por esta razão, o autor da sua própria irrelevância.
Isto significa que a liderança de QA tem de entrar na reunião de “lançar-não lançar” com uma história clara e convincente que conduza a uma recomendação inequívoca. Por outras palavras, tem de entrar nessa reunião pronta e disposta a assinar na linha pontilhada, com sangue digital, qualquer que seja a recomendação apresentada. Nada de proteger as suas opções. Nada de se esconder atrás das saias da negação plausível.
Porque, se não o fizer, perderá, juntamente com a sua equipa, toda a credibilidade na organização. E, pior ainda, ficará numa posição em que assumirá todas as culpas se outros tiverem de tomar essa decisão por si e o resultado for um desastre de qualidade em produção. O que, sejamos honestos, é exatamente o que as outras funções querem que aconteça. Querem culpá-lo por tudo e usar a sua própria hesitação relativamente à qualidade do produto como prova contra si.
Um fator essencial desta abordagem passivo-agressiva à decisão de “lançar-não lançar” é a convicção — frequentemente utilizada de forma oportunista — de que “Não importa o que eu diga, eles vão lançar na mesma”. Esta mentalidade, esta adoção estratégica da impotência, é precisamente o que perpetua a impotência organizacional do QA. É caso para dizer: uma profecia autorrealizável!
Deixando de lado a política e a psicologia autodestrutiva, esta estratégia baseia-se numa incompreensão fundamental daquilo que é pedido ao QA nessa reunião. Na verdade, não lhe é pedido que emita uma decisão irrevogável de “lançar-não lançar”, embora a decisão que lhe pedem publicamente para tomar assuma essa forma pública.
E, sim, continua a ter de apresentar um veredicto autoritário. Mas, para o fazer, tem de compreender a pergunta a que deve responder de forma efetivamente autoritária.
A pergunta a que a liderança de QA está realmente a ser chamada a responder é esta: quais são os riscos — a sua provável prevalência e gravidade no terreno — de lançar hoje? Em vez de, por exemplo, no próximo mês? Por outras palavras, está a ser-lhe pedido que forneça uma avaliação de risco que permita à administração de topo assumir riscos de forma racional nesse momento.
Isto significa que a sua resposta definitiva na reunião de decisão sobre lançar ou não é, em última análise, uma resposta definitiva sobre o risco. Não sobre lançar ou não o foguetão para o espaço.
O que, por sua vez, significa que, em última análise, a história de qualidade que conta nessa reunião tem de ser baseada em cenários. Ou seja, não será um simples sim ou não, por muito que todos os outros desejem isso para se isentarem de qualquer responsabilidade pela decisão (o que nunca acontece, pois não?). Para esquematizar um pouco, a sua apresentação deve ter duas partes:
- Primeiro, uma declaração autorizada e *significativamente* orientada por dados sobre o estado atual da qualidade do produto. Com métricas que a sustentem. Alerta de spoiler: vai precisar de mais do que métricas de erros para fazer isto.
- Segundo, uma avaliação autorizada da qualidade latente que ficará por alcançar se a decisão for lançar já o produto. É assim tão grande que justifique acrescentar tempo ao calendário de lançamento para recuperar essa dívida de qualidade? Em caso afirmativo, quais são as compensações entre tempo e qualidade que a QA recomenda? E que áreas específicas da funcionalidade do produto teriam de ser visadas durante essa extensão, e como saberíamos que a qualidade latente foi concretizada?
Na realidade, isto não é uma forma de fugir à pergunta colocada. É uma forma de lhe responder no contexto completo de todos os parâmetros, variáveis e custos associados a essa decisão — hoje, na próxima semana ou no próximo mês.
Porque, e esta é uma verdade que precisa de gravar na sua consciência de QA, o seu verdadeiro público nessa reunião não são os outros responsáveis funcionais. É a administração de topo. Esteja fisicamente presente na reunião ou não. O que disser ser-lhes-á transmitido de imediato. Acredite em mim.
E isto funciona apenas a seu favor. Porque aquilo de que os CEO e COO mais gostam é de lhes serem apresentadas opções significativas, sustentadas por factos e dados concretos. O que mais detestam é que simplesmente lhes digam: “Hum, ainda não estamos prontos para lançar. E não lhe conseguimos dizer exatamente porquê. Mas talvez consigamos daqui a quatro meses.” É por isso que os CEO andam à procura de novas aquisições — para obter uma equipa totalmente nova de entrega de produtos.
A queixa recorrente das equipas de entrega de produtos é que a administração de topo dita, por decreto, uma data de lançamento fixa, que se recusa a comprometer. Talvez queira perguntar a si próprio por que motivo fazem isto de forma tão consistente.
É porque nunca conseguem obter uma resposta definitiva sobre o estado da qualidade do produto e, se a data de lançamento que preferem não puder ser cumprida, qual será a data em que poderá. Por isso, impõem a sua própria data. Porque a equipa do produto não lhes deixou alternativas com significado.
Assim, tem de ir à reunião de decisão sobre lançar ou não com uma história convincente, tridimensional, factual e baseada em cenários para contar, que conduza a um conjunto autorizado de recomendações, as quais podem incluir opções significativas de custo/benefício da qualidade em torno da decisão de lançar — ou não. Murmurar durante alguns minutos sobre métricas de erros e depois deixar a decisão nas mãos de todos os outros não é essa história.
É claro que, para fazer isto, terá de ter a sua própria metodologia de QA, formação e métricas em excelentes condições. Escrevi artigos detalhados sobre estes temas noutros locais (ou seja, no LI), mas, por serem teóricos do ponto de vista do processo, estão fora do foco pragmático deste artigo.
Um final feliz
O que escrevi acima pode parecer assustador e talvez um pouco contraditório — à primeira vista. Por isso, permitam-me terminar este artigo com a minha experiência numa reunião de decisão sobre lançar ou não que foi muito bem-sucedida. Uma reunião que decorreu de forma um pouco diferente do que descrevo acima e até de forma diferente daquela que eu esperava.
A minha equipa tinha estado a testar um produto completamente novo. Não apenas um produto novo, mas um produto que abordava um nicho de mercado em que a empresa não tinha experiência anterior. Por isso, foi, desde o início, uma maratona de perigos ocultos, incógnitas desconhecidas e surpresas desagradáveis.
Chegou o momento da reunião de decisão sobre lançar ou não. No início do meu mandato como Diretor de QA, tinha instituído um regime rigoroso sobre a forma como definiríamos as métricas de qualidade, incluindo métricas de cobertura de testes baseadas nos requisitos, e não num módulo ou num guião de teste. Também tínhamos implementado não apenas métricas de erros, mas métricas de tendências de erros e métricas de velocidade de alteração do código, para reforçar a nossa posição.
E todas estas métricas eram inegavelmente positivas. Todos os sistemas estavam prontos. Não eram necessários cenários do tipo se/então/senão. Pela primeira vez, não vi qualquer razão para não dizer, em voz alta e clara, “Lançar!”, sem reservas.
No entanto, tecnicamente, não era essa a minha função. Isto porque o projeto tinha sido liderado por um dos meus Gestores de QA, e cabia a essa pessoa proferir esse veredito autorizado. Este gestor resumiu corretamente todas as métricas e reconheceu que eram todas positivas.
Depois, para minha surpresa, mostrou-se hesitante e indeciso quanto a estarmos ou não prontos para lançar. Fiquei surpreendido porque, evidentemente, tínhamos discutido qual seria a posição da QA antes de entrarmos naquela reunião. (Nota importante: Nunca surpreenda o seu chefe numa reunião.)
Perguntei ao gestor: “O que seria necessário para se sentir confortável em recomendar uma decisão de lançamento? Se não hoje, no futuro?”
Mais uma vez, para minha surpresa, o gestor não conseguiu — ou não quis — responder à minha pergunta. Tornou-se claro para mim que este gestor simplesmente não queria assumir a responsabilidade por tomar essa decisão, por assinar na linha pontilhada. O que achei extremamente dececionante.
Foi também um insulto ao gestor de engenharia do projeto, que tinha apoiado incansavelmente o esforço de QA e tinha desenvolvido um produto de primeira categoria. Ele não merecia ser apanhado desprevenido desta forma. Nem eu.
Por isso, intervim e disse: “Não vi nem ouvi nenhuma boa razão para não lançarmos este produto HOJE. Esse é o veredito da QA e eu, enquanto Diretor de QA, assumo toda a responsabilidade por tomar esta decisão.”
Pensei que o gestor de engenharia estivesse prestes a beijar-me. Mas, depois dessa reunião, a QA ganhou enorme credibilidade e grande respeito por parte da engenharia, da gestão de projetos e da gestão de produto.
Porque o caminho para sermos levados a sério no nosso mundo passa por assumir publicamente a responsabilidade. Naquele momento, senti-me totalmente seguro ao fazê-lo, porque a nossa história tinha sido preparada desde o início. E tinha sido escrita com um final feliz em mente.
Depois de lançado, o produto demonstrou uma excelente qualidade no terreno e foi um enorme sucesso. Adiar o seu lançamento para evitar a responsabilidade de decidir se devia ou não ser lançado teria resultado apenas num aumento minúsculo da qualidade do produto, a um custo incomportável em dinheiro e tempo de chegada ao mercado.
A forma como fizemos isso é outra história para outro dia.
Como sempre, desejo-vos as maiores felicidades nos vossos esforços de QA.
Podcast relacionado: TRABALHO DE EQUIPA, IA E CONTENTORIZAÇÃO (COM MICHAEL RITCHSON, DA NASA)