Como garantir que sua empresa não fique submersa se seus programadores ganharem na loteria [fechado]

Eu tenho alguns programadores, todos eles estão muito bem e são muito inteligentes, obviamente. Muito obrigado.

Mas o problema é que todos e cada um deles são responsáveis ​​por uma área central, que mais ninguém na equipe tem a menor idéia do que é. Isso significa que, se alguém for retirado, minha empresa como empresa está morta porque não é substituível.

Estou pensando em trazer novos programadores para cobri-los, apenas no caso de serem atropelados por um ônibus, ou demitir-se ou algo assim. Mas eu temia que

1. Os programadores antigos podem resistir ativamente à idéia de transferência de conhecimento, temendo que um backup possa reduzir seu valor.
2. Eu não tenho um sistema para facilitar a transferência de tecnologia entre diferentes desenvolvedores; portanto, mesmo se eu pedir a eles para fazer isso, não tenho garantia de que eles farão isso corretamente.

Minha pergunta é,

1. Como colocá-lo para os antigos programadores em que eles concordariam
2. Quais são os sistemas que você usa para facilitar esse tipo de "backup"? Entendo que você pode fazer uma revisão de código, mas existe uma maneira simples de fazer isso? Acho que não estamos prontos para uma análise completa do código de check-in por check-in.

Como colocá-lo para os antigos programadores em que eles concordariam

Apresente o problema abertamente a eles, é claro que eles não o verão como uma ameaça, mas como uma oportunidade para fazer a equipe e o projeto funcionarem melhor. Por exemplo: "Gostaria que outras pessoas soubessem o que você sabe, caso seja demitido" é obviamente uma abordagem errada :-) "Gostaria de garantir o bom funcionamento do projeto, mesmo que alguns de vocês saiam de férias ou fiquem doentes. " é muito melhor.

Geralmente, os próprios desenvolvedores enfrentam os problemas sempre que alguns estão de férias e precisam cobri-lo. Além disso, bons desenvolvedores sentem a responsabilidade pelo projeto em que estão trabalhando, portanto provavelmente concordarão com essa ideia. Ainda assim, dê a eles tempo para discutir e (espero) se comprometer com a ideia. Além disso, permita que eles tenham uma opinião sobre como e com quem compartilhar seus conhecimentos dentro da equipe. Pode parecer que Joe se sente bem em trabalhar (e compartilhar seu conhecimento) com Jim, mas não com Jack etc.

Quais são os sistemas que você usa para facilitar esse tipo de "backup"? Entendo que você pode fazer uma revisão de código, mas existe uma maneira simples de fazer isso? Acho que não estamos prontos para uma análise completa do código de check-in por check-in.

Em nossa equipe, além das revisões de código / design, usamos

• Rotação de tarefas e áreas de responsabilidade entre os membros da equipe (cada um de nós tem suas principais áreas de responsabilidade, mas, de vez em quando, realizamos tarefas em uma área mais conhecida por outro membro da equipe)
• Sessões presenciais de transferência de conhecimento (geralmente quando as tarefas acima exigem, mas também antes de alguém sair da equipe)
• Wiki da equipe / projeto

A revisão de código por si só pode não ser suficiente, pois em muitas áreas geralmente há muito mais para um desenvolvedor saber do que o que é diretamente legível a partir do código. Em outras palavras, também existe o modelo de domínio . Você pode ler o que o código realmente faz, mas sem o modelo, você não saberá o porquê .

Uma maneira de motivá-los a compartilhar seus conhecimentos seria pedir-lhes que fizessem uma breve apresentação de seu trabalho para outras pessoas. Os programadores normalmente se orgulham de seu trabalho, e isso seria uma chance de demonstrá-lo. Uma apresentação é uma boa oportunidade para fazê-los mostrar algumas das peculiaridades raramente conhecidas por pessoas de fora.

Além disso, por que não ser aberto e dizer a todos que todos precisam criar um esquema de compartilhamento de conhecimento, caso alguém seja atropelado por um ônibus. Eu não vejo isso como irracional. Está acontecendo na minha empresa no momento e, embora alguns sejam defensivos, sabem que precisa ser feito.

Talvez eles possam trabalhar em pares em algumas coisas, se eles são de natureza inquisidora, não deve haver problema.

Atualizar a documentação interna do software deve ser o primeiro passo, antes de começar a contratar novas pessoas. Claro, isso significa que seus valiosos programadores passarão algum tempo com as ferramentas do Office e UML em vez do IDE, mas acho que vale a pena em qualquer caso.

Depois de ter uma documentação atual, você pode permitir que seus programadores a verifiquem para garantir que todos entendam o que os outros escreveram. Ainda não há necessidade de novas pessoas.

Então você pode considerar contratar novas pessoas. Ou não, dependendo da carga de trabalho na sua empresa.

