Os papéis escritos do gerente de desenvolvimento de software [closed]

62

Todos nós sabemos o que um gerente de desenvolvimento de software faz, mas temo que só o entendamos vagamente . Achamos que sabemos o que ele está fazendo, mas listar exatamente qual é o escopo do trabalho é um pouco difícil.

Na sua opinião, quais são os papéis de um gerente de desenvolvimento de software?

    
por Graviton 16.11.2010 / 07:44
fonte

1 resposta

100

Falando como alguém no trabalho (que também foi desenvolvedor), as principais coisas que tenho que fazer são:

  • Mantenha a equipe de desenvolvimento no caminho certo (e feliz sempre que possível) - faça as coisas saírem do caminho para impedi-las de trabalhar sempre que possível, explique por que não é possível onde não podem ser movido para tentar reduzir qualquer estresse resultante (as pessoas são mais propensas a aceitar as coisas se pelo menos as entenderem). Em última análise, se houver um conflito entre o projeto e a equipe que não pode 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 um líder sindical. A habilidade óbvia é minimizar a frequência com que isso acontece.

  • Certifique-se de que a equipe esteja se comunicando com o cliente com o valor correto . Isso tende a ser partes iguais mantendo o cliente longe da equipe e certificando-se de que a equipe está perguntando ao cliente sobre coisas que não entendem completamente (em vez de apenas fazer suposições que podem estar incorretas). Os desenvolvedores são muito grandes para garantir que o cliente não os perturbe e ocasionalmente se esqueça de que o cliente pode ter algo útil para adicionar.

  • Planejamento e priorização de projetos de conflitos de recursos, demandas de clientes, problemas de suporte e afins. Eu costumo ser a pessoa que diz que esse cliente tem prioridade sobre esse, ou que esse bug tem que ser consertado antes de ser enviado, mas que um pode sair como um problema conhecido.

  • Gerencie o lado comercial do desenvolvimento - certificando-se de que as coisas que devem ser cobradas e cobradas e que não estamos tentando cobrar por itens que devem ser cobertos sob apoio.

  • Seja a voz da equipe no negócio e na empresa dentro da equipe - ajude a entender a posição do outro e ajude a resolver as diferenças onde elas surgem. Isso tende, em grande parte, a cobrir os conflitos culturais entre as necessidades / desejos das equipes e as organizações maiores, além de questões orçamentárias. Isso é realmente muito ruim, pois significa que quando há divergências, você é o inimigo de todos.

  • Trabalhe com a equipe para garantir que processos e ferramentas suficientes estejam em vigor para atender aos requisitos da empresa e dos clientes . Certifique-se de que 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), alguns os definem (para as coisas que entendo melhor do que para eles - planejamento, estimativa e assim por diante). A palavra importante aqui é suficiente - você não quer processar pelo processo, mas há coisas que precisam acontecer e processar é a melhor maneira de conseguir isso de forma consistente.

  • Garanta que todos os membros da equipe estejam trabalhando em pelo menos um nível razoável e, idealmente, além disso. Trabalhe com eles para ajudar a resolver problemas que estão impedindo que eles atinjam esse nível. Eu adoraria dizer que meu papel é fazer com que eles sejam o melhor que podem ser, mas enquanto isso é verdade em outras exigências (projeto, orçamento, tempo) significa que isso quase sempre será comprometido em maior ou menor extensão.

  • Fazendo toda a administração e as coisas que a organização (e a lei) exigem

Em geral, é parte de mentoria, parte de secretariado, parte de gerenciamento de projetos, gerenciamento de parte de contas e parte de RP (para a equipe). Há muita coisa pegando coisas que os desenvolvedores não precisam pensar ou não pensam em fazer, e algumas certificando-se de que fazem coisas que precisam fazer, mas não querem fazer.

Não se trata de ser o melhor desenvolvedor (geralmente você está muito ocupado para permanecer atualizado por muito tempo, então precisa aceitar que as pessoas saberão mais do que você - a habilidade é saber onde está sua experiência mais longa, mas ultrapassada) mais relevante do que a sua experiência mais curta, mas mais recente) ou ser algum tipo de ditador. A esse respeito, a melhor maneira de pensar sobre isso não é que você é mais antigo, apenas que você tem responsabilidades diferentes. Às vezes, isso envolve fazer a chamada final de algo (o que pode ir contra as opiniões da equipe), mas, mais frequentemente, deve ser sobre consenso ou compromisso.

    
por 16.11.2010 / 11:05
fonte

Tags