O que fazer como desenvolvedor quando há anos sua equipe carece de inovação de produto, não usa metodologias de gerenciamento de projetos e mantém práticas ruins de desenvolvedor de software? [fechadas]

Estou interessado em saber como lidar com um processo atual de desenvolvimento de software que não foi alterado por anos e acabará por levar à falha do produto e da equipe. Sim, provavelmente a maneira mais fácil de resolver isso é mudar de emprego, mas com essa economia é mais fácil falar do que fazer. No entanto, se você possui exemplos específicos e já viu ou esteve várias vezes na mesma situação e acha que a melhor solução para resolver esses problemas é sair da empresa, apoie sua resposta. O ponto é que essa pergunta realmente tem uma resposta, especialmente se vários especialistas no assunto acabarem indicando que o melhor caminho a seguir é: rota A.

Eu sei que muitos desenvolvedores estiveram ou estão em situações semelhantes. Essa é uma das principais razões pelas quais as empresas deixam de ser a número 1 no mercado e se tornam as últimas ou mesmo fora do mercado. Esperamos que as respostas neste post ajudem outros desenvolvedores a enfrentar obstáculos semelhantes. Em uma equipe de desenvolvimento pequena ou grande, isso geralmente acontece:

• Alguns desenvolvedores parecem não se importar e decidem seguir o fluxo e preferem deixar o código com muito cheiro do código e o processo de desenvolvimento como está,
• Outros se cansam de nenhuma mudança, renunciam e se mudam para outra empresa,
• Outros parecem ter medo de conversar e preferem ficar calados,
• Às vezes, muito poucos desenvolvedores ou apenas um tentam defender a melhoria do produto e informam à equipe a importância de seguir as melhores práticas de codificação e os benefícios de fazê-lo para clientes, usuários e equipe. Esse tipo de desenvolvedor geralmente decide ficar com a equipe devido a razões como a empresa oferece benefícios que poucas empresas oferecem, ou o produto tem muito potencial etc.

O produto em nossa equipe é apenas uma fração de onde a empresa obtém sua receita, pois possui um guarda-chuva de produtos (esta empresa não é uma empresa de software / hardware; portanto, não há litígios constantes de patentes, pelo menos por enquanto, o que cria empregos instabilidade). O que aprendi até agora durante esses anos com as experiências de outros desenvolvedores e minha experiência é que, para conhecer realmente uma equipe de desenvolvimento, leva tempo, não dias, nem semanas, mas alguns meses. Durante o processo de entrevista, se a equipe quiser contratar você ou precisar de você; eles fazem tudo parecer ótimo e podem dizer o que você quer ouvir. No entanto, a realidade é diferente quando você começa a trabalhar nessa equipe e começa a se aprofundar no código e a avançar para o processo completo do SDLC. É quando, como desenvolvedor, você começa a ver a realidade do trabalho em que se envolveu. Essa realidade dificulta a mudança de uma empresa para outra, porque é difícil saber se a empresa para a qual você se muda será melhor ou pior. Sim, você pode ler as opiniões do Glassdoor etc., mas quantas dessas avaliações on-line são reais e não do RH?

Qual seria a melhor maneira de resolver os problemas descritos abaixo, considerando que o gerente desde o início sempre resistiu à mudança e os desenvolvedores anteriores fazem o mesmo há anos?

• Falta de inovação do produto há anos: o produto tem muito potencial e gera uma boa receita para a empresa, mas parece que o produto foi produzido há 20 anos. Alguns usuários reclamaram que o produto não é amigável nem intuitivo, e outros mencionaram que estão acostumados a aplicativos como o Gmail e ficam frustrados ao usar o produto por não terem recursos semelhantes. O principal problema aqui é que, quando você tenta, como desenvolvedor, fazer alterações no produto e começar a mover os principais elementos do produto a apenas alguns pixels de distância (para torná-lo mais amigável ou intuitivo), o gerente entra em pânico e informa colocá-lo de volta onde estava. Se você tentar adicionar um recurso que beneficiará a produtividade dos usuários, o gerente solicita que você o remova por causa de "os usuários estão acostumados a fazer o processo do jeito que está, etc." Acho que você entendeu a resistência à mudança, à melhoria e à inovação (o gerente não está aberto à mudança, mesmo quando você, como desenvolvedor, fornece fortes argumentos de benefícios). A empresa possui alguns concorrentes em campo (os produtos de alguns deles são muito mais competitivos), mas de alguma forma a empresa mantém os clientes atuais há anos.

