Como devo gerenciar uma equipe com diferentes níveis de habilidade?


15

Vou trabalhar em um projeto de software com alguns amigos meus e fui indicado como líder técnico. Nenhum desses caras é um péssimo programador, mas eu tenho significativamente mais experiência do que eles. Eu preciso ser capaz de distribuir o trabalho entre todos da equipe, além de garantir que não pisemos nos dedos uns dos outros; que eles atendam aos relativamente altos padrões de qualidade e escalabilidade necessários para que este projeto seja bem-sucedido, sem que seja necessário revisar tudo o que eles comprometem.

Como devo manter os padrões e evitar o microgerenciamento? É o suficiente para fazer alguns diagramas, agendar algumas revisões de código e confiar que poderei consertar qualquer coisa que eles possam quebrar ou devo seguir a rota do TDD e escrever testes explícitos para a equipe satisfazer?


11
Existe uma equipe com os mesmos níveis de habilidade?
P.Brian.Mackey

@ P.Brian.Mackey: Quero dizer bem diferente.
Jon Purdy

@ Jon: Eu realmente espero que você saiba no que está se metendo. Certifique-se de que eles tenham alguma "carne de porco" no negócio desde o início (!). Tenho a vaga sensação de que você precisa de alguém com muita experiência lá, se, ao que parece, eles não conseguem nem escrever testes de unidade e (!) Não descobriram como fazer isso sozinhos: isso leva eu acho que talvez você esteja exagerando as habilidades deles. Escusado será dizer que assumir mais competência do que é o caso não é uma boa técnica de gerenciamento de projetos.
Henrik

@ Henrik: Eu sei no que estou me metendo, só não tenho muita experiência no gerenciamento de outros desenvolvedores e quero obter alguns conselhos sobre como garantir que as coisas corram bem. Eu tenho total confiança em suas habilidades e acho que as pessoas estão lendo muito mais negatividade em minha pergunta do que eu realmente coloquei lá. Acabei de programar por mais da metade da minha vida, por isso já cometi muitos erros que esses caras com 2 a 3 anos de experiência ainda precisam encontrar.
Jon Purdy

É para uma empresa ou projeto paralelo?
Mareie

Respostas:


10

Você deve revisar parte de seu código e permitir que eles revisem um ao outro. Não é que você queira ser a Polícia de Check-in, mas queira fornecer feedback o mais rápido possível. Ser um revisor pode reforçar sua compreensão. Deixe-os revisar seu código também. Seja o modelo.

Nota lateral: não deve haver surpresas durante uma revisão anual.


2
+1 em "Seja o modelo". Esse foi o maior benefício que vi nas análises de código: aprender com a astúcia de outras pessoas. Isso, e pegando o defeito ocasional.
Peter K.

1
Uma ferramenta para o código-revisão sendo um "purgatório" é [ code.google.com/p/gerrit/]
Henrik

9

Acima de tudo : comunique suas expectativas e design da maneira mais possível. Diagramas são bons para alguns; interfaces definidas funcionam para outros; programação em pares também funciona; revisões formais de código também podem ajudar algumas pessoas.

Eu também recomendo usar a automação, tanto quanto possível:

  • Obter a equipe para usar uma ferramenta como NDepend ou ReSharper se você está no reino .Net. Ajuste as regras padrão se você não gostar delas.
  • Automatize seus testes o máximo possível.

É difícil argumentar com um caso de teste com falha ou uma ferramenta de inspeção automatizada, desde que bem configurados.


3
Programadores ruins provavelmente configuram casos de teste ruins?
JeffO 13/02/11

1
Ferramentas como o Resharper são def. limpo, mas certamente não são gratuitos. O teste automatizado exige a criação de código passível de teste, o que pode estar definindo um requisito impraticável se os níveis de habilidade estiverem muito abaixo do esperado.
P.Brian.Mackey

@ Jeff: Eles não são maus programadores, apenas temos experiências diferentes e eu tenho anos neles. Presumivelmente, eu e o cara mais experiente estariam escrevendo os testes, se houver.
Jon Purdy

@ Jeff O: Então tire-os do time.
Peter K.

@ P.Brian.Mackey: Não havia especificação de ferramentas gratuitas na questão. Se o código não for testável, tire-o da equipe. Tente mostrar a eles como escrever código testável e, se eles não melhorarem, tire-os da equipe.
Peter K.

5

