Gestão de Qualidade X Gestão de Produto

Como entender qualidade te ajuda a ser uma boa gestora de produto

Vamos começar por qualidade

QA não é uma fase do desenvolvimento, é a porra toda. O início, o meio e o fim.

Meu primeiro emprego após completar a faculdade foi na área de qualidade. Essa área me brilhava os olhos, porquê naquela época eu encarava qualidade como uma fase do projeto, a fase onde a gente impede que os Bad Ugly Guys (bugs) atrapalhem a vida do nosso usuário. Me sentia a Jessica Jones dando aquele olé e derrotando o Kilgrave.

Eu tive um crescimento relativamente rápido nessa empresa e quando passei a liderar projetos e gerenciar as contas de nossos clientes, percebi o quanto era difícil vender a qualidade. Era muito fácil mostrar o valor de um bom processo, mas não era fácil explicar e convencer o porquê investir dinheiro em qualidade era um bom negócio.

Por ser muito difícil estimar qual será o custo de “não fazer nada”, para a maioria das empresas “fazer” aparenta ser um custo injustificável. Isso porquê à primeira vista “não fazer nada” parece ter custo zero.

A boa notícia é que algumas empresas entendem muito bem esse risco e veem qualidade como um investimento e foi nessas empresas que aprendi que QA não era só uma fase, mas sim uma cultura.

Não foi algo rápido de se aprender. Estudei e tirei certificações em qualidade e agilidade, aprendi testes não funcionais e sempre procurei melhorar processos. Conforme descobria novos aspectos da qualidade percebi que ela vai muito além de um software funcionando de acordo com uma lista de requisitos.

Todos nessa vida de produtos digitais sabem, ou deveriam saber, que quanto mais tempo passa para se corrigir um bug, maior será o custo da correção.

Se o custo de correção aumenta conforme o tempo passa, será que o custo de não entregar segue o mesmo padrão? Fiquei pensando nisso e refletindo se essa não era outra armadilha onde nós não entendemos de fato o custo do “não fazer”. Foi então que percebi que participei de projetos que levaram anos para entrar em produção, onde até houve preocupação com o custo de não investir em qualidade, mas nunca com o custo da entrada tardia em produção.

Também aprendi na prática e pude ver com os meus próprios olhos que era a mais pura verdade que algumas das funcionalidades (que tiveram toda a preocupação de requisitos, desenvolvimento e testes funcionais e não funcionais) poderiam não ser tão utilizadas…

Descobri que só 7% das funcionalidades de um software são SEMPRE utilizadas e que 45% NUNCA serão utilizadas.

Foi então que tive a certeza de que esse tempo todo eu estava ignorando um dos aspectos da qualidade. De nada adianta apenas testar, escrever listas intermináveis de requisitos, se preocupar com a performance e garantir que a integração com vinte sistemas diferentes seja perfeita se as necessidades das pessoas que utilizam o produto não estiverem nessa equação. É necessário entregar rápido! Precisamos ajudar as pessoas hoje e não daqui 2 anos, quando a dor já será outra. Para isso, devemos descobrir qual é a dor real e entregar rápido as melhores soluções, sem cair na armadilha de simplesmente seguir a risca o que está sendo pedido, pois a explicação sucinta de um problema normalmente esconde causas muito mais profundas do que se pode ver superficialmente e é nossa responsabilidade conseguir traduzir essa dor.

E a gestão de produto?

Ser ágil não é trabalhar com Scrum, Kanban ou afins. Fazer é completamente diferente de ser, e se você não tem uma boa priorização de objetivos e de produto, no máximo você está entregando rápido um monte de coisa que não faz diferença.

Lá quando eu ainda achava que qualidade era um software superbem testado e sem riscos de bugs críticos em produção, fiz minha primeira certificação de ágil, a PSM. O tema prometia agilidade na entrega e melhoria contínua (mesmo que eu ainda não entendesse bem como isso funcionava).

O tempo passou e eu estudei mais e mais. Estava determinada a entender a fundo como funciona de fato toda a “agilidade” para garantir todos os aspectos que precisamos ter em um produto de qualidade. Meu objetivo era entender todos os aspectos e papeis do “fazer ágil”.

