Como impedir um funcionário de manter a empresa refém?

O que posso fazer para resolver esta situação?

Nada, só lá está há alguns meses, não é o seu papel e não tem poder para fazer nada, excepto lamentar-se.

Os seus superiores têm muitos recursos, mas não os usam há 7 anos, por isso, nesta altura, está apenas a adivinhar as suas razões e a analisar um colega em vez de se concentrar nas suas próprias responsabilidades e tarefas.

Contrate dois ou três dos mais inteligentes programadores que conseguir encontrar. Entregue-lhes o código todo. Deixe-os verificar se de facto têm todo o código, tudo o que é necessário para executar o software. Faça-os aprender o que o código faz, documente-o, refactore-o, até chegarem ao ponto em que possam resolver os problemas mais rapidamente do que o Sr. A. Tudo isto obviamente sem qualquer conhecimento de A.

Nessa altura certifique-se de que desligou completamente o Sr. A de quaisquer recursos da empresa, transfira o trabalho para os seus novos programadores, e informe o Sr. A. A que o seu emprego terminou.

Penso que, com os métodos de desenvolvimento do Sr. A, a quantidade de trabalho que o seu código faz é, na verdade, muito inferior a sete anos de desenvolvimento, e que o código é ofuscado, mas não é difícil, o que torna o trabalho dos novos colaboradores muito mais fácil.

PS. Devido a alguns comentários, gostaria de salientar novamente este aspecto: O problema não é apenas o dinheiro, o problema é que o software está muito menos bem desenvolvido do que poderia estar, porque A concentra-se em tornar o desenvolvimento difícil, não em melhorar o software.

Resposta curta: A sua organização está actualmente em grave perigo de The Bus Factor .

É por isso que nunca se deixa uma pessoa deter todo o conhecimento. É um risco enorme. O que aconteceria se essa pessoa decidisse desistir, ou fosse literalmente atropelada por um autocarro? Se a situação é como a descreve, então a empresa inteira desaparece. Tem de assinalar isto aos seus gestores como um risco organizacional, não como uma questão de RH.

Comece a fazer com que outras pessoas passem o código, com ou sem o Sr. A. De preferência sem, porque já o identificou como a questão.

Lembre-se, se o Sr. A não ajudar nesta mitigação do risco para a sua organização, então ele próprio é um perigo para a organização e precisa de ser gerido. Tire-lhe o poder para que, se ele for realmente atropelado por um autocarro, vocês não acabem todos sem caminho para a frente.

As outras respostas são bastante boas, mas há mais uma coisa que gostaria de considerar:

O meu conselho pessoal seria considerar começar a procurar outros locais para trabalhar… se a gerência não tomar qualquer medida em 7 anos, não tenho a certeza se este é um local para o qual gostaria de trabalhar a longo prazo. Para mim, isto é um sinal de aviso para outros tipos de problemas na empresa.

e ele repetidamente toma más decisões de propósito para manter o produto de software instável, difícil de manter e resolver problemas

Então porque é que a sua equipa deixa estas “más decisões” passarem na revisão do design ou na revisão do código? Se não tem um processo de revisão de código ou mesmo um processo de revisão de design, defenda isso a longo prazo.

Mas até lá, tudo o que precisa de saber está no artigo do blog Joel on Software: Getting Things Done When You’re Only a Grunt

E ele tem uma chamada específica para lidar com bozos: FILE BUGS. Per Spolsky:

Como um grunt, o seu objectivo é a minimização de danos, ou seja, a contenção. Em algum momento, um desses gênios vai passar duas semanas escrevendo um pouco de código que é tão incrivelmente ruim que nunca pode funcionar. É tentado a passar os quinze minutos que demora a reescrever a coisa correctamente a partir do zero. Resista à tentação. Você tem uma oportunidade perfeita para neutralizar este idiota durante vários meses. Basta continuar a reportar bugs contra o seu código. Eles não terão outra escolha a não ser continuar a trabalhar nisso durante meses até que não consigas encontrar mais bugs. São meses em que eles não podem fazer nenhum dano em nenhum outro lugar.

Caso contrário, como um novo contratado da equipe, seu objetivo deve ser desenvolver sua própria reputação de excelência.

Só para dizer mais claramente do que as respostas actuais…

Seu problema :

ninguém sabia como resolvê-lo.

Sua solução :

• Aprenda a resolvê-lo você mesmo.

Ali, agora a empresa já não precisa do outro tipo.

Afixar isto na parede: (Você terá que mudar alguns dos nomes e lugares).

