O melhor time do ponto de vista de um desenvolvedor

Disclaimer

Se você é um desenvolvedor como eu, poderíamos dizer que diariamente, vamos para nossos trabalhos, conversamos com nossos colegas e amigos, analisamos e desenvolvemos atividades e produtos, resolvemos bugs, rimos de piadas com tecnologias e frameworks, porém nem sempre nos sentimos em um ambiente de qualidade, ou trabalhando com tecnologias e desafios interessantes que nos motivem a produzir sempre as melhores soluções.

Em frente à este cenário nem sempre fica exatamente claro quais são as características que melhorariam a qualidade de vida que temos em nosso trabalho, ou quais seriam os desafios que nos motivariam a construir um produto incrível.

Já se você é um CSO (Chief Something Officer) construindo uma startup ou um líder de uma equipe de desenvolvimento consolidada pode ter se pego pensando em como formar uma equipe de alta performance, ou manter os membros da equipe motivados para entregar as melhores soluções.

Bom, para ambos os casos este post propoe algumas ideias e metodologias que tornam desenvolvedores mais engajados e motivados a produzir soluções incríveis enquanto evoluem como profissionais e como pessoas.

Estas ideias se baseiam em alguns anos pensando sobre isso, discutindo com outros desenvolvedores pouco ou muito motivados, conversando com techleads, com a comunidade de desenvolvimento e com diretores e donos de empresas.

Para garantir que todos os aspectos de uma equipe sejam abordados, vou falar sobre a visão técnica e também a visão de gestão de pessoas.

Visão Tecnica

Se o departamento de tecnologia possui várias equipes, é necessário que cada uma dessas equipes respeitem as tecnologias escolhidas e tenham ciência dos porquês de tais tecnologias terem sido escolhidas. Por várias vezes, notei que quando essa interação de respeito não ocorre, as equipes passam a se sentirem melhores que as outras, requerendo mais recursos, ou até mesmo não vendo a importância do que é produzido pelas outras. Uma solução interessante, é apresentar os processos que cada equipe segue, qual é o roadmap, a importância do que está sendo desenvolvido e por que isso é tão relevante para a empresa.
A equipe de desenvolvimento e os desenvolvedores precisam ter autonomia para fazer as escolhas das tecnologias que serão utilizadas dentro dos projetos, essa falta de autonomia acarreta também a desmotivação, ou mesmo a falta de desempenho no processo de desenvolvimento.

É preciso também ter transparência sobre o porquê tais tecnologias estão sendo escolhidas, deixando claro para todos os desenvolvedores quais são os pontos fortes e fracos.

Uma apresentação de defesa sobre as tecnologias para o time de desenvolvimento é uma boa dinâmica para esclarecer duvidas, e facilitar a compreensão de qual tecnologia será escolhida.

Isso também garante que as tecnologias serão utilizadas a longo prazo, pois escolhas deliberadas, sem o conhecimento de todo o desenvolvimento, geralmente causam a centralização do conhecimento e um consequente abandono da tecnologia quando determinado desenvolvedor sai da empresa.
Pair programming entre os membros do time os nivela melhor e descentraliza o conhecimento, code reviews sem preciosismo e egocetrismo, seguindo uma coding style definido por todos os membros também facilita o entendimento de todos os devs, ele também é importante para integrar os membros, permitir que ocorra também um desenvolvimento emocional dos desenvolvedores dentro da equipe. Nas minhas experiências fazendo isso, foi muito importante para que eu aprendesse a dizer que não sabia de algo, e reforçar a confiança entre os membros da equipe.
Promova Dojos e hackathons para solucionar problemas enfrentados por toda a equipe, pense junto com a equipe o que seria interessante de ser implementado e que anima todos. Essa é uma iniciativa que motiva muito os desenvolvedores, todos gostamos de criar coisas novas, ou solucionar problemas existentes. A recompensa de criar algo novo, e estar integrado junto dos seus colegas de trabalho, com certeza é muito importante para a evolução do time
Participe ou permita que sua equipe participe de eventos de tecnologia, e incentive-os a ir buscando mais do que apenas novas tecnologias mas também conhecer pessoas. Atualmente trabalho em uma empresa que conheci por conta de pessoas em eventos da comunidade, isso permitiu que eu conhecesse a empresa e também os profissionais que trabalhavam nela.

Visao de Pessoas

Se você é um líder contratando um novo membro para equipe ou mesmo montando uma, busque avaliar o perfil do candidato, é essencial que ele se encaixe com o time que você tem não apenas pelo conhecimento tecnológico, mas também pelo perfil comportamental.

Para garantir que o melhor candidato seja contratado, estabeleça no processo de contratação, que o candidato passe um período de tempo junto aos membros do time, essa interação é o melhor jeito de identificar se o candidato tem o fit para a posição, na empresa que trabalho hoje, passei cerca de uma hora com a equipe que trabalharia, esse tempo foi crucial para que eu compreendesse o perfil da equipe, e também serviu para que o o contratante avaliasse se eu tinha o fit desejado.

