OK como líder, é seu trabalho divulgar os projetos. Então você tem que ser quem impõe padrões, revisões de código, solicita relatórios de progresso e todas essas coisas quando os desenvolvedores preferem que você os deixe em paz. Essas são apenas exigências da gerência e, exceto pelas revisões de código, não aumentam realmente as habilidades dos funcionários.
No entanto, você deseja ajudá-los a crescer, o que é um ótimo atributo em um líder.
As revisões de código são certamente um primeiro passo, elas ajudarão você a ver quem tem menos do que habilidades estelares e precisa de melhorias para ter um desempenho satisfatório. Eles ajudarão os desenvolvedores a ver outras maneiras de fazer as coisas e a entender partes diferentes da base de código que não aquelas em que eles trabalharam pessoalmente. Na minha opinião, a melhor revisão de código é feita pessoalmente em uma sala de conferência com o desenvolvedor e o revisor (que deve ser outro desenvolvedor sempre que possível, nem sempre o líder, revisar o código de outros também é uma habilidade que precisa ser desenvolvida) e você como um moderador. Você deve fazer anotações sobre o que precisava ser alterado para identificar tendências. O que você realmente procura não são erros ou alterações (o código de todos pode ser aprimorado), mas falha consistente em aprender com os erros. Não diga à gerência superior que você está mantendo essas anotações ou você será forçado a usá-las como medidas no processo de análise de desempenho, o que frustra francamente o objetivo. Se vários desenvolvedores estão cometendo os mesmos erros, uma sessão de treinamento ou uma entrada no wiki sobre como fazer o X pode estar em ordem.
Agora vamos ao vício crescente, chegando ao nível mínimo. Primeiro, você precisa saber quais conjuntos de habilidades os desenvolvedores têm e quais seriam úteis que eles tivessem e o que eles poderiam estar interessados em obter conhecimento. Você precisa conversar com eles, revisar seus currículos e entender o que eles mentem e não gosto de fazer.
Não dê todas as tarefas interessantes apenas aos mais habilidosos. Isso não ajuda os outros a se familiarizarem com novos problemas e tecnologias. Você não pode deixar de ser o cara mais novo, recebendo apenas as tarefas menores e menos importantes para o cara mais velho, a menos que alguém se arrisque e atribua um trabalho mais difícil a você. Dito isto, os menos experientes podem precisar ser designados primeiro para emparelhar o programa com um sênior para obter habilidades mais avançadas. Incluir os juniores nas revisões de código também os expõe a técnicas mais avançadas.
Primeiro, dê a eles a chance de descobrir o problema eles mesmos. Mas, às vezes, as pessoas ficam presas e não sabem por onde começar (uma habilidade que você também precisa desenvolver, especialmente em novos programadores) ou o que fazer para resolver um problema.
Se você lhes der alguns dias para pesquisar algo e eles ainda não tiverem uma orientação sobre como vão fazer algo, talvez seja necessário intervir com algumas sugestões. Se você é técnico, pode dar algumas idéias sobre como resolver o problema. Caso contrário, uma reunião com várias pessoas em que você debata idéias pode ajudar se a pessoa estiver presa. Ou pedir a uma pessoa mais experiente que dê algumas sugestões. O que você não quer fazer é tirar o problema deles e resolvê-lo você mesmo. Mas você precisa equilibrar a conclusão do projeto com o ego do programador e, às vezes, precisa enviá-lo em uma direção específica. Se ele tem uma solução ruim e precisa ser corrigida, a pior coisa que você pode fazer é entregá-la a outra pessoa, a menos que você pretenda acionar o programador.
Vi programadores ruins mimados, onde outra pessoa precisa consertar quase tudo o que faz. Os outros programadores se ressentem disso e querem apenas a pessoa fora de suas vidas. Mimar um programador ruim leva à saída de bons programadores. Você tem que encontrar a linha entre as habilidades de mimar e devloping. Se você der a alguém várias chances e ele nunca melhorar, então solte-o.
Para os idosos que já são competentes em seus conjuntos de habilidades atuais, as coisas são mais fáceis. Normalmente, você só precisa dar a eles a oportunidade de fazer algo novo e eles entram e aprendem. Apenas garanta que as oportunidades interessantes se espalhem e nem todos procurem Joe, o Programador Maravilha, que pode consertar qualquer coisa. Você quer acabar com dez Joes e não apenas um.
Outra maneira de desenvolver habilidades é ter uma sessão semanal de treinamento de 1 hora. Torne cada devloper responsável por um tópico específico. Isso os ajudará a melhorar a comunicação, fará com que eles pesquisem algo em profundidade e traga a todos os benefícios de suas pesquisas. Alguns tópicos devem ser atribuídos a pessoas que não são familiares com o tópico para forçá-los a desenvolver algum conhecimento e outros devem ser atribuídos a pessoas que você conhece como especialistas locais nesse tópico. Os tópicos devem ser uma combinação de coisas nas quais você precisa que as pessoas sejam boas no futuro ou agora, e alguma cobertura das novas tecnologias que você não usa no momento, mas as pessoas estão interessadas em aprender a ver se elas podem ser úteis. Mas todo mundo, incluindo o mais jovem, deve receber um tópico.
Dependendo de como o tempo dos seus desenvolvedores é cobrado (isso é mais difícil em uma situação de cobrança do cliente), geralmente vale a pena que os desenvolvedores tenham de 4 a 8 horas por semana para trabalhar em projetos pessoais. Eles ficarão animados para fazer isso. As melhores pessoas vão querer trabalhar lá e aprenderão muito que se tornarão úteis para o futuro. É difícil para os contadores de feijão entenderem a necessidade disso, mas esse tempo será recompensado muitas vezes em satisfação dos funcionários, novos recursos ou software que ninguém exigia (ou que ajudaria a automatizar parte da labuta) e desenvolvimento mais rápido devido a novas técnicas aprendidas. Alguns desenvolvedores usarão esse tempo estritamente para projetos pessoais não relacionados ao que você faz (e isso é bom, eles ainda estarão adquirindo habilidades e felizes com a oportunidade), mas muitos outros o usarão para resolver problemas persistentes que, devido à natureza de como os projetos são gerenciados, ninguém teve tempo de corrigir previamente. Portanto, você pode obter refatorações que beneficiam a todos; algumas pessoas podem escrever testes para melhorar a cobertura dos testes e facilitar a refatoração; alguns outros podem explorar alguns novos recursos que podem tornar seu software mais útil para seus clientes. Em geral, se você pode convencer os contadores de feijão, não há como perder, permitindo-lhes essa liberdade.
Você precisa aprender a equilibrar, permitindo que as pessoas se esforcem por suas habilidades e mantendo o projeto nos trilhos. Quanto menos experiente o desenvolvedor, mais alguém precisa verificar o progresso, especialmente nos estágios iniciais, quando mudar de direção é mais fácil. Os inexperientes podem lutar e ter medo de falar. Essas pessoas tendem a sair um pouco antes do lançamento e você acha que a parte do projeto não está nem perto de ser concluída. Seja especialmente cuidadoso ao verificar o progresso de qualquer pessoa que tenha trocado de emprego com freqüência (a menos que seja um contratado, pois essa é a natureza da contratação).
Geralmente, os mais experientes podem contar quando estão com problemas para encontrar a solução e precisam de ajuda de alguém com mais conhecimento na área ou então procurarão essa pessoa e obterão a transferência de conhecimento. Portanto, eles não precisam ser monitorados tão de perto nas fases iniciais de aprendizado de um novo conjunto de habilidades para um projeto. Eles encontrarão uma maneira de entregar o projeto. Aqueles que têm um histórico de entrega geralmente podem ser deixados em paz, exceto por relatórios de progresso mínimos (geralmente você também precisa se reportar à sua gerência e, portanto, precisa de algumas informações).