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


40

Eu trabalho para uma grande empresa (mais de 8.000 funcionários) há quase 2 anos e fui contratada 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 começo, mantive um perfil discreto, 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 a reconstrução completa
  • .def arquivos que devem ser mantidos manualmente e separadamente para todas as arquiteturas existentes
  • arquivos e projetos de cabeçalhos monolíticos com muito poucos arquivos diferentes (mas cada um tem cerca de 3000 linhas de código, que às vezes cuida de tarefas muito diferentes)
  • nenhum uso das "novas" instalações de idiomas (bem, std::stringnão é tão novo, mas ninguém além de mim o usa)

Decidi, há alguns meses, fazer algo a respeito, criando um novo ambiente de compilação. Eu conseguia que as compilações incrementais funcionassem de forma confiável, tempos de compilação mais rápidos, projetos melhor estruturados, .defgeração automática de arquivos. Eu até criei uma ponte de / para Git para / do Visual SourceSafe.

Mostrei minhas realizações a 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 mudaríamos as coisas?"

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

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

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


10
"Decidi, há alguns meses, fazer algo a respeito", "..." mostrei o resultado ao meu chefe ". Parece que você errou o pedido.

3
@ ThorbjørnRavnAndersen: Não tenho certeza de entender: como devo mostrar algo que ainda não fiz? Ou talvez você quis dizer que eu deveria ter perguntado antes de fazer isso?
ereOn

21
Eu estive lá, e na OMI, você precisa sair de lá, porque, como diz o ditado, "um idiota sempre o derrota - primeiro ele o deixa no nível dele e depois o derruba com sua experiência. " Se as pessoas não conseguem reconhecer a necessidade de atualizar, isso é estagnação profissional, e estagnação em nosso campo é a morte. Você pode colocar as coisas que fez no seu currículo e, se for bom, provavelmente conseguirá um bom emprego dentro de um mês.
TC1 27/01

8
Vaca sagrada, 8000 desenvolvedores? Para quem você trabalha, o Facebook? Google? Microsoft?
precisa saber é o seguinte

5
@ Kyralessa: Eu não acho que o Facebook nem o Google usam VSS.
Jake Berger

Respostas:


46

Apontar para a cabeça : "Liderar pelo exemplo" deve ter melhorias em mente, mas deve ser direcionado a pessoas que não usam tecnologia. Talvez você tenha investido muito tempo na melhoria da tecnologia, mas não há tempo suficiente no que está acontecendo na cabeça deles. Pense nos fatores determinantes para a oposição de 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 simpatizarão com suas idéias. Deixe-os de lado.

Cresça para uma massa crítica : encontre pessoas que simpatizem com suas idéias. Ganhe o mais de um por um. Em algum momento, se uma massa crítica for alcançada, mais e mais pessoas seguirão seu exemplo voluntariamente.

Vocabulário de gerenciamento : os gerentes não estão interessados ​​em projetos melhores. A linguagem deles é dinheiro e tempo. Deixe claro quanto tempo de trabalho são desperdiçados por bugs. Deixe claro que os clientes insatisfeitos que encontram 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 : as melhores tecnologias não produzem melhores programadores e programas. Se você possui bons processos em execução, até tecnologias desatualizadas levam a bons resultados. Pense no esforço e no tempo desperdiçados. Talvez não seja a tecnologia, mas algo nos processos está dando errado. Na maioria dos casos, é falta de comunicação.

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


3
Relacionado a "crescer massa crítica": youtube.com/watch?v=V74AxCqOTvg
back2dos

2
@ Farmac, se você não conseguir convencê-los sem dizer "vá ler uma página da web", talvez seja você quem precise aprimorar as habilidades de comunicação.

11
Quero dizer, se eles são teimosos e não ouvem os jovens. Você pode expressar sua opinião consultando a documentação. Por exemplo, se eles disserem que seus pontos não estão corretos e quase todos os especialistas em versão escreverem seu ponto, eles serão forçados a enviar. E eu gosto de provocar os arrogantes. Por exemplo, se eles gostam de Torvalds, você pode dizer que Torvals diz: "Se você gosta de SVN, você é estúpido e feio", como ele fez em seu discurso no Google. Não entendo por que me referir à documentação quando uma pessoa teimosa não acredita que você é a coisa errada. Você pode até fazer isso no telefone e mostrá-los imediatamente.
Farmor