• Falta de coordenação de gerenciamento de projetos: como resultado disso, alguns projetos são entregues com atraso, com bugs e alguns clientes reclamam (os clientes relatam os bugs também) ou o orçamento é usado muito rápido antes da entrega do projeto etc. algumas dicas de coordenação de projetos e as idéias agora estão sendo usadas regularmente para rastrear o progresso dos projetos e tarefas a serem realizadas.

• Práticas inadequadas de desenvolvimento de software: O cheiro do código é visto na maioria, se não em todos os arquivos, sem documentação, redundância de código, camada de front-end e back-end misturados no mesmo arquivo, ferramentas de desenvolvimento desatualizadas, sem ambiente de teste real nem ferramentas de teste (basta copiar e colar arquivos do ambiente de desenvolvimento à produção e, em seguida, teste manualmente se as coisas parecem boas e liberam). A maioria das ferramentas de desenvolvimento que eu uso para desenvolvimento e teste é desconhecida pela equipe, pois a equipe usa apenas 2 IDEs para desenvolvimento de código e controle de origem, apenas disponível para o ambiente de desenvolvimento. Outros desenvolvedores tentaram usar as estruturas mais recentes para melhorar os problemas atuais, mas o gerente não gosta disso por causa de "e se você sair, quem manterá esse código ?, vamos deixar do jeito que está" Alguns desses desenvolvedores já saiu e mudou-se para outras empresas.

Em resumo, tenho certeza de que situações semelhantes acontecem a muitos desenvolvedores de outras empresas, mas devido a circunstâncias diferentes, um desenvolvedor pode preferir permanecer na equipe do que ir para outra empresa por razões como (conveniência do trabalho, flexibilidade no trabalho, benefícios da empresa ou apenas porque não chegou uma oportunidade melhor). Não tenho uma empresa perfeita que eu conheço, mas como você, como desenvolvedor, se comportaria e abordaria todas essas questões para manter as coisas positivas e, finalmente, promover mudanças para melhorar o produto e melhorar o processo de desenvolvimento de software (se você tem muitos anos de experiência em desenvolvimento ou apenas alguns)? Eu sei que este post é longo, mas eu preferi dar detalhes extras para aumentar as chances de obter feedback mais útil.

Muito obrigado por todos os seus comentários e tempo

A citação de Martin Fowler é relevante: "Você pode alterar sua organização ou sua organização". Dado que você aparentemente decidiu mudar sua organização (melhorá-la) em vez de mudar sua organização (trabalhar para uma organização diferente), aqui estão algumas sugestões.

Primeiro, grande parte do seu curso de ação depende de detalhes sobre as estruturas de poder e a política em ação. Existe um gerente de desenvolvimento de software ou vários? Se vários, existem alguns que não são avessos à mudança? Quantos desenvolvedores de software existem? Os desenvolvedores estão interessados ​​em mudar? Nesse caso, existem algumas alterações que você deve poder fazer mesmo sem a aprovação da gerência. (Como sugere Fowler em Refatoração , talvez você nem precise informar à gerência. Você provavelmente foi contratado para desenvolver o software da melhor maneira possível; portanto, se houver uma maneira melhor de fazê-lo, basta fazê-lo).

Segundo, lembre-se de que a gerência pode ter boas razões para o que está fazendo. Você é um desenvolvedor de software; seu trabalho é desenvolver um bom software e conhecer boas técnicas para fazê-lo. O trabalho da gerência é entender questões gerais e considerações de negócios que podem estar além do seu alcance. Mesmo que você esteja certo e errado sobre quais são as considerações de negócios (suas preocupações com falta de inovação, atraso na entrega, reclamações de clientes etc.), entender de onde vem a administração ajudará você a se comunicar nos termos deles, aliviar suas preocupações e assim por diante.

Terceiro (e relacionado), verifique se consegue falar o idioma dos negócios. Uma empresa (com razão) não está diretamente preocupada com boas práticas de desenvolvimento de software; uma empresa preocupa-se em atender às necessidades dos clientes e obter lucro. (E muitas empresas obviamente farão o atendimento mínimo das necessidades possível para obter lucro.) Você será mais eficaz na promoção de mudanças se puder explicar como as más práticas de desenvolvimento de software e a falta de inovação prejudicam o lucro da empresa ou a longo prazo. saúde.

Quarto, mudar a cultura de uma empresa da posição de trabalhador de classificação é extremamente difícil. James Shore (consultor e autor ágil) escreveu um Diário de Mudança descrevendo seus próprios esforços para fazê-lo. Eu recomendo fortemente a leitura da coisa toda. Alguns pontos relevantes:

