Lidando com programadores inflexíveis

Às vezes, programadores que trabalham em um projeto por muito tempo ficam inflexíveis e fica difícil argumentar com eles. Mesmo se conseguirmos convencê-los, é improvável que eles implementem nossas sugestões.

Por exemplo, ingressei recentemente em um projeto em que o processo de compilação e liberação é muito complicado e apresenta obstáculos desnecessários.

Sugeri que nos livássemos de algumas das despesas gerais de desenvolvimento (como preencher algumas planilhas) apenas integrando ferramentas de gerenciamento de defeitos e controle de versão (ambas são ferramentas IBM-Rational, para que a integração possa ser um esforço único e muito fácil). Além disso, se usarmos ferramentas como Maven & Ant (o projeto envolve Java e alguns produtos COTS), a compilação e a liberação podem ser simplificadas, o que deve reduzir erros e intervenções manuais.

Consegui convencer os outros e estou pronto para fazer um esforço para desenvolver uma prova de conceito. Mas o desenvolvedor 'Sênior' não está disposto, possivelmente porque o processo atual o torna mais valioso.

Como lidamos com essa situação sem desenvolver atritos na equipe?

Você é o novo membro da equipe e deseja alterar alguns aspectos fundamentais de como a equipe funciona. Boa sorte, sinto uma equipe feliz no seu futuro.

Ok, alguns conselhos práticos:

Prove-se para a equipe. Você precisará fazer isso de uma perspectiva técnica e de confiabilidade. Se você quer que as pessoas o sigam, você precisa dar um motivo para isso.

Entenda o histórico da metodologia. Por que isso existe? Que problema estava resolvendo na época? Verifique se a sua solução é realmente um benefício para a equipe. Talvez suas alterações sejam melhores, mas elas podem não resolver o problema da equipe.

Conheça seus obstáculos. Descubra as razões de sua resistência e trabalhe nesses itens.

Se você deseja ser um agente de mudança, aprenda como ser um agente de mudança bem-sucedido . Dezenas de livros e outras fontes disponíveis para lhe fornecer muito mais informações do que você encontrará aqui.

E sim, desejo-lhe boa sorte. Mas por favor, pelo bem da sua felicidade e da felicidade de sua equipe, seja esperto. Seu desejo de mudar o processo, sem investir energia para criar o caminho certo, pode causar muito mais mal do que bem.

Eu estive na posição que você mencionou. Passei anos como desenvolvedor Java e, eventualmente, fui para um trabalho em que todos estavam usando Smalltalk. Minha primeira reação foi "OMG, eles estão usando essa tecnologia antiquada" e comecei a tentar resolver problemas específicos do Smalltalk com soluções Java. Só posso imaginar como devo ter sido uma dor de cabeça para os outros desenvolvedores e eles odiavam o Java com paixão.

Não foi até que recebi um projeto de tamanho médio para trabalhar enquanto fui orientado por dois desenvolvedores seniores ao longo de alguns meses que comecei a entender o idioma do Smalltalk e a aprender a gostar dele. Desde que deixei esse trabalho e voltei a fazer o desenvolvimento Java, me sinto muito mais flexível, pois posso pegar um projeto e implementá-lo em qualquer linguagem que a empresa use. O principal para que essas pessoas entendam é que a linguagem nada mais é do que o meio. Eu também tomei um tempo para me ensinar Lisp e Erlang, mas isso pode não funcionar com todos.

Como estratégia de formação de equipe, recomendo o Seven Languages ​​in Seven Weeks para as pessoas com quem você está tendo problemas.

Eu acho que também se resume a quanto tempo essas pessoas estão dispostas a investir para se tornarem mais flexíveis. O problema com a maioria das universidades (pelo menos as que eu já vi) é que elas são direcionadas a um idioma específico e seus alunos se tornam 'institucionalizados' como você mencionou. Eu acho que parte da sua estratégia deve ser cultivar flexibilidade em sua equipe. Isso pode ser complementado com o desenvolvimento orientado a domínio .

(1) Modele um domínio (simples) (2) Implemente-o usando duas linguagens diferentes (por exemplo, Java e Lisp)

Novamente, isso pressupõe que eles estejam motivados para fazer o que precede e que estejam dispostos a investir seu próprio tempo para conseguir isso.

Espero que isto ajude

Eu posso estar no caminho totalmente errado aqui, mas parece-me que os mesmos problemas são comuns em uma escala mais ampla e se relacionam ao conservadorismo humano. As pessoas geralmente se recusam a mudar os padrões de comportamento conhecidos, por razões que são numerosas demais para mencionar.

Sendo um desenvolvedor russo (e, portanto, vendo menos pragmatismo ocidental racional), vejo o raciocínio prático muito menos convincente do que tentar andar no lugar de outra pessoa.