6
-1 para o envelhecimento. Às vezes, você precisa ouvir atentamente o "especialista em fósseis" e se permitir ter um pouco de humildade. Então, com o conhecimento adquirido, torne sua ideia ainda melhor. Deixar de lado os outros apenas porque são velhos é uma maneira de perder um valioso conhecimento e o apoio de desenvolvedores seniores influentes.
Doug T.

11
@Lundin: Os gerentes devem ter conhecimento técnico, mas quanto mais você sobe na escada, mais dinheiro e tempo se tornam importantes. Não há nada de errado com isso, porque alguém precisa acompanhar os aspectos comerciais de uma empresa. É vital fornecer aos gerentes os argumentos certos em suas mãos para que eles possam justificar suas decisões aos gerentes. Como desenvolvedor, você pode conquistar um gerente se servir a ele os argumentos certos.
Theo Lenndorff 27/01

30

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

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

Criar criadores de gado é como tentar agrupar gatos, eles têm uma mente própria e uma maneira preferida de fazer as coisas, certo ou não. Tenho dificuldade em impor as melhores práticas e gerenciar uma equipe de 2 desenvolvedores, mas você trabalha para uma empresa que possui 8000.

Esse é um número incrivelmente grande. Mesmo uma simples mudança de processo que determina que todos os desenvolvedores devem agendar reuniões e o tempo de ausência no calendário público se torna uma política extremamente complexa e difícil de implementar em todos os setores. Também exigiria um esforço significativo da gerência para garantir que a política seja aceita e adotada em todos os setores.

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

  • Suporte de gerenciamento significativo

  • Ampla aceitação da empresa

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

  • 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 / hora = € 400.000 em custo de treinamento. Isso é mais dinheiro do que minha equipe de desenvolvimento de software recebe um orçamento 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 economizado com o aumento da produtividade". Com razão, mas um investimento significativo é um risco significativo, então é melhor eu ter certeza de que você está certo sobre isso antes de eu assinar. Se nenhum dos veteranos está apoiando você, não posso justificar a despesa. Por fim, 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 de maneira precisa e objetiva uma maneira de medir o tempo perdido de desenvolvedor com a ineficiência. Esse tempo equivale a dólares e apenas dólares e política o ajudarão a vencer esta batalha.


4
Obrigado. Para ser sincero, no começo, quando cheguei, por algumas semanas eu era tudo: "Que diabos, esses caras não têm idéia!" então percebi o quão errado eu estava em muitos pontos. Mas, depois de dois anos lá, tenho certeza de que alguns processos podem ser aprimorados e podem resolver muitas das reclamações que ouvi. Entendo que também é uma questão de opinião, mas se alguém viesse a mim com evidências de que estou fazendo algo ineficiente, pelo menos ouviria o cara, porque ele está me fazendo um favor. Meu departamento é composto apenas por 40 pessoas, e somente nós fazemos esse tipo de desenvolvimento.
ereOn

11
Tenho certeza de que eles podem melhorar, mas, como eu disse, é diferente mudar meus comportamentos e práticas para melhorar, do que treinar e forçar 40 desenvolvedores a fazer isso. Um gerente não técnico não vai ouvi-lo sem que pessoas seniores politicamente importantes apóiem ​​a idéia.
maple_shaft

Não é apenas "as coisas poderiam ser feitas melhor?". Substituir um repositório de origem é uma grande mudança. há grandes custos para fazer a troca, entre os quais está treinando toda a equipe. Depois, há o risco. Você tem 100% de certeza de que não haverá alguma capacidade que o antigo repositório de código-fonte precise, que você não esteja ciente e qual o novo não teria?
precisa saber é o seguinte

@DJClayworth: O repositório VSS é usado apenas como um sistema de armazenamento básico. Ninguém nunca olha a história e geralmente apaga tudo antes de copiar o diretório inteiro novamente.
ereOn

