Gestão de Equipes¶
Como formar, desenvolver e conduzir times de forma sustentável. Complementa Liderança (como influenciar pessoas) e Gestão de Projetos (métodos e planejamento), e se conecta a Soft Skills.
Equipes ágeis: composição e tamanho¶
- Equipe cross-funcional: reúne todas as habilidades necessárias para entregar valor (desenvolvimento, teste, design, negócio), em vez de times separados por função (um de programadores, um de testes...). Todos respondem pelo resultado da entrega, e não só pela sua especialidade.
- Profissional em T: é especialista em uma área (a haste vertical) e capaz de ajudar em outras (a barra horizontal), o que dissolve gargalos. Ninguém precisa saber fazer tudo.
- Equipe de funcionalidade (feature team) x de componente (component team): a primeira entrega uma funcionalidade completa de ponta a ponta; a segunda cuida de uma parte da arquitetura (só o front-end, só o back-end), exigindo coordenação para integrar. A de funcionalidade tende a gerar mais valor por iteração.
- Tamanho pequeno: cerca de 5 a 9 pessoas (equipes funcionais tradicionais passavam de 30), para manter a comunicação simples.
- Estabilidade: equipes precisam de tempo juntas para passar pelos estágios de formação (Tuckman); mover pessoas como peças de um tabuleiro destrói a fluência (veja Fluência ágil).
- Contratação colaborativa: o time participa de entrevistas e da decisão de contratar, o que exige confiança da gestão e maturidade da equipe — e aumenta o compromisso com quem entra.
Auto-organização e gestão em ambiente complexo¶
Equipes ágeis funcionam na complexidade (poucas regras, muita autonomia — veja ordem, caos e complexidade). Auto-organização exige empoderamento, e empoderamento exige confiança e objetivos compartilhados: sem direção comum, ela leva a qualquer resultado. A gestão não desaparece — o papel de gestor está sempre presente; a questão é se está concentrado em uma pessoa ou dividido entre todos. Se não souber quem gerencia, pergunte quem cuida do desenvolvimento e da carreira das pessoas.
Gestão 1.0, 2.0 e 3.0 (Jurgen Appelo)¶
| Versão | Foco | Modelo |
|---|---|---|
| 1.0 | Hierarquia | Comando e controle; poder concentrado em poucos; ainda o mais comum na prática |
| 2.0 | Técnicas | Modismos e metodologias (Six Sigma, qualidade total, teoria das restrições) aplicadas de cima para baixo |
| 3.0 | Pessoas e sistema | Gestão baseada na teoria da complexidade: adaptabilidade em vez de previsibilidade; a organização é uma rede social adaptativa |
Seis visões da Gestão 3.0:
- Energizar pessoas: a motivação extrínseca (dinheiro, prêmios) é como um fator de "higiene" — sua falta desmotiva, mas sua presença não basta. A intrínseca (competência, aceitação, curiosidade, honra, idealismo, propósito) é a que sustenta o engajamento, e varia entre as pessoas. Relaciona-se às Teorias X e Y.
- Empoderar times: delegar é transferir responsabilidade mantendo a responsabilidade pelo resultado; empoderar é mais. Não é binário: há sete níveis de delegação — contar (você decide e anuncia), vender (decide e convence), consultar (pede opinião antes de decidir), concordar (decide em consenso, com voz igual), aconselhar (influencia, mas a decisão é do time), investigar (a equipe decide e depois informa) e delegar (total autonomia). O quadro de autoridade (authority board) mostra, para cada área de decisão (salários, contratação, ferramentas, horários), o nível e quem é responsável, tornando a autonomia transparente; o delegation poker é uma dinâmica para negociar esses níveis.
- Alinhar restrições: dar propósito claro e metas compartilhadas para que a auto-organização vá na direção certa. Metas SMART podem ser difíceis de aplicar a objetivos qualitativos; use métricas diferentes para cada parte interessada.
- Desenvolver competências: equipes só atingem metas se as pessoas forem capacitadas; a gestão apoia o aprendizado.
- Estruturar: organizar equipes e canais de comunicação (comunidades, equipes de funcionalidade) de forma que a informação flua.
- Melhorar tudo: melhoria contínua com visão sistêmica — considerar o sistema, os indivíduos, as interações e o ambiente, pois o ambiente determina como o sistema se auto-organiza.
Definição: pensamento sistêmico
Um sistema é um conjunto de partes interdependentes com um propósito comum; seu desempenho depende de como as partes interagem, não de cada uma ser a melhor isoladamente. Por isso otimizar métricas locais pode piorar o resultado do todo.
Feedback¶
Feedback rápido e frequente permite corrigir e melhorar: desenvolvedores o recebem do código (testes, integração contínua, revisão por pares), o PO dos usuários, e as pessoas das outras pessoas.
- Reuniões one-on-one: o gestor se reúne individualmente (idealmente toda semana, no mesmo horário e dia) com cada pessoa para conhecer seus desejos, frustrações e pontos fortes, e construir confiança. Perguntas úteis: como está o projeto? o que mais gosta? o que mais frustra? como posso ajudar? Dicas: ritmo regular, presença total, foco na pessoa e anotar compromissos. Tempo com as pessoas é gestão, não distração dela.
- Feedback 360°: a pessoa recebe retorno de vários pontos de vista (colegas, liderança, clientes internos), em competências escolhidas pelo time. Formatos: face a face (roda informal), envelopes (cada pessoa escreve para as outras em envelopes com o nome) ou formulários (avaliações objetivas comparadas com a média do time e a autoavaliação). Prepare o grupo, explique o objetivo (desenvolvimento, não punição), defina um tempo limite e evite transformá-lo em avaliação de cima para baixo ou em "fogo para todo lado". Mais sobre dar e receber feedback em Soft Skills.
Aprendizagem contínua¶
A tecnologia muda rápido: sem aprender, o profissional "apodrece". A responsabilidade pela carreira é da própria pessoa, mas a organização pode criar um ambiente que favoreça isso (equação de Lewin: o comportamento é função da pessoa e do ambiente — a tendência é se adaptar ao meio). Dedicar 20 minutos por dia ao estudo já faz diferença. O básico: inglês, leitura constante (livros, blogs, portais) e eventos e comunidades.
| Prática | O que é |
|---|---|
| Coding Dojo | Encontro para resolver um desafio de programação com TDD, de forma colaborativa e sem pressão. Formato Randori: um par programa, e a cada ~7 minutos o navegador assume o teclado e o piloto volta à plateia, com retrospectiva ao final. Formato Prepared Kata: alguém apresenta passo a passo uma solução preparada |
| Clube do livro | Grupo que lê o mesmo livro e discute capítulos; ótimo para uma transição ágil, por exemplo |
| Brown bag session | Apresentação informal na hora do almoço, compartilhando algo que alguém aprendeu |
| Hackathon | Um dia (ou mais) de trabalho livre para experimentar ideias; exemplos de empresas com "dias de entrega" trimestrais. Muitos projetos viram produto, e o aprendizado vale mesmo se não virarem |
| Comunidades de prática | Grupos de pessoas com um interesse ou função em comum espalhadas por várias equipes (testadores, scrum masters, designers, uma tecnologia), que compartilham práticas e padronizam métodos |
Escalando o ágil¶
Quando uma equipe não basta, várias equipes trabalham em paralelo no mesmo ciclo de releases, coordenadas por um Product Manager ou por uma comunidade de práticas de Product Owners, com um backlog de programa. Para vários programas, usa-se um portfólio, que trata dos requisitos de mais alto nível (épicos) e dos investimentos. Frameworks de escala (SAFe, LeSS, Scrum of Scrums) formalizam esses níveis.
Para o dia a dia (e para entrevistas)¶
(Complemento do projeto.)
- Como líder de equipe ágil, mostre que você cria condições (clareza de objetivo, autonomia, aprendizado) em vez de dar ordens.
- Se perguntarem sobre delegar, cite os níveis: decide o que precisa de seu controle e delegue o resto de forma explícita.
- Se perguntarem sobre motivação, fale em propósito, autonomia e domínio — não só em bônus.
- Se perguntarem como mede o desempenho do time, mencione medir equipes e resultados (valor entregue, qualidade, fluxo), não indivíduos.