Your Web News in One Place

Help Webnuz

Referal links:

Sign up for GreenGeeks web hosting
September 17, 2022 08:10 pm GMT

Liderana comea com confiana: minha trajetria

Neste post, quero compartilhar um pouco da minha trajetria e alguns valores sobre trabalho em equipe e liderana que costumo aplicar no meu dia-dia.

H diversos estudos, livros e prticas catalogadas sobre o assunto, mas eu prefiro me apoiar em valores vindo de pessoas com as quais trabalhei e sempre admirei, sendo timos lderes que trabalham para que a equipe se sinta confortvel e produtiva no desempenhar das funes.

No espere um artigo cientfico cheio de referncias, mas sim um compilado emprico baseado to somente na minha viso de mundo e trajetria.

Mas no 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 verso web.

Tudo comea com confiana

Minha primeira experincia profissional foi no Brasil em um rgo pblico do Estado de So Paulo. L, pude aprender sobre processos e como as pessoas "adultas" trabalham.

Eu tinha 18 anos.

Minha primeira lder foi uma pessoa que me inspirou, pois ela confiava no trabalho das pessoas. Eu comparava com outros departamentos, e na minha viso de uma pessoa ainda sem experincia 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 liderana que confia no trabalho, pude dar o meu melhor, evoluindo ali dentro profissionalmente e tambm enquanto pessoa, pois estava praticamente iniciando minha vida profissional naquele departamento.

Pensar simples difcil

Depois de experimentar diversos projetos para adquirir experincia, me deparei com um projeto onde o lder estimulava todos a pensarem no mais simples possvel.

Mas o que define simplicidade?

Ali, pude sentir que simplicidade era um desafio constante, e no um estado de arte. Se o simples fosse fcil, no haveria tantos projetos falhos, com desperdcio 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 soluo que estou pensando, j existe na minha atual caixa de ferramentas ou terei que buscar fora?

A resposta para isto no simples. Mas uma vez que conseguimos uma resposta adequada para estas perguntas, estamos pelo menos a meio caminho da soluo simples.

Blindagem da equipe

Uma outra experincia minha foi trabalhar em uma empresa grande com processos burocrticos e muito bem definidos.

Geralmente, em ambientes assim, h muita poltica envolvida e conflito de interesses. normal, faz parte da natureza humana de interaes.

Mas deixar os conflitos baterem na equipe de desenvolvimento a receita para a desmotivao e alta rotatividade. Meus lderes faziam um timo papel em blindar. Eu no sabia de muita coisa; e no queria saber. H pessoas que gostam de lidar com isso, mas julgo que a grande maioria, no.

Eu queria apenas ajudar a equipe a desenhar e desenvolver solues para os problemas reais que as pessoas tinham ao utilizar o software.

Pra mim, um bom lder precisa saber blindar a equipe em diversos aspectos: poltica, prazos, escopos, oramentos...mas isto no tem a ver com no ter transparncia, que assunto do prximo tpico.

Transparncia abre caminhos para a entrega de valor

Muito se fala de entrega de valor. Mas o qu entrega de valor?

Valor a satisfao que se obtm atravs de um trabalho. Se a satisfao alta, ento o valor alto. Num cenrio em que no h entrega alguma, ento no h valor sendo entregue.

Em outra experincia que tive, meu lder tinha uma postura de confiar na equipe e fomentar a transparncia.

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, no h muita margem para a falta de entrega pois o prprio processo se encarrega que as entregas sejam feitas. Com transparncia, conseguimos saber o que est sendo feito (no confundir isto com micro-gerenciamento, que danoso para a sade das equipes!), como est sendo feito, se a entrega est sendo feita com qualidade e se a satisfao est sendo ou no garantida.

Como atingir isto?

  • eleger uma nica ferramenta de apoio em projetos
  • centralizar em apenas um nico lugar a documentao e desenhos de arquitetura
  • fomentar code reviews
  • falar sobre trabalho em canais pblicos de comunicao, e no em canais privados

Experimentao converte em inovao

Uma notria experincia que tive em Portugal foi onde a liderana incentivava a experimentao. 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 experimentao no incentivada ou evitada, geralmente tm a tendncia a ficarem defasados em termos de tecnologia e muitas vezes so massacrados pelo ecossistema acelerado de startups.

