O que se pode fazer quando “liderar pelo exemplo” não funciona? [fechadas]

40

Tenho trabalhado para uma grande empresa (mais de 8000 funcionários) há quase dois anos e fui contratado logo após terminar meu curso.

Todo mundo aqui tem que lidar diariamente com o código legado, que muitas vezes é muito mal projetado e cheio de hacks. No início, eu mantive um perfil baixo, tentando não criticar muito as coisas. Mas a situação, como está, tornou-se muito difícil de conviver e parece que ninguém está disposto a melhorar / substituir as ferramentas que usamos.

Para ser mais explícito, temos:

  • Uma ferramenta de controle de origem obsoleta (Visual SourceSafe)
  • Makefiles antigos simples que suportam apenas reconstrução total
  • .def arquivos que devem ser mantidos manualmente e separadamente para todas as arquiteturas existentes
  • arquivos e projetos de cabeçalhos monolíticos com poucos arquivos diferentes (mas cada um tem cerca de 3.000 linhas de código, o que às vezes cuida de tarefas muito diferentes)
  • não há uso dos "novos" recursos de idiomas (bem std::string não é novo, mas ninguém, exceto eu, o usa)

Eu decidi, há alguns meses atrás, fazer algo sobre isso, projetando um novo ambiente de compilação. Eu poderia obter builds incrementais para trabalhar de forma confiável, tempos de compilação mais rápidos, projetos melhor estruturados, geração automática de arquivos .def . Eu até criei uma ponte de / para o Git para / do Visual SourceSafe.

Eu mostrei minhas conquistas para vários colegas e nosso chefe, mas era como se ninguém se importasse. Eles eram todos como "Bem ... as pessoas estão acostumadas a fazer dessa maneira agora. Por que nós mudaríamos as coisas?"

As alterações que sugeri foram projetadas para que pudéssemos ter uma transição suave do sistema antigo para o novo. Cada melhoria pode ser aplicada separadamente e com segurança.

Até tentei envolver alguns colegas de trabalho nas mudanças. Mas até agora, nenhum sucesso.

Você já enfrentou uma situação semelhante? O que se pode fazer quando "liderar pelo exemplo" não funciona?

    
por ereOn 27.01.2012 / 09:40
fonte

9 respostas

46

Apontar para o chefe : "Liderar pelo exemplo" deve ter a melhoria em mente, mas deve ser direcionado a pessoas que não estão na tecnologia. Talvez você tenha investido muito tempo na melhoria da tecnologia, mas não tenha tempo suficiente no que está acontecendo em suas cabeças. Pense nos fatores determinantes para que haja uma oposição a coisas novas. Em muitos casos, eles apenas temem algum risco. Identifique esses riscos e encontre contra-argumentos para eles.

Pegue a carne fresca : é mais fácil conquistar os funcionários que querem mudar as coisas. Você os percebe imediatamente quando os vê.

Evite a carne podre : Alguns nunca vão simpatizar com as suas ideias. Deixe-os de lado.

Cresça até uma massa crítica : encontre pessoas que simpatizam com suas ideias. Ganhe o mais um por um. Em algum momento, se uma massa crítica for atingida, mais e mais pessoas seguirão seu exemplo voluntariamente.

Vocabulário de gerenciamento : os gerentes não estão interessados em designs melhores. Sua linguagem é dinheiro e tempo. Deixe claro quanto tempo homem é desperdiçado por insetos. Deixe claro que os clientes insatisfeitos que encontrarem bugs não são lucrativos. Demonstre quanto mais rápido você pode implementar um novo recurso. Você precisa escolher outro vocabulário para os gerentes.

É tudo sobre processos : tecnologias melhores não fazem programadores e programas melhores. Se você tiver bons processos em execução, até mesmo tecnologias desatualizadas levarão a bons resultados. Pense nisso foram esforço e tempo é desperdiçado. Talvez não seja a tecnologia, mas algo nos processos está indo muito mal. Na maioria dos casos, é uma falta de comunicação.