Se você estiver realmente trabalhando com uma grande variedade de níveis de habilidade no mesmo projeto, haverá alguns problemas. A questão é quando você lida com eles? Eles vão escrever um código tão ruim que é melhor você não ter a assistência deles? Isso vai criar tensão pessoal? Você vai terminar amizades? Essas perguntas que ninguém pode responder além de você.

Supondo que todos permaneçam na equipe, recomendo dividir as tarefas em pequenos pedaços (os maiores vão para caras mais habilidosos) e deixamos que os desenvolvedores mais habilidosos refatorem quando terminar. Certifique-se de executar o controle de qualidade em intervalos regulares e apertados. Isso é bem parecido com o que acontece na realidade de qualquer maneira.


3

Tanto quanto possível, fique fora das ervas daninhas. Em qualquer equipe, se você é o líder, precisa economizar um pouco da sua largura de banda para as crises e para o cenário geral. Os diagramas são bons e os padrões de codificação são sempre sãos, mas a criação de processos em que as pessoas verificam o trabalho umas das outras é ainda melhor (testes cruzados, revisões por pares, programação em pares). Nem todo mundo na equipe precisa ser uma estrela - a equipe em conjunto geralmente pode superar as fraquezas dos indivíduos.

O que eu recomendo é que você resista à tentação, na medida do possível, de dizer às pessoas quais erros você vê na codificação - em vez disso, leve-as a ver por si mesmas. Permaneça parte da revisão colaborativa do trabalho de desenvolvimento, mas certifique-se de não contribuir com mais do que outros membros. Em vez disso, faça um esforço extra para incentivar as pessoas a ver o que você vê e dê muitas explicações sobre por que as coisas que você vê são importantes.

Não se preocupe muito com a sobreposição - além de uma interrupção sensata do trabalho, você pode pedir aos membros da equipe que façam check-in entre si e, em seguida, apenas verifique se a comunicação ocorreu. A equipe começará rapidamente a se olhar como uma maneira de obter consenso, e isso facilita seu trabalho cerca de 20 vezes - então tudo o que você precisa fazer é desempate quando as principais áreas discordam.

Em seguida, salve seu esforço para analisar a equipe coletivamente. Cada pessoa terá alguns pontos fortes impressionantes e algumas fraquezas fascinantes. Idealmente, você começará a trabalhar com pessoas que se encaixam em seus pontos fortes, enquanto ainda lhes oferece a chance de trabalhar com suas fraquezas de maneiras que não desabilitem a produtividade da equipe.

A melhor estrela de ouro da liderança de equipes é conscientizar as pessoas de suas fraquezas, de forma que elas sejam motivadas e bem informadas o suficiente para começar a corrigi-las.


2

Sente-se e discuta sobre as tecnologias e os conjuntos de ferramentas com os quais todos da equipe concordam. Algumas pessoas podem ter mais experiência nas ferramentas acordadas do que outras na equipe; portanto, as que têm mais experiência devem estar dispostas e agradáveis ​​a compartilhar a experiência e o conhecimento com o resto.

Discuta, concorde, anote, modele e comunique os padrões (como convenção de nomenclatura, práticas recomendadas de codificação e estruturas de pastas).

Faça testes contínuos e regulares e verificação de controle de qualidade. Notifique a pessoa o mais rápido possível quando houver inconsistências.


2

Eu ia dizer 'convide a pessoa mais experiente da equipe para organizá-la', mas parece que você é essa pessoa.

Se você puder, divida o projeto em dois níveis. Camada de aplicação / camada de driver é uma boa divisão. Forme dois subgrupos dentro de sua equipe e torne uma pessoa em cada responsável por esse nível. Isso pode funcionar extremamente bem.

Resigne-se a isso. Você terá que revisar tudo o que eles comprometem, principalmente no início. Se tudo estiver indo bem, você estará observando o código. A revisão não demorará muito tempo e dará muita confiança para que as coisas estejam indo bem. Provavelmente, você descobrirá que alguém está usando semáforos incorretamente ou está escrevendo sua própria versão de uma função de biblioteca ou alguma loucura. Minha experiência é que você deve estar observando o código enquanto ele está sendo escrito para resolver problemas de código pela raiz.


Concorde com a parte da revisão do código. Você deve orientá-los o mais cedo possível.

2

