Como fizemos para melhorar o sentimento de produtividade do time de Engenharia
4 práticas que implementamos e nossas lições aprendidas
Sentimento de Produtividade
Aqui no Nubank queremos escalar de forma ágil e sustentável. Queremos ir cada vez mais longe e mais rápido. Entre uma conversa e outra sobre planejamento surgiu a pergunta:
"Como a gente faz para ser mais produtivo no squad?"
E começou a ir para coisas do tipo "vamos mensurar a produtividade da Engenharia". Poderia escrever um artigo inteiro sobre produtividade e ainda não seria suficiente. Como sugestão recomendo o artigo do Blog da Engenharia da SoundCloud:
Nesse artigo, porém, gostaria de focar no sentimento de produtividade, ou sentimento de "make things done".
- Ou seja: sentirmos que as tarefas estão progredindo, que os projetos estão evoluindo, que estamos aprendendo, que estamos atingindo nossos objetivos
- Isso é ao contrário de: sentirmos que estamos presos, que não conseguimos evoluir, que não estamos aprendendo nada ou não estamos entregando valor para ninguém
Productivity is not about doing more in less time. It’s about achieving what you want or need.
Algumas práticas que implementamos
- Three Day no Meeting Rule
- Zeladoria
- Polish Weeks
- Free dev time
1) Three Day No Meeting Rule
O próprio nome já diz: 3 dias sem reuniões. O Vitor Olivier compartilhou esse artigo do time de Engenharia do Pinterest e eu fiquei encantada com a simplicidade dele. "Temos muitas reuniões" era algo que aparecia com frequência em nossas Retrospectivas.
Maker x Manager's Schedule
Além de reuniões que às vezes não são importantes, o simples fato de ter uma reunião quebra o flow de uma pessoa Engenheira ou de uma Designer por exemplo, que operam no modo "maker".
When you’re operating on the manager’s schedule you can do something you’d never want to do on the maker’s: you can have speculative meetings. You can meet someone just to get to know one another. If you have an empty slot in your schedule, why not?
Speculative meetings are terribly costly if you’re on the maker’s schedule, though. Which puts us in something of a bind. Paul Graham
Fizemos uma votação para decidir quais seriam os 3 dias sem reuniões e cada pessoa da Engenharia adicionou um evento recorrente no calendário escrito "No Meetings":
Mas isso não é mágica!
As reuniões não vão simplesmente desaparecer e por isso é preciso explicar para as pessoas não-engenheiras o porque dessa iniciativa e convidar todo mundo a refletir sobre a importância das reuniões e para que as próprias engenheiras julguem quando vale abrir uma exceção à regra.
2) Zeladoria
Zeladoria é como carinhosamente chamamos a pessoa que fica cuidando de problemas críticos que afetam nossa operação (atendimento ao cliente) e obviamente aos nossos clientes. Muitos times que conheço já possuem esse tipo de esquema onde cada pessoa Engenheira fica nesse papel de Zeladora por um tempo e sem tocar tarefas do backlog.
O que fizemos que recomendo muito é testar vários formatos. De tempos em tempos fazemos uma retrospectiva do modelo atual da Zeladoria e criamos um novo modelo para testar. Abaixo todos os formatos que testamos até hoje:
- Uma pessoa durante uma semana inteira cuidando de deadletters, mismatches, problemas críticos da operação, tretas. Aqui a principal crítica foi a quantidade de coisas e sua dificuldade para apenas uma pessoa.
- Todas as pessoas engenheiras participando da Zeladoria na mesma semana em um formato de escala: problema 1 vai para Maitê, problema 2 vai para André e assim por diante. O maior problema desse modelo foi o foco que era interrompido frequentemente.
- Uma pessoa fica na Zeladoria durante 3 semanas, sendo que durante 2 semanas fica em pair com outra pessoa. Foi a primeira vez que testamos fazer a escala de forma voluntária. Estabelecemos que os bugs encontrados durante a Zeladoria ganhavam prioridade no nosso backlog para conseguir diminuir o número de problemas que apareciam toda semana. Um dos problemas desse modelo foi que nem todas as pessoas quiseram participar e logo, a mesma pessoa tinha que ser Zeladora novamente.
- Uma pessoa durante 2 semanas e todas as pessoas da Engenharia participando da Zeladoria. Ela tem responsabilidade de documentar problemas recorrentes, resolver mismatches mais simples (os mais difíceis vão para o backlog do time) e cuidar de problemas específicos da operação. Esse é nosso modelo atual.
Hoje temos um modelo que acredito que atende nossas necessidades pois permite o time ter mais foco e reduz o re-trabalho, uma vez que os problemas recorrentes entram com alta prioridade no backlog. Mas esse modelo pode não ser o melhor pra você. A dica aqui é testar, refletir, iterar :)
3 ) Polish weeks
Uma maneira que encontramos de dar um foco e atenção maior aos débitos técnicos foi realizar uma Polish Week: uma semana dedicada a eliminar débitos técnicos.
Inspirada nesse artigo aqui pedi para o time revisar todos os débitos técnicos abertos no nosso repositório e adicionar novos. Ficamos com uma grande lista para priorizarmos:
- Priorizamos os débitos na matriz de Dor x Dificuldade: aqueles de maior dor e facilidade de atacar seriam os primeiros do backlog
Removing the technical debt located here is very valuable to our development process in addition to it also requiring only little effort to do so. Not only we can go for the low hanging fruit first but we also identified the most valuable ones. A classical win-win situation.
Porém, havia alguns que não eram fáceis mas eram urgentes! Se a gente não fizesse algo a respeito teríamos problemas em breve. Então, fizemos outra priorização:
2. Priorizamos os débitos numa linha de Urgente x Não-urgente
Algumas lições aprendidas:
- Ao invés de se comprometer com o tempo, se comprometa com os problemas que são importantes e que você quer resolver. Uma semana para gente não foi suficiente, levamos praticamente 3 semanas pra atuar nos débitos priorizados
- Alinhe bem com seu time todo e se for o caso, inclua no planejamento do trimestre. Existem muitas coisas que dependem da Engenharia e no nosso caso, alinhar com todas as pessoas (Business Analysts, Operação, Business Architects…) foi bem importante para não barrar o trabalho de ninguém e não criar falsas expectativas
- O débito técnico é de todo mundo, não é só da Engenharia. Não é obrigação de uma pessoa que não é da engenharia saber o que é um débito técnico, mas acredito que é meu papel e da Engenharia trazer porque deveríamos nos preocupar e atuar nisso.
The biggest cost of technical debt is the fact that it slows your ability to deliver future features, thus handing you an opportunity cost for lost revenue.
4) Free time (failed)
Trabalhar em projetos fora do Roadmap é algo que gostaríamos de fazer como time. A gente sempre tinha ideias interessantes: ferramentas internas pra facilitar a investigação de problemas, criar novos serviços, usar uma tecnologia nova. Um monte de coisa que quando priorizávamos em conjunto, não tinha uma importância muito grande.
Foi lendo esse artigo da Monzo que pensamos em ter um tempo para as pessoas da Engenharia atuarem em qualquer projeto que quisessem fora do que já estava no Backlog.
Para ter transparência e ser mais colaborativo criamos um board com as ideias. Para incentivar a Engenharia a trabalhar nessas ideias cada um colocou na sua agenda um tempo na semana dedicado pra isso.
Porém o tempo foi passando e as ideias não saíam do papel e minha principal lição foi incentivar autonomia para as pessoas gerenciarem seu próprio tempo entre tarefas do backlog e projetos paralelos ao invés de dar tempo e um board. Quando a gente parou de falar no board e desistiu dos tempos definidos alguns projetos começaram a sair :)
