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!