Menu

Criando uma cultura de desenvolvimento

No seguimento do ultimo post do Rui Alves, vamos agora falar de outro tipo de cultura numa empresa - cultura de equipas de desenvolvimento. No passado dia 10 de Dezembro, como parte do evento Merge #3, tivemos a oportunidade de falar abertamente deste tema.

Com vis√Ķes e experi√™ncias de pessoas t√£o diferentes como Peter Tielsen (CTO da Uniplaces), Jo√£o Pedro Martins (ex-CTO na CreateIT), Jo√£o Quit√©rio (Engineering Manager na Talkdesk) e Rui Ribeiro da Silva (Technical Director na GrandUnion), o debate, moderado por Gon√ßalo Gaiolas (Global Customer Experience Manager da Outsystems) teve como objectivo responder √† pergunta "como se cria uma cultura de desenvolvimento excelente?".

O próprio João Pedro Martins escreveu um artigo sobre a sua experiência no evento, o qual recomendo a leitura.

Qual a definição de cultura de desenvolvimento?

Na minha opinião, cultura de uma equipa de desenvolvimento abrange todos os momentos desde a abertura de um processo de recrutamento até à forma como a equipa lida com problemas nos sistemas que desenvolve. Ou seja, não estamos só a falar de arquitectura de software nem de best-practices de código, mas também de processos e inteligência emocional.

O ponto de partida - recrutamento

Quando uma equipa decide contratar um novo elemento, duas perguntas que raramente vejo s√£o "Por que estamos a contratar e o que queremos que a nova pessoa traga?". Pelo contr√°rio, √© tipico ver empresas que saltam directamente para uma job description completamente meaningless e com 10 ou mais pontos que a pessoa tem de cumprir. Num epis√≥dio do excelente podcast Scrum Master Toolbox (pe√ßo desculpa, n√£o me lembro do epis√≥dio em espec√≠fico), o convidado (penso que da Spotify) disse que uma job description deve ter n√£o mais do que 3 pontos chave para a fun√ß√£o pretendida. Eu concordo. Ali√°s, eu at√© prefiro algo como ‚ÄúPrecisamos de ajuda em X e Y. Consegues ajudar-nos?‚ÄĚ.

Ao colocar o foco no que a pessoa pode trazer, é muito mais fácil encontrarmos alguém que satisfaça o principal requisito de um processo de recrutamento - fazer a equipa crescer em skills.

Quando falamos de contratar developers, a minha preferência vai para um modelo hibrido entre ser a chefia a contratar sem "dar cavaco a ninguém" e ser a equipa por si só a decidir. Já estive em ambos os lados. Para mim, um bom processo de recrutamento tem 3 fases:

1. Filtragem de candidatos por uma equipa de recrutamento.

2. Entrevista com chefia directa e pares.

3. Exercício prático de código - resolver um problema real, em casa, ao longo de uns dias.

Este processo dá oportunidade à equipa e ao candidato para se conhecerem o melhor possível antes de decidirem que vão passar muito tempo juntos. Gosto particularmente de candidatos que fazem perguntas sobre como a equipa interage no dia a dia e gosto ainda mais de candidatos que pedem para passar algum tempo lado a lado com a equipa. Um processo de recrutamento não é "one-way", quanto mais exigente for o candidato com a empresa, melhor.

O caminho - processos e standards

Depois de a equipa ter um novo membro - e assumindo que o onboarding √© relativamente bem feito (ou seja, o candidato n√£o √© largado aos lobos) - o dia a dia passa a ser um reflexo dos processos que a equipa coloca em pr√°tica. Em culturas muito burocr√°ticas, torna-se muito dif√≠cil fazer o que quer que seja. Em culturas demasiado livres, tende a existir alguma falta de acompanhamento dos novos elementos. O ideal √© algo muito pr√≥ximo da autonomia total, desde que esteja garantido que os processos est√£o preparados para tal. √Č cr√≠tico garantir que, mesmo com um enorme n√≠vel de autonomia, a pessoa sinta que tem as seguintes condi√ß√Ķes reunidas:

1. Expectativas muito claras sobre a sua contribuição.

2. Tem ajuda, sempre que precisar, da sua equipa.

3. Tem feedback constante.

Tendo estes 3 pontos garantidos, para mim temos uma base sólida para garantir agora o próximo passo crítico: fazer a pessoa crescer. A principal prioridade de uma equipa quando contrata alguém é fazer essa pessoa crescer. Period.

Os processos de desenvolvimento que a equipa coloca em prática variam imenso, cada equipa deve escolher aquilo que funciona. Acima de tudo, deve experimentar o mais possível e questionar constantemente onde pode melhorar. O que dita o sucesso de uma equipa não é se adopta Scrum, Kanban ou mesmo Waterfall. Não é se usa Ruby ou C#. Não é se usa o Trello ou o TFS. O sucesso de uma equipa é ditado em grande parte pela capacidade que esta tem de ir descobrindo e melhorando constantemente o que melhor funciona para ela.

