Sobre QA (e Front-end e BA)

No artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas, prometi que o próximo artigo seria sobre o papel de gestor de gestores de produto. Contudo, recebi alguns comentários sobre a falta do time e do papel de QA (Quality Assurance) na organização dos times, por isso resolvi mudar um pouco a sequência de temas e vou falar nesse artigo sobre QA (e Font-end e BA).

Disclaimer

Antes de mais nada, gostaria de citar uma frase muito bacana que ouvi certa vez e que deve ser lembrada sempre que conversas sobre pontos de vista distintos acontecem:

O fato de discordamos não significa necessariamente que um dos dois está errado.

Qual é o objetivo?

Na minha visão, processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

QA (e Front-end e BA) na Locaweb

Até meados do segundo semestre de 2015 tínhamos na Locaweb os times de engenharia de produtos, um time para cada um ou dois produtos, e tínhamos dois times funcionais separados desses times de engenharia de produtos, os times de Front-end e de QA. O artigo anterior foi extraído do meu livro e no livro o texto ainda contempla Front-end e QA separados da engenharia. No final do ano decidimos por não ter mais time de Front-end nem de QA.

Sobre o time de Front-end:

  • O time tinha 5 desenvolvedores, enquanto a Locaweb tinha 12 times de desenvolvimento de produtos e sistemas. Como desenvolvedores de back-end não mexiam com front-end, o time de front-end acabava virando gargalo.
  • O time havia desenvolvido, junto com UX, o Locaweb Style um framework front-end de comportamento e estilo que usamos em nossos produtos e disponibilizamos para que qualquer pessoa tb possa utilizar em seus projetos. O objetivo do Locaweb Style é facilitar o programação front-end das interfaces de nossos produtos. Com o Locaweb Style ficou mais fácil desenvolvedores de back-end fazerem front-end e diminuir o gargalo.
  • Com isso decidimos não ter mais o time de Front-end e os desenvolvedores de front-end foram para os times de produtos onde front-end é mais relevante. Os desenvolvedores de front-end passaram a tb mexer em back-end, assim como os desenvolvedores back-end passaram a mexer em fron-end. Sempre respeitando o Locaweb Style.
  • Diego Eis, que era coordenador desse time de Front-end, contou em um artigo como foi a mudança. Ele passou de coordenador de time funcional a coordenador de time de engenharia de um produto. Isso deu a ele a aos membros do time de front-end, que agora são desenvolvedores alocados em um time de produto, um senso maior de propósito, pois entregam um produto completo e não só a programação da interface.

Sobre o time de QA:

  • Quando existe a função de QA separada da função de desenvolvimento de software, é comum ouvir frases do tipo “a funcionalidade está pronta, agora está em QA”, o que denota uma cultura waterfall, o que pode aumentar consideravelmente o tempo de desenvolvimento e impactar negativamente a qualidade do software.
  • Quando existe a função de QA separada da função de desenvolvimento de software, também é comum ouvir frases do tipo “por que o QA não pegou esse bug?”, o que denota uma cultura de busca de culpados, que pode ser bem prejudicial para o clima do time e, consequentemente, impactar negativamente a qualidade do software.
  • Qualidade não deve ser a preocupação de uma pessoa ou de um time, deve ser uma preocupação de todas as pessoas que estão trabalhando no software.
  • Qualidade é um requisito não-funcional, ou seja, um requisito que especifica um critério para julgar a operação de um software, o que é diferente do requisito funcional, que especifica um comportamento do software. Performance, escalabilidade, “operabilidade”, “monitorabilidade” são alguns exemplos de requisitos não-funcionais de software que são tão importantes quanto a qualidade. Mesmo assim, não existem o papéis de perfomance assurance, scalability assurance, operability assurance e monitorability assurance. Por que qualidade é o único requisito não-funcional que tem uma função específica para assegurá-lo?
  • QA tem por foco garantir a qualidade do processo de desenvolvimento de software. Se é necessário um papel separado para garantir essa qualidade, por que não existe a necessidade de um papel separado para garantir a qualidade do processo de gestão de produtos, do processo de design de UX, do processo de marketing de produtos, do processo de vendas, do processo financeiro?
  • Na Locaweb tínhamos em torno de 12 QAs, alguns com perfil mais de desenvolvedor e outros com perfil mais de SysAdmin. Ao propormos a extinção do papel de QA, alguns dos QAs viraram devs de um produto enquanto outros assumiram o papel de sysadmins.
  • Existia entre os devs a preocupação de que, se o próprio dev agora vai ter que testar, as entregas vão demorar mais para ficar prontas. Essa preocupação existia pois os devs consideravam que seu trabalho terminava quando passavam a história para o QA testar. Contudo, essa visão de pronto do dev é incorreta, pois ele só passou a história para a próxima fase, o teste. Do ponto de vista do usuário do software, a história só está pronta quando o usuário pode utilizar a nova funcionalidade. E o que acontece quando a história não passa por QA e tem que voltar pro desenvolvimento?