Se você estiver em uma grande empresa, ligue para o RH e fale sobre esse problema. Acredite, o pessoal da contabilidade tem o mesmo problema se o pessoal-chave for atropelado por um ônibus. O pessoal de marketing também terá muitos problemas se um vendedor-chave se tornar um zumbi no meio de negociações importantes - isso acontece frequentemente, ou pelo que me disseram.

Acredito que a linguagem correta de RH para isso seja o planejamento de sucessão . Sua empresa já pode ter políticas e estruturas para lidar com isso.

Um lugar em que trabalhei tinha o mesmo problema. O que eles fizeram foi contratar um desenvolvedor júnior para trabalhar com cada desenvolvedor sênior. Eles criaram pequenas equipes de 2 pessoas que trabalharam juntas em projetos. A cada poucos meses ou projetos, eles alternavam os desenvolvedores juniores entre as equipes. Dessa forma, os desenvolvedores seniores continuaram sendo os especialistas no assunto, mas os desenvolvedores juniores começaram a entender bem todos os sistemas e como eles trabalhavam juntos. Além disso, com o tamanho da equipe, os projetos de duplicação foram realizados mais rapidamente.

Para projetos maiores que surgiam, às vezes era pedido aos desenvolvedores seniores que atuassem como desenvolvedores Junior em outra parte do sistema durante a duração de um projeto, para que pudessem começar a aprender os outros sistemas.

A chave era respeitar o conhecimento e a antiguidade dos desenvolvedores existentes enquanto continuava a expandir e aumentar a equipe. Foi um processo lento, mas com o tempo funcionou muito bem.

Uma das coisas que torna os projetos de código aberto bem-sucedidos é a falta de "propriedade" do código. Com isso, quero dizer que ninguém é o único mantenedor de uma área do aplicativo - qualquer pessoa pode e é incentivada a fazer contribuições para qualquer parte do aplicativo. É algo em que acredito fortemente.

O que você quer fazer é explicar que a maneira como as coisas estão realmente prejudicando a equipe que você tem agora. Aqui estão os pontos que você deseja transmitir e, de preferência nesta ordem:

• Não posso libertá-lo para trabalhar em outras coisas legais que estão chegando, se você é o único que sabe como isso funciona.
• Queremos que você seja capaz de tirar boas férias, mas não pode se dar ao luxo de, porque ninguém mais pode fazer o que você faz.
• É um fato desagradável que as pessoas mudem de emprego porque estão insatisfeitas com sua posição atual; não queremos perdê-lo porque você se sente preso pela área em que está trabalhando.

Em uma nota pessoal, tive que lidar com um colega de trabalho falecendo. Embora não houvesse silos de informações, a perda ainda era forte. As chances de isso acontecer são bem menores que o terceiro ponto acima.

Depois de apresentar seu caso, solicite a ajuda deles para obter idéias sobre como corrigir o problema. Venha com o seu próprio, é claro. Suas idéias os ajudarão a perceber que fazem parte de uma equipe e são necessárias para mais do que apenas sua área de especialização. Pode ser que Jane tenha interesse no que Joe está fazendo, mas se sinta um pouco intimidada por isso. Saber que isso pode ajudar a tornar o conhecimento mais divertido. Algumas das coisas que você deseja fazer são:

• Treine a equipe atual. Você pode perder um pouco de eficiência a curto prazo, mas pode haver algumas lições aprendidas em um canto do aplicativo que podem ser aplicadas a outras partes do aplicativo. Jane e Joe trabalham juntos no projeto um do outro por um tempo.
• Promover uma cultura de compartilhamento de conhecimento. Uma empresa em que trabalhei tinha um programa de "conversa sobre tecnologia com sacolas marrons". Qualquer pessoa poderia apresentar sobre qualquer tópico aprovado (geralmente apresentando processos de tecnologia ou software). A empresa serviu o almoço e o apresentador recebeu algumas centenas de dólares por seu esforço.
• A tutoria deve ser um modo de vida. O objetivo de orientar outras pessoas é libertá-lo para fazer coisas novas e torná-lo ainda mais valioso para a empresa.
• Encontre maneiras de cruzar os limites do silo de informações sem puxar a classificação. Quanto mais divertido você o fizer, menos ameaçador será. Se as pessoas da sua equipe são tão boas quanto você diz, provavelmente não estão completamente felizes com a maneira como as coisas são. Você terá que julgar se a equipe pode lidar com isso, mas você pode ter uma semana "vamos escolher mais ou menos". Sempre comece com você mesmo aqui. A idéia é chamar a atenção de todos sobre quais são as responsabilidades do "tal e qual" e como eles podem resolver os problemas que estão tendo melhor. Desde que você comece com o pescoço na linha primeiro, eles terão a ideia de que ninguém está disposto a aceitar seu trabalho

