squads, tribos, colaboradores e tudo mais
Saber quando escalar e como preparar sua aplicação são passos importantes para o sucesso do seu produto, mas existe um ponto muitas vezes ignorado: o time também precisa escalar.
Não adianta ter microsserviços state of art, pipelines automatizadas e deploy azul-verde se por trás disso tudo você tem um time atolado com retrabalho, sem visibilidade e que vive apagando incêndio.
Na parte 1 falamos sobre o "por que escalar?", na parte 2 falamos sobre "como se preparar pra escalar?¨
a team that puts out too many fires ends up burning out
não é só contratar mais
A primeira ideia que vem na cabeça quando falamos sobre escalar uma equipe é integrar mais pessoas.
Mas se você só coloca mais desenvolvedores no projeto sem mudar processos, o caos e a dor de cabeça escalam juntos.
Como já dizia o clássico The Mythical Man-Month: nove grávidas não fazem um bebê em um mês.
Na prática, mais gente não significa mais velocidade, mas mais nós de comunicação e mais chance de retrabalho.
Conforme o time cresce, a comunicação entre as pessoas cresce de forma quadrática (n * (n - 1) / 2). E se você não cuida disso, o gargalo deixa de ser técnico e vira humano.
Escalar o time envolve muitos pontos e sem dar a devida atenção o time trava e o sistema também.
documentação é sua melhor amiga
Times escaláveis compartilham conhecimento. Não é mérito um dev específico saber que existe um if escrito em 2019 que quebra todo o sistema se for comentado.
Deixe claro onde estão e como executar manuais de deploy, onboarding, configs de infraestrutura e principalmente os fluxos de negócio.
Por mais sênior que o novo desenvolvedor seja, ele pode até ser o mago do Java mas ele pode ter esquecido a bola de cristal em casa e não saber rodar aquela versão de react native com as libs todas quebradas e sem suporte desde 2022.
Montar um ambiente assim não é trivial, mas deveria!
Use ferramentas que as pessoas realmente usam e têm acesso: notion, anotações em markdown, github issues e até papel de pão já resolve muita coisa, mas se você entregar pro desenvolvedor recém-contratado da sua equipe um Docusaurus com os insumos gerados nas últimas plannings ele vai conseguir ter um bom cenário sobre o que está acontecendo dentro da empresa.
Documente o suficiente, com exemplos reais, sem burocracia. E se isso não costuma acontecer, então você constrói essa cultura ou com o tempo essas informações vão se perder.
As perguntas do desenvolvedor recém-integrado na equipe devem girar em torno de:
- Como executar o seu sistema de ponta a ponta?
- Como executar os testes?
- Quais são as regras? Para que serve X tabela?
- Existem triggers? Procedures? Side effects?
- Qual o fluxo para construir um CRUD?
- É possível reproduzir o ambiente de produção?
- Como funciona o fluxo de deploy?
- Como funcionam os rituais da equipe?
Se isso é tão comum, esteja preparado para responder essas perguntas de forma assíncrona. Dessa forma você vai estar economizando horas de trabalho de vários companheiros da sua equipe, pois se alguém te perguntar a mesma coisa 2x em menos de um mês, isso deveria estar escrito em algum lugar.
divisão de responsabilidades
Com o tempo, é normal que o sistema fique grande demais para uma pessoa entender tudo. É importante que partes do sistema tenham donos (não estamos falando necessariamente do Product Owner) com liberdade e responsabilidade de manter e melhorar o que tocam.
Isso evita o famoso “quem fez isso?” no chat às 3 da manhã.
E pior do que isso, é não saber quem fez ou não ter com quem tirar as dúvidas, muito cuidado com o turnover no projeto.
Você não quer ter sua equipe travada por meses porque você perdeu seu sênior mais valioso..
comunicação e alinhamento
Mesmo tendo squads ágeis e kanban colorido, se a comunicação não fluir, o sistema vai engasgar onde menos se espera. Algumas práticas do Scrum auxiliam com essas deficiências:
- Ritual de alinhamento com visão de negócio, tecnologia e visão do projeto.
- Disponibilidade para a tirada de dúvidas.
- Contextos bem passados antes de iniciar qualquer processo.
Times que se falam constroem melhor. Tudo o que pode ser delegado, deve ser delegado. Mas o princípio de poder delegar significa que você já sabe o que deve ser feito e como deve ser feito. Você investiria seu dinheiro em algo que não entende?
autonomia (com responsabilidade)
Um time escalável precisa de autonomia para testar ideias, mudar caminhos e ajustar processos. Mas também precisa de responsabilidade e visibilidade.
Autonomia não é fazer o que quiser. É saber o que fazer sem precisar pedir permissão o tempo todo, mas com o suporte necessário.