As empresas devem considerar funcionários remotos ou seguir os funcionários locais? [fechadas]

Os desenvolvedores de elite podem ser 10x mais produtivos que um desenvolvedor comum.

Claramente, é mais fácil encontrar um desenvolvedor de elite em todo o mundo do que no quintal de uma empresa.

Se uma empresa não estiver localizada em um hot spot de programação, eles deveriam considerar contratar pessoas que trabalham em casa?

Trabalhei como e gerenciei funcionários em ambas as situações e combinações de ambas. Fiz as seguintes observações:

• Os funcionários juniores não trabalham remotamente. Eles exigem uma boa e pessoal relação de trabalho com um mentor. Acho que minha equipe júnior prefere esperar que eu esteja disponível do que perguntar alguma coisa ao desenvolvedor remoto sênior (e bom).

• Certifique-se de que qualquer pessoa que considere trabalhar remotamente seja eficaz quando autoguiada e não saia tangente.

• A equipe remota pode se isolar com muita facilidade e não se sentir parte de uma equipe, a menos que seja feito um esforço especial para incluí-la. Esse isolamento pode levar a um mal-entendido do driver de negócios específico de um projeto ou a interpretar os eventos de maneira negativa.

• Nunca faça com que um contratado trabalhe remotamente, a menos que tenha o incentivo certo para executar.

• Ao trabalhar com um membro remoto da equipe, certifique-se de que eles obtenham acesso equitativo aos recursos, incluindo controle de origem, material de referência, etc.

• Organize as reuniões presenciais sempre que possível. Isso incentiva uma colaboração de equipe muito melhor, pois as pessoas se sentem mais confortáveis ​​com aqueles que conheceram.

Talvez.

Seus benefícios são:

• Acesso a um conjunto maior de candidatos (como você indica)
• Acesso a pessoas que desejam trabalhar em casa

Seus custos são:

• Comunicação mais difícil - você não pode simplesmente puxar alguém para uma sala de conferências gratuita.
• Não há garantia de comunicação instantânea - se você está bloqueado e aguarda Joe Remote, não pode simplesmente ir até a mesa dele e perguntar o que está acontecendo. Se ele é incomunicável, você é SOL.
• Nem todos os desenvolvedores trabalham bem remotamente. Alguns precisam que o ambiente estruturado seja produtivo.
• Geralmente, não há garantia de horários correspondentes - por exemplo, uma pessoa que trabalha em casa pode dormir ou uma pessoa em outro fuso horário pode estar acordada e trabalhando em horários diferentes dos seus.

Atwood tinha um artigo decente sobre isso.

Edit, do artigo de Atwood:

O tamanho mínimo da equipe remota é dois. Sempre tenha um amigo, mesmo que ele esteja em outro continente do outro lado do mundo.

Somente veteranos grisalhos que adoram codificar precisam se candidatar a cargos de desenvolvimento remoto. A orientação de iniciantes ou programadores casuais simplesmente não funciona remotamente.

Para serem eficazes, as equipes remotas precisam de total autonomia e de um líder (PM, se desejar), que possui uma visão forte e o poder de executar totalmente essa visão.

As empresas que não sabem o que estão fazendo não devem ter funcionários remotos. O gerente mais incompetente só sentirá que você está trabalhando duro se ele puder realmente vê-lo sentado no seu computador digitando bastante. Além disso, participar de reuniões inúteis é um dos melhores indicadores de comunicação forte e gerenciamento de tempo.

Quando você tem pessoas que sabem o que estão fazendo e são gerenciadas por quem sabe o que estão fazendo, isso realmente não importa quando, onde ou como elas funcionam. Eles fazem o que é necessário quando é necessário.

Estou em uma empresa que paga alguém para fazer um depósito direto da folha de pagamento E imprimir um cheque em papel falso (papel de cheque pré-impresso real), coloca-o em um envelope e o coloca em nossas caixas de correio. Acho que o email interno não é seguro o suficiente e o que faríamos com todas essas verificações? Acredito que este edital veio do Departamento de Redundância. Se alguém trabalhasse remotamente, haveria um custo extra de postagem, uma boa razão para não deixar as pessoas trabalharem remotamente - muito caras.