Alguns anos atrás eu passei uma semana dando um curso interno de desenho de programas em uma empresa de manufatura no meio-oeste dos Estados Unidos. Na sexta-feira à tarde estava tudo acabado. O Director da DP, que tinha organizado o curso e estava a pagá-lo a partir do seu orçamento, pediu-me para entrar no seu escritório. “O que acha?”, perguntou ele. Pediu-me que lhe transmitisse as minhas impressões sobre a sua operação e sobre o seu pessoal. “Muito bem”, disse eu. “Você tem gente boa lá.” Os cursos de concepção de programas são um trabalho árduo; eu estava muito cansado; e a consultoria de avaliação de pessoal é cobrada a mais. De qualquer forma, eu sabia que ele queria mesmo dizer-me o que pensava.

“O que achou do Fred?”, perguntou ele. Todos nós achamos que o Fred é brilhante". “Ele é muito esperto”, disse eu. “Ele não é muito entusiasta de métodos, mas sabe muito de programação”. “Sim”, disse o Director da PD. Ele rodou redondo na sua cadeira para enfrentar um enorme fluxograma colado à parede: cerca de cinco grandes folhas de papel de impressora de linhas, talvez duzentos símbolos, centenas de linhas de ligação. “O Fred fez isso. É a acumulação de salário bruto para a nossa folha de pagamentos semanal”. Ninguém mais, excepto o Fred, entende isso". A sua voz caiu num silêncio reverente. “O Fred diz-me que ele próprio não o compreende”.

“Fantástico”, murmurei respeitosamente. Percebi a imagem claramente. Fred como Frankenstein, Fred o brilhante criador do fluxograma incontrolável dos monstros. “Mas e a Jane?” Eu disse. “Pensei que Jane era muito boa. Ela pegou nas ideias de design do programa muito rapidamente”

“Sim”, disse o Director da DP. “A Jane veio até nós com uma grande reputação. Achámos que ela ia ser tão brilhante como o Fred”. Mas ela ainda não provou realmente o seu valor. Nós demos-lhe alguns problemas que pensávamos que iam ser muito difíceis, mas quando ela acabou, não foram nada difíceis. A maioria deles acabou por se revelar bastante simples. Ela ainda não provou realmente a si própria — se é que me entendes?“

"Eu vi o que ele quis dizer”

• Extracto do livro “Software Requirements & Specifications” - Michel Jackson (Bem vale a pena ler).

A resposta é simples: despedi-lo. Talvez tenha de pagar uma quantia não trivial a curto prazo para resolver a confusão que ele fez, mas o Sr. A não é mais esperto do que qualquer outra pessoa no mundo - alguém mais_ será capaz de manter o software a curto prazo, e torná-lo melhor a longo prazo.

Há uma perspectiva a considerar.

A empresa gosta desta forma. Se não o fizeram 7 anos é muito tempo para o deixar persistir.

Nós tendemos a esquecer como programadores, que não nos compete escrever código bom ou inteligente. O nosso trabalho é fazer um produto existir. Escrever um bom código só torna esse processo melhor, mas pode ser um produto totalmente fantástico com um código totalmente de merda.

A empresa apoiou as suas decisões, e até o contratou de volta. Eles “gostam” dele e da sua maneira de fazer as coisas. Não é provável que isso mude, mesmo que, de alguma forma, consiga que ele seja despedido. O que é provável que aconteça é eles escolherem uma nova pessoa para ser “o tipo” e o processo começa tudo de novo.

Não é a sua função gerir a empresa. A empresa já fez a sua escolha. Você precisa de fazer a sua. Aprenda com o cara (ele tem o mesmo emprego há 7 anos ele deve estar fazendo algo certo) ou siga em frente.

Para o bem ou para o mal, nem nada nem ninguém é insubstituível. (uns podem ser mais do que outros, mas mesmo assim ) Se as pessoas conhecerem a solução, podem começar a fazer a engenharia inversa.

Estive no seu lugar mais do que um par de vezes no passado. Na situação mais semelhante à vossa, o “Sr. A” já se foi há muito tempo, no entanto, eu tinha uma solução monolítica a trabalhar para a parte de trás de uma empresa de cabo onde não tinha código fonte para as bibliotecas desenvolvidas localmente, e ainda por cima se eu fosse um novato nessa indústria.

Eu praticamente ataquei-o numa abordagem modular, dando uma vista de olhos ao código existente, engenharia inversa onde faltava e escrevendo módulos que substituíam por turnos com melhores funcionalidades e tarefas centrais de velocidade. Aperfeiçoei cada módulo antes de ir para o próximo. Em poucos meses eu tinha morto a aplicação anterior.