H que se fazer um balano entre entregar valor e experimentar. Diversas formas de atingir isto, dentre as alternativas:

  • criar uma equipe de "R&D" focada nestas prticas de pesquisa
  • fomentar a prtica de spikes/POC's (provas de conceito) que buscam respostas rpidas para problemas que surgem

E aqui vai uma dica, na minha completa viso mais emprica possvel: nunca, jamais, em hiptese alguma, uma liderana tcnica deve permitir que spikes sejam contabilizados no escopo de produto. Isto a mdio prazo corta qualquer ideia de inovao, pois na primeira oportunidade de cumprir um prazo apertado, produto vai desestimular a experimentao de forma indireta.

E este mais um motivo para eu no ser a favor se "sprints de refactoring" ou algo do gnero. Uma boa liderana tcnica 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 experimentao, mas tambm precisamos ser capazes de convenc-los que saudvel que isto no seja contabilizado no planejamento de produto.

Automao no abre margem para discusses inteis

Todos sabemos que discusses so importantes e devem ser fomentadas, caso contrrio o produto no anda pra frente. Mas tambm sabemos que h diversas discusses que so completamente inteis e no ajudam a chegar a lugar algum.

Outro projeto que eu gostaria de mencionar, a equipe contava com uma linha de automao top-notch, onde no havia margem para discusses triviais, o cdigo era revisado com base em padres arquiteturais apenas, pois code-style e preferncias de padres eram avaliados por ferramentas automticas.

As features eram entregues numa velocidade adequada, no havia PR's enormes com discusses que nunca terminavam nem havia guerra de preferncia de cdigo.

Em um ambiente com muitas pessoas, natural que cada uma tenha opinio diferente. Mas precisamos estabelecer um processo onde problemas triviais so resolvidos de forma automtica, deixando para as pessoas a tarefa de discutirem problemas que so realmente difceis.

Coisas como discutir indentao de cdigo, preferncia de cor, usar um padro A vs padro B etc etc so coisas triviais que podem ser resolvidas de forma automatizada, no deixando margem para que as pessoas fiquem dias discutindo algo que um linter teria resolvido.

Algumas prticas para ajudar na automao:

  • investir em linters durante a integrao contnua (CI)
  • estabelecer um styleguide. H quem goste e quem no goste, mas um projeto precisa ter um ponto de partida. Deixar tudo aberto faz o projeto travar
  • deploy automtico, testes automatizados, rollback acessvel

Estas prticas ajudam a mitigar o problema de discusses triviais.

Formao de talentos

Um valor que sempre admirei foi nos lderes que incentivavam a formao de talentos de forma genuna.

Recentemente passei a atuar num projeto onde a formao a premissa base. L no pode haver margem para julgar uma pessoa por uma falta de conhecimento, nem coloc-la em pblico quando erros so cometidos.

Um lugar onde no h essa preocupao, 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 no h a cultura de formao de talentos, pelo que os ninja developers buscam seus prprios caminhos ao longo do tempo.

Ambiente assim ruim para o projeto, e no para os ditos ninjas.

Sendo assim, um ambiente que pratica a cultura de no culpar as pessoas, no julg-las e, acima de tudo, ajud-las a evoluir, tem menos propenso a ficar defasado.

Bons lderes formam outros lderes.

Resumo

Aps descrever um pouco de minha trajetria e em como avaliei diferentes tipos de liderana, coloco aqui um resumo do que acredito traduzir em uma boa liderana:

  1. Confiana: sem margem para micro-gerenciamento
  2. Simplicidade: buscar solues dentro antes de ir pra fora
  3. Experimentao: fomentar prtica de experimentar sem adicionar ou afetar escopo do projeto
  4. Automao: delegar para as ferramentas a tarefa de avaliar problemas triviais e de preferncias de cdigo
  5. Formao: no culpar, no julgar, e ensinar. Bons lderes criam outros lderes.

Concluso

Este artigo foi uma tentativa de compilar os valores que acredito serem importantes para uma boa liderana.

Apesar de saber que nunca sabemos todo o necessrio, o que faz lderes serem "bons" pode ser relativo dependendo da experincia de cada um.

Aqui, foi apenas uma tentativa emprica baseada apenas na minha experincia.


Original Link: https://dev.to/leandronsp/lideranca-comeca-com-confianca-minha-trajetoria-4i68

Share this article:    Share on Facebook
View Full Article

Dev To

An online community for sharing and discovering great ideas, having debates, and making friends

More About this Source Visit Dev To