O que normalmente é esperado de um líder técnico em sua empresa? Sou gerente e já estive neste local algumas vezes e estou prestes a fazê-lo novamente a partir desta semana (contratação de novatos e outros para ingressar em uma equipe de 20 e 4 anos de pessoas experientes).

Sou gerente e posso ser um líder técnico (nos últimos anos, desempenhei o último papel de aumentar a liderança dentro da equipe. De qualquer forma, alguns pensamentos:

  • Avalie habilidades e fraquezas de toda a equipe.
  • Crie um plano de crescimento - Enquanto seu foco é aumentar os membros mais fracos, você realmente deve se concentrar em aumentar todos como indivíduos e como equipe.
  • Comunique esse plano e defina as expectativas de todos.
  • Distribua o aprendizado e a validação em toda a equipe. Embora você, como líder, seja meu compartilhador do trabalho, distribuir o trabalho ajudará os membros mais graduados da sua equipe a liderar.
  • Crie um ciclo de feedback regular. Reúna-se com os membros da equipe para avaliar o progresso e fornecer feedback.
  • Ajuste o plano, conforme necessário, para garantir o sucesso.
  • Se alguém não está malhando e não quer, mesmo com uma ajuda razoável, estar preparado para empurrá-lo. Isso é complicado, mas se você definir um plano, expectativas e fornecer um ciclo de feedback, estará em uma posição muito melhor para fazê-lo.
  • Fique de olho no moral da equipe. Esse tipo de situação pode fazer grandes coisas para formar uma equipe ou destruí-la. Suas habilidades de liderança e investimento na equipe farão um longo caminho para definir o resultado.

1

Tente analisar o que é necessário para definir uma "arquitetura de software". A criação de módulos desenvolvíveis separadamente é um dos principais motivos para a realização de análises e projetos iniciais. Eu sei que fazer esse tipo de trabalho está fora de moda, mas funciona em todos os casos, ao contrário de apenas alguns casos que os novos métodos de desenvolvimento defendem.


1

Como o desenvolvedor mais experiente da equipe, eu esperaria do seu treinamento pesado .

Deixe a equipe atribuir trabalho a si mesmos usando o kanban e depois passe o dia inteiro fazendo a programação em pares com cada um deles.

Quando vir um mau hábito ou algo que eles devam (todos) estar cientes, pare tudo e desenhe no quadro branco.

Depois de algumas semanas, você poderá desacelerar o treinamento pesado, pois as habilidades gerais da equipe se aproximarão das suas.


1

Há algumas listas diferentes que eu ficaria tentado a analisar a partir de sua posição:

  1. Quão bem eu conheço essa equipe. Você conhece os pontos fortes e fracos de todos na equipe? Você sabe como tirar o melhor proveito de cada pessoa? Você sabe como dividir o trabalho de uma maneira relativamente justa para todos? Esses tipos de perguntas são algo a fazer e entender que pode haver mudanças nessas listas ao longo do tempo, pois algumas pessoas podem desenvolver algumas habilidades que podem mudar a forma como são vistas. Quando você foi nomeado, havia expectativas que alguns da equipe tinham de você? Essa última pergunta pode ser difícil de convencer as pessoas a responder honestamente, mas pode ajudar muito se isso puder ser divulgado e discutido de maneira significativa sem provocar ofensa ou ressentimento, o que pode ser bastante fácil se o que estiver sendo discutido for muito pessoal para alguns. pessoas. Não tente obter opiniões pessoais em uma reunião de grupo,

  2. Quão bem eu me conheço. Quais elementos do seu histórico você está usando para reivindicar alguma autoridade técnica aqui? Quais pontos fortes e fracos você traz para a equipe? Você deve entrar nas trincheiras regularmente? Existem práticas que você já viu que gostaria de apresentar a essa equipe para ajudar a orientá-las? Existem sinais de aviso que você lembra de experiências passadas que podem ser úteis para ver se algum deles está começando a aparecer no trabalho que a equipe está fazendo.

De certa forma, tudo se resume à comunicação. Boa sorte!


0

faça uma apresentação regular (semanal) de algum tópico técnico e faça-o girar em torno do grupo. Dessa forma, todos aprenderão alguma coisa. E deixe os membros mais jovens presentes também, não há melhor maneira de realmente entender algo do que ensiná-lo. Você pode ter que ajudá-los a escolher tópicos.

Alguns treinamentos sobre como dar uma palestra podem estar em ordem para todos. Eu tinha um professor na faculdade que fez isso por mim e foi muito útil.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.