Ser insubstituível é exagerado.

Lidar também com coisas antigas não é uma tarefa fácil, talvez o seu colega de trabalho o faça por inércia ou porque ele não sabe nada melhor.

De uma perspectiva empresarial, existem basicamente duas soluções:

1. Transição gradual, por outras palavras, pegar numa pequena peça da funcionalidade, reimplementá-la a um nível elevado e colocá-la em produção, e continuar a fazer esta peça por peça até que o sistema antigo possa ser totalmente desactivado.
2. Construir completamente um novo sistema, e depois fazer a transição para ele, de uma só vez ou gradualmente, por exemplo, iniciar novos clientes nele e mover gradualmente clientes antigos para ele. O novo sistema não tem de ser tão característico como o antigo inicialmente; o seu ponto de venda pode ser um preço mais baixo, apoio mais rápido, etc.

As vantagens da opção 1 são que não precisa de um grande investimento inicial, o seu novo código é testado no terreno gradualmente em vez de tudo de uma só vez, e começa a ver benefícios mais cedo (porque o negócio gasta menos tempo e dinheiro a manter as partes do antigo sistema que já não estão activas).

Contudo, as desvantagens são que a estrutura do novo sistema pode ser fortemente influenciada pela estrutura do antigo sistema e, em alguns casos, é realmente difícil substituir partes de um sistema muito confuso. Por vezes é necessário um pouco de criatividade - se tudo o resto falhar, o seu novo código pode simular teclas e cliques de botão no sistema antigo! Mas a interface com o sistema antigo pode gerar tanto trabalho que é melhor optar pela opção 2.

Seja como for, há é algo que pode ser feito. A questão é, quanto é que vai custar e quanto é que vai poupar? Tentar estimar que para cada uma das opções acima ajudará a determinar qual a opção a escolher (se houver). Dependerá dos requisitos funcionais, da estrutura do sistema existente e da vontade da empresa em gastar dinheiro/utilizar o crédito antecipadamente para poupanças futuras.

Como membro da equipa de software a sua função não é gerir a empresa e os seus colaboradores.

A sua função é escrever bom software. Por isso preocupa-te com o software e não com as pessoas.

Vês os problemas com o software, e pela tua pergunta, parece que tens algumas ideias para resolver os problemas. Traga estas ideias ao seu gestor e lute por elas.

“Manger, este software não é testado e a sua implementação actual não é testável. Sugiro que trabalhemos na reimplantação numa linguagem mais testable, usando padrões de design que permitam testes mais fáceis”

Agora, é muito provável que:

A. Esta é uma grande empresa em que a empresa não está disposta a investir, porque não vê a necessidade

B. O Sr. A irá argumentar contra estas coisas e será ouvido, uma vez que é mais sénior

Se isso acontecer então tentou fazer bem o seu trabalho e foi asfixiado. Hora de procurar um novo emprego.

Se este se esforçar e eles o ouvirem, o senhor inscreveu-se para uma tonelada de trabalho.

Não se pode assumir a intenção por detrás da situação.

Purpositadamente mantido afastado das estruturas modernas de desenvolvimento de software

Ele pode estar apenas mais confortável com o que sabe melhor?

Trabalhei em grandes empresas cujo pipeline era uma manta de retalhos de código antigo e novinho em folha e onde certas peças de código “apenas funcionavam” e nunca foram tocadas. Para além disso, os programadores que o escreveram já tinham desaparecido há muito tempo e ninguém compreendia realmente como funcionavam, pelo que apenas acrescentaram novas funções para se adaptarem às novas exigências. O seu pipeline estava sempre ao vivo, por isso qualquer grande implementação poderia ter consequências desastrosas (ou seja, trabalho muito dispendioso e interrupção da entrega), por isso evitaram tocar demasiado nele.

É um mau hábito e faz com que a infra-estrutura não seja optimizada, mas na verdade tem o seu mérito.

O que se pode fazer, especialmente se se quiser trabalhar em muito ou em todo o código: Se não houver documentação adequada, proponha-se criar uma (se souber que é qualificado e tem tempo) ou pergunte se deve ser feita uma para acelerar o trabalho.

Deve (como já faz) falar com o seu gestor sobre a adaptação de novas tecnologias ou melhorias, mas espere que nada possa vir daí, mesmo que ele concorde consigo.

É provável que ninguém mais acima veja o benefício de gastar recursos nisto e a sua tentativa possa ser vista como ah, o novo sangue pensa que pode mudar o mundo e ensinar-nos o erro dos nossos caminhos.