• Não tente mudar tudo de uma vez. Encontre os maiores pontos problemáticos e comece por aí. Junte todos a bordo, ajudando-os a ver como suas alterações tratam desses pontos problemáticos.
• Entenda as perspectivas dos outros. Shore fala sobre como as mudanças que ele estava promovendo da perspectiva do desenvolvimento de software foram resistidas pelo gerente de projetos porque ele (Shore) não considerou como as mudanças afetariam o gerente de projetos.
• Eventualmente, você precisará de algum suporte de cima, mesmo se estiver solicitando a maioria das alterações. Shore fala sobre seu campeão ("alguém com quem trabalho que tem mais influência do que eu e pensa da mesma maneira que eu").

A resposta curta e óbvia é deixar a empresa. Outros já foram embora e seu gerente é um obstáculo ativo ao progresso. Se você permanecer nessa posição, decairá lentamente (tanto no moral quanto nas habilidades). Encontrar um novo emprego nem sempre é fácil, mas, neste caso, é necessário.

Apenas no caso de você optar por não sair da empresa (a primeira linha da sua pergunta meio que revelou isso):

Seu gerente tem um chefe? Se sim, como esse chefe vê o produto? Você pode (ouso dizer isso?) Passar por cima da cabeça do seu gerente e se aproximar do chefe dele? Não o incomode com detalhes técnicos, apenas expresse interesse e entusiasmo em crescer dentro da empresa. Apresente idéias tangíveis para melhorias que afetariam de maneira mensurável os resultados. Você pode ser promovido por baixo do obstáculo.

Porém, esteja avisado - enquanto algumas rodas estridentes se lubrificam, outras são substituídas. Você fará seu gerente não gostar muito de você. Ele vai ouvir sobre isso, e ele vai dizer coisas desagradáveis sobre você para o seu patrão. Pise com cuidado, mas lembre-se - sem risco, sem recompensa.

O pior que pode acontecer é que você esteja procurando um novo emprego, o que deveria estar fazendo de qualquer maneira.

Parece que é hora de você aprender sobre vacas em dinheiro. Vá aqui e aqui . E dê uma olhada na Matriz de compartilhamento de crescimento . O GSM fornece algumas informações adicionais sobre o motivo pelo qual a vaca leiteira é um bom estado.

A Investopedia (segundo link) provavelmente tem a melhor cotação neste caso.

1. Uma vaca leiteira requer pouco capital de investimento e fornece, de forma perene, fluxos de caixa positivos, que podem ser alocados a outras divisões da corporação. Esses geradores de caixa também podem usar seu dinheiro para recomprar ações no mercado ou pagar dividendos aos acionistas.

Como você observou, há algumas vantagens em estar em um projeto de vaca leiteira.

• É estável
• Um grau modesto de novo desenvolvimento é garantido
• Há sempre um trabalho de correção de bugs no combate.

E, como você também observou, existem algumas desvantagens nesses projetos.

• É estável e a base de código não muda muito
• As novas tecnologias geralmente são ignoradas (caras demais para serem usadas)
• E as coisas ficam ... velhas.

Certa vez, trabalhei em um projeto em que tive muitas queixas semelhantes às que você levantou. Lembro-me claramente de compartilhar minhas preocupações sobre a base de código com meu chefe na época. Seu insight não foi particularmente esclarecedor, então não vou compartilhá-lo. Mas destaquei o projeto e, verdade seja dita, foi um dos melhores projetos que já vi. Não, não era chamativo. Sim, perdemos os prazos. Sim, acumulei algumas marchas da morte de lá. Não, a tecnologia do código não era tão inovadora, mas geramos algumas soluções surpreendentes.

O problema era eu. Eu não tinha perspectiva suficiente para entender o que uma base de código realmente requer para sobreviver. Não tive a experiência de ver onde a inovação estava realmente ocorrendo. Não entendi os fundamentos do mercado que ditavam qual era o nível apropriado de financiamento para esse projeto.

Gostaria de encorajá-lo a ver isso como uma oportunidade de aprendizado para entender melhor como os negócios funcionam e como você pode melhorar suas habilidades na adaptação de um produto às necessidades dos negócios. Embora o trabalho não seja chamativo, o potencial de aprendizado é alto e essas habilidades o sustentarão mais tarde em sua carreira. A maioria do desenvolvimento no nível corporativo gira em torno de todas as restrições que você acabou de mencionar. O código fede; as coisas foram batidas no lugar para conter prazos que já haviam escapado; muitos desenvolvedores são resistentes à mudança.

Em algum momento, você ainda seguirá em frente no projeto. As lições que você pode tirar com você podem ser verdadeiras lições de carreira.

