O artigo a seguir foi possível após um ano de desenvolvimento, no qual eu pude reunir toda a minha experiência de trabalhos anteriores.

Ter trabalhado em diferentes posições, desde programador júnior até sênior, eu pude chegar à posição de líder na versão móvel do jogo Jake & Jess Finding Monsters Adventure.

Agora é hora de compartilhar esse conhecimento.

Ser um programador líder frequentemente é associado a um pensamento crítico puro e tomada de decisões, mas muito frequentemente o lado humano da posição é negligenciado. Nós normalmente encontramos líderes que sabem exatamente como fazer um bom código, mas não exatamente como lidar com as pessoas ao seu redor.

Este artigo tratará principalmente dois aspectos do programador líder:

• Interação com os engenheiros, focando na boa mentorização, resolução de conflitos e mantendo a equipe trabalhando da melhor maneira possível.
• Interação com outras áreas e com a alta administração.

Em primeiro lugar, todos os seres humanos são emocionais. Não importa quão centrado alguém seja, as emoções conduzem algumas tomadas de decisão, nas interações e na produtividade.

Se isso não fosse suficiente, a síndrome do impostor é um problema bem documentado que ocorre com pessoas que trabalham com códigos em equipe. Seu trabalho/processo de pensamento/soluções são todos extremamente expostos aos seus companheiros e constantemente revisados. Isso faz com que eles se sintam menos confiantes como programadores comparados aos seus colegas de trabalho.

Como líder, o objetivo é alcançar um produto estável, com um código altamente otimizado e bem organizado sendo entregue no prazo.

Tudo isso alcançado em um ambiente radical e mutável que é a indústria de jogos, onde as funcionalidades podem mudar, assim como os cronogramas e as datas de entrega.

Liderar pessoas, não códigos

Programador líder pode ser o título do cargo, mas não é um programa que está sendo liderado. São as pessoas produzindo-o. Algumas coisas podem passar despercebidas.

• Níveis diferentes de senioridade e experiência estão trabalhando na mesma base de código;
•  Estilos diferentes de codificar coexistem;
• Áreas diferentes interferem diretamente no que o código fará depois;
• A frustração é um vilão que constantemente mina a vontade de codificar.

Todos os projetos que têm mais do que 3 programadores enfrentarão diferenças radicais de níveis de habilidades com diferentes estilos de pessoas trabalhando juntas e tentando ter uma base única e coerente de código.

Mantenha em mente que eles provavelmente estarão sofrendo com a síndrome do impostor, no que diz respeito ao quão bem eles estão comparados aos membros da equipe.

Manter as pessoas motivadas a codificar é um trabalho que tem que ser mantido constantemente durante toda a duração do projeto, ao mesmo tempo em que qualidade, estabilidade e otimização do código devem ser cobradas da equipe todo o tempo, o que envolverá críticas.

Criticar o trabalho de um desenvolvedor pode ser a parte mais delicada de liderar programadores. O sucesso na entrega dessa crítica é a diferença entre transformar um bom desenvolvedor em um ótimo desenvolvedor ou atirá-lo em um buraco de falta de produtividade, onde ou ele vai deixar a empresa ou será demitido.

Como os programadores já tem uma tendência de comparar seus trabalhos com os dos colegas, realizar as críticas utilizando comparação dos códigos pode ser um dos piores erros que um líder pode realizar.

Deve ser claro para a pessoa que todos os seus esforços são apreciados, e que ela não será punida pelos erros em seus códigos (nunca apresente como erros!). Em vez disso, diga que são esperados melhores resultados dele, não porque a empresa pede, mas porque a equipe confia que ele é capaz.

Mesmo que bons resultados sejam realmente esperados de uma pessoa realizando uma tarefa, dizer isso de uma maneira negativa colocará todo o foco da pessoa em quão ruim está a situação, em vez de pensar em que sentido ela pode melhorar sua performance e habilidades.

Como líder, você quer desenvolver um ambiente confortável e seguro para o crescimento das pessoas, blindando aquela pessoa da pressão e da possibilidade de ser demitida se as melhorias não forem alcançadas.

