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.
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
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.
