Com quantas pessoas se faz um bom time de tecnologia?
TEMPO DE LEITURA: 7 a 9 MIN
No cenário dinâmico e desafiador do desenvolvimento de software, a composição de uma equipe eficaz desempenha um papel crucial no sucesso de um projeto. Nesse cenário, as perguntas que mais aparecem são:
- Como definir a estrutura de time mais adequada para o desenvolvimento de software? Quais perfis considerar?
- Como atrair o interesse de pessoas desenvolvedoras e lideranças para a empresa?
- Como identificar e reconhecer talentos?
- Como apoiar a formação e desenvolvimento dessas pessoas?
- Como criar e manter o alinhamento dessas pessoas aos objetivos do produto, área e empresa aos objetivos?
- Quais métricas utilizar para acompanhar o trabalho e os resultados do time?
Não prometo responder todas elas hoje, mas sim em uma série de conteúdos que irei trazer aqui periodicamente. Hoje irei me ater ao primeiro tópico que é como definir a estrutura de time mais adequada para o desenvolvimento de software. Afinal, encontrar o equilíbrio certo entre o tamanho da equipe, suas habilidades individuais e a natureza do projeto é uma busca contínua para líderes e gestores técnicos. Neste artigo, exploro as nuances dessa questão, analisando fatores que influenciam a formação ideal de um time de tecnologia e como otimizar a colaboração para atingir resultados significativos.
Saiba como aplicar isso na prática por meio de ferramentas, playbooks e estudos de cases com a Mentoria CTO do IFTL. De maneira estratégica e próxima da realidade de grande parte dos gestores de tecnologia, essa mentoria aborda sobre como:
- Implementar uma máquina de talentos
- Desenvolver know how para recrutar, contratar e reter talentos
- Implementar plano de desenvolvimento de carreiras para acelerar crescimento do time
.png)
Acompanhe também o IFTL para continuar aprendendo sobre estrutura de time, desenvolvimento e arquitetura de software, principais tendências tecnológicas e muito mais!
Sem mais delongas, vamos ao primeiro tópico…
Qual é o número ideal de membros para um time de tecnologia?
Você pode encontrar nas literaturas de agilidade os mais variados números para tamanhos de squads/times. Entrando na moda do ChatGPT, pedi a ele para listar quais são os conjuntos mínimo-máximo de membros de times de desenvolvimento e a resposta foi essa abaixo:
Estabelecer um número máximo ideal de pessoas é, talvez, o mais complicado, pois isso depende muito da complexidade do produto e projeto. Contudo, um fato é: quanto mais a equipe se aproxima de cerca de 10 pessoas, mais difícil se torna manter a comunicação fluida e um bom trabalho de gestão.
Ok, mas e o número mínimo?
Qual o número mínimo de pessoas necessárias para o time de tecnologia?
Antes de compartilhar a minha visão, é importante frisar que estou considerando que este time tem apenas pessoas desenvolvedoras. Desta maneira, PMs (Product Manager), QAs (Quality Assurance), SREs (Site Reliability Engineering), etc não fazem parte desta conta. Aqui levo em consideração uma Engenharia em que a parte de plataforma e infraestrutura é desempenhada por times transversais, focados em Devex - (experiência do desenvolvedor) e que a pessoa desenvolvedora é a responsável principal pela qualidade do produto que entrega.
Outro ponto é que irei considerar um cenário de empresa que já tem uma certa estrutura de Engenharia. Quem está começando uma Startup agora, sabe que às vezes uma mesma pessoa é desenvolvedora, SRE, CTO (Chief Technology Officer) ao mesmo tempo. Bom, uma vez feito esses disclaimers, considero que o número de pessoas desenvolvedoras em uma squad são cinco. E em “ideal” leia-se um time que promove uma entrega contínua de valor para o usuário final, com qualidade e que mantém uma operação sustentável e preserva a saúde das pessoas.
Já em momentos críticos da empresa, correndo o risco de perder pessoas em algumas frentes, diria que é aceitável ter quatro, temporariamente.
“Nossa, é muita gente!” Olha, já vi muitos gestores organizando times, olhando só para o backlog de novas coisas a serem feitas e dizendo: “não precisamos desse tanto de pessoas para tocar este roadmap!”. Porém, se esquecem que já existe um produto rodando e, que a cada novo deploy, é criado “um legado novo”, que deve ser bem monitorado e refinado.
Além disso, é preciso ter em mente sobre times de tecnologia:
- Pessoas entram de férias, licença, ficam doentes;
- Revisão de código em pares é algo que não se pode abrir mão;
- Uma vez que o time é o responsável final pela qualidade do produto, ritos de revisão do produto com PMs e demais partes interessadas são muito bem vindos;
- O escopo técnico da feature não vai surgir magicamente no card a partir da descrição do requisito de negócio pelo PM (pelo menos, não antes da AI generativa). São necessárias sessões de refinamento de requisitos antes da tarefa estar “preparada para o desenvolvimento”;
- CS (Customer Success), PMs e time de Operações têm dúvidas que precisam ser sanadas;
- Incidentes críticos e crises acontecem;
- Existem demandas “internas” vindas dos times transversais, que visam a evolução da plataforma de desenvolvimento (atualização de libs, ferramentas, etc).
- E por aí vai…
Na Mentoria CTO do IFTL, abordamos como montar times de tecnologia de forma eficaz, com base em tamanhos de empresa, tipos de segmentos e de produto ou serviço. Damos exemplos reais e analisamos caso a caso para indicar a melhor solução para não travar o fluxo de desenvolvimento de software.
Confira quais são os temas abordados na Mentoria CTO do IFTL, sobre Gestão:
- Overview máquina de talentos
- Estratégias de atração
- Contratando os melhores
- Criando um processo de onboarding eficiente
- Formação contínua
Qual deve ser a proporção da senioridade do time de tecnologia?
Quem não quer um time só de seniores e especialistas? Quem dera a vida e o mercado de tecnologia fossem fáceis assim e, exatamente por isso, o provável é que você tenha entre as cinco pessoas do time de tecnologia, profissionais juniores, plenos e, pelo menos, um ou dois seniores e/ou especialistas. Com isso, é possível promover uma trilha de evolução de carreira com pessoas que podem servir de inspiração e ajudar no crescimento de outras.
Quais são as stacks necessárias em um time de tecnologia?
Outro ponto importante na concepção do time de desenvolvimento de software são as stacks em que cada pessoa vai trabalhar. Novamente, em um “mundo perfeito”, as cinco pessoas seriam fullstack com plena proficiência para atuar nos mais complexos problemas de backend e frontend. Porém, a realidade nem sempre é essa e vejo também com bom olhos termos nesse grupo ao menos uma pessoa mais back e outra mais front “de ofício” para poder atacar pontos mais complexos e conduzir novos desenhos arquiteturais.
Geralmente, esta questão depende também do produto que será desenvolvido. Se for um app, por exemplo, com vários fluxos de interfaces, um número maior de pessoas desenvolvedoras mobile seria melhor. Já para um produto com muitas integrações e APIs, focar em expertise em backend seria uma solução.
E quanto a liderança do time de tecnologia?
Bom, isso é assunto para outro artigo, mas adianto aqui minha opinião: considero sim muito importante que os times de tecnologia tenham uma pessoa para focar na gestão, indicadores, melhoria de processos e comunicação. E nem digo que poderia ser uma por time, acredito que a pessoa líder pode atuar em mais de uma squad simultaneamente.
Agora, fazendo um recap rápido:
PROBLEMA: Qual a composição ideal de um time de tecnologia?
DOS:
- Mínimo ideal: 5 pessoas. Podendo em momentos mais críticos cair para 4;
- Ter pelo menos uma ou duas pessoas como seniores/especialistas. Assim é possível criar um ambiente que estimula a evolução de carreira para o restante: plenos, e juniores.
- Ter pelo menos uma pessoa mais backend e outra mais frontend “de ofício”. Caso seja possível, ter o restante como fullstacks seria o ideal.
DON’TS:
- Não olhe apenas para o backlog de “coisas a serem feitas” para definir o tamanho do time;
- Não subestime o esforço necessário para manter uma operação saudável, um software com qualidade e o atendimento às demais partes interessadas.
RESULTADO:
- Um time capaz de manter um fluxo contínuo de desenvolvimento de software, que cuida de sua operação/sustentação, fomentando a evolução das pessoas, de uma forma saudável para elas.
Enfim, espero que este artigo tenha te ajudado a obter insights, com base no que já deu certo e deu errado nas empresas por onde passei.
Assim como uma trilha rumo ao topo de uma montanha, essa é uma jornada em que vemos flores, belos seres, pegamos bons atalhos, rimos, nos divertimos. Também, nos arranhamos em espinhos, pisamos em buracos, discutimos sobre o melhor caminho, nos perdemos. Mas o que importa em toda essa caminhada é chegar ao topo com a sensação que valeu a pena! Vamos juntos?
Se esse conteúdo fez sentido para você, compartilhe o material e conecte-se comigo nas redes sociais para trocarmos mais aprendizados.
.jpeg)
Embaixador
Luis Batista
Head de Engenharia de Software especializado em produtos digitais. Graduado em Ciência da Computação (UFMG), com experiência em liderança de pessoas em diversas áreas de TI, como engenharia e arquitetura de software, infraestrutura cloud, business intelligence, governança de TI, segurança da informação dentre outras. Além de startups, empresas públicas e privadas de variados portes/segmentos, nacionais e multinacionais. Tem interesse em assuntos relacionados a liderança e desenvolvimento de pessoas, gestão, tecnologia, música, esportes e viagens.
.svg){kind=icon}
.svg){kind=icon}
Embaixador
Luis Batista
Head de Engenharia de Software especializado em produtos digitais. Graduado em Ciência da Computação (UFMG), com experiência em liderança de pessoas em diversas áreas de TI, como engenharia e arquitetura de software, infraestrutura cloud, business intelligence, governança de TI, segurança da informação dentre outras. Além de startups, empresas públicas e privadas de variados portes/segmentos, nacionais e multinacionais. Tem interesse em assuntos relacionados a liderança e desenvolvimento de pessoas, gestão, tecnologia, música, esportes e viagens.
Ver perfil do autor
.jpg)