Infelizmente as estruturas da empresa resistem a mudanças súbitas e as modernizações são uma questão de desgastar gradualmente a resistência ou implementá-la pouco a pouco a menos que possa mostrar que as suas “mudanças revolucionárias trarão uma era dourada de lucro financeiro sem riscos”.

Mesmo que ele faça isto maliciosamente para manter o seu trabalho, não vejo que seja da sua responsabilidade rebentar a tampa, especialmente se o seu superior imediato estiver informado sobre isso.

O que faria? falar com o seu director ou sem ele com a direcção superior ou com o colega em questão?

Visto que o seu superior hierárquico decidiu não prosseguir com o assunto, ele provavelmente não quererá falar com os seus superiores hierárquicos com ou sem si, ou ele já o fez e enfrentou um bloqueio.

Se falar com os seus superiores hierárquicos sem ele, arrisca-se a aliená-lo.

Falar com o colega irá certamente criar um ambiente de trabalho muito mau e ele irá certamente negar qualquer acusação.

A única maneira de resolver isto é tirar o controlo ao Sr. A.

Primeiro obter a aprovação da gestão.

Fazer um novo git.

1. Importar um bem, acordado no ponto de partida.

2. Comece a partir daí e antecipe o código.

3. Não dê acesso ao Sr. A (nem sequer lhe diga que ele existe)

4. Deixe o Sr. A. fazer o que quiser ao seu reporte, pois não o vai usar.

5. Faça alterações de código falsas para que pareça activo se necessário para lhe esconder o seu novo repo.

6. Eventualmente o código irá divergir o suficiente para que ele se torne automaticamente obsoleto.

Tem de tomar uma decisão crítica para manter ou abandonar a estratégia dos módulos. Os módulos não são necessariamente maus, precisa de os manter sincronizados e em ordem.

Isto vai dar muito trabalho pois terá de reescrever muito do código existente.

Um benefício adicional, é que o código acabará por divergir o suficiente para que ele já não possa reclamar o seu código. Será completamente estranho para ele.

Esteja ciente de que, como não-gerente, este não tem que ser o seu problema a resolver (além de seguir instruções para fazer coisas que foram decididas como parte de uma solução).

Também, nunca interprete cegamente “Queremos o problema XY resolvido” para uma declaração “…por causa do problema XY”.

Também esteja ciente de que, uma vez que dirige qualquer iniciativa, mesmo com aprovação, para mudar a situação, está a envolver-se na política da empresa. Na política da empresa, não existe “um inovador inocente, sem agenda pessoal, que não possamos responsabilizar por consequências indesejadas”.

Se o fizer, faça-o com uma agenda pessoal, e seja dono das consequências de qualquer maneira.

@MightyPizza - Você está perdendo seu tempo. Vá trabalhar para outra empresa que tem um futuro melhor e mais brilhante. Só deve gastar tanta energia para resolver este problema se esta empresa for a sua última paragem.

Esta é a melhor resposta que vai ter. Prepare-se para o salto.

“Eu quero tornar o software moderno, manutenível e estável”

A melhor maneira de o fazer é no Dia Um, primeira linha de código, não com a pilha de lixo quente de outra pessoa.

Para ele ter ficado tanto tempo na posição mostra que o negócio está consciente ou inconscientemente a aplicar Hanlon’s razor :

Nunca atribuir à malícia aquilo que é adequadamente explicado pela estupidez.

Parece que é muito difícil encontrar casos reais de malícia, apenas coisas que não funcionaram tão bem ao longo do tempo. Na verdade, parece que o Sr. A deixou que as pessoas tentassem mudar as coisas e depois as consertassem heroicamente quando elas correram mal.

Deve também considerar que o Sr. A pode estar a sofrer do efeito Dunning-Kruger , na medida em que é incapaz de ver que o que está a fazer está errado.

Pode ser que ele já tenha sido bom, mas deixou de aprender e deixou de tentar. Quem sabe. O que tem de tomar como primeiro princípio, é que por muito exasperante que ele seja, tem de lidar com ele como se não fosse um agente malicioso.

A sua pergunta parece tomar o pressuposto de que ele está logo a seguir à segurança do emprego e recusa-se a actualizar as coisas para incorporar isto. Pode ter razão, mas não consegue lidar com ele nesta base.

Tenho a certeza que algumas das suas brilhantes ideias surgem com a resistência de “tentámos uma vez e não resultou devido a X”. De uma perspectiva empresarial isto faz sentido, eles correram um risco de que algo não funcionasse, então porque deveriam tentar novamente.

Você declara como seu objectivo.

Eu quero tornar o software moderno, manutenível e estável.