E ai vem mais um aprendizado: “fazer ágil” está a anos-luz de ser ágil. Infelizmente isso é o que mais vemos no mercado: empresas que se acham ágeis porque tem squads e sprints semanais e usam várias outros termos desse mundo, sem entender o porquê fazem o que fazem, sem fazer melhoria contínua e saindo da retrospectiva sem “To Do” (tarefas a serem feitas para evitar que um problema ocorra novamente).

Chamar o time de desenvolvimento de squad, os requisitos de história, e utilizar Scrum, Kanban ou algo do tipo, provavelmente vai fazer com que depois de um tempo você tenha software com mais frequência sendo colocado em produção (espero que sem bugs), mas você pode só estar entregando mais rápido os 45% do software que ninguém quer.

Quando entendi essa conexão me apaixonei pelo papel de gestora de produto (PO do Scrum um pouco mais incrementado). A gestora de produto é a qualidade em pessoa, porque ela vai buscar os 7% de software que o usuário mais precisa e junto com um bom time garantir a qualidade necessária desses 7% (sem bugs críticos em produção).

Trabalhar com produto é trabalhar com a qualidade em todo o processo. Meu histórico com a área de qualidade não só me ajuda a escrever histórias e tarefas mais claras, mas me faz não descuidar do objetivo principal, entregar produtos que as pessoas precisam.

Priorizar produto não é fácil e você precisa aprender a desapegar de soluções completas, o que não significa que está tudo bem pôr algo em produção que vá quebrar. Um MVP precisa se sustentar, ser autossuficiente, no mínimo tratar as exceções que não atende com um aviso e se possível nem deixar o caso de exceção chegue muito longe no fluxo.

Você precisa aprender a fazer melhoria contínua. E não, fazer retrospectiva não significa necessariamente que você faz melhoria continua. Melhoria contínua é inspeção, é ter “To Do”, é saber identificar um problema sem apontar dedos e ajustar o processo para que ele não se repita.

Você precisa de transparência, pois ninguém faz um produto sozinha. O produto é feito por todo um time, com especialidades diferentes e que se complementam. PO/PM que trata o time como executor não sabe o quanto está perdendo! Porque sim, desenvolvedores também estudaram muito e podem propor soluções como qualquer outro perfil, mas para isso o time precisa ser envolvido. Então não, transparência não é enviar um status ou compartilhar qual a próxima funcionalidade, transparência é dividir os problemas e objetivos o tempo todo. Transparência é construir junto trazendo as restrições das quais não temos poder o quanto antes.

Você precisa de um time em que a base seja a confiança, onde todos saibam que o que se conflita são ideias e não pessoas. Se não houver confiança, se não houver sentimento de pertencimento, então não haverá comprometimento.

E o que tudo isso tem a ver com a qualidade?

Sabe o custo do não fazer? Ele está em tudo…

Melhoria contínua

Quanto mais tempo você demora para resolver um problema, mais difícil é de responder, mais custo ele gera, menos valor você entrega.

Transparência

Quantas soluções mais simples e rápidas não foram feitas por que quem saberia dela não sabia do problema?

Confiança

Quanto menos confiança, mais tempo leva para executar, para entregar valor no final;

Priorização

Fazer ágil é diferente de ser, e ser está relacionado a saber o que fazer, nem preciso dizer que o custo de fazer algo que ninguém vai usar é só todo o tempo que foi utilizado para desenvolver né? Somado a isso, tem o fato de que outra coisa que era muito necessária não foi feita no lugar e um concorrente pode ter feito nesse meio tempo.

Iniciar minha carreira na área de qualidade me deu a chance de em dado momento perceber que ela não é uma fase do projeto, ela é a porra toda. Quando você percebe que qualidade faz parte do todo, se força a pensar diferente e a entregar melhores produtos. Você se questiona e questiona priorizações. Fica mais fácil sempre lembrar de perguntar: “Porque vamos fazer isso?” “Será que tem outra coisa mais necessária que essa?”

Cada profissional tem sua jornada, essa foi a minha entre qualidade, agilidade e produto.