Isso não deve ser confundido com “pegar leve” com alguém.

Esse ambiente seguro tem que ser preparado desde o primeiro dia do projeto. A mentorização por melhores resultados deve ser parte do dia a dia de um programador líder.

Conhecendo sua equipe

Criar um perfil de cada membro da sua equipe com suas forças e fraquezas, qual seu estilo, e conversar sobre problemas de comportamento assim que seja detectado é essencial.

Detectar o quanto antes em quais áreas o membro da equipe pode falhar torna mais fácil tanto para o mentor quando para o aprendiz terem melhores hábitos de programação e manter uma base estável e coerente durante o caminho.

Divulgando as notícias

Um líder não pode deixar como última instância tratar os maus hábitos e mudança das demandas. Fazer isso provavelmente levará a uma série de problemas com os códigos desenvolvidos por cada indivíduo.

Ele provavelmente entrará em um estado defensivo de medo. O mais provável que aconteça é uma queda na produtividade por medo de novos erros, geralmente aumentando a quantidade de erros feitos por aquele desenvolvedor. E também será mais difícil identificar os erros, pois ele tenderá a esconder seu trabalho dos outros, ou fazer o jogo do “culpado”.

Em vez de aguardar, deve-se atuar logo que um mau habito for notado, mas não dizendo “Ei, você errou!”. Devem ser utilizadas formas de sugestões, explicando por que é melhor agir de outra maneira.

Sentar ao lado da pessoa para ela descobrir uma melhor maneira de realizar a mesma tarefa a acostumará a trabalhar melhor. Então, sempre reconheça seu esforço e a parabenize pela nova solução que encontrou.

Quando um problema ocorre em uma equipe porque já existiam maus hábitos e um novo líder chega, fazer uma reunião com a equipe pode ser o caminho. Deve ter o tom de um alinhamento, não de uma bronca para todos.

Por que ser como uma babá?

Alguns podem achar que as pessoas deveriam ser maduras o suficiente para descobrir tudo isso sozinhos, afinal de contas, são pessoas técnicas, pensadores críticos que sabem como o código deve ser. No entanto, os humanos são criaturas de hábitos. Algumas pessoas podem ter hábitos destrutivos e não saber.

Mudar os hábitos é difícil. Ser confrontado por isso é o gatilho para nossa autodefesa e nos fechar para as mudanças.

Um líder deve entender esse aspecto da natureza humana e ter boas habilidades para tratar os conflitos sem acionar as defesas.

Ser duro e sincero pode funcionar para alguns indivíduos, mas há grande probabilidade de causar rancor entre o líder e os desenvolvedores ao invés de juntar a equipe por uma melhor produtividade.

Um líder não deve querer promover-se ou ditar a “maneira correta de fazer”. Criar um jogo não é como martelar um prego. Se as pessoas não estiverem motivadas a fazer o game, elas não criarão soluções criativas. Se esforce para criar uma equipe faminta por desafios.

Equipe de desenvolvimento vs alta gerência

O desenvolvimento de jogos é delicado. Não somente a equipe tem que dar vida ao game, mas também deve criar ferramentas para outros projetos, garantindo a estabilidade e a entrega no prazo.

Estúdios maiores e mais maduros podem ter equipes dedicadas para cada segmento, mas os menores precisam compartilhar os recursos.

Movimentar os desenvolvedores entre os projetos não é como movimentar funcionários de construção. Leva tempo para eles se adaptarem ao novo projeto e voltarem a produzir à 100%.

Um grande problema que os desenvolvedores enfrentam é a busca por qualidade de código quando a alta gerência quer interferir no desenvolvimento diretamente. Isso cria turbulência, a possibilidade de retrabalho, novas funcionalidades e muita frustração para os desenvolvedores.

O desenvolvedor líder deve ter voz contra mudanças imprudentes. Ele deve blindar os desenvolvedores da equipe dessas turbulências, liberando apenas as mudanças que devem ocorrer e que serão mais próximas das decisões finais.