Vamos decompor isto por necessidade empresarial

1. Moderno

Não há valor implícito no negócio moderno. Em qualquer caso, é discutível. Diz-se Java 8, outros diriam que o Rust ou o Golag são modernos. Desde que um sistema seja suportado não há grande valor na sua actualização.

2. Mantenível

Isto também pode ser difícil de argumentar. O Sr. A vai argumentar que é sustentável, tal como ele o mantém. Terá de argumentar que o custo de manutenção diminuiria drasticamente para justificar uma alteração global do enquadramento.

3. Estável

O senhor diz que quer fazer o sistema HA, mas também diz que ele

o software monitoriza os eventos, faz algum processamento sobre eles e depois toma as medidas adequadas.

O que não soa como se precisasse de HA.

** Então o que fazer?**

O seu sistema soa como uma big ball of mud definida por

A Big Ball of Mud é uma grande bola de lama estruturada de forma aleatória, esparramada, desleixada, com fita adesiva e fio de calandragem, selva de código esparguete. Estes sistemas mostram sinais inequívocos de crescimento não regulado, e reparações repetidas e expeditas.

Atacar esta cabeça, com um revelador não cooperante a gerir isto será muito frustrante, e provavelmente infrutífero. Parece que muitos outros tentaram e falharam.

O que pode fazer é começar a contorná-lo:

• Se não consegue fazer o sistema HA, então use um sistema de barramento de mensagens ou algo do género para capturar as mensagens dessa forma se o sistema cair, não perde dados.
• Se não consegue escrever testes unitários, escreva testes do sistema. Estes não são tão simples mas permitem que os testes sejam feitos no sistema
• Da próxima vez que alguma acção for necessária, comece a construir isso num subsistema independente que possa ouvir o barramento de mensagens e executar a sua própria acção.
• Se puder começar a afectar alguns efeitos a jusante (por exemplo encapsulando as acções que são tomadas) então coloque-os num subsistema.

Há algum argumento para apoiar o majectic monolith sobre microservices , mas assume que o monólito está bem concebido. No seu caso, o sistema pode ser bom como um monólito bem desenhado mas se não estiver bem desenhado você precisa dividir as coisas. Este parece um bom artigo para começar:

Uma abordagem mais comum é começar com um monólito e gradualmente descascar os microserviços nas bordas. Tal abordagem pode deixar um monólito substancial no coração da arquitectura dos microserviços, mas com a maioria dos novos desenvolvimentos a ocorrer nos microserviços enquanto o monólito está relativamente quiescente.

No entanto é importante jogar com o Sr. A, não lhe diga que está a substituir o sistema, mas que está a “melhorar a fiabilidade” ou a acrescentar redundância. Se atacar o que ele fez, ele vai tornar mais difícil para si atingir os seus objectivos.

Pode acontecer que fique com falhas de que está a tornar o sistema mais complexo. É verdade, mas é necessário se quiser avançar a longo prazo.

Porque é que toda a gente quer tanto despedir o Sr. A? Penso que ele não fez nada de mal aqui. O desenvolvimento de software não se trata de fazer coisas novas utilizando ferramentas fixes, ou uma estrutura. Trata-se de fazer uma coisa estável que apenas “funcione”. A sua empresa adora o Sr. A e está satisfeita com o seu trabalho.

Purpositadamente mantido afastado das modernas frameworks de desenvolvimento de software

O seu sistema está actualmente em condições estáveis, então porque é que a equipa precisa mesmo de usar uma framework de desenvolvimento de software moderna como Scrum ou ágil?

Lógica escrita do core business em linguagens que não podem ser testadas

Existe algum requisito que a lógica escrita do core business tenha de ser automaticamente testada?

Re-arquitectar componentes de software em 30 módulos para adicionar complexidade e questões de certificação de versões

Quanto mais custou esta implementação à sua empresa?

Desenhou-a de forma não escalonável, assegurando que não há capacidades HA (alta disponibilidade)

Ainda a mesma questão - quanto mais custou esta implementação à sua empresa?

Na minha opinião, tudo o que escreve aqui é apenas a sua queixa contra ele. Se ele tivesse feito muitas coisas “terríveis” o próprio sistema teria derretido no primeiro ano e ele não poderia ter ficado tanto tempo na sua empresa.

Simples, o negócio tem de lhe oferecer um aumento generoso para documentar o estado actual do software e todo o conhecimento que não está a ser documentado e depois despedem-no. Ou em alternativa, contratam uma empresa de consultoria técnica para documentar tudo e ele vai ver a escrita na parede e eventualmente vai-se embora.