Minha experiência é que as equipes de desenvolvimento (mas em geral, qualquer equipe) consistem em 3 tipos de pessoas:
- aqueles com uma unidade interna de qualidade,
- aqueles que estão apenas nele pelo dinheiro (cerveja / garotas / o que for) e não se importam menos, no entanto, você tenta motivá-los,
- os "medíocres" (por falta de uma palavra melhor).
O último grupo é o maior e eles tendem a seguir o partido no poder. Se houver pessoas de qualidade suficientes na equipe, elas poderão atrair a maioria consigo mesmas, criando uma forte espiral ascendente no espírito e na motivação da equipe. No entanto, se houver muitos preguiçosos, eles podem facilmente criar o efeito oposto, uma espiral da morte.
Portanto, a principal tarefa do gerente é escolher e manter as pessoas certas e livrar-se das pessoas ruins o mais rápido possível . Porém, não os "medíocres" - eles podem ser influenciados a começar a melhorar, a apoiar as boas idéias dos outros, e alguns deles podem até se tornar criadores de tendências positivos por si mesmos.
[Update2] refletindo sobre a resposta de Alb : Na IMO, não há necessidade de os desenvolvedores de qualidade estarem na maioria clara da equipe (embora isso não doa :-). Existe um "limiar de definição de tendências" , acima do qual as visões e o comportamento de um subgrupo podem rapidamente se tornar o "mainstream" dentro de uma comunidade , para que outras pessoas notem e comecem a seguir. Você pode ver isso no trabalho da sociedade em geral o tempo todo (por exemplo, hábitos (não) de fumar, saúde e dietas, moda passageira, comida orgânica). Minha estimativa muito aproximada é que pode estar entre 25 e 30%, mas depende de muitos fatores. É aqui que as pessoas más podem machucar muito. Até algumas pessoas más da sua equipe podem aumentar esse limite significativamente. [/ Update2]
Claro que nem sempre é possível contratar o suficiente dos melhores. Portanto, quando a primeira facção não é forte o suficiente para conduzir as coisas por conta própria, a gerência precisa ajudá-las. Algumas reflexões sobre isso:
Eu acho que o Scrum tem uma boa idéia para isso com demonstrações de produtos. Demonstrar o recurso que você implementou na frente de uma audiência que consiste não apenas de seus colegas de equipe, mas possivelmente de desenvolvedores de outras equipes, da gerência e até de usuários do aplicativo, pode ser uma enorme fonte de orgulho e também um forte fator para ajudar a equipe a se divertir.
Outra coisa é que a gerência ouça atentamente a equipe de desenvolvimento em relação à qualidade. DeMarco e Lister até mencionam que existem empresas / departamentos em que as equipes de desenvolvimento têm veto sobre o que pode ser produzido. Se eles acham que o aplicativo ainda não está pronto para o horário nobre, eles podem adiar o lançamento, independentemente do que a gerência gostaria. Agora isso é difícil para a gerência, mas posso imaginar que ela cria espírito de equipe e comunica fortemente a mensagem de que a qualidade é realmente importante aqui, não apenas no nível das palavras.
Isso leva ao próximo ponto: para criar um "culto à qualidade", o gerenciamento deve entender completamente o que os desenvolvedores mais experientes já sabem: que a qualidade não é uma reflexão tardia - ela deve ser incorporada ao produto desde o início. Portanto, as pessoas devem ser encorajadas a (e recompensadas por!) Pensar em manutenção de longo prazo, buscando as boas soluções, em vez das rápidas .
Atualizar
@Machado em seu comentário deu uma nova reviravolta à pergunta (pelo menos para mim):
O que eu, como membro da equipe, não como gerente, posso fazer para melhorar a qualidade do código da minha equipe?
Algumas reflexões:
- Continue aprendendo e espalhe o conhecimento para quem ouve. Aprenda e use as melhores práticas em suas áreas de especialização.
- Orgulhe-se do seu trabalho .
- Esses dois quase naturalmente permitem que você se torne um modelo positivo para os outros - especialmente os novatos e os juniores -; tenha consciência disso e alavanque seu papel para o benefício de toda a equipe. A melhor maneira de influenciar os outros é por exemplo positivo.
- Observe não apenas o código, mas todo o processo de desenvolvimento de software; continue fazendo perguntas e fornecendo feedback para otimizar o processo de desenvolvimento .
E por último mas não menos importante: encontre um lugar onde você possa ser um "cara de primeira" . Se você está no grupo "medíocre" agora, lute para se desenvolver - espero que as idéias acima ajudem nisso. Mas se você estiver nos "estratos mais baixos" da sua equipe atual, recomendo que você analise os motivos. O que é que te desmotiva? Más condições de trabalho? Companheiros de equipe? Gestão? Tipo de trabalho? E o que é que te excita e interessa? Você pode precisar conversar com seus colegas de trabalho e / ou chefe sobre isso. Ou talvez você precise procurar um emprego melhor - ou até uma nova profissão - onde possa começar a brilhar. Realmente não vale a pena gastar uma parte significativa da vida com atividades insatisfatórias ou deprimentes.
Também pode ser que você seja forçado a continuar seu trabalho atual, abaixo do ideal, devido a fatores externos (falta de melhores oportunidades de trabalho, necessidade de pagar as contas etc.) - isso acontece de vez em quando. Mesmo nesse caso, tente tirar o melhor proveito disso. Produzir um trabalho de qualidade (tanto quanto as circunstâncias o permitirem) é uma recompensa em si, que ajuda a manter sua auto-estima elevada e a manter-se são e abertos a longo prazo. Assim, quando uma oportunidade para algo melhor aparecer, você estará melhor preparado para aproveitá-la.