Fotografia de capa por Fía Yang, tirado por uma Canon, Powershot G5 X
Recentemente eu fiz um tweet que foi suficiente pra instaurar o caos em toda bolha de tecnologia incluindo produtos:
E a primeira coisa que tenho a dizer sobre isso, é que eu acho impressionante como uma persona de cusão consegue mais engajamento (111.1k views) do que um cara com boas intenções (principalmente no twitter). Dá uma olhada nesse tweet onde falo de um treinamento gratis que mantenho até hoje mas soltei em 2021 (171k views), em 2 dias o tweet cusão pegou a maioria de views que esse de bom samaritano.
Isso me lembra do famoso meme:
E isso nos trás ao assunto desse artigo onde vou dissertar mais sobre agilidade, que com criação de produtos digitais são meus tópicos preferidos, e ajuda a entender o tema que trago aqui: QA como processo e não como cargo.
O termo ágil foi prostituído e isso não é novidade para ninguém, scrum (que muito se diz como sinônimo de ágil) foi aplicado a força nas empresas por conta de medo dos donos em ficar pra trás, e terem sido comprados com uma ideia de uma maneira melhor de mostrar números que mostram resultados.
Isso causou a visão:
- QAs veem devs: terem o ego alto e não fazerem o mínimo como testes unitários bem feitos.
- Devs veem QAs: são usuários remunerados que só precisam usar o sistema.
Colocar uma pessoa com cargo de QA, Product Manager/Product Owner (que são papeis diferentes), Agile Master não faz seu time ágil! mas isso acontece frequentemente dado que muitas empresas contratam consultorias para "implantar" o ágil sendo que agilidade é muito mais sobre pessoas e interações do necessariamente o processo.
Existe um artigo chamado Agile is Dead (Long Live Agility), em que um trecho mostra o que seria realmente considerado agilidade:
Fazendo uma tradução direta seria algo como:
# O que fazer
1. Entender onde você está
2. Pegue um pequeno passo pra chegar na meta
3. Ajuste o que você aprendeu baseado no que você passou
4. Repetir
(parece fácil mas não é, pois você aplica isso a tudo!)
# Como fazer
Quando se esbarrar com duas ou mais alternativas que entregam o mesmo valor, pegue o caminho que torne mais fácil mudar no futuro
(um bom design é mais fácil mudar do que um mau design)No final o que importa é se o resultado gerado pelo código escrito valeu o investimento, ou seja, outcomes over output!
Recentemente foi gerado um debate muito bom após sair um "estudo de caso" da empresa linear.app, onde causou um alvoroço sobre o papel product manager na organização, gerando comentários como:
Se você me conhece, ou mesmo lê o meu blog, sabe que defendo muito product-minded engineers e falo muito sobre produto para desenvolvedores, pois isso vira a chave na cabeça do dev que o foco não é na solução e sim no problema, e não necessariamente vão resolver o problema com código.
A visão da linear.app é justamente a visão que compartilho, mas é totalmente valido o comentário do Jamie no tweet acima, afinal, como fazer isso funcionar em times grandes?
Empresas maiores precisam de mais times em paralelo para satisfazer a gama maior de clientes, o que deixaria o diretor de produto sobrecarregado e causa ruído na comunicação entre a pessoa que tem o chapéu de product manager da vez e o pessoal do CX (customer experience). Coincidentemente é em empresas maiores que geralmente o termo ágil é prostituído, e boa parte do trabalho é politicagem, apontamento de dedo e falsa sensação de entrega de valor (output-based roadmaps).
PM, QAs, Agile Master realmente são um desperdício de dinheiro na sua cia, SE eles estão lá para criar a fantasia ilusória de time ágil.
Um exemplo, eu já tive a oportunidade de trabalhar com ótimos QAs, mas eles não apenas testavam a aplicação quando o dev terminava, eles participavam de TODO o fluxo de desenvolvimento do produto/feature (o que ajudava a conhecessem o produto a fundo facilitando até a encontrar bugs), aplicavam automações dos testes sempre pensando em deixar-los mais eficientes e torna-los escaláveis além de ajudar a definir os DOR e DOD.
Dado uma necessidade do usuário, sentava-mos PM, QA, e dev para discutir como poderíamos trazer valor ao produto de forma onde conseguimos testar rápido e criar um fluxo de entregas baseadas em resultados maior.
- Todo mundo do time era QA, responsável por garantir a qualidade das entregas e ter certeza que no próximo fluxo melhoraria-mos o que fizemos de errado.
- Todo mundo no time era PM, sempre olhando para os dados e clientes para saber o que há de errado e oportunidades de novas funcionalidades.
- Todo mundo do time era Agile Master, todos empenhados em ser ágeis, e aplicar aquilo ao que realmente importa: como criar um fluxo de entrega de resultados e gerenciando riscos que possam aparecer no meio do caminho.
Ter esses papeis como alguém alocado full-time deveria vir naturalmente (e caso precise) após o time praticar os princípios de agilidade.