Como estruturar uma equipe de desenvolvimento

Sou o gerente de uma equipe de 11 desenvolvedores de software que cuidam dos sites / aplicativos da web da minha empresa, executando até 4 projetos simultâneos, além de suporte diário a qualquer momento. Nos 11 desenvolvedores, há uma mistura de habilidades técnicas, cargos e experiência, embora a estrutura da equipe seja plana, com todos os 11 desenvolvedores se reportando diretamente a mim.

Toda a equipe que tem um único gerente está começando a provar que não está muito bem dimensionada. Estou começando a me espalhar muito pouco, então quero reduzir meu número de subordinados diretos. Todas as maneiras pelas quais posso pensar em fazer isso têm desvantagens significativas:

• Faça com que os desenvolvedores juniores se reportem aos seniores. Isso reduz o tempo gasto no desenvolvimento pelos melhores técnicos.
• Divida a equipe por produto de software, por exemplo, os desenvolvedores 1-6 trabalham na intranet e 7-11 trabalham em sites externos, com cada seção tendo um novo líder de equipe (possivelmente uma nova descrição de cargo com mais responsabilidade de gerenciamento / mentoria / treinamento do que os atuais desenvolvedores seniores ) Isso adiciona silos artificiais e pode dificultar que um "desenvolvedor da intranet" trabalhe em um site externo, se eu quiser.
• Mantenha a estrutura plana e adicione suporte gerencial na forma de gerentes de projeto / administradores de equipe apenas para aliviar a pressão. Isso não resolve o problema, pois a equipe não pode continuar crescendo assim para sempre.

Existe uma maneira padrão de resolver esse problema que estou perdendo?

Se não, como outros resolveram esse problema?

Algumas reflexões rápidas:

• As sub-equipes são uma boa idéia: 11 subordinados diretos sem nenhuma estrutura são muito grandes para uma equipe viável (você não terá tempo suficiente para treinamento direto e as reuniões de equipe com tantas pessoas tendem a ser improdutivas).
• Considere separar as operações do desenvolvimento - é um conjunto de habilidades um pouco diferente e ser interrompido por problemas operacionais durante todo o dia pode prejudicar seriamente a produtividade do desenvolvimento dos projetos.
• Como resultado dos dois primeiros pontos, acho que você deveria ter talvez três subequipes - Intranet, Sites externos e Operações. A equipe de operações lidará com todos os problemas do dia-a-dia / correções de manutenção etc., enquanto as duas equipes de desenvolvimento se concentram em fornecer novos projetos / valor aos negócios.
• Ciclo de pessoas entre equipes em uma base regular. Isso pode ser ocasional (por exemplo, fazer as pessoas revisarem o código em outra subequipe), para um projeto ou de forma permanente. Mas verifique se as funções da equipe mudam sempre que houver uma necessidade comercial - ninguém "possui" uma função específica para sempre.
• Não adicione mais gerentes / administradores - esta é uma maneira infalível de reduzir a eficácia / produtividade geral de suas equipes. Faça com que a pessoa mais experiente em cada subequipe desempenhe um papel de líder / treinador da equipe. Certifique-se de que eles vejam seu papel aqui como treinador e fazer com que toda a equipe seja bem-sucedida, e verifique se eles estão equipados para se comportar dessa maneira, em vez de agir como um "gerente de tarefas".
• Seu papel deve ser focado no gerenciamento de partes interessadas externas, priorização de recursos / tarefas dentro do grupo e atuação como "treinador principal". Você precisará lidar com o problema escalado ocasional das sub-equipes, mas em geral você deve incentivá-los a resolver os problemas eles mesmos, sem chegar até você.
• Se você é altamente técnico, também pode optar por desempenhar uma função de arquiteto / garantia de projeto. Caso contrário, encontre alguém que possa, dentro da equipe ou em outro lugar ...

Além disso, sempre vale a pena ir e (re) ler o Manifesto Ágil , e especialmente os doze princípios .