Seu gerente provavelmente é resistente a mudanças porque vê que nenhum valor (comercial) está mudando as práticas. A empresa não vê nenhum problema real porque tudo o que é solicitado à equipe de desenvolvimento acaba sendo feito e as reclamações dos clientes não chegam às pessoas que se importam e / ou podem fazer algo para garantir um melhor resultado. Ou isso ou a empresa passou a aceitar o estado atual das coisas como inevitável.

Se você vai mudar as práticas de desenvolvimento, precisa mostrar a elas que o estado atual das coisas não é inevitável. E a única maneira de você ser ouvido é construindo um caso de negócios que mostre como o estado atual das coisas está aumentando o custo do produto e retendo o potencial de receita, dado outro estado de coisas.

Para criar esse caso de negócios, você precisa conversar com o gerente de produto deste software. O gerente de produto é a pessoa que decide sobre a prioridade dos itens a serem desenvolvidos com base no valor comercial que eles representam. O gerente de produto é (deve ser) aquele que pode ver o benefício e o valor comercial de poder criar um software melhor mais rapidamente. (E espero que não seja o mesmo responsável pela equipe de desenvolvimento.)

O business case precisa abordar quais são os efeitos na receita comercial de:

• Recursos que ainda não foram implementados que gerariam mais clientes ou reteriam mais clientes, caso tivessem sido implementados.
• Recursos inadequadamente implementados que geram insatisfação do cliente e levam a atrito nos clientes.

O business case também precisa mostrar como as práticas atuais de desenvolvimento estão afetando a velocidade e o custo do desenvolvimento dos recursos muito necessários:

• Quanto tempo leva para fazer as alterações mais simples.
• Quantos erros foram introduzidos como resultado do desenvolvimento de novos recursos, tanto no novo recurso quanto em danos colaterais em outros recursos.
• Quanto tempo leva para consertar esses bugs que não podem ser gastos na implementação de novos recursos.
• Quantas chamadas de suporte são geradas devido a esses bugs e quanto pessoal de suporte precisa gastar nessas chamadas.

E, é claro, precisa mostrar como a adoção de melhores práticas de desenvolvimento afetará esses números.

Você provavelmente está enfrentando a necessidade de reescrever (principais) partes (principais) do software. Mesmo se não o fizer, então Como sobreviver a uma reescrita do zero sem perder a sanidade é uma leitura obrigatória sobre como abordar esse tipo de projeto.

Nota final: se o gerente de produto não estiver interessado em tudo isso, você estará perdido: saltar de navio.

Eu acho que esse é um problema muito difícil, sem solução direta. Aqui estão algumas idéias sobre o que você pode tentar fazer:

Medo da mudança No que diz respeito a mudar as coisas para melhor, entendo por que os medos da administração mudam. As pessoas estão acostumadas às coisas de uma certa maneira e, se você mudar, os usuários se revoltarão (talvez). Mudar é algo assustador e geralmente requer muito pensamento e estudo antes de ser feito. O que você precisa são dados para mostrar que isso é melhor e que os usuários querem. Por falar em gmail, você pode pensar em fazer algo como "Google Labs", onde você pode ativar / desativar novos recursos para que os usuários possam experimentá-los. Em seguida, conecte alguma coleta de dados para ajudar a fazer backup de suas alterações.

Mudando o processo de desenvolvimento de software Novamente, mudar é difícil, as pessoas não mudam porque você diz que há uma maneira melhor. Penso que, neste cenário, a minha melhor recomendação é dar o exemplo. Faça as coisas da maneira que você deseja que sejam feitas e mostre às pessoas o quanto elas são melhores. Além disso, e isso é fundamental, você precisa encontrar os outros que compartilham seus pensamentos. Se você conseguir reunir algumas pessoas, isso ajudará muito sua causa. Depois de mostrar alguns resultados, você poderá abordar o gerenciamento sobre como tornar essas alterações mais amplas. Acho que um esforço de cima para baixo e de base realmente ajuda a fazer mudanças.

Também no lado das ferramentas, as empresas temem atualizá-las / alterá-las porque custam dinheiro e os resultados de novas ferramentas nem sempre são mensuráveis. Minha recomendação aqui é fazer suas próprias ferramentas. Se você se dedicar, economizará tempo e fará um trabalho melhor. Espero que as pessoas comecem a perceber e queiram usá-las também.

Mudar a gestão Isso é difícil e não sei como fazê-lo, além de ser alguém que produz resultados e tem sua opinião valorizada. Uma vez que sua opinião é valorizada, as pessoas podem começar a ouvir ou não.

Por fim, lembre-se de que a mudança é difícil e leva tempo. Aguente firme e comece pequeno e construa.