O profissional de RH da empresa provavelmente tem conhecimentos em analise comportamental e conhecimento sobre fit cultural, com certeza ele poderá auxiliar neste processo. (enquanto escrevo este paragrafo, estou pensando que talvez um artigo com ideias de um bom processo de contratação de devs faça sentido)

E por fim você como contratante pode falar: “O mercado está escasso de devs experientes, não tenho o luxo de me prender à fit cultural e perfil, além do mais, podemos adequar este dev a nossa cultura e perfil de trabalho”. Lembre-se que nem todo o profissional estará disposto a mudar, e que se houver esta indisposição, no longo prazo isso pode gerar atrito na equipe, e desmotivar os membros.
Os desenvolvedores precisam entender qual é o propósito do produto que está sendo desenvolvido, por que ele foi concebido, quais são as particularidades do mercado em questão e qual é o problema que o produto se propoe a resolver. Alguns desenvolvedores podem acabar vendo este ponto como algo ruim, “sou desenvolvedor, preciso garantir a qualidade técnica, não me importar com o produto”, mas sabemos que as coisas não funcionam assim. Tendo em mente essa consciência sobre o ponto de vista comercial, aumenta o ownership sobre o produto e também permite comercial e desenvolvimento conversarem em melhor sintonia sobre novas features, e priorizações.

Os resultados de uma equipe que não compreende as nuances comerciais podem causar retrabalho, entregando features que deveriam fazer X e não Y, causa frustração para os devs pois não sabem exatamente a necessidade de focar em uma entrega de valor especifica e aumentando a desmotivação em um momento de pressão.

Uma estratégia para melhorar essa compreensão, é promover a comunicação entre comercial e desenvolvimento, levando desenvolvedores para explicar a importância técnica do que é desenvolvido para o CEO e toda a parte comercial (vendas, marketing, pre-vendas, diretores) , e também levando esse conhecimento de mercado para os desenvolvedores, mostrando como as vendas podem evoluir naquele momento especifico com aquela entrega tão importante, etc…
É preciso ter um tech lead que insipire as pessoas. Tech leads costumam ser conhecidos como sêniors muito experientes, esse é um ponto importante para garantir que os membros do time se sintam inspirados a aprender e superar os desafios do dia a dia, por isso, este tech lead precisa ter boas softskills, saber guiar o time, entender as particularidades da equipe e saber aproveitar os pontos fortes de cada membro.
Tenha 1:1 periodicamente, uma 1:1 consiste basicamente em uma rodada de update e feedback entre um tech lead/gestor e um membro do time, a ideia é que em poucos minutos (15 em geral) seja possível tratar das frustrações e êxitos que o desenvolvedor passou naquele período avaliado, isso é muito importante pois dá voz ao desenvolvedor para que ele possa reclamar, parabenizar e/ou sugerir mudanças que tornem o dia-a-dia, processo, metodologia ou qualquer outra coisa associada ao ambiente de trabalho, melhor. Isso claro é uma via de mão dupla e serve também para o techlead que está guiando a 1:1 possa dar insights produtivos e construtivos sobre o desenvolvimento do dev. 5 dicas sobre como fazer one-on-one
Estabelecer sprint reviews e plannings é muito importante, somos seres humanos e como tais costumamos postergar atividades que não tenham prazos muito definidos, para uma equipe que não esta completamente alinhada entre cultura, metodologia e velocidade de desenvolvimento, essa é uma estratégia muito boa de se usar, não necessariamente pensando em sprints ou se prendendo a metodologias, mas em estimativas visando uma data de entrega.

Levar em consideração as capacidades da equipe é um ponto importante também, você não deve pressionar exageradamente todos os membros, mas criar um ambiente onde tenha certa pressão pode estimular a evolução dos membros e consequentemente do produto.
Promover pequenas recompensas e reconhecimentos é uma estratégia para manter o seu time focado e motivado, não é necessário ocorrer uma periodicidade, mas sempre que existir um sucesso seja em uma sprint concluída ou uma release lançada, recompense a equipe pelo esforço bem sucedido. Isso mostra que a equipe teve êxito naquela atividade, e também libera endorfinas que associarão o bom trabalho feito à recompensa.
Quando um processo falha, ou um bug vai pra produção é importante que não ocorram acusações do desenvolvedor que causou o problema em público, e sim que a equipe se comprometa em entender o problema, corrigí-lo e avaliar o processo que levou ao acontecimento deste. após, em uma avaliação individual e em particular, pode-se fazer o levantamento dos pontos que levaram aquela falha a acontecer.

É necessário também sempre estabelecer a importância de garantir a entrega de valor para o cliente, e não apenas concluir a feature.

Agradecimentos

Bom, estes são os pontos que acabei levantando, se você discorda de algum, ou concorda e apoia muito, não deixa de comentar sobre, no meu twitter (ainda não inseri uma sessão de comentários aqui, esse é o MVP do blog) ou me enviar um email, se você encontrou um erro no texto e gostaria de corrigir abre uma PR no repo do site com certeza eu vou olhar e aceitar :).

Quero agradecer à comunidade do FloripaJS que ajudou muito, levantando, discutindo e comentando sobre os pontos desse artigo no último meetup.

Valeu pessoal!