Essa estrutura irá principalmente depend on project specifications

Idealmente, deve haver três juniores por desenvolvedor sênior em uma equipe. Consequentemente, existem 2-3 desenvolvedores seniores por líder de ensino.

Assim, apenas os líderes técnicos reportarão à PM o status do progresso do projeto. A estrutura descrita ainda pressupõe que, para problemas não técnicos (férias, folgas, conflitos etc.), todos possam ter acesso ao PM.

Uma das equipes de desenvolvimento de software relativamente bem-sucedidas das quais eu fazia parte era algo assim, por projeto:

Um gerente de desenvolvimento de software / desenvolvedor sênior / mentor, para quem todos se reportaram diretamente.

• Um gerente de projeto, que manteve cronogramas, facilitou a negociação de requisitos e aceitação e fez comunicações. Todos os membros da equipe também se reportaram a essa pessoa. Uma pessoa de documentação (que ocasionalmente também era a PM, mas somente quando a perícia permitida).
• Uma mistura de 1-3 desenvolvedores ou desenvolvedores seniores, dependendo das necessidades do projeto.
• Um desenvolvedor júnior, quando disponível.
• Alguém designado de um pool de controle de qualidade.
• Uma pessoa de infraestrutura (uma função frequentemente desempenhada pelo gerente, pois ele também possuía sólida competência em SA).

Funcionou perfeitamente bem, e eu amei essa organização. Por outro lado, eu era o gerente de desenvolvimento de software e a estrutura organizacional da equipe estava evoluindo.

Considere seguir o padrão da Organização de Funcionários Funcionais . Isso indica sua segunda opção de dividir a equipe por produto de software.

Para citar o artigo no seu contexto:

A maior força de uma organização funcional é que ela vincula estruturas sociais à entrega de valor comercial. Na minha opinião, os projetos de software são bem-sucedidos tanto quanto melhoram a eficácia da atividade que suportam - gerando valor comercial. Ao organizar suas equipes da mesma maneira, você tem uma equipe orientada para satisfazer seus usuários de negócios.

A estrutura real de gestão / RH é irrelevante além disso.

Existe uma maneira padrão de resolver esse problema que estou perdendo?

Na verdade não. Depende da sua equipe, você, o que você precisa fazer e que recursos a empresa disponibilizará para você.

Pessoalmente, o melhor tipo de opção é dividir o gerenciamento técnico do gerenciamento administrativo. É raro que as pessoas sejam boas em ambas, e raramente tendem a interagir.

Uma pessoa lida com os aspectos técnicos. O que precisa ser feito, quem vai fazer isso, como as coisas precisam se alinhar. O outro lida com aspectos administrativos. Revisões, reuniões de orçamento, planejamento de produtos etc. Eles trabalham juntos para comunicar idéias de um lado para o outro e fornecer uma frente unida.

Como isso é dividido pode seguir algumas maneiras diferentes. O mais comum é ter o gerente de engenharia no lado administrativo e um arquiteto no lado técnico. Eles são colegas e se reportam a um diretor / vice-presidente.

Outro trabalho que vi foi o de fazer com que o gerente de engenharia seja a pessoa administrativa e, em seguida, o (s) líder (es) da equipe atuam como pessoa técnica. Isso é mais complicado e requer que as pessoas certas ajam como (principalmente) colegas, mesmo que os relatórios sejam hierárquicos.

Para o seu cenário específico, eu recomendaria ter 2-3 equipes e ter líderes técnicos para fazer os aspectos técnicos e você se concentrar no administrativo. Sim, isso reduz o tempo dos leads que realmente escrevem o código, mas eles devem (se estão fazendo um bom trabalho) recuperar esse tempo, tornando os desenvolvedores mais jovens mais eficientes / produtivos. Isso lhes proporciona mais motivação e um senso de realização com a promoção real também. E, na prática, é mais fácil vender para a gerência do que abrir uma nova posição.