Sobre BA:

Outro questionamento que recebi quando publiquei o artigo anterior foi sobre a ausência de BA (Business Analyst). Não coloquei explicitamente o BA pois BA e PO são papéis muito similares no desenvolvimento de software. Ambos têm o mesmo objetivo: ajudar o time a fazer um software que atenda ao objetivos do dono do software enquanto resolve problemas e necessidades de seus usuários. Em algumas organizações pode acontecer de o BA estar focado exclusivamente no business, ou seja, em entender apenas quais são os objetivos de negócio, deixando de lado os problemas e as necessidades dos usuários. Nesse caso, é importante o BA passar a levar tb em consideração os problemas e as necessidades dos usuários do software, balanceado-os com os objetivos de negócio.

Concluindo

Com esse artigo espero ter esclarecido as perguntas sobre a ausência de QA e BA que ficaram do artigo anterior, sobre organização de times de desenvolvimento de produtos e sistemas. Vale lembrar que processos, metodologias e formas de se organizar um time não são o objetivo em si, mas sim os meios, as ferramentas para se atingir um objetivo. No caso de um software, o objetivo normalmente é atender aos objetivos estratégicos do dono desse software e, ao mesmo tempo, resolver problemas e necessidades dos usuários desse software.

No próximo artigo meu plano é falar um pouco sobre o papel de gestor de gestores de produto. Stay tuned!

Livro sobre gestão de produtos

Vc gosta do tema gestão de produtos de software? Quer se aprofundar mais no assunto? Escrevi um livro sobre o assunto, dividido em 5 grandes áreas:

  • Definições e requisitos
  • Ciclo de vida de um produto de software
  • Relacionamento com as outras funções
  • Gestão de portfólio de produtos
  • Onde usar gestão de produtos de software
Capa do Livro Gestão de Produtos

Esse livro é indicado não só para quem tem software como seu core business, como tb para empresas que desenvolvem software sob demanda e empresas que não tem software como seu core business mas usam software para se comunicar com seus clientes como, por exemplo, escolas, bancos e laboratórios clínicos.

Interessou? Então adquira sua cópia hoje mesmo!

Newsletter

Se você quiser receber artigos por email sobre startup, gestão de produtos e gestão de TI, digite seu endereço abaixo e aperte enter:


8 ideias sobre “Sobre QA (e Front-end e BA)

  1. Ola Joca, tudo bom?

    Primeiro desculpem-me sobre os acentos, pois estou em uma escola em outro pais e nao tenho permissao para configurar o teclado em portugues.

    Muito bom o artigo e principalmente a parte que fala: “O fato de discordamos não significa necessariamente que um dos dois esta errado.”… foi isso que me fez admirar a gestao da Locaweb.

    Para quem nao me conhece, eu era o lider do time de QA na Locaweb antes do mesmo acabar.

    Sobre o fim de QA eu tenho uma visao diferente, mas e necessario alinhar como estavamos trabalhando no momento que se encerrou as atividades de QA. Nao eramos um time separado, mas sim faziamos parte do time do produto, isto e, os QAs ficavam alocados em cada time e nao eram de um time separado do time de desenvolvimento, tinha um envolvimento lado a lado com todos os integrantes do produto que estava testando, cada QA estava inserido no time ficando lado a lado com os desenvolvedores e com os POs/BAs. Diferente do que ocorria com o time de Front e de UX que sim, eram um time completamente separado (em um silo), um grupo fora do time do produto que faziam atividades ordenadas por eles. As atividades do QA eram priorizadas pelo proprio time que ajudava na qualidade em conjunto com os QAs.

    O time de QA tinha eu como lider, mas lider para orientar em melhores tecnicas para se utilizar, para motivar, para cuidar de toda parte funcional (ferias, folgas, salarios…), treinar e orientar quando necessario, sendo que o principal objetivo sempre foi o mesmo do time de produtos ao qual fazia parte, entregar o produto no tempo e com qualidade (seguindo as funcionalidades ordenadas pelo PO). Tinhamos algumas metas de QA, mas jamais sobrepos as metas do time do produto que estava trabalhando.

    Nao tinhamos QAs no nivel que gostariamos, mas estavamos caminhando rapidamente para isso. O objetivo era ser um DevQA ( tem alguns artigos bons sobre isso que a Kamila Queiros escreveu http://mihqueiroz.com.br/tag/devqa/ ) e tentei passar isso para a gestao que tinha um pensamento diferente. Todos os QAs ja estavam preparados para automatizar UI e API, estavam sendo preparados para automatizar Testes Unitarios e estavam tendo treinamento de Ruby para ajudar o time no dia a dia com mao na massa em partes que geram qualidade (como monitoracao de API por exemplo).

    Mostrei as atividades dos QAs (que nao eram poucas) e falei que se nao tivessem QAs os Devs deveriam realizar esta atividade, como por exemplo Planejar os melhores testes a serem realizados, usando tecnicas de testes (como Classe de Equivalencia, valores limitrofes, PairWise, regra de pareto, tabela de decisao…) no qual os QAs estavam treinados. Muitos dos Devs que trabalhavamos nao tinham ideia de varias destas tecnicas, e precisavam ser treinados se quisessem realizar os melhores testes e os mais importantes sem repetir testes desnecessarios. Agora pergunto sera que foram treinados, estao aptos para fazer o melhor planejamento?

    Outra duvida, fizemos um trabalho de automacao de UI de todas as funcionalidades criticas dos paineis. E testes de regressao sao importantes em qualquer empresa, para garantir que o que entrou de novo nao esta quebrando algo que estava pronto, entao pergunto, estao mantendo esta automacao, ou ela esta esquecida?

    Sem no minimo estas duas atividades, o time nao conseguira manter a mesma qualidade e em um momento ou outro pode surgir um problema que seria evitado se tivesse um QA.

    Outra duvida, foi desfeito o time de Front End, e o mesmo foi inserido no time de produtos, a intencao e o pessoal de front saber desenvolver em back e front e o time de back saber desenvolver em front e back tambem, isto e, um desenvolvedor full stack, sera que isso esta acontecendo? Foi possivel ter desenvolvedores full stack desde os com menos experiencia ate os que tem mais experiencia e nao gostam de fazer as duas coisas (pois ja tinha optado por um lado)?

    Para encerrar gostaria de colocar uma situacao, se a cultura era jogar a bola para o QA (o que nao estava mais vendo dos desenvolvedores a muito tempo e sim muitas vezes somente nos gestores e coordenadores de produtos), nao adianta ter o fim do time de QA, pois o culpado vai ser outro a partir de agora: UX, ou os Devs com menos conhecimento, ou Marketing… o problema e o pensamento das pessoas e nao QA em si.

    Torco de coracao para que tenha dado certo, pois gosto muito da Locaweb (excelente lugar para trabalhar), mas nao concordo com o fim dos QAs nos times.

    E como ja falado no inicio, foram apenas diferentes pensamentos que levaram ao fim de QA, as empresas precisam mudar para tentar evoluir e esta sendo uma tentativa da Locaweb.

    Acredito que consegui explicar um pouco de minha visao.

    Grande abraco a todos.

    E bons testes com qualidade.

    Robson Agapito Correa
    QA Specialist

    • Oi Agapito,

      Obrigado pelo seu comentário e por apresentar a sua visão. Como disse no artigo, o fato de discordamos não significa que necessariamente um dos dois esteja errado. A questão não é ter ou não ter QA, mas sim entregar um software que atenda aos objetivos estratégicos, enquanto resolve os problemas e necessidades dos seus usuários. Ainda é cedo para afirmar que a mudança que fizemos foi um sucesso. Sem dúvida foi uma mudança arriscada.

      Contudo, temos percebido um aumento do senso de propriedade que os devs estão tendo em relação ao sistema ou produto que cuidam, o que era um dos objetivos dessa mudança. Nenhum time fez questionamentos sobre como manter a qualidade sem os QAs. A percepção é que os devs têm condições de fazer isso. Acredito que o principal questionamento que ainda existe é que o time vai ficar menos produtivo, pois terá que absorver mais uma tarefa.

      Enfim, vamos continuar experimentando e adaptando! Só assim aprendemos e melhoramos!

      Abs,
      Joca.

  2. Joca, parabéns pelo texto. Muito interessante essa reorganização e os outputs q essa mudança mira. Minha pergunta é: não seria necessária uma reeducação dos desenvolvedores para que tenham uma visão voltada à qualidade? Digo isso pois quem disseminava a cultura e as ações q visavam a qualidade – como continuous integration por exemplo – eram sempre os QA’s. Coordenadores e desenvolvedores raramente tinham tempo para pareamento ou refatoramentobde código. Logo, devido a alta demanda de trabalho e a dificuldade em manter pessoal, me parece uma mudança arriscada. Adoraria ouvir sua opinião sobre isso.

    • Oi Vinícius,

      Sim, sem dúvida é uma mudança arriscada, mas já temos percebido um aumento do senso de propriedade que os devs estão tendo em relação ao sistema ou produto que cuidam. Nenhum time fez questionamentos sobre como manter a qualidade sem os QAs. A percepção é que os devs têm condições de manter a qualidade. Os questionamentos que existem é que talvez o time vai ficar menos produtivo, pois terá que absorver mais uma tarefa. Ainda é cedo para afirmar que a mudança foi um sucesso, mas há indícios de que estamos no caminho certo!

      Abs.

  3. Boa tarde Srs,

    Entendo a preocupação de ambos os lados, enquanto inovar é preciso (opinião do Joca) e manter o funcionamento é necessário (opinião do Robson).

    Acredito que o empirismo falará mais alto, compartilho do receio do Robson quanto movimentar as pessoas das áreas que elas escolheram, uma vez que o perfil de um “Front-End” está mais voltado para criação a lógica sendo quee o oposto acontece com o “Back-End” e o ponto de vista de quem realiza os testes é diferente daquele de quem o desenvolveu. Ao meu entender seriam necessários diversos treinamentos e tempo para esses profissionais, sem levar em consideração o “turnover” da equipe que sofreu alteração e os que conseguissem se adequar as exigências, teriam o seu valor de mercado maior do que no inicio da mudança, podendo tornar um problema para a própria Locaweb em encontrar profissionais que se encaixem nesse “novo” perfil, podendo elevar mais ainda os custos de manutenção dos produtos.

    Gostaria de esclarecer que é só mais um ponto de vista e que isso poderá ser contornado com outras estratégias da empresa, e que é um ponto de vista de fora dos envolvidos.

    • Oi Diego,

      Obrigado por deixar sua opinião aqui! Como disse, ainda cedo para sabermos se o experimento deu certo. A mudança ocorreu no início do ano. Acho que precisaremos esperar até o meio do ano para sabermos se esse modelo de organização funciona, pelo menos para a Locaweb. Lembrando sempre que o objetivo não é o modelo de organização. Isso é só um meio para se atingir a um objetivo que, no nosso caso, é desenvolver sistemas e produtos que atendam aos objetivos estratégicos da Locaweb enquanto resolvem problemas e necessidades de nossos usuários.

      Abs,
      Joca.

  4. Pingback: Como quadruplicamos a produtividade de desenvolvimento de software sem aumentar o time e sem queda de qualidade | Guia da Startup e da Gestão de Produtos de Software

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>