- Equipes de engenharia frequentemente sofrem pressão para “lançar mais funcionalidades, mais rápido”
- Mas tocar trabalho demais ao mesmo tempo acaba reduzindo a produtividade
- “O segredo para lançar mais é, na verdade, fazer menos” -
Less is More
Princípios centrais
- Tornar todo o trabalho visível
- Definir o trabalho em unidades pequenas
- Limitar o trabalho em andamento
- Alocar recursos de acordo com a capacidade
- Bônus: reservar folga para o inesperado
# Tornar todo o trabalho visível
- Tornar o trabalho visível obriga o time a encarar a realidade
- Quando todo o trabalho fica visível de uma vez, há vantagens como:
- definir prioridades com clareza
- interromper ou pausar trabalhos desnecessários
- ajudar a equipe a se concentrar em concluir o que já começou
- O objetivo não é rastrear tudo para sempre → e sim entender claramente a realidade e tomar decisões melhores
# Definir o trabalho em unidades pequenas
- Quando o trabalho é grande demais, a energia do time se esgota e o progresso deixa de ficar claro
- Limitar as unidades de trabalho a cerca de 1 a 2 semanas
- desenvolvedores mantêm a motivação com resultados de curto prazo
- é possível receber feedback rapidamente e corrigir o rumo
- Vantagens de unidades menores de trabalho
- code review fica mais fácil
- compartilhamento de conhecimento acontece de forma natural
- a colaboração entre os membros do time se fortalece
- o risco de deploy diminui
- Reduzir o tamanho das unidades acelera a velocidade → permite manter o ritmo sem ser engolido por funcionalidades complexas
# Limitar o trabalho em andamento
- Lidar com várias funcionalidades ao mesmo tempo acaba diminuindo a produtividade
- Surge o custo de troca de contexto → adaptar-se a uma nova tarefa pode levar até 23 minutos
- Quanto mais trabalho em andamento existe, mais problemas aparecem, como:
- queda na qualidade
- aumento de bugs
- queda no moral da equipe
- Sinais de sobrecarga no nível do time
- mais de 4 tarefas por desenvolvedor
- o tempo de conclusão fica maior do que o previsto
- há mais funcionalidades em andamento do que concluídas
- Sinais de sobrecarga no nível individual
- perda de foco
- aumento no tempo de resposta em code review
- dificuldade para explicar prioridades em reuniões de status
# Alocar recursos de acordo com a capacidade
- A abordagem “um desenvolvedor, uma funcionalidade” é ineficiente
- Concentrar os recursos do time no trabalho mais importante
- mais colaboração → resolução de problemas mais rápida
- melhor qualidade de código → peer review em tempo real
- conclusão mais rápida do trabalho
- Desenvolvedores conseguem alcançar um entendimento mais profundo por meio da colaboração
- É preciso incentivar resultados no nível do time → foco no desempenho da equipe, não no desempenho individual
# Reservar folga
- Operar com 100% da capacidade acaba piorando os resultados
- Trabalho inesperado é inevitável → a única incerteza é quando ele vai surgir
- Problemas que aparecem quando não há folga
- o time passa a trabalhar de forma reativa
- queda na qualidade
- menos inovação
- aumento da dívida técnica
- Quando existe folga, há vantagens como:
- responder com flexibilidade a problemas inesperados
- resolver problemas de forma criativa
- manter alta qualidade
- sustentar um ritmo de trabalho saudável
- A folga ideal é de cerca de 20% → pode ser ajustada conforme as características do time
Resumo da estratégia central
- Tornar o trabalho visível → para enxergar a realidade com clareza
- Definir o trabalho em unidades pequenas → para manter o ritmo
- Limitar o trabalho em andamento → para aumentar o foco
- Alocar recursos de acordo com a capacidade → para concentrar energia nas prioridades
- Reservar folga → para garantir flexibilidade
Conclusão
- Para fazer mais, é necessário adotar a estratégia de fazer menos
- O desempenho do time não deve ser medido por quantas funcionalidades ele tocou ao mesmo tempo, mas por quão efetivamente entregou valor ao cliente
- O papel da liderança não é adicionar mais trabalho ao time, e sim remover o trabalho desnecessário
12 comentários
No livro <Phoenix Project>, que já foi mencionado várias vezes no GeekNews, aparece uma ideia parecida. Quanto mais perto de 100% da capacidade, mais o tempo de resposta aumenta de forma exponencial.
Oh. Isso também aparece no livro The Goal!
<Projeto Phoenix>em si foi escrito como uma versão de TI de<The Goal>Nossa........ obrigado!!
Tentamos trabalhar com 80% de carga e deixar 20% de folga, mas sempre fico pensando em qual critério usar para isso... Às vezes acho que talvez devesse ser simplesmente pelo tempo.
Por isso, eu reservo totalmente as tardes de sexta-feira para tempo de desenvolvimento pessoal!
Quando isso é dividido em tarefas tão pequenas, o líder que tem a visão do todo acaba ficando com um grande poder. Os engenheiros que estão junto, por outro lado, acabam desmotivados e pensando: "afinal, para onde estamos indo?" Um dos principais pontos fracos do ágil baseado em sprint.
Parece que foi escrito demais apenas da perspectiva do líder, exatamente como diz o título.
O momentum dos engenheiros também é muito influenciado pela direção para a qual o líder está apontando a bandeira. Também parece necessário pensar um pouco mais sobre como apresentar qual é o valor que se quer entregar ao cliente e quais são o output e o outcome de entrega de cada sprint. Claro, são soft skills difíceis, então é raro ver líderes que façam isso bem, e também não há muitos textos bons sobre isso.
Concordo fortemente com este comentário. Havia (ou há) o risco de ocorrer microgerenciamento das partes técnicas. Realmente não é nada fácil.
Não seria compartilhar a visão geral e, com todo mundo entendendo, dividir o trabalho em pequenas tarefas??
Se dividir em períodos de 1 a 2 semanas, parece natural que apenas um número limitado de pessoas acabe conhecendo a visão de uma funcionalidade. Como a diferença entre processo e thread. A ideia é aumentar a produtividade limitando o foco.
Mesmo que a visão seja compartilhada, isso parte do pressuposto de que haverá questionamentos sobre essa visão; mas acho que também assumi naturalmente que, por causa da direção que vai mudando um pouco a cada sprint planning, não se consegue acompanhar como a visão geral está sendo seguida.
Concordo totalmente com o que este texto propõe, e também concordo com o problema que você mencionou,
na verdade esse também é um ponto sobre o qual venho refletindo.
Variava de squad para squad, mas quando os membros do time participavam ativamente do sprint planning, o problema que você mencionou não costumava acontecer. Compartilhávamos o contexto do projeto e, a cada sprint, também as mudanças de cenário, para que todos pudessem entender bem as tarefas que iam mudando; ao mesmo tempo, eu pedia que o trabalho fosse dividido de forma bem detalhada.
Como você disse, do ponto de vista da gestão, considerando acompanhamento do progresso, medição da velocidade de trabalho, resposta a situações inesperadas e o custo de oportunidade quando o trabalho não sai como planejado, no fim das contas realmente funciona melhor quando as tarefas são quebradas em partes menores.
Textos parecidos vivem se repetindo, mas a ganância humana não tem fim e os mesmos erros continuam sendo repetidos
Carga de CPU de 100% em um computador não é normal, mas
quando a carga de trabalho humana chega a 100%, a conclusão é que é preciso se esforçar ainda mais...