Pular para o conteúdo principal

Efeito Peltzman e a Centralização da Responsabilidade

Incluir uma nova camada de qualidade pode reduzir a qualidade do software?

O Contexto de Implementação​

Imaginemos um cenário em que uma nova equipe de testers é contratada com a finalidade de implementar uma camada adicional de qualidade, testando as alterações antes que estas cheguem à produção. O objetivo dessa mudança é assegurar que todos os erros sejam detectados antes de afetar os usuários finais, transferindo a responsabilidade pela qualidade para essa equipe especializada.

Após essa alteração, um resultado inesperado ocorre: o número de erros em produção começa a aumentar. A gestão não compreende por que mais falhas estão surgindo no fluxo de desenvolvimento. Como solução, aumenta-se o tempo dedicado aos testes, com o intuito de torná-los mais detalhados e abrangentes. Mas essa decisão de "aumento no tempo de execução" resulta também em atrasos no desenvolvimento.

Com o tempo, a equipe de testes é desfeita, incapaz de alcançar os resultados esperados. A responsabilidade de testar retorna à equipe de desenvolvimento, o que, curiosamente, leva a uma diminuição no número de erros em produção.

SDLC com nova camada de qualidade

Análise do Cenário​

A introdução de uma nova camada de qualidade, embora inicialmente promissora, resultou em uma diminuição da qualidade do software. Isso aconteceu porque não é eficaz transferir toda a responsabilidade pela qualidade para uma única equipe em um processo de desenvolvimento dinâmico e complexo.

O que ocorreu foi que a criação dessa nova equipe gerou uma falsa sensação de segurança entre os envolvidos no processo. Os desenvolvedores, agora amparados por uma equipe dedicada ao controle de qualidade, passaram a acreditar que poderiam relaxar em suas próprias práticas de testes e desenvolvimento. Essa confiança levou ao descuido nas etapas de desenvolvimento e testes, o que resultou em um aumento no número de erros. A equipe de testes, por sua vez, não conseguiu identificar todos esses erros antes que chegassem à produção. Essa situação é um bom exemplo do Efeito Peltzman.

O Efeito Peltzman​

O Efeito Peltzman é um conceito proposto pelo economista Sam Peltzman em seu estudo de 1975, "The Effects of Automobile Safety Regulation". Em sua pesquisa, Peltzman analisou os impactos das regulamentações de segurança em automóveis, observando que, paradoxalmente, a implementação dessas normas de segurança levou a um aumento no número de acidentes.

A ideia central é que, quando as pessoas percebem um aumento na segurança, regulamentações ou medidas preventivas, elas tendem a adotar comportamentos mais arriscados, reduzindo sua vigilância e negligenciando as precauções que tomavam anteriormente. Ou seja, a sensação de segurança gerada pela intervenção faz com que as pessoas se tornem mais propensas a agir de maneira imprudente.

Esse fenômeno também pode ser aplicado ao desenvolvimento de software. A introdução de uma equipe de testes, encarregada de identificar falhas antes da produção, não deve ser vista como a única responsável pela qualidade. Em vez disso, a qualidade deve ser uma responsabilidade compartilhada entre todos os membros da equipe de desenvolvimento. Quando se transfere completamente a responsabilidade para uma única camada de testes, os desenvolvedores podem negligenciar suas próprias responsabilidades, resultando no aumento dos erros.

A centralização da responsabilidade de garantir a qualidade do software em uma única equipe pode gerar um ambiente propício ao desleixo, reduzindo a eficácia geral do processo de desenvolvimento.

A Necessidade de Vigilância Coletiva e Dados Consistentes​

A responsabilidade pela qualidade do software é de todos os envolvidos no processo, desde os desenvolvedores até os testadores. A introdução de qualquer nova camada de controle, como a equipe de testes, deve ser acompanhada de dados objetivos e mensuráveis que comprovem, tanto a eficácia da nova equipe, quanto das equipes já anteriormente presentes no SDLC. Esses dados coletados e analisados ao longo de todo o fluxo de desenvolvimento serão usados para garantir que cada etapa esteja contribuindo de forma significativa para a qualidade do produto final.

Ao manter uma abordagem colaborativa e uma vigilância completa sobre todas as fases do desenvolvimento, é possível evitar a criação de uma falsa sensação de segurança. Isso assegura que nenhuma equipe se sinta alheia às suas responsabilidades e que a qualidade do software seja efetivamente garantida de forma integral e contínua.

Mapa Mental​

  • Nova camada de qualidade:
    • 🔴 Método A (Diminuição da qualidade):
      • Incluir equipe;
      • Centralizar a responsabilidade.
    • 🟢 Método B (Aumento da qualidade):
      • Incluir equipe;
      • Incluir monitoramento etapa por etapa;
      • Dividir a responsabilidade.

Referências​