Como convencer meus colegas de trabalho que fazer as coisas corretamente economizará tempo

Recentemente, comecei em uma nova empresa, com um punhado de programadores. É uma empresa de médio porte, com cerca de 70 funcionários, mas a TI possui apenas 9 a 10 e existem 3 "programadores" fora de mim. No entanto, esses caras têm uma experiência muito limitada e estão fazendo muitas coisas terrivelmente. Por exemplo, um de nossos projetos é um site PHP. A maioria do código é armazenada em um controlador PHP de 20.000 linhas, com ~ 6000 linhas de JavaScript incorporadas no PHP.

Eu continuo fazendo pequenas sugestões aqui e ali, mas ninguém está ouvindo, todo mundo diz que está ocupado demais para implementar minhas sugestões. O problema é que eles não deveriam estar tão ocupados e não estariam se as coisas fossem feitas corretamente. Eles passam a maior parte do tempo consertando coisas que continuam quebrando. Se cada projeto fosse construído corretamente, eu poderia fazer tudo sozinho.

Que abordagem devo adotar para convencer esses caras ou o gerente de que as coisas precisam mudar e que mudar as coisas vai economizar um monte de tempo? Devo deixar de tentar convencer meus colegas de trabalho e ir direto ao gerente, com uma proposta comercial de como a empresa economizará muito dinheiro se começarem a fazer as coisas corretamente?

Descobri que a principal causa do trabalho desleixado, fora do programador simplesmente não se importando, é a falta de conhecimento. Infelizmente, em muitos ambientes, a falta de conhecimento é menosprezada do que discutida abertamente.

Algumas técnicas que usei com sucesso para promover discussões, crescimento e entusiasmo geral sobre programação são:

• Sessões semanais de tecnologia de malas marrons (peça-lhes que pesquisem um tópico e um presente).
• Sessões diárias ou semanais de mentoria entre os membros júnior e sênior.
• Revisões de código (com ênfase na aprendizagem, sem apontar erros).

Aprender é contagioso. Quando você promove um ambiente que incentiva o aprendizado, você não apenas produz melhores desenvolvedores, mas mostra aos outros da sua equipe que eles fazem parte de algo maior do que uma maneira de receber um salário.

Ao ver que você foi contratado como desenvolvedor Sr. PHP e seu trabalho é consertar as coisas, sugiro que seja hora de flexionar um pouco os músculos.

Se eu estivesse no seu lugar, faria uma boa pesquisa do código e veria os erros que estão acontecendo repetidamente. Bloqueie o horário das reuniões toda semana para discutir essas coisas com a equipe. Não aponte dedos ou nomeie nomes, apenas mostre como fazer essa tarefa corretamente.

Em seguida, como você já viu as necessidades de correção, faça uma lista. Se for rápido e fácil, faça. Se isso facilitar sua vida, faça-o ... faça-o. Faça uma lista de todas as coisas que precisam ser feitas e faça ingressos para elas e veja quando as pessoas têm ciclos para fazê-las. Se alguém estiver corrigindo um bug em uma área problemática, ensine como corrigi-lo corretamente.

Se exigir uma grande mudança, sente-se com a equipe e as partes interessadas e discuta as opções.

Tenha uma política de portas abertas para ajudar as pessoas. Seja alguém que educa e não intimida. Não, "você tem que fazer dessa maneira" e mais "seria melhor se fosse feito dessa maneira". Explique as vantagens de fazê-lo da maneira que você sugere e as desvantagens de como isso foi feito. As pessoas estarão mais dispostas a fazê-lo da maneira certa, se sentirem que aprenderam alguma coisa, em vez de serem informadas de que seu caminho está errado e fazê-lo de outra maneira porque você diz isso.

Perspectiva da gerência sobre o problema Se eles aceitaram o tempo de desenvolvimento em relação à quantidade de defeitos, por que eles arriscariam? Quando os benefícios a longo prazo contradizem os objetivos a curto prazo, eles geralmente perdem. Você está pedindo que eles dêem um pequeno passo para trás. Eles podem pensar que isso causará um longo atraso. Você precisa convencê-los de que não vai junto com os benefícios adicionais. Se eles não acham que estão bagunçados, peça que expliquem por que demora tanto para introduzir rapidamente novos bugs a cada "correção".

A qualidade do código depende de muitas circunstâncias e situações. Vendas, marketing e gerentes farão com que você acredite em todos os prazos que falharem, o que significa que a empresa perderá aquela chance de atingir o mega-milhão de investidores em capital de risco. A realidade é que eles não querem divulgar as más notícias a 1% dos seus clientes que realmente não precisavam do recurso. Estou sendo extremo e, geralmente, fica em algum lugar no meio, então os desenvolvedores precisam aprender o que é uma emergência real. Então é mais fácil convencê-los a dedicar tempo para fazê-lo corretamente, em vez de precisar de tempo para fazê-lo novamente. Você tem que entender os riscos.

Como um grande romance, o código não é bem escrito da primeira vez, mas infelizmente ainda é publicado com muita frequência. Comece com algo fundamental como estabelecer um padrão de codificação. Todo mundo tem um, mas muitos como na sua situação, eles não foram formalizados nem são muito rigorosos. "Faça o que você quiser." é um padrão muito fácil de manter. O próximo passo é determinar como você manterá seus padrões.

Você tem uma grande tarefa pela frente. Talvez alguns grandes programadores tenham desenvolvido suas habilidades e hábitos a ponto de nunca comprometerem a qualidade de seu código ou se endividarem, mas esperem e vejam o que acontece quando esse investidor anjo promete que todos ficarão ricos.

Sente e escreva o protótipo (ou algum módulo, se todo o projeto for muito grande), que usa um design muito bom, conforme você achar melhor. Em seguida, apresente / discuta com a equipe. Pode ser mais fácil convencer pelo exemplo.

Nesse processo, você também pode descobrir que algumas ferramentas, bibliotecas, abordagens ou similares não são tão boas. Sempre avalie primeiro e peça à sua equipe para usá-lo mais tarde. Cuidado com o marketing barato em torno de ferramentas precárias.