A observação de que desmantelar a equipe de QA pode ter sido uma decisão errada
(davidkcaudill.medium.com)- Depois de reduzir gargalos em release, deploy, gerenciamento de imagens e rollback com otimizações no estilo DevOps, o ponto mais lento na entrega de software continuou sendo testes
- O setor passou a ver não os testes em si, mas a equipe de QA como gargalo; as expectativas sobre o papel aumentaram, mas vieram junto piora nas condições, contratação temporária, offshoring e redução de vagas
- O desmonte das organizações de QA desmotivou profissionais experientes da área e, como os desenvolvedores não passaram naturalmente a assumir o trabalho de qualidade, o problema de software de baixa qualidade cresceu
- Gestão de qualidade é trabalho real que precisa ser nomeado e atribuído, como rastreamento de defeitos, triagem, investigação, defesa da qualidade e testes de ponta a ponta
- Quando o trabalho de qualidade não é organizado, quem encontra e resolve problemas não é recompensado, enquanto quem entrega rápido e quebra tudo acaba sendo recompensado repetidamente
O gargalo que sobrou depois da otimização com DevOps
- Profissionais de DevOps aplicaram a Theory Of Constraints para otimizar fortemente o pipeline e as práticas de entrega de software
- Gerenciamento manual de releases, deploy, gerenciamento de imagens e rollback em produção viraram alvos de automação
- No processo entre o backlog do produto e o código chegar ao cliente, atividades de baixo valor passaram a ser tratadas como gargalos a eliminar ou otimizar
- Como resultado, a parte mais lenta da entrega de software continuou sendo testes
- Testes também são a razão de existir da entrega contínua
- É possível tornar testes mais rápidos, automatizá-los e paralelizá-los
- Se, em uma prática, a atividade de maior valor é o gargalo, então o entendimento é que o sistema já está perto do ótimo
O setor passou a ver a equipe de QA como gargalo
- O hábito de otimização foi além dos testes em si e passou a ser aplicado também ao papel de QA
- Houve movimentos para reduzir testes de integração e de ponta a ponta a testes unitários, para paralelizá-los
- No plano de pessoas, também aconteceu de empurrarem para funções específicas quem era visto como alguém que não sabia programar
- O setor começou a considerar que o gargalo talvez não fossem os testes, mas a equipe de QA
- As expectativas sobre o papel de QA aumentaram
- Os salários caíram ou deixaram de subir em relação a outras funções
- O papel foi sendo transformado em contratação temporária e offshoring
- Seguiram-se decisões para reduzir a contratação de engenheiros de QA
O ciclo vicioso criado pela redução do papel de QA
- Quem permaneceu em QA passou a enfrentar uma estrutura cada vez mais desfavorável
- Quem programava bem o suficiente, ou quem se cansou das condições, saiu de QA
- Os demais passaram a ver quem ficou em QA como “pessoas que não eram boas o bastante para sair daquela área”
- Também diminuiu o número de pessoas que recomendavam QA para recém-formados
- As empresas romperam com QA no estilo “não vamos mais ter essa função, se virem”
- Esse processo foi grosseiro e desmoralizante para quem havia construído carreira em QA
- O desmonte de QA ampliou o problema de software de baixa qualidade, e muitas organizações ficaram sem saber quem deveria fazer o quê em qualidade de software
- Mesmo organizações que mantiveram a função de QA passaram a ter dificuldade para encontrar o lugar desse papel dentro de uma área já danificada
“Demitir testadores” não era a solução
- O “truque estranho” para entregar software mais rápido não era demitir testadores
- O que foi feito com a área de QA chega perto de um dos piores erros de gestão
- Foi uma escolha que destruiu algo desenvolvido ao longo de décadas
- O impacto pode não ser sentido por anos
- Quando a organização perceber o problema, a recuperação significativa pode levar mais anos ainda
- As partes do papel de QA que já eram problemáticas continuam sem solução
- A divisão do trabalho não aconteceu, e os desenvolvedores não assumem de bom grado tarefas de QA sem compensação, reconhecimento e estruturas de recompensa adicionais
- Algumas pessoas que já trabalharam com equipes de QA de alto desempenho conseguem imitar parte desses comportamentos, mas engenheiros e gestores mais novos têm dificuldade para saber o que está faltando
- O princípio central é que garantia de qualidade é trabalho
- Como qualquer outro trabalho, falha quando se presume que “alguém” vai fazer
- Também falha quando é tratado como trabalho invisível
O trabalho necessário para gerir a qualidade de software
-
Rastreamento de defeitos
- É preciso haver uma forma de usuários enviarem informações sobre bugs e de desenvolvedores registrarem bugs
- Bugs são tickets individuais que descrevem o que deu errado e quão grave é
- Não são a descrição do trabalho de correção em si
- Devem conter o defeito, a forma de reproduzi-lo e seu impacto
- A maioria das equipes de desenvolvimento com que o autor trabalhou recentemente não rastreava esses defeitos
- Motivos como “nem vamos corrigir isso”, “não é meu trabalho” ou “somos recompensados por funcionalidades novas” não justificam resultados de baixa qualidade
- Gerenciar uma lista de bugs já é, por si só, trabalho
-
Triagem e priorização
- Triagem de bugs é o processo de atribuir, priorizar, organizar, classificar e remover duplicações dos bugs recebidos
- Ter critérios consistentes para severidade alta, média e baixa ajuda a organização
- No passado, isso era chamado de “higiene de bugs”
- Decidir qual equipe deve assumir determinado bug também é trabalho
- Organizações que funcionam bem respondem melhor a pressões externas ou a reestruturações
- Mesmo com demissões, gerenciam a queda de qualidade de forma gradual
- Em reorganizações, transferem categorias específicas de bugs para novas equipes
- Descartam em lote bugs de funcionalidades descontinuadas
- Dizer que uma equipe sem nenhum estresse externo ou reorganização pode ignorar a triagem é quase uma piada
-
Investigação de defeitos
- Reproduzir o problema é uma parte importante da gestão de bugs
- Alguém precisa transformar um relato como “tentei comprar um ingresso de cinema e não consegui” em algo como “um problema de codificação de caracteres em clientes com caracteres não ingleses no nome quebrou o fluxo de compra”
- Perguntas como “quantas vezes isso aconteceu?” e “qual foi o impacto para os usuários?” exigem que uma pessoa real dedique tempo para responder
- Investigar defeitos é aplicar rigor de engenharia ao backlog de bugs
-
Um papel focado em qualidade
- Há valor real em ter dentro da empresa alguém focado na qualidade do produto final
- Qualidade pode ser trabalho de todos, mas ao mesmo tempo precisa ser trabalho de alguém
- A tensão entre qualidade e velocidade exige alguém que defenda a qualidade
- Ferramentas de teste, qualidade dos testes e planejamento de testes precisam de uma parte interessada com opinião e empenhada em fazê-los o melhor possível
-
Testes de ponta a ponta
- Um dos maiores e mais comuns problemas em várias organizações de engenharia é a propriedade do sistema
- O aumento da complexidade arquitetural aconteceu com o objetivo de manter equipes e aplicações pequenas, e isso pode ser uma estratégia razoável
- Mas, como resultado, surgem lacunas nas partes mais importantes da aplicação
- A equipe média já não faz mais uso e validação do produto no nível ponta a ponta, porque isso é difícil demais
- É preciso verificar se existe alguém dentro da organização realmente usando o produto antes de ele ser lançado
Problemas organizacionais que surgem quando o trabalho de qualidade é ignorado
- Pode haver a reação de que “somos ágeis, lean e dinâmicos, então não precisamos fazer esse tipo de coisa”
- Olhando de perto, é muito provável que esse trabalho já esteja acontecendo dentro da organização, só que muito mal executado
- Em áreas como automóveis, bancos ou medicina, ouvir “nós não fazemos garantia de qualidade” não é uma experiência tranquilizadora
- Quando atividades de qualidade não são reconhecidas e organizadas, o resultado pode ser muito ruim
- Os funcionários mais conscienciosos acabam no estado mais amargo
- Veem problemas de qualidade e os resolvem com frequência
- Não recebem reconhecimento por isso
- Quando levantam preocupações de qualidade, são tratados como pessoas que querem desacelerar
- Veem repetidamente pessoas que “se movem rápido e quebram tudo” sendo recompensadas
- Sentem que estão limpando, com raiva, a bagunça dos outros
- Em organizações assim, o simples ato de se importar vira uma desvantagem para a carreira
1 comentários
Opiniões do Hacker News
No início da minha carreira, no fim dos anos 1970, trabalhei na organização de Product Assurance, ou QA, da IBM Hursley Park. Para testar o produto pelo qual eu era responsável, um sistema de processamento de texto, eu criava código e hardware e executava casos de teste no sistema sob teste.
Os problemas encontrados eram repassados à equipe de desenvolvimento apenas com uma descrição geral; o objetivo era fazê-los corrigir os bugs, em vez de ajustar o código para passar nos casos de teste. Como resultado, quando encontrávamos 3 bugs em quebra de linha de palavras com hífen e exclusão com backspace, a equipe de desenvolvimento corrigia 4 bugs naquela área, mas apenas 2 dos que de fato tínhamos encontrado, e assim era possível estimar estatisticamente o número de bugs reais restantes.
Em organizações sem equipe de QA, introduzi o conceito de sniff test. Normalmente era uma sessão de cerca de 1 hora em que qualquer pessoa da empresa ou do departamento mexia em uma nova funcionalidade; mesmo quando a funcionalidade era considerada concluída, as condições de contorno quase sempre estavam quebradas. Problemas apareciam com frequência ao tentar condições simples, como preencher todos os campos com
""e enviar, navegar pela UI só com o teclado, ou usar fontes grandes e o navegador com zoom de 110%; hoje isso nem me surpreende mais.Durante o desenvolvimento de funcionalidades pequenas, geralmente só os programadores testam, então é especialmente útil porque essa forma de testar pode ser diferente de como os usuários finais reais vão usar.
Trabalhei, 15 a 20 anos atrás, em duas empresas que investiam em equipes de QA de altíssimo nível, e essas equipes realmente valiam o que custavam. QA conseguia encontrar muito bem bugs que os desenvolvedores não pensavam porque estavam próximos demais do problema, e os produtos também se tornaram de nível mundial.
Em ambas as empresas, o ponto central era que a alta direção havia definido que a equipe de QA tinha a autoridade final sobre liberar ou não uma release.
Hoje as empresas parecem achar melhor que desenvolvedores usem testes automatizados e se preocupem demais com cobertura de código, mas já vi produtos demais com 100% de cobertura de código que objetivamente não funcionavam. Não quero dizer que testes automatizados sejam ruins; quero dizer que o problema é eliminar testadores humanos de QA.
A equipe de QE da empresa em que trabalhei recentemente escrevia uma quantidade enorme de código para executar testes; tinha mais linhas de código do que o módulo que era alvo dos testes e da certificação.
Ainda assim, já ouvi um gerente de testes de uma grande empresa de software que todo mundo conhece declarar que, como tinham alcançado 100% de cobertura, a equipe de testes estava encerrada.
Mesmo com essa autoridade, em empresas onde a maior parte do QA era de contratados mal pagos que só faziam o que mandavam, continuava sendo uma bagunça.
assertTrue(true). Sempre ficam verdes e a cobertura é 100%.Essas mesmas pessoas perguntavam por que deveriam escrever testes se poderiam criar novas funcionalidades, até que vinha um QA sênior e quebrava tudo. Uma vez, ele descobriu que apertar F5 50 vezes em 1 minuto fazia o backend ficar disparando requisições ao banco de dados até morrer com
outOfMemory.Eles têm orgulho de encontrar condições de contorno que vão muito além da especificação, e isso tem bastante valor. Assim como um bom sistema de tipos dá confiança para fazer mudanças, um ótimo QA também dá confiança aos desenvolvedores. Especialmente em apps com muita interação, como jogos, é difícil cobrir todo o espaço de parâmetros apenas com testes unitários e de integração.
É uma verdade amarga dizer que os funcionários mais conscienciosos de uma organização são os que ficam mais ressentidos. Eles veem problemas de qualidade, muitas vezes os resolvem diretamente, mas não recebem reconhecimento; quando levantam preocupações sobre qualidade, são tratados como pessoas que querem desacelerar tudo.
O lado do “mova-se rápido e quebre coisas” continua sendo recompensado, enquanto as pessoas que se importam limpam a bagunça depois e acumulam raiva. Para elas, o simples fato de se importar parece um grande prejuízo para a carreira, porque de fato é.
DBAs e organizações de infraestrutura estão na mesma situação que QA, e espero que em breve o pêndulo volte.
O cálculo é: se os usuários podem reportar bugs e receber atualizações pela internet, por que gastar muito dinheiro e tempo? Depois que jogos e softwares passaram de mídia física para distribuição centrada em downloads, parece que aplicar patches ficou mais barato. Claro que isso leva a problemas de segurança horríveis e a uma experiência de usuário ruim, mas, enquanto as pessoas no topo maximizarem o lucro, elas não se importam muito.
Se você está criando um produto SaaS de POC, não precisa de qualidade no nível de um microcontrolador aviônico. Toda concessão envolve riscos e custos, e um bom engenheiro precisa saber a diferença.
O problema central das equipes de QA é o mesmo das equipes de TI ou das organizações de gestão. Quando fazem bem o trabalho, parece que não estão fazendo nada.
Por isso, muitas vezes acabam tendo de “justificar” o próprio trabalho, e isso geralmente vem de uma dependência excessiva de métricas. Como na lei de Goodhart, não se entende do que a métrica é um valor substituto nem qual é o objetivo real daquele trabalho.
Uma equipe de QA ruim fica procurando pelo em ovo em excesso para parecer que tem algo a dizer; uma boa equipe de QA verifica a qualidade e, ao mesmo tempo, treina os funcionários para produzirem com mais qualidade.
Sinto que há falta de treinamento de modo geral nas equipes. Aquele texto que apareceu há pouco na front page, “o percentil 95 também não é tão impressionante” (https://news.ycombinator.com/item?id=38560345), dizia que, como a maioria dos profissionais não treina ativamente nem recebe feedback, chegar aos 5% melhores em qualquer área é fácil.
Acho que empresas deveriam treinar continuamente como times profissionais, não como equipes esportivas amadoras. A contratação também deveria olhar menos para “essa pessoa já é uma top performer?” e mais para “conseguimos transformar essa pessoa em uma top performer?”. O fato de alguém ter tido sucesso em um ambiente anterior significa menos do que se imagina quando o novo ambiente é muito diferente.
Em todo texto sobre qualidade de software, há muitos comentários que tratam a indiferença generalizada dos engenheiros como algo natural. Depende do contexto, mas as pessoas parecem bastante dispostas a simplesmente seguir o ótimo local da própria organização e abrir mão da iniciativa. Não é inteiramente culpa delas, mas também não são inocentes.
Se você elimina tarefas repetitivas com automação, o cargo dessa pessoa desaparece; mas, se fizer isso direito, o gerente acha que ela fica sentada o dia inteiro sem fazer nada, então há pouco incentivo para fazer do jeito certo.
Como não são avaliados pelo número de bugs encontrados, também não há pressão para forçar a descoberta de bugs bobos só para aumentar os números.
Um bom treinamento exige um grupo técnico com pessoas boas e suficientemente amplas. Não precisam conhecer todas as tecnologias mais recentes, mas precisam ser capazes de detectar e apontar besteiras. Nem a FAANG é exceção.
Como o texto também aponta, o ponto realmente central é que QA quase sempre é visto pelas unidades de negócio e pela alta gestão como um departamento de custos.
Tenho a hipótese de que é melhor não trabalhar em uma organização que é vista como departamento de custos. Bônus, reconhecimento e respeito sempre vão para o lado que gera dinheiro; departamentos de custos assumem mais trabalho com menos gente, levam a culpa pelos fracassos e são cortados primeiro quando a empresa reduz o tamanho. TI é igual.
Por causa desse ciclo vicioso, uma carreira em QA inevitavelmente acaba sendo mais difícil do que virar desenvolvedor com habilidades parecidas. As pessoas excelentes se cansam e saem o mais rápido possível, e essa estrutura se reforça sozinha.
Acessibilidade, observabilidade, bom logging, melhorias na infraestrutura de testes, ajustes de CI/CD, estabilidade, linting melhor e problemas de analisadores são todos importantes, mas a recompensa vem quando se lançam funcionalidades rapidamente.
Este ano, passei tempo demais nesse tipo de trabalho porque achava necessário para a equipe e para o app, e estou preocupado com a avaliação de desempenho de fim de ano. Agora entendo por que os outros evitavam essas tarefas, e no ano que vem pretendo focar em lançar funcionalidades mais visíveis. Sinto muito pelos bugs do app, mas preciso do emprego para pagar a hipoteca.
Algumas organizações valorizam sinceramente o valor que QA/QC traz. Vi isso melhor na manufatura do que em software, imagino que porque software é intrinsecamente mais abstrato e é mais difícil rastrear desperdício.
Um QA realmente bom não é alguém que procura o caminho mais fácil, mas alguém que acredita na missão do QA. No fim, isso quer dizer que o valor vem de a organização e os indivíduos abraçarem de verdade o espírito de QA, e há muitos lugares que fazem isso só de maneira formal.
Ainda assim, tudo bem. Gosto de tornar as coisas melhores e mais robustas, e isso me deixa em paz. Vou deixar o trabalho de quebrar as coisas para os cínicos.
Tudo bem que bônus e afins vão para outros grupos. Sou suficientemente bem pago como profissional técnico, e muitos desses cargos que geram dinheiro teriam me deixado realmente infeliz, mesmo que eu fosse de fato bom neles.
Qualidade de software, manutenibilidade do código e bom design só importam quando você planeja trabalhar naquela empresa por muito tempo.
Se você pretende ficar alguns anos e depois ir para a próxima empresa, o caminho ideal é fazer trabalho bem visível, subir rapidamente e usar esse histórico para conseguir um emprego com salário maior. Se, alguns anos depois, aquele projeto quebrar ou se tornar impossível de manter, não importa, porque você já não estará lá.
Startups funcionam do mesmo jeito. O mindset de crescimento gravado por toda parte é exatamente esse padrão. Mesmo que o produto se torne impossível de manter daqui a 5 anos, talvez a essa altura você já tenha feito o exit e embolsado o dinheiro.
Não culpo exatamente essas pessoas. As próprias empresas usam essas práticas, e as pessoas apenas jogam de acordo com essas regras. Não gosto disso e realmente odeio, mas entendo.
A parte engraçada é ver gerentes e executivos reclamando de turnover, falta de comprometimento com a empresa e quiet quitting. É como se estivessem provando do próprio veneno.
Se, depois de 5 anos, ela ainda estiver viva com dívida técnica, para muitas startups isso é, na verdade, um bom problema. Porque significa que, de algum modo, elas sobreviveram 5 anos.
Engenheiros de QA também costumam ser muito bons em depuração. Eles mexem em pipelines, código-fonte e diretórios de testes, e lidam com quase todos os aspectos do desenvolvimento e da implantação de aplicações
Quando eu era líder de QA, via com frequência engenheiros de software reclamando todos os dias no Slack sem sequer tentar ler as mensagens de erro do pipeline. Mesmo em otimizações de pipeline, ignoravam o problema raiz e passavam dias tentando resolver por tentativa e erro os sintomas derivados dele, fingindo que eram problemas mágicos e incompreensíveis
O desprezo por engenheiros de QA descrito neste texto não é exagero. Mesmo empresas com organizações de QA muitas vezes não têm processos de entrevista tão rigorosos quanto os da engenharia, então engenheiros de QA acabam sendo subestimados
Os únicos SWEs que respeitavam QA eram os que já tinham trabalhado em QA. O desprezo era tão disseminado que acabei voltando para a organização de engenharia e tentei mudar isso usando minha senioridade como principal engineer e papéis de gestão, mas fracassei. A engenharia não conseguia enxergar além da própria arrogância, e a liderança também não ajudou
O novo CTO da empresa em que eu trabalhava antes de ser demitido dizia que seria possível eliminar a necessidade de QA com automação, mas não dava um único exemplo do que queria dizer. Esse era o nível de respeito que vinha de cima pelo trabalho de fazer bom software
A Microsoft parece ser o caso em que esse problema é mais evidente. Depois que acabou com as equipes de QA, os bugs em atualizações do Windows e de produtos de nuvem aumentaram visivelmente
Uso muito software e serviços da Microsoft no trabalho, e gostaria que eles pagassem de alguma forma pela queda de qualidade
Pode ser apenas minha experiência pessoal, mas nunca vi uma equipe de QA que realmente escrevesse testes para a engenharia
As equipes de QA com que trabalhei escreviam planos de teste e os executavam manualmente ou, mais raramente, por meio de testes automatizados de navegador/dispositivo. Esses testes também têm valor, mas acho que menos do que testes unitários ou de integração
Nesse modelo, na prática a equipe de engenharia vira a equipe de QA, e uma equipe de QA separada muitas vezes acaba gerando ruído ao apontar como bugs coisas que não são bugs, criando mais custo do que valor
Gostaria de aprender um modelo de equipe de QA que funcione bem. Testes manuais são ótimos, mas pela minha experiência têm limites. Não quero diminuir o pessoal de QA, apenas compartilhar minha experiência
Conhece de forma abrangente o sistema inteiro visto pelo usuário, mais do que PMs, vendas ou a maioria das equipes de desenvolvimento, e consegue dizer exatamente o que acontece quando se aperta determinado botão. QA ruim realmente é uma fonte de ruído, mas desenvolvedores, administradores de sistema e suporte de nível 1/2 ruins também são
Enquanto você está passando por isso, é realmente irritante, mas a qualidade do resultado fica muito melhor
Antigamente, QA normalmente não escrevia testes; testava o código manualmente e fazia todo tipo de coisa estranha que você torceria para um usuário não fazer. Encontrava problemas e bugs difíceis de capturar de forma geral com testes
Agora empurramos QA para os usuários. Ao trabalhar com desenvolvedores mais jovens, sinto que o próprio conceito de QA está ficando cada vez mais estranho. Quando um bug chega à produção e pergunto “como foi quando você mexeu nisso localmente?”, muitas vezes recebo um olhar esquisito. É como se a ideia fosse: passou no type checker, então por que não lançar?
Hoje a eficiência de programadores é medida em PRs por minuto, então introduzir bugs não é um problema; na verdade, é até bom. Se alguém descobrir em produção, dá para abrir outro PR corrigindo alguns dias depois. Se houvesse QA, esse fluxo teria sido estragado
Cada empresa implementa a função de QA de um jeito. Algumas deixam para os clientes; outras para desenvolvedores, suporte ao cliente, QA manual ou SDETs. No fim, depende de quanto a liderança valoriza qualidade e de como enxerga QA
Se existe uma equipe de QA, acho que ela tem mais chance de sucesso quando participa desde o início do processo. Uma boa equipe de QA deve encontrar bugs antes de o código ser escrito. Quanto mais tarde entra, mais tarde os bugs são encontrados e mais ela fica espremida entre o “código concluído” e o lançamento. A equipe de QA precisa ter capacidade de automação para poder dedicar tempo a novos casos de teste, em vez de repetir testes manuais
Este texto me atingiu de forma bem dolorosa. QA às vezes é tratado como cidadão de segunda classe e fica de fora de discussões em que poderia obter o contexto necessário para fazer bem o trabalho. Quando pessoas boas saem para desenvolvimento ou gestão de produto, a situação piora, e a espiral descendente realmente existe
O que você acabou de descrever é um problema de liderança, não um problema de utilidade de QA
QA passava tempo criando infraestrutura de testes e planos de teste sem ser integrado desde o início, e então, no final, recebia um bloco de código e um prazo de 48 horas para aprovação, tendo de assinar sob enorme pressão
Mas, de vez em quando, era possível encontrar uma organização de QA que entendia profundamente o domínio do problema e realmente conduzia o desenvolvimento. Ela avançava lado a lado com o desenvolvimento do começo ao fim e não só aumentava a qualidade como também economizava o tempo de todos
Ao criar o FoundationDB, houve um foco quase obsessivo em qualidade e testes. Por isso, chegaram a criar uma linguagem chamada Flow, que permitia simular de forma determinística clusters do FDB de tamanho arbitrário, submetê-los a condições extremas, sinalizar violações de propriedades do sistema e reproduzir perfeitamente a execução do teste que causou a violação
Todas as noites, dezenas de milhares de execuções de testes chegaram ao ponto em que, se não houvesse código novo, basicamente todas ficavam verdes. Testes que ficavam vermelhos quase sempre eram causados por uma adição recente de código, então eram fáceis de identificar e corrigir
Graças a isso, a equipe podia desenvolver sabendo que bugs recém-introduzidos seriam encontrados rapidamente, o que levou a um ritmo em que era possível assumir com confiança projetos ousados, como a reescrita do sistema de processamento de transações após o lançamento. Como resultado, também obtiveram um ganho de velocidade de 10x
No fim, o foco em qualidade levou a velocidade, e os dois não entravam em conflito de forma alguma. Não acho que isso seja um fenômeno isolado, e foi por isso que isso levou a um novo projeto, mas essa é uma história para outra hora