Estrutura de Times

Por que estruturar times?

A forma como seu time está estruturado tem um impacto significativo no sucesso do negócio. Quando falamos em modelos de equipe, estamos buscando a estrutura mais otimizada e que nos leve a melhores resultados. 

Se você está numa iniciativa de pequeno porte, uma equipe multifuncional provavelmente é suficiente para dar conta do recado. Contudo, à medida que sua empresa ou produto vai ganhando corpo, naturalmente surge o desejo de criar novos times, de crescer a estrutura, de acelerar a entrega de valor.

Porém, como essas equipes devem se estruturar de modo a alcançar coordenação, comunicação e performance?

Equipe de Componentes x Equipe de Feature 

Equipes de Componentes têm a responsabilidade sobre determinado componente, tornando mais fácil sua padronização e manutenção. Todo o foco do time está voltado à tecnologia e não ao negócio. Portanto, equipes de componentes não possuem todas as habilidades necessárias para entregar uma feature de ponta-a-ponta, ou seja, estão mais voltadas a práticas waterfall atendendo a diversas demandas porém de uma única fase.

São compostas por especialistas e possuem referência técnica dentro do próprio time, onde é comum haver ver uma certa segregação do conhecimento, onde geralmente o mais sênior é o líder/gerente da equipe.

Por não responder a uma feature em específico, precisam lidar com diferentes prioridades que podem acabar por impactar a entrega de outros times e consequentemente no desenvolvimento, lançamento ou respostas à mudança daquela feature. Prática comum é a famosa fila de demandas (first in, first out). 

Equipes de Feature são mais utilizadas em uma abordagem ágil por estarem focadas na entrega ao cliente de ponta-a-ponta, promovendo um menor tempo de resposta ao usuário final. Dessa forma equipes de feature tendem a criar funcionalidades mais user-centered, pois vivem mais a dor do cliente.

Essa entrega mais rápida é possível, pois times de features devem possuir todas as habilidades para entregar a feature por completo, reduzindo assim a dependência externa. Contudo, os códigos de componentes estarão distribuídos pelas features, ou seja, sua manutenção dependerá de maior comunicação entre os desenvolvedores, podendo contribuir para o aparecimento de débito técnico, subotimização ou inadequação de padrões arquiteturais.

Imagine a seguinte situação:

Existem 3 times de componentes (UX, Front, e Back) responsáveis por um único produto. A feature “Catálogo de Produtos” é então dividida para cada time, que ao final da Sprint deverá entregar um incremento integrado com os demais componentes. Até aqui tudo ok. A chance de dar algum problema é baixa, mas pode acontecer, caso algum time de componente não consiga entregar a sua parte, então todo o incremento estará em risco.

Agora imagine que esses mesmos 3 times de componentes, precisam trabalhar em 2 demandas diferentes: “Catálogo de Produtos” e “Pagamento”. Ao final da Sprint, os 3 times devem entregar sua parte de componente integrada ao incremento. Caso algum time não entregue, aquele incremento estará em risco, certo? A mesma coisa que aconteceu no exemplo anterior, mas dessa vez, há um detalhe a mais: E se o time de componente 1 priorizar a demanda de Catálogo de Produtos e os demais times priorizarem a demanda de Pagamento? Pode acontecer de, no final da Sprint, nenhum dos dois produtos terem um incremento entregue! Conseguem imaginar se tivermos 5, 10, 15 demandas para esses 3 times de componentes? A probabilidade de falha nessa entrega é enorme!

Para solucionar esse problema, podemos estruturar a equipe, como equipe de features, assim, todas as habilidades necessárias para criar uma feature estará dentro de um único time e não precisaríamos terceirizar uma parte de um componente.

Equipes de features reduzem a dependência externa e focam na feature como um todo enquanto equipes de componentes tem um foco mais individual e aumento de dependência externa

Uma forma de melhorar a comunicação entre os desenvolvedores de um mesmo componente cross-feature é adotar a estrutura representada abaixo, onde, na linha vertical temos a disposição de equipe de features, e na horizontal, os desenvolvedores organizados em componentes distribuídos nas features.

Essa é uma forma de alinhar padrões, tecnologias, conhecimentos e compartilhar problemas do dia a dia com os pares. Portanto, a estrutura horizontal é composta por desenvolvedores que possuem um mesmo domínio técnico – por exemplo UX – disposta em um nível hierárquico o qual geralmente é representado por um líder técnico.

Na vertical estamos otimizando a entrega de valor, na horizontal estamos otimizando a qualidade da camada/componente.

Fechamento

Embora pensando em escalabilidade a adoção de times de features seja mais adequada, não existe um veredicto em que a escolha pela abordagem de equipes de componentes não deva ser realizada. Muito depende do atual momento de transição da organização, de como as habilidades técnicas estão distribuídas e como a arquitetura técnica das features estão desenhadas.

É natural para empresas que estão fazendo transformação digital, haver uma transição de times de componentes para times de features. Já para startups, ainda em processo de amadurecimento da sua estrutura, os times de features acabam ocorrendo naturalmente pois geralmente começam com um ou poucos times multi-funcionais.

De forma geral, é comum encontrar os 2 tipos de estrutura em uma organização. Cabe analisar qual é a melhor configuração e distribuição de estrutura dentro do seu contexto.