Como criar um "culto à qualidade" [fechado]

DeMarco e Lister (Peopleware) sugerem que você crie um "culto à qualidade" dentro de sua equipe de programação. Frustrantemente, eles não sugerem como você faz isso!

Alguém tem alguma idéia de como fazer isso?

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.

Ótima resposta de Péter Török para destacar que você só gerenciará isso com a maioria das pessoas boas. Depois de ter boas pessoas, você precisa mirar mais na abordagem da cenoura do que na vara. Capacite os desenvolvedores, permita que eles tomem posse de projetos / tarefas e incentivem a concorrência em termos de qualidade; talvez as pessoas façam breves apresentações sobre como eles melhoraram a qualidade nos projetos. Bons desenvolvedores serão motivados a impressionar seus pares.

Além dos comentários de Peter (que são realmente o principal problema), você precisa garantir que a qualidade não seja um recurso adicionado posteriormente.

Mais especificamente:

• Remova qualquer vestígio do pensamento 'Vamos limpar isso mais tarde'. Em vez disso, faça um esforço no começo para fazê-lo da maneira correta.
• Exija que as alterações sejam revisadas e trabalhadas através de algum tipo de processo de controle de qualidade envolvendo alguém que não seja o desenvolvedor.
• Forçar pensamentos sobre qualidade nas fases iniciais dos projetos. Mantenha coisas como "como é fácil com isso manter os outros" em foco durante o desenvolvimento.
• Acompanhe e relate os erros que ocorrem. Se houver tendências, procure maneiras de combater a causa raiz dos bugs.
• Introduzir o pensamento do software como uma arte que pode ser aprimorada e algo que os criadores podem se orgulhar.

Eu diria que a melhor maneira é incentivar a qualidade sobre a produção. Essa é uma das premissas do movimento Lean Software (baseado no Lean Manufacturing). Eu escrevi uma longa postagem no blog discutindo sobre o que é Lean . Eu digo a você como criar um culto à qualidade. Invista nos seus funcionários e deixe-os investir na sua empresa (não investimento monetário, mas sim um investimento pessoal).

Dan Pink fez uma ótima palestra no TED sobre o que nos motiva. Enquanto ele não faz referência específica. A hierarquia de necessidades de Maslow explica perfeitamente o fenômeno observado. Desde que o empregador atenda às duas primeiras necessidades (ou seja, pague dinheiro suficiente para que o dinheiro não seja um problema), tudo o que resta é pertencer, estima e auto-atualização.

• Forneça uma comunidade sólida para pertencer.
• Proporcione um ambiente em que o funcionário se sinta livre para cometer erros, a fim de obter estima quando realizar realizações.
• Entregue aos desenvolvedores as rédeas para que eles possam tomar decisões importantes para a auto-atualização

Qualidade não é algo que possa ser ditado ... mas sim ativado. Confie nos seus funcionários para fazer o melhor e sair do caminho. Eventualmente, você precisará dizer a eles que eles precisam sair. Em vez de pedir para eles colocarem mais horas