Para tal, além de exercícios tipicos de retrospectivas agile e / ou Kaizen, há algumas perguntas que esta deve responder de forma unanime entre todos os seus elementos. Qual o nível de exigência que a equipa coloca sobre si mesma? Quando alguém não cumpre este nível de exigência, como é que a equipa dá feedback (se é que dá)? Deixa para a chefia ou é a própria equipa a fazê-lo? Quando alguém supera as expectativas, como é que a equipa premeia (se é que premeia)?

O desvio - emo√ß√Ķes

Para responder √†s quest√Ķes colocadas acima, temos de responder a uma pergunta primeiro. Quanto √© que a equipa deixa as emo√ß√Ķes tomarem conta do seu dia a dia?

Esta √© a parte dif√≠cil, a parte que n√£o nos ensinam na escola. Confesso que me faz imensa confus√£o como passamos entre 12 a 20 anos a estudar e nunca somos ensinados a lidar com pessoas e emo√ß√Ķes. No pr√≥ximo dia 22 de Fevereiro vou ao IST, como parte da excelente SINFO, falar sobre este desafio.

Comecemos pelas emo√ß√Ķes da chefia (a partir daqui designada de manager). Algu√©m que gere pessoas e tem uma baixa auto-estima tipicamente vai ser algu√©m que, das duas uma, ou √© altamente complacente ou, mais comum, √© altamente ditador. Um manager com elevada auto-estima n√£o tem qualquer problema em confiar na sua equipa e em assumir total responsabilidade pelo desempenho da mesma (para o bem e para o mal). Por outro lado, um manager incapaz de lidar com as suas emo√ß√Ķes, vai estar constantemente a fugir a confrontos (mesmo que saud√°veis) e vai colocar uma m√°scara de dur√£o perante as pessoas que gere. Baseado na minha experi√™ncia, o mais comum √© o 2¬ļ caso. Temos imensos dur√Ķes, demasiados. Com isto, acabei de chegar a uma uma frase bonita:

"As emo√ß√Ķes de uma equipa s√£o um reflexo directo da intelig√™ncia emocional da sua lideran√ßa."

Assumindo que a equipa tem um manager ao seu n√≠vel, ou seja, algu√©m com capacidade de dar e receber feedback e actuar sobre o mesmo, voltamos agora a aten√ß√£o para as emo√ß√Ķes da equipa. E digo j√°: √© da responsabilidade de um manager criar as condi√ß√Ķes necess√°rias para que a sua equipa se sinta segura a partilhar emo√ß√Ķes. Comecemos por olhar para as 5 disfun√ß√Ķes de uma equipa, tal como descrito no livro Five Dysfunctions of a Team, do Patrick Lencioni. Muito referenciado em s√≠tios t√£o diferentes como a StackOverflow ou o Scrum Master Toolbox, esta f√°bula de lideran√ßa mostra como uma CEO em Sillicon Valley transformou uma equipa completamente disfuncional numa equipa high performant e contem exerc√≠cios para a equipa fazer. Ao longo do livro, um tema comum √©, drumroll, emo√ß√Ķes.

Five Disfunctions

Fonte

Segundo o autor, mais de 90% das empresas nem o n√≠vel 1 consegue superar (absence of trust). Olhem √† vossa volta e tentem identificar em que n√≠vel est√£o na pir√Ęmide. Sejam honestos. Numa das equipas pela qual sou respons√°vel, a de engenharia do InvoiceXpress, estamos sensivelmente a meio. O lado bom √© que tom√°mos consciencia de tal e a propria equipa pediu para ter esta pir√Ęmide na parede. S√≥ ao tomarmos consci√™ncia √© que podemos come√ßar a trabalhar em subir nesta pir√Ęmide.

Pass√°mos de modelos de feedback 1:1 para modelos de feedback entre todos os membros da equipa. Fazemos isto uma vez por m√™s. Todos os elementos s√£o convidados a dar feedback sobre todos os seus pares e managers, seja este bom ou uma oportunidade de melhoria. N√£o h√° mau feedback. Mau feedback seria dar feedback que n√£o ajuda em nada o destinat√°rio. O resultado destas reuni√Ķes √© termos baixado drasticamente o medo de falar. Longe de estarmos perfeitos, estamos no caminho certo. Encorajamos as pessoas a dar feedback sem filtros (diz o que sentes) e ao destin√°rio aconselhamos a n√£o tornar o feedback pessoal, mas sim sobre o seu desempenho (n√£o leves nada a peito).

O destino - all systems operational

All systems go!

Depois de termos a parte humana resolvida, podemos então deixar a equipa focar-se naquilo que deve estar focada: criar software excelente. Qualquer entrave a esse objectivo tem de ser removido. Não é uma opção, é uma obrigação de quem gere a equipa.

Isto passa pela arquitectura do software em si, pelos fornecedores de hosting ou outros serviços que a equipa escolhe, pela forma como o código é revisto pelos outros elementos antes de ir para produção e pelas ferramentas que a equipa tem à disposição.

Qual a vossa opinião? Deverão os developers adotar um cultura uniforme ou construir a mesma através dos diferentes processos?

Não percam o próximo post sobre cultura de desenvolvimento, onde iremos falar destes através de uma perspectiva técnica.

Leave a comment