Estruturar times de produto de forma eficaz é fundamental para impulsionar a inovação, otimizar a produtividade de equipes e entregar experiências de alta qualidade em toda a jornada do usuário. No entanto, a dúvida mais recorrente entre os CPO's (Chief Product Officer) é: como realizar essa distribuição de modo que as equipes operem de maneira eficiente e produtiva?
Neste artigo, iremos falar sobre os temas mais relevantes para a gestão de CPO's, quando o assunto é estruturar times de produto, como estrutura mínima de time, Topologia de Times, Lei de Conway e carga cognitiva. Além de trazer um compilado valioso de dúvidas reais de líderes de produto que foram respondidas pelo Joaquim Torres, que é Advisor e Consultor de Gestão de Produtos e Transformação Digital e Mentor do IFTL, durante uma de nossas Masterclass.
Entre os temas questionados pelos CPO's estão:
- Diferença entre os papeis de Product Manager e UX Designer;
- Como evitar gargalos nas squads estruturais?
- Integração entre o time de Design Ops e UX
- Como migrar a estruturação de time por produto para um modelo por jornada do usuário
- Como reestruturar times de produto, quando é necessário refazer o software?
Por isso, não deixe de acompanhar até o final. Todas as dúvidas foram respondidas com base na experiência real do Joca, ou seja, trazem exemplos práticos de como resolver gaps e maximizar a performance das suas estratégias como CPO
"O time de desenvolvimento de produto é quem vai executar a estratégia e atingir os objetivos para alcançar a visão de produto". Joca Torres
Esse time mínimo pode também ser chamado de squad e deve ter no máximo umas 7 pessoas. Quanto maior o time, maior a dificuldade de coordenação. Na Amazon existe a famosa regra dos times de duas pizzas, ou seja, o tamanho máximo do time é aquele que consegue ser alimentado por duas pizzas grandes. A quantidade de interações entre os membros do time crescem rapidamente com o tamanho do time, seguindo a fórmula n*(n-1)/2.
Assim, enquanto um time de 5 pessoas tem 10 possibilidades de interação entre seus membros, em um de 7 pessoas esse número cresce para 21.
Quando juntamos dois ou mais squads temos um time de produto, que também pode ser chamado de tribo.
Essa tribo de produto pode ter um, dois ou três líderes. Se for uma pessoa líder, ela será responsável por liderar Product Managers, Product Designers e engenheiros. Se forem dois líderes, normalmente um vai liderar Product Managers e Product Designers, e o outro liderará engenheiros. Se forem três, um lidera Product Managers, outro, Product Designers e o terceiro, engenheiros.
Times de produto também podem ter alguns papéis compartilhados entre os squads.
Há outros papéis que podem ser compartilhados mas lembre-se de que, quanto mais papéis compartilhados tiver, mais difícil ficará a coordenação das pessoas da tribo. Na mentoria CPO do IFTL, o Joca recomenda ter no máximo 3 papéis compartilhados. Eles podem ser liderados pela(s) líder(es) da tribo ou pela líder da tribo estrutural correspondente à sua função.
Na Mentoria CPO do IFTL, o Joca aborda profundamente como estruturar times mínimos de produto, dando exemplos reais da aplicação do SRE na Conta Azul em que realizaram a integração com o sistema das Secretarias da Fazenda de cada estado para emissão de nota fiscal.
Topologia de Times, ou "Team Topologies" é o termo que os autores Matthew Skelton e Manuel Pais, especialistas em DevOps, utilizaram para descrever como as “topologias de equipes” devem ser organizadas para melhorar a sua comunicação e, assim, conseguir mais agilidade, aumentando a eficiência e produtividade de times de produto e de equipes como um todo.
"Uma comunicação clara e eficiente é a chave para garantir a fluidez das entregas em times de produto bem-sucedidas." Joaquim Torres
No geral, o que se observa no contexto de times e DevOps é uma má distribuição entre funcionários altamente capacitados, que assumem problemas complexos e ficam atolados, enquanto funcionários menos experientes lidam com problemas mais simples e comuns.
Para solucionar isso e ter mais produtividade, os autores avaliaram que estruturas estáticas de time funcionam melhor para concluir entregas de produtos com o resultado esperado; e que o trabalho poderia ter um rendimento superior se organizado seguindo uma lógica que favoreça a autonomia, a automatização e o auto serviço.
Para adotar esse conceito, é importante considerar os quatro principais tipos de organização de times de produto. em Topologias de Time.
Como deve ter notado, cada topologia de time tem suas vantagens e desvantagens, e a escolha do melhor modelo depende das necessidades e características específicas de cada empresa e projeto. Também é comum que empresas utilizem uma combinação de diferentes topologias para otimizar a eficiência e produtividade de times de produto.
Essas diferentes formas de organizar times de produto podem ser usadas em conjunto, ou seja, não são exclusivas. Na verdade, é raro um time de produto usando exclusivamente um tipo de organização.
É possível ter um time por produto e outro focado na jornada do cliente e assim por diante.
Quer saber como escolher a melhor estrutura de time usando o conceito de Topologia de Times e, inclusive, descobrir como o Joca realizou essa organização de forma híbrida em suas passagens pela Locaweb, Gympass, Conta Azul e Lopes? Inscreva-se na próxima Mentoria CPO do IFTL. Nela, trazemos exemplos práticos e estudamos caso a caso para indicar a melhor solução para aumentar a produtividade de times de produto.
A Lei de Conway, também conhecida como "Lei da Organização de Sistemas", foi proposta por Melvin Conway em 1967. Esse conceito nada mais é do que uma observação sobre a relação entre a estrutura organizacional de uma equipe e o design de sistema que ela produz.
Essa lei afirma:
"As organizações que projetam sistemas estão inevitavelmente limitadas a produzir projetos cujas estruturas sejam cópias das estruturas de comunicação dessas organizações."
Em outras palavras, a lei sugere que a arquitetura de um sistema de software refletirá a comunicação e a estrutura da equipe que o desenvolveu.
Assim, quando falamos da estruturação de times de produtos, essa lei ressalta a importância de alinhar a estrutura organizacional com a arquitetura desejada para os sistemas. Em um exemplo prático, se uma empresa deseja criar um sistema altamente modular e colaborativo, será necessário que sua estrutura organizacional também seja modular e permita uma comunicação eficiente entre os times de produto.
De maneira simples se sua comunicação com a área de negócio não é clara não adianta você trabalhar com as melhores tecnologias e engenheiros que a chance de não terem um produto de sucesso é grande, por outro lado se uma organização é arranjada em silos funcionais como QA, DBA, Frontend, Backend, etc é improvável que produza um produto bem arquitetado de ponta a ponta.
"Se a arquitetura de um sistema e a arquitetura de uma organização estão em desacordo ou fora de sintonia, provavelmente, a arquitetura da organização ganha". Ruth Malan
Aqui entramos no assunto sobre a carga cognitiva, que refere-se à quantidade de esforço mental exigida para realizar uma determinada tarefa. No contexto de um time de produto e tecnologia, a carga cognitiva está relacionada à complexidade das atividades desempenhadas pelos membros da equipe.
Os três principais problemas de uma estruturação de time de produto mal planejada ou uma carga cognitiva excessiva, são:
Para distribuir adequadamente as responsabilidades, é importante considerar a experiência e as capacidades individuais dos membros da equipe, além de utilizar ferramentas e processos que ajudem a reduzir a carga cognitiva para que se obtenha produtividade.
Essa distribuição pode começar com alguns questionamentos, que você como:
Como CPO é sua função não desperdiçar talentos e a melhor forma de fazer isso é mapear exatamente as habilidades necessárias para a contratação. Desta forma, você ganha tempo e terá um custo muito menor.
A seguir está o compilado com as dúvidas de CPO's que participaram de eventos do IFTL. Decidimos reuni-las aqui, pois esse exercício ajuda a ampliar sua compreensão como líder de produto, enriquecendo sua visão geral. As dúvidas abordam problemas reais e desafios que outros profissionais do mercado estão enfrentando. Entender como essas questões podem ser resolvidas será útil para quando se deparar com barreiras semelhantes no futuro.
Sim, em algumas situações, um Product Manager (PM) pode assumir também o papel de UX Designer, especialmente em empresas menores ou em estágios iniciais de startups. Essa combinação de responsabilidades pode ser interessante quando a pessoa possui habilidades e conhecimentos sólidos em ambas as áreas. No entanto, é importante ressaltar que esses são dois campos distintos, e é difícil dividir a atenção de forma adequada entre ambas as funções.
Com o crescimento do produto e aumento das demandas, é provável que a pessoa acabe se concentrando mais em uma das áreas, de acordo com suas afinidades e expertise. Em estágios mais avançados ou em empresas com recursos disponíveis, é recomendado ter profissionais dedicados para cada função, com alguém focado em experiência/ usabilidade (UX Designer) e outro alinhado à conexão do produto com os objetivos estratégicos da empresa (Product Manager).
Os squads são equipes multifuncionais que trabalham de forma independente, o que, teoricamente, evita gargalos. No entanto, é possível que a demanda por certos produtos ou recursos específicos seja muito grande, resultando em sobrecarga para certos squads. Para evitar esse problema, é essencial analisar a capacidade de cada squad e ajustar o tamanho e a composição do time de produto de acordo com as necessidades do projeto.
Se um squad estiver sobrecarregado, a empresa e o CPO pode considerar a alocação de recursos adicionais para esse time ou a reorganização de algumas tarefas entre diferentes squads, garantindo que todos estejam operando em um nível ideal de capacidade.
O time de Design Ops, responsável por aprimorar a eficiência operacional do design dentro de uma organização, pode sim ser formado por profissionais transversais dos squads de produto, incluindo membros de UX Design. Essa abordagem pode ser especialmente útil em empresas com muitas squads e equipes de UX, onde centralizar algumas funções pode melhorar a colaboração e a padronização do trabalho.
O Design Ops pode ajudar a estabelecer processos mais eficientes, fornecer recursos e ferramentas padronizadas, garantir a consistência das diretrizes de design e promover a colaboração entre as equipes de UX. Isso permitirá que o CPO e o time de produto se concentrem mais nas tarefas principais, melhorando a qualidade do trabalho e a experiência do usuário.
Quando a empresa possui diferentes produtos com maturidade tecnológica distinta, migrar para um modelo de jornada pode ser uma excelente abordagem. A jornada do usuário representa todo o percurso do cliente ao interagir com a empresa, independentemente do produto ou canal específico. Isso permite uma visão mais holística das interações do cliente e facilita a identificação de pontos de melhoria em toda a experiência.
Se você é CPO e precisa (re)estruturar a área, é recomendado seguir os seguintes passos:
Refazer o software pode ser um desafio, pois requer mudanças significativas e impacta várias partes do produto. Nesse caso, a abordagem ideal é evitar dependências rígidas entre os times. A seguir, listamos três estratégias que podem ser utilizadas:
Referências:
Team Topologies
Lei de Conway
Estrutura de Time por Joca Torres