Não há problema em ter pessoas remotas se duas coisas são verdadeiras:

1. As pessoas são altas o suficiente e têm um histórico que significa que você confia nelas para fazer as coisas sem muita supervisão e para ser proativo em pedir ajuda ou informar se elas estão presas.
2. O "pulso" do seu projeto é curto o suficiente (de preferência diariamente), para que quaisquer problemas com o arranjo sejam identificados rapidamente. Não me refiro apenas a alguém dizendo que fez algo em um relatório de status ou verificando um item de uma lista de tarefas, mas progresso real e demonstrável com um recurso. É claro que existem várias maneiras de fazer isso, mas o truque principal é dividir as tarefas em pedaços pequenos o suficiente para serem executados em um dia ou menos e validar se essas tarefas estão sendo concluídas.

Atualmente, existem tecnologias impressionantes que facilitam a atuação em equipe sem estarmos sentados próximos um do outro.

O IRC, o Jabber ou um software similar do tipo bate-papo facilita muito manter todos os membros da equipe conscientes um do outro, o que estão fazendo e se sentirem à vontade para discutir os problemas imediatamente. Uso o IRC com os grupos do freenode frequentemente e é como ter um grande grupo de desenvolvedores em mãos, agindo como um cérebro coletivo gigante. A Apple tem um bom cliente de bate-papo integrado ao Mac OS que também suporta videoconferência, especialmente eficaz em seus laptops.

Imagine como seria se a empresa tivesse seu próprio servidor de bate-papo interno, com grupos para departamentos, projetos e grupos de interesse relacionados ao trabalho. Um desenvolvedor pode fazer uma pergunta onde seria visto em toda a empresa, para que outro desenvolvedor em qualquer outro lugar pudesse vê-lo e responder. As paredes do escritório desaparecem, disparos de comunicação e práticas recomendadas e compartilhamento de código podem acontecer por conta própria, sem que alguém empunhe um bastão.

Um de nossos engenheiros de teste de carga trabalha remotamente cerca de 1/3 do ano, às vezes de sua casa, a cerca de 48 quilômetros de nosso escritório, outras de fora do estado. Ele é tão eficaz no escritório quanto no exterior, porque mantém o software de bate-papo em funcionamento e liga para nossas teleconferências.

Meus colegas de trabalho na minha equipe sentam-se no corredor para que eu não possa vê-los ou ouvi-los. Eu não sei quando eles estão em seus cubos, então eu lhes envio uma mensagem de bate-papo, e eles respondem o mais rápido possível. Faço a programação da equipe com um de nossos engenheiros em outro local. A mesma coisa ocorre; Fazemos ping-nos regularmente com perguntas e / ou pensamentos insanos, e se precisarmos acelerar o ritmo, compartilharemos uma tela e ligaremos para o telefone. Não sei dizer se ele está no escritório ou em casa, e isso não importa. Trabalhamos da mesma maneira.

Nosso departamento de controle de qualidade é dividido em duas cidades diferentes em diferentes estados; nossos engenheiros estão espalhados por nossa cidade em cerca de quatro locais diferentes, mas é difícil saber porque usamos nossos telefones e conversamos regularmente. Todos nós trabalhamos remotamente um com o outro na realidade, então qual é a diferença? A diferença é a mentalidade corporativa.

Existem muitas vantagens em trabalhar remotamente e, principalmente, é preciso uma mudança de mentalidade para o empregador tentar descobrir que os funcionários respondem positivamente a ele.

Eu acho que também depende do que você quer que eles façam.

Se eles estão contribuindo para a arquitetura e o design geral do software, pode ser um problema.

Se eles estão recebendo especificações detalhadas e métodos de produção, não muito.

Edit: Para esclarecer, estou tentando dizer que, se o trabalho puder ser isolado, não há problema em dar a um funcionário remoto. Se, no entanto, precisar de discussões detalhadas e reuniões de projeto de arquitetura, isso é muito difícil de fazer em diferentes países.