O que é melhor: feature teams ou component teams?

A organização dos times de tecnologia dentro de uma empresa pode ser dividida basicamente entre dois tipos: feature teams ou component teams. Neste artigo pretendo explicar os conceitos de ambos times, as vantagens e desvantagens de cada um e lhe apresentar algumas conclusões práticas de quem já viveu (e ainda vive) os dois cenários nestes 12 anos de carreira com tecnologia.

Feature e Component

Uma feature é uma funcionalidade do sistema que entrega um benefício ou resolve um problema real do cliente, geralmente representada através de User Stories nos métodos ágeis. Para que as features sejam construídas é preciso que sejam criados os seus componentes primeiro, fazendo com que eles se comuniquem.

Um componente é uma parte de um software ligada a uma ou poucas tecnologias. Um banco de dados é um componente que é utilizado por várias features. Um webservice é um componente também, assim como uma tela do sistema e a somátoria de diversos componentes geram as mais variadas features.

Com isso em mente, podemos definir um Component Team como o tipo de time de tecnologia mais comum nas empresas médias e grandes: eles são organizados por uma tecnologia específica como o Time de Front-end Web, o Time de Back-end Java, o Time de Administradores MySQL e assim por diante. Também é comum serem criados Technology Teams focados em uma única skill, como o Time de Arquitetura, o Time de Redes, etc em uma visão departamental bem conhecida no mundo corporativo onde cada profissional fica no seu quadrado, entregando uma parte do produto/serviço da empresa.

Geralmente existe a figura do líder técnico e/ou gerente daquela tecnologia, dependendo do tamanho da empresa, que costuma trazer responsabilidades de gestão e uma hierarquia bem clara. É um time com uma especialidade vertical muito forte, mas bem menos versátil.

Já um Feature Team é um tipo de time de tecnologia mais comum em startups e pequenas empresas: eles são organizados por um produto ou funcionalidade específica dentro da empresa como o Time da Plataforma PHP (em uma empresa de hospedagem) ou o Time de Cartão de Crédito (em um banco). Empresas grandes que adotam esta formação geralmente quebram grandes produtos em partes ainda menores, em features (daí vem o nome) como o Time de Busca (focado na feature de busca do software) ou o Time de Relatórios (focado apenas em novos relatórios do sistema).

Nestes times as skills e backgrounds dos membros são mais diferenciadas, podendo haver mais de uma linguagem de programação envolvida (backend em Java e front-end mobile iOS, por exemplo) e pessoas de diferentes “setores” como infraestrutura, negócios, etc. Geralmente a liderança é compartilhada e mesmo quando ela é existente, é mais no intuito de apoio e servo-liderança do que gestão propriamente dita.

Encarando friamente o que os métodos ágeis pregam em termos de times, em especial o Scrum, os Feature Teams possuem um fit maior pois são verdadeiramente multifuncionais, conseguindo entregar o valor completo que a empresa precisa, de uma ponta a outra. Independente disso, vamos explorar as vantagens e desvantagens de cada um.

Vantagens e desvantagens

Falando de component teams as vantagens são:

• avanço tecnológico: times focados em uma tecnologia promovem uma evolução mais rápida, coesa e equilibrada daquela tecnologia entre todos os projetos da empresa. Quando você tem os programadores JavaScript espalhados por toda empresa é muito mais difícil de garantir padrões mínimos de qualidade e arquitetura, de garantir a evolução dos profissionais menos experientes (pois não estão tendo contato suficiente com os sêniors) e assim por diante.
• gestão/liderança: é muito mais prático elencar um gestor ou líder técnico para um time que possua uma tecnologia muito clara como foco. É natural que desenvolvedores Java enxerguem e se sintam representados por um profissional Java sênior como seu líder, além de ser muito mais fácil encontrar profissionais com um perfil “vertical” na área de tecnologia.

Enquanto que como desvantagens temos:

• cascateamento do projeto: uma vez que Component Teams não conseguem entregar produtos e soluções completas para a empresa, eles dependem do recebimento de insumos de outros times e/ou outros times dependem do insumo deles e essa cadeia completa precisa rodar muito “azeitada” para que as entregas aconteçam, no melhor estilo waterfall.
• foco na tecnologia: embora isso soe contra-intuitivo, o foco do time na tecnologia muitas vezes causa uma cegueira quanto ao produto e, principalmente, quanto ao valor gerado pelo seu trabalho para o usuário final. É sempre importante lembrar que a tecnologia é apenas um meio, não um fim.

Agora quando entramos em Feature Teams, temos algumas vantagens diferentes da sua contraparte:

• foco no cliente: mais do que foco no produto, quando o time é realmente focado em features e no valor que elas geram para os clientes, geralmente tende-se a criar produtos mais user-centered, com melhor usabilidade, com retorno financeiro maior e muito mais. Afinal, empresas vivem de clientes.
• velocidade: feature teams completos, ou seja, com todas as skills necessárias para a entrega acontecer, conseguem fazer entregas muito mais rápidas uma vez que a informação flui mais fácil entre todos os envolvidos, não há dependências (ou ela é menor) com outros times e todos os problemas do produto são compartilhados entre os membros do time.

No entanto, nem tudo são flores com os feature teams:

• débito técnico e de processos: a comunicação entre feature teams geralmente é fraca uma vez que eles são bem desacoplados uns dos outros, gerando desigualdade de tecnologias e práticas entre eles. Assim é comum termos uma pluralidade de arquiteturas e formas de conduzir os projetos que não necessariamente gera resultados positivos pra empresa, associando-se geralmente um débito técnico pesado se não há um equilíbrio entre entregar rapidamente e entregar “porcamente”.
• produtos que não se conversam: uma vez que tenhamos o desenvolvimento dos produtos espalhados entre os diversos times sem qualquer tipo de centralização dos padrões de arquitetura, UX, etc é muito comum que cada um siga uma linha de raciocínio diferente, com layouts diferentes, usando stacks de tecnologia diferentes, padrões de comunicação com o usuário, etc. Embora essa liberdade facilite as entregas, em grandes empresas isso gera um caos de gestão e pode acabar levando a uma experiência final ruim aos usuários do produto.

Tenha em mente que todas essas vantagens podem não ser a regra dependendo do perfil de profissional e de empresa que você esteja trabalhando, bem como as desvantagens podem ser contornadas sempre, desde que você tenha uma cultura forte de melhoria contínua na empresa.

Quando usar um ou outro

Note que essas classificações não são excludentes na totalidade da sua empresa, ou seja, você pode ter alguns feature teams e alguns component teams na sua organização. No entanto, elas são excludentes dentro de um time obviamente. Frameworks como SAFe falam do equilíbrio (vantagens x desvantagens) ser alcançado quando temos algo em torno de 75-80% de feature teams na empresa e o restante como component teams.

Segundo, note que não há um modelo que necessariamente seja melhor do que o outro. Tudo vai depender do seu quadro de profissionais, dos seus projetos, da cultura da sua empresa e das limitações que você possui. Como exemplos temos as pequenas empresas, onde existem poucos profissionais de cada skill, geralmente nem faz sentido organizá-los por componente, gerando times multifuncionais organicamente.

No entanto, caso você realmente queira adotar uma abordagem ágil de desenvolvimento, Feature Teams devem ser o seu objetivo para a maioria dos times. Obviamente este objetivo pode ser alcançado aos poucos, uma vez que a maturidade necessária é grande para que Feature Teams funcionem sem gerar um débito técnico altíssimo (nesse caso deve focar em Chapters fortes). Muitas transformações ágeis começam com Component Teams, para amadurecer o pessoal no core tecnológico de cada um, e aos poucos vão extraindo os profissionais preparados para atuar “solo” (sem seu líder técnico em constante contato) nos Feature Teams.

E por fim, em casos críticos onde sustentação esteja tomando todo o tempo dos times, o débito técnico esteja cobrando seu alto preço e a maturidade tecnológica esteja ridiculamente baixa, uma força-tarefa de Component Teams podem resolver este problema bem mais rapidamente antes de deixar as formações dos times mais livres novamente.

E você, como é na sua empresa? O que mais você vê como vantagem ou desvantagem em cada modelo que deseje compartilhar?

* OBS: curtiu o post? Então dá uma olhada no meu livro de Scrum e Métodos Ágeis e/ou no meu curso (abaixo) sobre o mesmo assunto!