Estamos todos familiarizados com o conceito de “Uma Equipa”. Podemos ter experimentado aquele momento em que produto, engenharia e operações foram unidos em direção a um objetivo comum. Isso é ótimo até que enfrentemos ações divergentes.

Imagine descobrir um engenheiro de software que prefere otimizar seu código em vez de entregar as prioridades definidas do utilizador. Na sua perspectiva ele tem razão: “Para mim (apenas) foi importante”.

O sucesso na implementação da abordagem de toda a equipe para resultados de qualidade a partir da combinação de elementos-chave. Neste artigo, identificamos as dificuldades de uma abordagem “Uma Equipa, Uma Qualidade” compartilhando orientações de implementação para cada ponto:

• Uma Qualidade não compreendida deve ser alinhada colaborativamente
• Uma Qualidade vista como “mais uma prioridade” deve ser incorporada
• Uma Qualidade que não é uma prioridade pessoal deve se tornar uma
• A Qualidade no silo deve ser disseminada organizacionalmente

Junte-se à QE Unit para fazer parte da comunidade de Quality Engineering para acessar conteúdo regular e exclusivo da comunidade.

Uma qualidade não compreendida deve ser alinhada de forma colaborativa

A colaboração dos membros da equipe começa com uma compreensão compartilhada de seus papéis em direção a um objetivo comum. Isso não é trivial para uma Qualidade raramente associada ao utilizador e questões de negócios, geralmente permanecendo dentro de um silo técnico. 

Em software, a Qualidade tende a ser associada principalmente a testes. Essa visão parcial da dimensão global da qualidade materializa sua subjetividade entre os atores. Uma compreensão compartilhada da Qualidade, portanto, requer escuta, empatia e uma visão comum construída por meio da colaboração. Cobrimos um exemplo nesta mesa redonda de Qualidade sem testes.

Este trabalho de alinhamento é o pré-requisito de uma abordagem “One Quality One Team”. A equipe precisa entender que, como em um jogo de futebol ou em uma orquestra, diferentes jogadores têm que contribuir de forma diferente para produzir um resultado de qualidade no final. O mesmo ocorre com o software; Um único defensor de controle de qualidade não pode alcançar a qualidade. É o resultado de um esforço colaborativo bem-sucedido.

É difícil conseguir uma qualidade integrada ao negociar por outras prioridades.

Uma Qualidade vista como “mais uma prioridade” deve ser incorporada

O desenvolvimento de software é um desafio, especialmente ao iniciar um novo produto ou entregá-lo sob pressão. Os prazos devem ser cumpridos a todo custo com a pressão dos stakeholders, onde a Qualidade será abordada “em uma segunda etapa”.

A qualidade considerada como um requisito totalmente separado é um problema. Ele desconsidera a necessidade de entregar o valor mínimo aos utilizadores, pensando que podemos recuperá-lo mais tarde. Fazendo um paralelo com a comida, comeria pão não assado porque era “mais rápido e mais barato” fazê-lo? Este é o nível de software que algumas organizações oferecem a seus utilizadores. Nesse contexto, a capacidade de negociar a qualidade fará a diferença.

“A amargura da má qualidade permanece muito depois de o preço baixo ser esquecido.”

Benjamin Franklin

O segundo aspecto de uma qualidade posterior assume que podemos recuperá-la mais tarde. Podemos, por exemplo, recuperar atrasos de teste automatizados, ao custo de possíveis problemas em lançamentos e um custo de execução manual. Podemos avaliar a arquitetura ao custo de seu redesenho e custo de oportunidade. Todos esses retrabalhos custam caro no final. E dificilmente podemos recuperar utilizadores insatisfeitos. 

Em suas raízes, uma Qualidade não considerada é impulsionada por indivíduos.

Uma qualidade que não é uma prioridade pessoal deve se tornar uma

Os humanos são movidos por interesses próprios, um mecanismo herdado para a sobrevivência. As partes interessadas envolvidas no software aplicam o mesmo raciocínio, perguntando “O que isso traz para mim?”. Os atores, portanto, precisam ver o valor em abordar os atributos de qualidade.

O ponto anterior de colaboração e design organizacional estão influenciando a necessidade de qualidade de uma perspectiva individual. Um Diretor de Marketing vinculando Qualidade a um NPS aprimorado e desempenho de negócios têm mais probabilidade de considerar a Qualidade como uma prioridade. Para alcançar o “One Quality One Team”, o mesmo nível de influência é necessário para alcançar o Tipping Point da Qualidade.

O aspecto multidimensional da Qualidade é a segunda dificuldade em fazer da Qualidade uma prioridade pessoal para as partes interessadas. Torna mais difícil para alguém ter uma visão geral, alcançar um verdadeiro equilíbrio e uma melhor priorização. Um engenheiro SRE pensará facilmente sobre os requisitos de desempenho ou confiabilidade, mas menos sobre usabilidade, por exemplo. Embora o líder da Qualidade possa ter a visão geral, ele deve ter sucesso em alinhá-la dentro da organização.

A combinação das várias perspectivas e conhecimentos fará a diferença.

A Qualidade no silo deve ser disseminada organizacionalmente.

Nossa necessidade de sobrevivência cria a tendência de permanecer dentro de nosso ecossistema conhecido e otimizá-lo, sem necessariamente considerar o quadro geral. Por exemplo, focamos principalmente em nosso círculo familiar, casa e vizinhança. Uma força contrária é, portanto, necessária para a Qualidade.

A qualidade vem com sua imagem histórica de Controle de Qualidade e Garantia de Qualidade, onde os produtos são retirados da linha de fabricação para verificação por outra equipe. Embora essa abordagem possa ser útil até certo ponto para o software, certamente não é suficiente para atender à abordagem “Uma Qualidade, Uma Equipe”. Um único silo de qualidade não é a resposta. Uma articulação diferente é necessária.

A responsabilidade pela Qualidade deve ser projetada dentro da organização, geralmente em 3 níveis. O primeiro é de nível “VP” ou “Chief”, para ter patrocínio e prestação de contas até o nível da diretoria. A segunda é do modelo “Enabler” ou “Servant Leader”, tendo pessoas capazes de auxiliar as equipes operacionais em suas responsabilidades de qualidade. A última é responsabilizar a equipe pelo seu nível de qualidade, amparada pelos outros dois níveis de suporte.

Alcançar uma qualidade compartilhada em uma equipe é, portanto, um assunto mais extenso.     

Uma Equipa, Uma Qualidade com o Quality Engineering

Cobrimos os pontos difíceis de um paradigma de “Uma equipa, uma Qualidade”: um entendimento compartilhado, um alinhamento geral (individual, equipe e organização) e projeto organizacional. O Quality Engineering pode nos ajudar nisso.

O Quality Engineering restringe todas as atividades do ciclo de vida do software para fornecer continuamente valor aos seus utilizadores. Em nosso caso, a gestão desempenha um papel fundamental no alinhamento e condução dos atores por meio da colaboração.

Podemos contar com o framework MAMOS com foco nos dois aspectos do Management e da Organização. “One Quality One Team” resulta de um esforço bem-sucedido de gerenciamento de mudanças, permitindo que os atores incorporem a qualidade no nível certo.

Finalmente, o deal do “One Quality One Team” é o Quality Engineering.