Encontre uma nova empresa : Você já fez muito. Você ainda pode tentar melhorar as coisas, mas também depende de você decidir por quanto tempo quer experimentá-lo e quanta energia deseja investir. Tenha em mente: Mesmo que você não consiga obter muitas melhorias, aprenderá muito com seus esforços. Em algum momento você precisa seguir em frente.

    
por 27.01.2012 / 10:36
fonte
30

Você já parou para considerar que pode estar errado?

Então você lê alguns desenhos e padrões de livros na escola e você está privado de práticas que são comparativamente antiquadas onde você trabalha. Sem dúvida, são provavelmente ideias melhores e novos projetos devem começar com isso em mente, mas parece que você está em um nível completamente diferente.

Criadores de pastoreio é como tentar acasalar gatos, eles inerentemente têm uma mente própria e uma maneira preferida de fazer as coisas, seja certo ou não. Eu tenho bastante dificuldade em aplicar as melhores práticas e gerenciar uma equipe de 2 desenvolvedores, mas você trabalha para uma empresa com 8000.

Esse é um número assustadoramente grande. Mesmo uma simples alteração no processo, que determina que todos os desenvolvedores devem agendar reuniões e tempo fora do escritório no calendário público, torna-se uma política extremamente complexa e difícil de implementar em toda a linha. Isso também exigiria uma pressão significativa da administração para garantir que a política fosse aceita e adotada em toda a parte.

Você pode não pensar, mas algo tão simples como passar de monolítico para vários arquivos de cabeçalho, ou mover o controle de versão do SourceSafe para o Git requer um enorme esforço e investimento por parte de todos os envolvidos. Isso exigiria:

  • Suporte de gerenciamento significativo

  • Aceitação ampla da empresa

  • Investimento de horas de reunião para todos os desenvolvedores para informá-los sobre as novas iniciativas (reuniões custam horas de trabalho, horas de trabalho custam horas)

  • O treinamento precisa ser planejado e estabelecido para garantir que até os desenvolvedores mais estúpidos saibam o que estão fazendo

  • Mesmo assumindo uma hora de treinamento, entre 8000 desenvolvedores x € 50 / h = 400.000 € custo de treinamento. Isso é mais dinheiro do que minha equipe de desenvolvimento de software é orçada em um ano inteiro para salário, software e hardware. Esse é um investimento excepcional que você está propondo.

Mas você está dizendo: "Pense em todo o tempo que poderia ser salvo através de aumentos de produtividade". Corretamente, mas investimento significativo é risco significativo, então é melhor eu ter certeza de que você está certo sobre isso antes de eu assinar. Se nenhum dos caras mais velhos está apoiando você, então eu não posso justificar a despesa. Em última análise, podemos ser ineficientes, mas somos consistentes e com 8000 desenvolvedores em toda a empresa, a consistência é a mais importante.

Para fazer isso, você precisa assinar com várias pessoas de nível sênior e precisa encontrar, com precisão e objetividade, uma maneira de medir o tempo perdido do desenvolvedor em relação à ineficiência. Esse tempo equivale a dólares e apenas dólares e a política ajudará você a vencer essa batalha.

    
por 27.01.2012 / 13:40
fonte
7

O que você descreveu não soa como "liderar pelo exemplo" para mim, parece que você fez uma proposta e foi rejeitada. Para liderar pelo exemplo, você precisa mostrar pessoas que o seu caminho é melhor. Dos problemas que você listou, vejo três que você mesmo pode começar a usar suas próprias alterações.

Plain old makefiles which only support full rebuild.

Crie seus próprios makefiles localmente e mostre com que eficiência você pode trabalhar com eles.

monolithic headers files and projects with very few different files (but each has around 3000 lines of code, which sometimes takes care of very different tasks)

Divida os já existentes ao tocá-los (sem quebrar a compilação) ou introduza arquivos de cabeçalho menores ao escrever um novo código. Quando as pessoas começarem a trabalhar com elas, elas perceberão que não precisam da duplicação.

no use of the "new" languages facilities (well std::string is not that new but nobody except me uses it)

Continue a introduzir novos recursos de idioma sempre que tocar em um código antigo ou introduzir um novo código. Certifique-se de simplificar as coisas. Não desanime desta. A maioria de nós é preguiçosa. Se percebermos que um novo recurso de idioma facilita as coisas, nós o adotaremos.