Em outras palavras, você mencionou que o programador sênior valoriza sua própria posição relacionada ao esquema de trabalho atual. Talvez você deva convencê-lo de que a nova maneira de fazer as coisas tornará sua posição ainda mais valiosa, e existem muitas maneiras de fazê-lo. Por exemplo, você pode fazê-lo pronunciar sua ideia e obter crédito por ela, ou você pode encontrar um ponto específico no processo que ele possa controlar exclusivamente etc.

Acredito que ser flexível fora das vantagens aparentes da sua ideia poderia ser seu feitiço aqui.

Consegui convencer os outros e estou pronto para fazer um esforço para desenvolver uma prova de conceito. Mas o desenvolvedor 'Sênior' não está disposto, possivelmente porque o processo atual o torna mais valioso.

Em vez de lançar aspersões sobre o personagem do desenvolvedor sênior (má jogada), talvez você deva tentar entender por que ele não está entusiasmado:

• Talvez ele pense que você é uma daquelas pessoas que exageram nas idéias. Talvez ele duvide que você possa cumpri-los.

• Talvez ele pense que você está exagerando nos problemas. (Eles não podem ser tão ruins ...)

• Talvez ele pense que você não entende completamente os riscos técnicos.

• Talvez ele pense (sabe) que há coisas mais importantes a fazer agora.

• Talvez você apenas o esfregue da maneira errada.

Meu conselho seria provar a si mesmo para ele. Como entregando os projetos que você realmente recebeu. Quando ele confiar mais em sua capacidade e julgamento, revisite esse assunto.

Se você deseja seguir a linha "melhoria de processo" agora, meu conselho seria fazê-lo lentamente, em pequenas etapas.

Lembre-se de que, sem dúvida, existe o risco de que as alterações propostas tenham um impacto maciço na produtividade do seu grupo e até na capacidade delas de manter o software existente. Se isso acontecer, é provável que o responsável receba o máximo de críticas da gerência sênior.

Institucionalizado sobre o que em particular? Tecnologias, padrões, práticas?

Se eles estão na organização / projeto há muito tempo, é provável que sejam desenvolvedores seniores e tenham a responsabilidade / experiência para fazer essas ligações, e tenham tido experiências no projeto, em vez de serem condicionados como o experimento dos 5 macacos .

A solução para convencê-los dependerá de qual é o assunto, pois se um padrão / tecnologia já for escolhido, haverá uma boa razão e terá que haver uma melhor razão para mudar para justificar jogar fora o trabalho e se familiarizar, etc. ., se assim for, uma solução é para um arquiteto / desenvolvedor sênior organizando uma reunião para decidir democraticamente a melhor solução.

Se a equipe realmente tiver obstáculos desnecessários, provavelmente ficará muito feliz em ajudá-los a corrigi-los. Note, no entanto, que pode haver uma boa razão para eles estarem lá, e você parecerá estúpido se tiver que dizer "oh, bem, minha ideia fantástica não funciona então" depois de vendê-la a todos por um longo tempo.

Investigue primeiro e depois avance. Observe também que ser capaz de MOSTRAR como você sugere a melhoria é muito melhor do que a navegação manual.

Estou inclinado a dizer que é você quem é o "Programador Inflexível". Você é novo no projeto, mas insiste em que sua idéia é a melhor e o cara que lidera o projeto, que já faz mais tempo e conhece o sistema por dentro e por fora, está fora de controle.

Sou bastante experiente, bem conceituado e sou frequentemente designado para consertar projetos difíceis como membro de uma equipe de tigres. Mesmo assim, ainda dedico um tempo para aprender como, por que, dinâmica da equipe, o projeto e suas práticas, sem entrar em detalhes e dizer a eles como isso e aquilo estão errados. Na verdade, nunca digo que o que eles estão fazendo está errado, porque isso não obtém a resposta que eu quero e, geralmente, o que eles estão fazendo não está errado, só precisa de alguns ajustes.

Cada projeto é único. Cada equipe é única. Sua solução pode ser melhor para você e os desenvolvedores, mas pode não ser melhor para o líder, o cliente, o negócio ou o projeto, mas como você não tem experiência com o projeto para conhecer melhor, não saberia a resposta para isso.

A melhor maneira de levar as pessoas a fazer o que você quer é fazê-las pensar que tudo é idéia delas. Então, em vez de fazer sugestões diretamente, apresente opções. Se suas idéias são claramente melhores do que as alternativas, dê ao desenvolvedor sênior a chance de selecioná-las e torná-las suas. Não se preocupe em obter crédito. As pessoas que importam saberão o que está acontecendo.