Isso envolve fortes conflitos e medo de perder o emprego quando “Não” começa a ser muito dito.

A chave aqui é a racionalidade.

A liderança é responsável pelas decisões técnicas do projeto. Se algo parecer insensato, ele não pode ceder.

Se o líder falhar em fazer isso, o trabalho será feito duas vezes: uma para a mudança insensata e outra para corrigi-la.

Tempo será perdido no processo e será gerada frustração entre os desenvolvedores.

Além disso, os desenvolvedores começarão a duvidar das decisões tomadas pela liderança, pois a permissão para que coisas insensatas os atinjam será vista como uma decisão tomada por ele (e realmente foi). A confiança pode ser abalada, o que pode resultar na falta de interesse dos membros da equipe em realizar mentorização e no fato de futuras solicitações serem recebidas com menos entusiasmo pela equipe.

Desenvolvedor vs outras áreas

Todas as áreas querem alguma coisa dos desenvolvedores. Pedidos de funcionalidades sempre serão intermináveis. Tudo depende de quanto os desenvolvedores poderão entregar.

Mudanças normalmente ocorrem nas funcionalidades do jogo durante o processo de desenvolvimento. Isso evolui e pode se transformar em coisas diferentes.

A base de código sofrerá quando códigos obsoletos começarem a se acumular.

Para controlar isso, a manutenção deve ser realizada sempre que antigos sistemas tenham passado por muitas mudanças para incluir novas funcionalidades, significando que o resto precisa ser retrabalhado.

Isso será recebido com muita resistência pela produção, pois eles não terão calculado esse trabalho extra.

Novamente, é papel do líder assegurar que o esforço da próxima Sprint será utilizado para retrabalhar esse código. Essa prática traz mais de um benefício.

Um benefício, obviamente, é a estabilidade. O código passa a ser mais previsível, imparcial e confiável.

Adicionalmente, os programadores envolvidos nessas tarefas se sentirão mais confortáveis sobre esse segmento do código e trabalharão com menos tensão em novas funcionalidades envolvendo isso. A decisão de solidificar o código indica que agora o projeto está mais maduro; a demanda de desenvolvimento daquela parte do código será mais fácil e mais flexível.

Esteja ciente de que quando um líder se junta à uma equipe que não tenha essa ideia formada, será percebida resistência de todas as áreas.

Mas, assim que o primeiro projeto for concluído, a estabilidade do código e a facilidade para correções vão deixar claro que tudo valeu a pena, especialmente se qualquer membro da equipe trabalhou antes em projetos caóticos que tinham problema o tempo todo próximo da data de entrega. Isso pode parecer loucura para os leitores dos estúdios maiores, mas os estúdios menores só agora estão começando a ter equipes maiores e passam por isso o tempo todo.

Conclusão

Liderar uma equipe de desenvolvedores pode parecer uma posição técnica muito complicada à primeira vista, mas pode ser ainda mais complicada a interação com os recursos humanos da equipe.

É essencial que o líder tenha um bom conhecimento técnico, mas muito frequentemente os líderes com poucas habilidades interpessoais assumem a posição. Quando isso acontece, ele acaba fazendo grande parte da programação, porque ele não conseguiu mentorizar as pessoas para produzir melhor. Essa segregação o distanciará ainda mais da equipe, criando quase uma luta de classes entre os desenvolvedores e “o chefe” que “bate” neles devido ao código ruim e espera que eles melhores sob a pressão de serem demitidos se eles não seguirem os mesmos padrões dos melhores desenvolvedores.

Não é somente isso, o líder deve ser maduro o suficiente para blindar a equipe de desenvolvimento de tempestades externas, permitindo que exista um ambiente estável e fértil em que cada desenvolvedor possa atingir melhores resultados.

***

Ariel Marcelo Madril faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://www.gamasutra.com/blogs/ArielMarceloMadril/20160114/263585/Lead_Programmer_less_programming_more_humaning.php.