Em geral, tente impressionar com eles que deseja tornar o trabalho mais agradável e que precisa da ajuda deles para fazê-lo.

Os estagiários podem ser uma boa ideia, eles serão subordinados diretos aos desenvolvedores atuais, para que não se sintam ameaçados.

À medida que a empresa cresce, você precisará de desenvolvedores antigos E daqueles que fizeram isso após o estágio.

Eu acho que isso pode funcionar.

Geralmente, quando algum gerente de repente começa a se preocupar com a documentação e o planejamento de sucessão, é um forte sinal de alerta de que os programadores estão prestes a ser demitidos ou demitidos. É um desvio do comportamento gerencial típico e preocupações que desencadeiam todos os tipos de sinais de aviso nos programadores.

Todos são instruídos a documentar todos os seus procedimentos e processos

Nível 3 de " Sinais de alerta da desgraça corporativa ".

Como alternativa, um ensaio sugere que encorajamos uma cultura de " ascensão ou saída ", embora o contra-argumento seja o fato de poucas empresas possuírem uma carreira técnica que, de alguma forma, se assemelhe ao espectro financeiro e de poder que a escada (des) gerencial da carreira contém.

Com base no conceito de documentação completa que o @ammoQ iniciou em sua resposta ...

Um bom gerente trabalha para desenvolver as habilidades de seus subordinados diretos, para que qualquer um deles possa substituí-los. Faça seus desenvolvedores entenderem que um funcionário que fornece total transparência de seu trabalho é mais valioso do que aquele que mantém todo seu trabalho em segredo e oculto. Se o desenvolvedor "secreto" morresse hoje, seria um enorme custo para a empresa recuperar esse conhecimento perdido. Se o funcionário de "divulgação completa" morresse hoje, a empresa ainda estaria perdida, mas seria menos devastadora. Portanto, o funcionário 'divulgação total' tem mais valor.

Qualquer funcionário que tente manter o conhecimento oculto para se tornar imune a ser demitido também se torna imune a uma promoção. Você não pode mover um desenvolvedor para uma posição mais desafiadora e recompensadora se não houver ninguém para concluir as tarefas mundanas com as quais eles estão sobrecarregados hoje. Se as tarefas mundanas forem totalmente documentadas e divulgadas, você poderá contratar um novo desenvolvedor júnior para preencher e promover o desenvolvedor anterior para uma posição mais sênior.

Isso significa que você também precisa documentar o que faz e fornecer treinamento para cada um de seus subordinados diretos. Dessa forma, se você morresse hoje, um deles poderia substituí-lo até que uma substituição em período integral fosse encontrada.

Antes de começar a trazer novos programadores, peço a cada um deles para ajudar a criar seu próprio legado documentado.

Ou com um wiki ou uma bíblia com três anéis de documentos sobre todos os aspectos de seu trabalho.

Ou, se você quiser uma documentação realmente detalhada e completa, contrate um escritor técnico, entreviste cada programador e crie uma documentação de tudo o que todo mundo faz, diariamente, semanalmente, mensalmente, anualmente.

Em seguida, faça uma versão wiki, na qual o programador possa atualizar / editar / participar / comentar.

Então você tem um sistema que crescerá com o tempo e será a curva de aprendizado aprimorada para qualquer novo programador.

Honestamente, não é aconselhável que o programador esteja preso em uma área central, realmente vale a pena treinar, cruzar o trabalho central.

Então você pode usar seu pessoal existente, quando uma pessoa tira férias ou algo assim.

Sempre que um de seus programadores estiver doente, ligue para ele repetidamente com perguntas e problemas.

Toda vez que um de seus programadores estiver de férias, ligue para ele repetidamente com perguntas e problemas.

Logo eles perceberão que é melhor para eles e para a empresa não ter pessoas solteiras responsáveis ​​pelas áreas principais.

Ninguém quer ser atropelado pelo ônibus, mas também não quer assumir o projeto de outra pessoa em pouco tempo e mantê-lo também. Então todo mundo corre o risco de sair do negócio.

Se você está desenvolvendo silos, precisa começar a mover pessoas de um projeto para outro. Comece com a documentação, a revisão do código ou a correção de um bug simples. Qualquer pequeno ato de proteção / territorialidade do código deve ser tratado antes que isso fique fora de controle.

Ter um especialista solitário em um pedaço do seu código é uma ilusão de eficiência.

Alguém já quis ir de férias?

Já tive muitas outras empresas em risco devido a erros estúpidos da gerência. Você não falhará e queimará se um ou dois engenheiros forem embora, apenas precisará trabalhar um pouco mais por um tempo. Nossa, eu gerencio uma equipe offshore que perde alguém a cada trimestre. Comece a mover as tarefas. Hoje.