Neste post, quero compartilhar um pouco da minha trajetória e alguns valores sobre trabalho em equipe e liderança que costumo aplicar no meu dia-dia.
Há diversos estudos, livros e práticas catalogadas sobre o assunto, mas eu prefiro me apoiar em valores vindo de pessoas com as quais trabalhei e sempre admirei, sendo ótimos líderes que trabalham para que a equipe se sinta confortável e produtiva no desempenhar das funções.
Não espere um artigo científico cheio de referências, mas sim um compilado empírico baseado tão somente na minha visão de mundo e trajetória.
Mas não posso deixar de destacar que o melhor livro que li sobre o assunto, é o Debugging Teams, do Ben Collins-Sussman e Brian Fitzpatrick. Inclusive há um website sobre o livro onde dá pra ler online a versão web.
Tudo começa com confiança
Minha primeira experiência profissional foi no Brasil em um órgão público do Estado de São Paulo. Lá, pude aprender sobre processos e como as pessoas "adultas" trabalham.
Eu tinha 18 anos.
Minha primeira líder foi uma pessoa que me inspirou, pois ela confiava no trabalho das pessoas. Eu comparava com outros departamentos, e na minha visão de uma pessoa ainda sem experiência de mercado (e de vida), nosso departamento era o que tinha mais sinergia.
Eu sempre tive um perfil de pessoa empenhada e focada no que faz. Isto adicionado a uma liderança que confia no trabalho, pude dar o meu melhor, evoluindo ali dentro profissionalmente e também enquanto pessoa, pois estava praticamente iniciando minha vida profissional naquele departamento.
Pensar simples é difícil
Depois de experimentar diversos projetos para adquirir experiência, me deparei com um projeto onde o líder estimulava todos a pensarem no mais simples possível.
Mas o que define simplicidade?
Ali, pude sentir que simplicidade era um desafio constante, e não um estado de arte. Se o simples fosse fácil, não haveria tantos projetos falhos, com desperdício de recursos, prazos exorbitantes e alta rotatividade.
No geral, o que aprendi sobre simplicidade era baseado em tentar responder a estas duas perguntas:
- eu realmente entendi o problema?
- a solução que estou pensando, já existe na minha atual caixa de ferramentas ou terei que buscar fora?
A resposta para isto não é simples. Mas uma vez que conseguimos uma resposta adequada para estas perguntas, estamos pelo menos a meio caminho da solução simples.
Blindagem da equipe
Uma outra experiência minha foi trabalhar em uma empresa grande com processos burocráticos e muito bem definidos.
Geralmente, em ambientes assim, há muita política envolvida e conflito de interesses. É normal, faz parte da natureza humana de interações.
Mas deixar os conflitos baterem na equipe de desenvolvimento é a receita para a desmotivação e alta rotatividade. Meus líderes faziam um ótimo papel em blindar. Eu não sabia de muita coisa; e não queria saber. Há pessoas que gostam de lidar com isso, mas julgo que a grande maioria, não.
Eu queria apenas ajudar a equipe a desenhar e desenvolver soluções para os problemas reais que as pessoas tinham ao utilizar o software.
Pra mim, um bom líder precisa saber blindar a equipe em diversos aspectos: política, prazos, escopos, orçamentos...mas isto não tem a ver com não ter transparência, que é assunto do próximo tópico.
Transparência abre caminhos para a entrega de valor
Muito se fala de entrega de valor. Mas o quê é entrega de valor?
Valor é a satisfação que se obtém através de um trabalho. Se a satisfação é alta, então o valor é alto. Num cenário em que não há entrega alguma, então não há valor sendo entregue.
Em outra experiência que tive, meu líder tinha uma postura de confiar na equipe e fomentar a transparência.
Havia apenas uma forma de visualizarmos o trabalho da equipe. Havia apenas uma forma de visualizarmos o feedback das entregas feitas.
Num processo transparente assim, não há muita margem para a falta de entrega pois o próprio processo se encarrega que as entregas sejam feitas. Com transparência, conseguimos saber o que está sendo feito (não confundir isto com micro-gerenciamento, que é danoso para a saúde das equipes!), como está sendo feito, se a entrega está sendo feita com qualidade e se a satisfação está sendo ou não garantida.
Como atingir isto?
- eleger uma única ferramenta de apoio em projetos
- centralizar em apenas um único lugar a documentação e desenhos de arquitetura
- fomentar code reviews
- falar sobre trabalho em canais públicos de comunicação, e não em canais privados
Experimentação converte em inovação
Uma notória experiência que tive em Portugal foi onde a liderança incentivava a experimentação. Isto colocava a empresa num patamar onde estava sempre inovando, quer trazendo novas ideias de produtos quer melhorando a arquitetura como um todo.
Lugares onde a experimentação não é incentivada ou é evitada, geralmente têm a tendência a ficarem defasados em termos de tecnologia e muitas vezes são massacrados pelo ecossistema acelerado de startups.
Há que se fazer um balanço entre entregar valor e experimentar. Diversas formas de atingir isto, dentre as alternativas:
- criar uma equipe de "R&D" focada nestas práticas de pesquisa
- fomentar a prática de spikes/POC's (provas de conceito) que buscam respostas rápidas para problemas que surgem
E aqui vai uma dica, na minha completa visão mais empírica possível: nunca, jamais, em hipótese alguma, uma liderança técnica deve permitir que spikes sejam contabilizados no escopo de produto. Isto a médio prazo corta qualquer ideia de inovação, pois na primeira oportunidade de cumprir um prazo apertado, produto vai desestimular a experimentação de forma indireta.
E este é mais um motivo para eu não ser a favor de "sprints de refactoring" ou algo do gênero. Uma boa liderança técnica precisa permitir que trabalho arquitetural, refactoring, spikes e coisa do tipo seja feito ao longo dos dias, durante o trabalho normal.
Precisamos ser transparentes em permitir que produto saiba da cultura de experimentação, mas também precisamos ser capazes de convencê-los que é saudável que isto não seja contabilizado no planejamento de produto.
Automação não abre margem para discussões inúteis
Todos sabemos que discussões são importantes e devem ser fomentadas, caso contrário o produto não anda pra frente. Mas também sabemos que há diversas discussões que são completamente inúteis e não ajudam a chegar a lugar algum.
Outro projeto que eu gostaria de mencionar, a equipe contava com uma linha de automação top-notch, onde não havia margem para discussões triviais, o código era revisado com base em padrões arquiteturais apenas, pois code-style e preferências de padrões eram avaliados por ferramentas automáticas.
As features eram entregues numa velocidade adequada, não havia PR's enormes com discussões que nunca terminavam nem havia guerra de preferência de código.
Em um ambiente com muitas pessoas, é natural que cada uma tenha opinião diferente. Mas precisamos estabelecer um processo onde problemas triviais são resolvidos de forma automática, deixando para as pessoas a tarefa de discutirem problemas que são realmente difíceis.
Coisas como discutir indentação de código, preferência de cor, usar um padrão A vs padrão B etc etc são coisas triviais que podem ser resolvidas de forma automatizada, não deixando margem para que as pessoas fiquem dias discutindo algo que um linter teria resolvido.
Algumas práticas para ajudar na automação:
- investir em linters durante a integração contínua (CI)
- estabelecer um styleguide. Há quem goste e quem não goste, mas um projeto precisa ter um ponto de partida. Deixar tudo aberto faz o projeto travar
- deploy automático, testes automatizados, rollback acessível
Estas práticas ajudam a mitigar o problema de discussões triviais.
Formação de talentos
Um valor que sempre admirei foi nos líderes que incentivavam a formação de talentos de forma genuína.
Recentemente passei a atuar num projeto onde a formação é a premissa base. Lá não pode haver margem para julgar uma pessoa por uma falta de conhecimento, nem colocá-la em público quando erros são cometidos.
Um lugar onde não há essa preocupação, tende a virar um ambiente cheio de pessoas "ninjas" que acham que podem resolver todos os problemas da "melhor forma". O problema é que lugares assim, ao longo do tempo, ficam defasados pois não há a cultura de formação de talentos, pelo que os ninja developers buscam seus próprios caminhos ao longo do tempo.
Ambiente assim é ruim para o projeto, e não para os ditos ninjas.
Sendo assim, um ambiente que pratica a cultura de não culpar as pessoas, não julgá-las e, acima de tudo, ajudá-las a evoluir, tem menos propensão a ficar defasado.
Bons líderes formam outros líderes.
Resumo
Após descrever um pouco de minha trajetória e em como avaliei diferentes tipos de liderança, coloco aqui um resumo do que acredito traduzir em uma boa liderança:
- Confiança: sem margem para micro-gerenciamento
- Simplicidade: buscar soluções dentro antes de ir pra fora
- Experimentação: fomentar prática de experimentar sem adicionar ou afetar escopo do projeto
- Automação: delegar para as ferramentas a tarefa de avaliar problemas triviais e de preferências de código
- Formação: não culpar, não julgar, e ensinar. Bons líderes criam outros líderes.
Conclusão
Este artigo foi uma tentativa de compilar os valores que acredito serem importantes para uma boa liderança.
Apesar de saber que nunca sabemos todo o necessário, o que faz líderes serem "bons" pode ser relativo dependendo da experiência de cada um.
Aqui, foi apenas uma tentativa empírica baseada apenas na minha experiência.
Top comments (8)
ótimo post como sempre Leandro, fiquei curioso em saber como vcs organizam um trabalho de refactoring sem incluir esse trabalho em algum escopo, onde ficam as informações sobre o que esta sendo feito?
Valeu Marcell! Eu costumo colocar junto às tarefas o que foi feito. Por exemplo, utilizando Trello, coloco tudo num card do Trello. Se o card é referente à "Implementar 2FA no Login", e eu vejo que é importante refatorar alguns componentes internos de Login, eu planejo o refactoring apenas daquela área, faço estimativa e sinalizo pra equipe de produto a importância daquele refactoring que SERÁ feito. Então quando puxar o card, vai ter o trabalho tbm associado no Pull Request (ou commit pra quem faz TBD) que terá link no card.
Ou seja, o card é sobre implementar 2FA, mas leva junto um refactoring necessário naquela área (sinalizado no card).
Particularmente, não acredito muito que refactorings estruturais em várias partes são eficientes. Prefiro o "refactoring oportunista", que toca apenas na parte necessária para implementar a feature ou fix. Muito daquela ideia de "deixe o quarto mais limpo do que encontrou, mas não precisa limpar todo o quarto de uma vez".
excelente post, os 5 pontos ali são coisas que sempre admirei enqto liderado e sempre procurei trazer comigo enqto líder também.
Só pra reforçar o item de experimentação, já tive a experiência de colocar no escopo do produto e não foi muito agradável, na primeira oportunidade ela é retirada não dando margem para argumentação, hoje prefiro me reunir com os envolvidos e fazer aos poucos, mas sempre fazer algo.
Excelente!
Como alguém que teve uma trajetória similar, me identifiquei bastante, e assino embaixo.
Muito bom, assino embaixo pois vivi junto um pouco disso com você! hahaha
Muito bom Leandro. Geralmente prefiro ver relatos de experiência do que apenas teorias abstratas. Tem um valor diferenciado. Gostei também da referência do Debugging Teams, vou dar uma olhada!
Valeu Thiago!