Falando como alguém no trabalho (que também foi desenvolvedor), as principais coisas que devo fazer são:
Mantenha a equipe de desenvolvimento nos trilhos (e feliz sempre que possível) - faça com que as coisas parem de funcionar onde for possível, explique por que não é possível onde elas não podem ser movidas para tentar reduzir o estresse resultante (as pessoas são mais provavelmente aceitarão as coisas se elas as entenderem). Por fim, se houver um conflito entre o projeto e a equipe que não puder ser resolvido, normalmente o projeto vencerá. Isso não necessariamente o torna popular com a equipe, mas você é pago para entregar projetos / produtos, não como líder sindical. A habilidade óbvia é minimizar a frequência com que isso acontece.
Verifique se a equipe está se comunicando com o cliente na quantidade certa . Isso tende a ser partes iguais, mantendo o cliente longe da equipe e garantindo que a equipe pergunte ao cliente sobre coisas que não entende completamente (em vez de apenas fazer suposições que podem estar incorretas). Os desenvolvedores são muito grandes em garantir que o cliente não os perturbe e ocasionalmente esquecem que o cliente pode ter algo útil a acrescentar.
Planejamento de projetos e priorização de conflitos de recursos, demandas de clientes, problemas de suporte e similares. Costumo ser a pessoa que diz que esse cliente tem prioridade sobre esse ou que esse bug precisa ser corrigido antes de ser lançado, mas que pode sair como um problema conhecido.
Gerencie o lado comercial do desenvolvimento - isso é garantir que as coisas que devem ser cobradas e cobradas e que não estamos tentando cobrar pelas coisas que devem ser cobertas pelo suporte.
Seja a voz da equipe nos negócios e os negócios dentro da equipe - ajude todos a entender a posição do outro e ajude a resolver as diferenças onde eles surgirem. Isso geralmente cobre conflitos culturais entre as necessidades / desejos das equipes e as organizações maiores, além de questões orçamentárias. Isso é realmente uma merda, pois significa que, quando há discordâncias, você é inimigo de todos.
Trabalhe com a equipe para garantir processos e ferramentas suficientes para atender aos requisitos dos negócios e dos clientes . Verifique se esses processos estão sendo seguidos e ajustados conforme necessário. Parte disso é garantir que a equipe defina processos (por exemplo, para coisas técnicas que eles entendem melhor do que eu), outros os define eu mesmo (para coisas que eu entendo melhor do que elas - planejamento, estimativa e assim por diante). A palavra importante aqui é suficiente - você não quer processo por causa de processo, mas há coisas que precisam acontecer e processo é a melhor maneira de conseguir isso de forma consistente.
Certifique-se de que todos os membros da equipe estejam trabalhando para pelo menos um nível razoável e, idealmente, além disso. Trabalhe com eles para ajudar a resolver quaisquer problemas que os impeçam de atingir esse nível. Eu adoraria dizer que meu papel é torná-los o melhor possível, mas, embora isso seja verdade até certo ponto, outras demandas (projeto, orçamento, tempo) significam que isso quase sempre será comprometido em maior ou menor grau.
- Fazendo toda a administração e coisas que a organização (e a lei) exigem
No geral, é parte de mentoria, parte de secretariado, parte de gerenciamento de projetos, parte de gerenciamento de contas e parte PR (para a equipe). Há muitas coisas que os desenvolvedores não precisam pensar ou não pensam em fazer, e algumas certificando-se de que fazem o que precisam, mas não querem.
O que não interessa é ser o melhor desenvolvedor (geralmente você está muito ocupado para permanecer atualizado por muito tempo, então você precisa aceitar que as pessoas saberão mais do que você - a habilidade é saber onde sua experiência mais longa, porém desatualizada, é mais relevante do que sua experiência mais curta, mas mais recente) ou ser algum tipo de ditador. Nesse aspecto, a melhor maneira de pensar sobre isso não é que você é mais experiente, apenas que possui responsabilidades diferentes. Às vezes, isso envolverá a decisão final de algo (que pode ser contrário às opiniões da equipe), mas mais frequentemente deve ser sobre consenso ou compromisso.