Após alguns meses, se outros desenvolvedores começarem a adotar suas melhorias, você poderá abordar seu chefe novamente sobre alterações mais radicais, como a atualização do seu sistema de controle de origem. Você precisa se certificar de que os outros desenvolvedores vejam o benefício, ou ele nunca passará. Uma maneira de abordar isso pode ser sugerir testar o Git em um projeto pequeno em que apenas alguns desenvolvedores estão ativos. Dessa forma, você pode promovê-lo como uma avaliação, não como uma transição completa para um sistema desconhecido.

Finalmente, se depois de vários meses tentando ninguém parece interessado em melhorar como as coisas são feitas na sua empresa, você precisa realmente considerar se é uma boa opção para você.

    
por 27.01.2012 / 14:06
fonte
5

Além de Lionel Barret (que eu concordo principalmente), considere também a possível motivação para a resistência.

  • Avalie o custo do processo real
  • Avalie o custo do processo, pois ele será como o seu

Mas também:

  • Avalie o custo da mudança no prazo de
    • Dinheiro para gastar para configurar o novo ambiente para qualquer pessoa
    • Tempo para treinar todo mundo para se acostumar com o novo modo (pode ser fácil para você, mas não é fácil para pessoas que não estão cientes do que você está fazendo)
    • Tempo decorrido necessário para gerenciar a alteração de maneira não disruptiva.

Eu tenho um suspeito: Quantos na sua empresa as pessoas gostam de você em termos de idade e cultura (eu sou "escola" e "tipo de escola")? Quantas pessoas como você devem ser contratadas nos próximos 2/3 anos e quantas se aposentarão ou mudarão seu papel na organização?

Meu suspeito é que você está em uma posição com força insuficiente para mudar a empresa. Nessa situação, a empresa irá mudá-lo ou "expulsá-lo" (no sentido em que ele se tornará seu próprio desejo de ir embora), se você não for capaz de esperar por mais tempo.

Mas pode ser que a empresa esteja avaliando que os custos adicionais que lhe contei podem ser salvos, permitindo que o processo de mudança aconteça espontaneamente, esperando que a substituição natural das pessoas aconteça. Você está apenas no começo de um processo que você não pode ver porque não tem nada (ainda) atrás de você.

    
por 27.01.2012 / 10:34
fonte
3

Neste ponto, só posso adicionar uma referência ao artigo Joel Como fazer as coisas quando você é apenas um grunhido . As seções incluem:

Strategy 1 Just Do It

Strategy 2 Harness the Power of Viral Marketing

Strategy 3 Create a Pocket of Excellence

Strategy 4 Neutralize The Bozos

Strategy 5 Get Away From Interruptions

Strategy 6 Become Invaluable

Eu resumiria o artigo como "A mudança precisa começar com você".

    
por 27.01.2012 / 17:04
fonte
1

Infelizmente, as pessoas ficam presas em um barranco e desenvolvem a mentalidade de que 'funciona, todo mundo usa tudo bem, por que mudar' E isso enfurece.

Você tem feito isso da maneira certa, não apenas reclamando, mas desenvolvendo uma solução viável como substituta, agora você só precisa de um buy-in.

Mostre seu gerente de linha direta (ou líder técnico). Se eles não estão interessados, você tem alguém responsável pelo controle de mudanças ou inovação?

Potencialmente, suas idéias e trabalhos podem ser ignorados e a situação permanecerá como está.

    
por 27.01.2012 / 10:03
fonte
1

Você precisa declarar seu caso de uma maneira que deixe seu chefe do seu lado. BTW, Esse tipo de mudança é proposto por um diretor técnico ou gerente de projeto, portanto, você precisará se comprometer com o projeto. (Como uma rota alternativa, você pode propor uma auditoria técnica, um estranho provavelmente dirá as mesmas coisas que você, mas terá mais peso.)

Até agora, ele não vê a necessidade de mudar, parece que os cosméticos mudam para ele: caro sem benefícios óbvios, exceto para satisfazer a fantasia de um desenvolvedor. Apenas duas coisas são importantes para ele: o fluxo de dinheiro e uma equipe estável. A tecnologia é uma caixa preta, se funcionar, isso é suficiente.

Primeiro dinheiro, você precisa provar que a configuração atual está lhe custando dinheiro. Qual o custo / hora de um desenvolvedor e quantas horas de compilação mais rápida o salvariam? Faça as contas. Além disso, compile artigos ou testemunhos sobre os riscos do atual pipeline de código e mostre a ele números assustadores: "por causa do SourceSafe / Bad Coding Practices, nossa empresa perdeu $ XXXK".

Segundo a equipe, seu chefe pode estar preso a velhos codificadores mal-humorados que não querem mudar seus modos. Se o primeiro ponto for estabelecido, você também precisará propor uma solução para esse problema. Quantos vocês são ? Pode ser interessante ressaltar que será difícil substituir alguém porque o atual pipeline de codificação é bizantino. Você precisa propor um plano para atualizar a equipe. Saiba quais são as práticas recomendadas do setor e verifique se estão seguindo as novas regras.

Por fim, é necessário propor um plano para alterar a base de código, dividida em pequenos projetos, com marcos e alocação de recursos. Na verdade, você está se vendendo como gerente de projeto e as alterações são obrigatórias para ter um pipeline de código sólido.

    
por 27.01.2012 / 10:09
fonte
1

Você trabalha em uma organização que acredita que fazer as coisas bem, eficiência e inovação levam ao sucesso e à lucratividade; ou que a busca de receita e a concentração na manutenção de vendas são os inquilinos do sucesso?

Empresas que se comportam como você estão descrevendo estão tecnologicamente entrincheiradas. Em um mercado competitivo, eles não seriam capazes de competir com uma empresa focada em indivíduos e inovação.

Se você é a pessoa que você diz ser, então trabalhe em algum lugar que honre e recompense seu espírito. Eventualmente, após anos de assentamento, você começará a comprometer-se com a mesma filosofia que seus superiores adotam. Vá trabalhar em outro lugar (provavelmente uma organização menor) que valorize o trabalho duro, a inspiração, a criatividade e o progresso.

Se você não se arrisca e faz isso logo, você acabará se estabelecendo e não poderá continuar alimentando sua curiosidade e criatividade, porque é filosoficamente contrário em seu atual grupo de pares.

Excelência é uma atitude e uma visão de mundo.

Saiba que essa experiência lhe deu uma visão para saber o que evitar, mantenha-se atento à complacência e ao protecionismo para que você possa detectá-lo antecipadamente.

Em sua próxima entrevista, faça perguntas como "Que tipo de inovações vêm de seus funcionários", "Quais são algumas das mudanças resultantes da criatividade individual?", "Quais talentos individuais posso trazer para essa equipe?" o sucesso de suas organizações? "," Como a sua organização está continuamente adotando a inovação tecnológica? "... As respostas a perguntas como essa são extremamente reveladoras. Muitas organizações não têm visão, ou aquelas que criaram a visão se foram, e a organização é executada por contadores. Se você estiver entrevistando com o Diretor de Tecnologia - pergunte se ele vê a organização como uma empresa de tecnologia.

    
por 27.01.2012 / 20:33
fonte
-1

Se você não gosta do ambiente em que está trabalhando, está prestando um desserviço a si mesmo. Você precisa estar cercado por pessoas que tenham interesses e objetivos semelhantes aos seus profissionais. Eu sei que às vezes é mais fácil dizer o que fazer, mas a sensação de olhar para trás vários anos e sentir que você perdeu seu tempo é pior do que o medo de correr riscos.

Como alternativa, se você deseja desenvolver em um sistema ou ambiente que usa tecnologia e / ou metodologias específicas, sugiro que encontre um projeto fora do trabalho para o qual possa contribuir. No mínimo, a variedade de trabalho em ambos os sistemas irá satisfazer a necessidade de algo diferente, enquanto você descobre onde você pertence.

Parece-me que você é peixe fora d'água. Vá encontrar seu corpo de oceano e nadar!

    
por 27.01.2012 / 20:57
fonte