11
@ereOn Lembre-se de que você trabalha para uma empresa, e uma empresa é ganhar dinheiro, não código. A menos que seja sem fins lucrativos. De qualquer forma, seu principal valor para seus clientes provavelmente não é "forneceremos o código com os makefiles de compilação mais rápidos do setor". Você deve descobrir o que importa para o seu chefe (por exemplo, cortar custos) e depois calcular os custos. Fator de pessoas e custos de ferramentas.
Jasonk

7

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

Makefiles antigos simples que suportam apenas a reconstrução completa.

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

arquivos e projetos de cabeçalhos monolíticos com muito poucos arquivos diferentes (mas cada um tem cerca de 3000 linhas de código, que às vezes cuida de tarefas muito diferentes)

Quebre os existentes quando você os tocar (sem interromper 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, perceberão que não precisam da duplicação.

nenhum uso das instalações de "novas" linguagens (bem, std :: string não é tão novo, mas ninguém, exceto eu, a usa)

Continue introduzindo novos recursos de idioma sempre que tocar no código antigo ou introduzir um novo código. Certifique-se de simplificar as coisas. Não desanime com isso. A maioria de nós é preguiçosa. Se percebermos que um novo recurso de idioma facilita as coisas, vamos adotá-lo.

Depois de alguns meses, se outros desenvolvedores começarem a adotar suas melhorias, você poderá abordar seu chefe novamente sobre mudanças mais radicais, como atualizar seu sistema de controle de origem. Você precisa garantir que os outros desenvolvedores vejam o benefício ou ele nunca será alcançado. Uma maneira de abordar isso pode ser sugerir a experimentação do Git em um projeto pequeno, no qual apenas alguns desenvolvedores estão ativos. Dessa forma, você pode promovê-lo como uma avaliação, não como uma transição em grande escala para um sistema desconhecido.

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


5

Além de Lionel Barret (que 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, como será 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 gastar para treinar todos a se acostumarem ao novo modo (pode ser fácil para você, mas não tão fácil para as pessoas que não sabem o que você está fazendo)
    • Tempo decorrido necessário para gerenciar a alteração de uma maneira sem interrupções.

Eu tenho um suspeito: Quantos são na sua empresa as pessoas como você em termos de idade e cultura (I homens "escola" e "o tipo de escola")? Quantas pessoas como você devem ser contratadas nos próximos 2/3 anos e quantas se aposentarão ou mudarão de 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 o mudará ou o "expulsará" (no sentido em que será seu próprio desejo ir embora), se você não puder esperar por mais tempo.

Mas pode ser que a empresa esteja avaliando que os custos adicionais que eu lhe disse podem ser economizados, permitindo que o processo de mudança ocorra espontaneamente, aguardando a substituição natural das pessoas. Você está apenas no início de um processo que não pode ver porque não tem nada (ainda) atrás de você.


11
Seus palpites estão certos: sou de fato um dos mais jovens do meu departamento. Alguns deles parecem perceber que, apesar da minha tenra idade, tenho um conhecimento valioso. Sei e entendo que ainda tenho muito a aprender (e acredito que será assim até o dia em que morrer), mas muitos deles parecem ofendidos por coisas que não sabem. Não quero afastá-los ou roubar seu emprego ou o que quer que seja: só quero melhorar as coisas para que todos possam trabalhar / viver melhor. Vou ter que esperar para ficar mais velho para ganhar peso?
ereOn

11
@ereOn: sua condução é tão nobre que toda pessoa sã deve querer trabalhar com você.
o0 '.

@ereOn: "Vou ter que esperar para ficar mais velho para ganhar peso?" Não necessariamente. A idade é um valor em termos de experiência no gerenciamento da complexidade. Não é um valor para entender coisas novas (elas são novas para qualquer pessoa e não ter backlog pode ser uma vantagem). Não é um problema "pessoal". É um problema de "massa crítica". Até que as pessoas que desejam a mudança sejam inferiores a 20%, elas serão sufocadas. Se são mais, a liderança se torna visível (e não é uma questão de idade). Se um líder pode atingir 40% da população, a "coisa nova" terá cidadania adequada. A mudança de 60% é espontânea.
Emilio Garavaglia 27/01

3

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

Estratégia 1 Just Do It

Estratégia 2 Aproveite o poder do marketing viral

Estratégia 3 Crie um bolso de excelência

Estratégia 4 Neutralizar os Bozos

Estratégia 5 Evite interrupções

Estratégia 6 Torne-se Inestimável

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


2
Eu achei o GTDWYOG não muito útil. Na minha opinião, pelo menos o título é enganador: alguém que "é involuntário na contratação" ou tem a liberdade de ignorar o resto do mundo enquanto trabalha na cafeteria não é um grunhido. Um grunhido é alguém que precisa fazer o que foi dito, com pouco ou nenhum controle sobre as circunstâncias em que está. Na minha experiência, apesar da imagem idealista pintada aqui no stackexchange, esse é o caso da maioria dos desenvolvedores. E para aqueles, o GTDWYOG é mais uma receita de ser demitido por desobediência.
Keppla

1

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

Você fez tudo da maneira certa, não apenas reclamando, mas desenvolvendo uma solução viável como substituta, agora você só precisa de uma adesão.

Mostre ao seu gerente de linha direta (ou líder técnico). Se eles não estiverem interessados, você tem alguém encarregado do controle de mudanças ou inovação?

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


2
ah, mas o número de vezes que ouvi "vamos reescrevê-lo, será muito melhor e mais legal na nova tecnologia x" apenas para descobrir que a nova não era melhor que a antiga (e, em muitos casos, pior). Muitas vezes, até que haja uma necessidade , é melhor não quebrar algo que funcione.
precisa saber é o seguinte

1

Você precisa declarar seu caso de maneira a colocar 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, é provável que alguém de fora diga o mesmo 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, é o 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 mais rápidas o tempo de compilação o salvaria? Faça as contas. Além disso, compile artigos ou testemunhos sobre os riscos do pipeline de código atual e mostre números assustadores: "por causa do SourceSafe / Bad Coding Practices, nossa empresa perdeu US $ XXXK".

Segundo a equipe, seu chefe pode estar preso a codificadores rabugentos antigos que não querem mudar de atitude. 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. Aprenda as melhores práticas do setor e verifique se estão seguindo as novas regras.

Por fim, você precisa 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.


Obrigado por seus conselhos. O fato é que o responsável parece gostar muito de todos os desenvolvedores antigos (porque, no final, eles fazem o trabalho e não contam as horas). Sinto que tenho muito pouco peso porque sou jovem. Várias pessoas no meu departamento vêm me perguntar coisas sobre boas práticas, mas mesmo quando explico as coisas com muita humildade, em algum momento elas não querem mostrar que não sabem muito sobre isso e tentam defender seus velhos hábitos.
ereOn

1

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

As empresas que se comportam como você está descrevendo estão tecnologicamente arraigadas. 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 diz ser, então trabalhe em algum lugar que honre e recompense seu espírito. Eventualmente, depois de anos de estabelecimento, você começará a se comprometer 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 arriscar e fizer isso em breve, acabará por se estabelecer e não poderá continuar alimentando sua curiosidade e criatividade, porque isso é filosoficamente contrário ao seu atual grupo de pares.

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

Saiba que essa experiência deu a você o insight para saber o que evitar; fique atento à complacência e ao protecionismo, para que você possa detectá-lo mais cedo.

Na sua próxima entrevista, faça perguntas como "Que tipo de inovação vem de seus funcionários", "Quais são algumas das mudanças decorrentes da criatividade individual?", "Que talentos individuais posso trazer para essa equipe?", "O que impulsiona o sucesso de suas organizações ? "," Como sua organização está adotando continuamente 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 as que criaram a visão se foram, e a organização é administrada por contadores. Se você estiver entrevistando o diretor de tecnologia, pergunte se ele vê a organização como uma empresa de tecnologia.


-1

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

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

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.