Criando uma cultura de qualidade de software. (QA)

Toda empresa de produtos deseja encantar os clientes com um produto de alta qualidade, e muitas organizações de engenharia naturalmente se concentram em melhorias de processo para atingir as metas de qualidade. Mas a cultura organizacional come a estratégia e o processo no café da manhã. Então, como você cria uma cultura de qualidade?

A qualidade do produto é uma das áreas que as equipes de engenharia monitoram de perto durante todo o ciclo de vida do desenvolvimento de software. Na maioria das vezes, uma combinação de ambas as medidas de qualidade externas visíveis pelos clientes – como defeitos, confiabilidade ou segurança – são rastreadas juntamente com medidas de qualidade internas não visíveis pelos clientes – como conformidade com uma especificação, manutenibilidade, eficiência do código ou base de tamanho do código. Quando são necessárias melhorias de qualidade externas/internas significativas ou recorrentes, as equipes de engenharia geralmente se concentram em melhorias de processo como forma de chegar lá. Afinal, a qualidade do produto é uma manifestação da qualidade do processo que foi utilizado para criá-lo, certo?

Os produtos também são manifestações da cultura que os criou. Como Bill Aulet, diretor-gerente do Martin Trust Center for MIT Entrepreneurship e palestrante sênior da Sloan, nos lembra, a cultura come a estratégia no café da manhã – e, eu argumento, o processo também. Quando a cultura organizacional colide com o espírito de uma mudança de processo – como quando uma cultura de comando e controle tenta obter ganhos de produtividade por meio de equipes auto gerenciadas e ágeis – a cultura sempre vence.

A cultura se manifesta por meio dos valores, normas, crenças e hábitos de uma organização – e estes, por sua vez, impactam a qualidade do produto ao orientar as ações da equipe. Não estou falando sobre o que uma organização diz que faz; Estou falando sobre o que ele realmente faz – em todos os níveis. Para começar, os valores organizacionais normalmente ajudam a priorizar o que é mais importante para as equipes. Por exemplo, uma organização que valoriza muito a simplicidade no design pode reverter uma correção para um defeito se acidentalmente adicionar complexidade à experiência do usuário. A qualidade geral de um lançamento pode ser avaliada pela elegância da implementação de novos recursos que planeja introduzir.

As normas organizacionais definem o que é considerado comportamento aceitável, normalmente por meio do histórico de uma organização. Um exemplo pode incluir se as versões anteriores exigiram horas extras dos desenvolvedores para corrigir defeitos críticos no final de uma versão. Sem ter esse histórico, o planejamento de uma versão de alta qualidade exigirá que um gerente de projeto seja muito conservador ao estimar a produtividade da equipe – uma vez que uma equipe pode não aceitar dedicar horas extras para cumprir um compromisso de qualidade.

Crenças organizacionais são ideias ou princípios compartilhados sobre como as coisas deveriam ser. Isso pode incluir a crença de que os desenvolvedores devem ter propriedade e responsabilidade sobre o código que escrevem – para que seu código reflita sua própria diligência e trabalho duro. Quando grandes defeitos são rastreados em seu código, esses desenvolvedores sentirão uma sensação saudável de constrangimento por terem perdido algo e tentarão resolvê-lo o mais rápido possível. Compare isso com o comportamento resultante de uma crença organizacional de que todo projeto e toda área de código aprimorado terá defeitos – e isso deve ser esperado. Com essa crença, os desenvolvedores serão mais lentos para reagir quando forem encontrados defeitos em seu código.

O último elemento da cultura são os hábitos organizacionais, e estes orientam as tendências regulares e muitas vezes não ditas que as equipes têm. Um exemplo é o estilo com que a tomada de decisão ocorre. Para algumas organizações, as decisões exigem adiamento para a pessoa mais sênior da sala, enquanto outras organizações definirão e usarão critérios baseados em evidências que pessoas em qualquer nível podem aplicar para que a decisão seja aceita. Pode ser bastante instrutivo observar como uma equipe decide se a qualidade é boa o suficiente para ser lançada – já que essa é talvez a decisão mais importante que afeta a qualidade que é feita durante uma versão.

Então, como você impulsiona a qualidade por meio da cultura? Em seu artigo da HBR sobre a criação de uma cultura de qualidade, Ashwin Srinivasan e Bryan Kurey, da CEB, compartilham os resultados de suas pesquisas recentes sobre essa questão. Eles estudaram mais de 850 funcionários que impactam a qualidade de 80 multinacionais para encontrar quatro fatores que impulsionam a qualidade como um valor cultural:

Ênfase na liderança. Os gerentes precisam demonstrar como “andar a pé” com relação à qualidade, e isso deve vir de cima. Você pode fazer isso por:

  • Acompanhamento de métricas de qualidade. Defina medidas significativas de qualidade com as quais a liderança sênior, gerenciamento de produtos, controle de qualidade e engenharia possam concordar.
  • Tornando suas métricas visíveis. Retire-os com frequência em reuniões e revise-os em check-ins regulares com sua equipe.
  • Usando qualidade em trade-offs . Crie definições e diretrizes claras para os níveis mínimos de qualidade e use-os em reuniões quando as trocas precisam ser feitas no final de um release. Quando sua equipe vir as métricas de qualidade sendo usadas na tomada de decisões, eles saberão que a qualidade é importante.

Uma observação especial é necessária aqui ao introduzir ou alterar métricas em sua organização. Como em qualquer iniciativa de mudança, é fundamental equilibrar a adesão com os mandatos para adotar a mudança. O risco com as métricas é que diferentes equipes podem começar a usar suas próprias variações que enfatizem seus interesses sobre os dos outros. Como o objetivo das métricas é medir e mudar o comportamento da equipe em todos os níveis, é fundamental que todas as partes interessadas (liderança sênior, produto, controle de qualidade e engenharia) concordem e sigam um conjunto comum. Você pode conseguir isso por:

Formar um grupo de trabalho multifuncional com propósito. Motive a necessidade das métricas identificando claramente os pontos problemáticos atuais que existem sem elas, por que a ação é imperativa agora e como as métricas comuns ajudarão. Convide as partes interessadas influentes de toda a liderança sênior, produto, controle de qualidade e engenharia para projetar as métricas. Cada participante pode representar os interesses de sua equipe durante as discussões, bem como ajudar a vender as métricas internamente para outras pessoas. Escolha um bom facilitador e certifique-se de pedir explicitamente aos participantes que vendam o resultado para seus colegas depois que as métricas forem projetadas.

Medição de resultados que importam. Peça ao grupo de trabalho para começar identificando os resultados de produto qualitativos desejados que as diferentes partes interessadas esperam. Depois que esses resultados forem identificados, convide o grupo a trabalhar de trás para frente para selecionar métricas que medem o movimento em direção ou em direção a cada resultado. Por exemplo, digamos que seu produto seja um aplicativo em nuvem cujos custos computacionais estejam aumentando mais rapidamente do que a adoção – e a gerência sênior está preocupada. O grupo de trabalho pode identificar várias métricas para medir a eficiência, como a utilização da CPU nos servidores, que podem ser rastreadas durante o desenvolvimento e o teste. Depois que as métricas estiverem finalizadas e em uso, mostre às suas equipes o impacto que elas estão causando.

Padronização do uso de métricas entre as equipesEncarregue o grupo de trabalho de criar os modelos e painéis que todas as equipes usarão para visualizar as métricas. Convide cada participante a apresentar os resultados para suas respectivas equipes e certifique-se de que eles sejam usados ​​de forma consistente. Como todas as funções contribuíram para o processo, defina claramente as expectativas de que essas métricas devem ser usadas no futuro por todos.

Credibilidade da mensagem. Gerentes bem-sucedidos escolhem cuidadosamente a maneira certa de comunicar a mensagem de qualidade com base no que ressoa com sua equipe. Isso pode levar alguma experimentação para acertar. Comunique a perspectiva de diferentes partes interessadas internas ou externas sobre a qualidade do produto e veja o que ilumina sua equipe. Os exemplos podem incluir:

> Satisfação do cliente. Entreviste ou pesquise os clientes sobre sua satisfação geral com o produto e inclua citações para dar vida ao seu sentimento.

> Experiência em vendas durante demonstrações. Como qualquer representante de vendas lhe dirá, a falha do produto durante uma demonstração de prospecção, pode ser muito prejudicial – e desconfortável para o representante de vendas. Descubra como os representantes de vendas experimentam o produto durante as demonstrações e com que confiabilidade podem exibi-lo.

> Percepções da liderança sênior. Em muitas organizações, os líderes seniores (especialmente os fundadores) adoram brincar com os novos recursos do produto. Convide-os a se envolver no final de um release e entreviste-os sobre sua experiência.

Envolvimento dos pares. Sua equipe internalizará a qualidade assim que começarem a se envolver com isso – e você pode ajudar a incentivar isso seguindo várias etapas:

Crie rituais em tempo de design. Durante as discussões de projeto, ajude sua equipe a desenvolver uma rotina para avaliar o impacto na qualidade de várias opções de projeto. Forneça perguntas para a equipe responder para cada design que está sendo considerado e, após um lançamento, mostre como elas contribuíram para a qualidade geral.

Convide avaliações de pares. Durante reuniões periódicas de status, mostre à sua equipe as métricas de qualidade mais recentes e peça a cada pessoa que faça sua própria avaliação de onde você está. Onde há acordo e onde divergem as conclusões? Independentemente da resposta, simplesmente convidar a equipe para fazer sua própria avaliação fará com que pensem sobre qualidade.

Incentive a programação em pares. Se feito em intervalos regulares, principalmente entre desenvolvedores juniores e seniores, isso ajudará a incentivar discussões sobre qualidade no projeto e na implementação. Incentive seus desenvolvedores seniores a discutir isso em cada sessão de programação em par.

Propriedade e empoderamento dos funcionários. Você pode capacitar sua equipe para tomar decisões de qualidade e sentir maior propriedade sobre os resultados. Para fazer isso, considere o seguinte:

> Reconhecer iniciativas de qualidade. Crie medidas individuais de qualidade (como bugs por desenvolvedor, talvez dimensionados pela complexidade do projeto) e forneça visibilidade e reconhecimento para aqueles em sua equipe que obtêm resultados. Crie um painel exibindo com destaque para cada pessoa para ver como eles se comparam aos colegas. Use isso em reuniões.

> Crie competições. Para um grande projeto, considere conceder prêmios aos melhores desempenhos que implementarem o código da mais alta qualidade. Certifique-se de anunciar a competição no início e esclarecer como as pessoas serão avaliadas. Divirta-se com isso.

> Construir oportunidades de aprendizagem. Convide membros da equipe com o melhor histórico para dar palestras sobre como eles abordam a qualidade, as escolhas de design que fizeram e os resultados de projetos recentes. Ao preparar a palestra, incentive o membro da equipe a mostrar as ligações entre sua abordagem à qualidade durante a implementação de um recurso e como os clientes, representantes de vendas ou líderes seniores a vivenciaram.

Por fim, colocando em prática algumas dessas diretrizes explicadas acima, teremos com certeza mais qualidade no produto final.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *