Como controlar o trabalho de programadores (outsourcers) [closed]

Você deve definir métricas e metas de desempenho que eles devem atender. Se você estivesse fazendo algum tipo de Agile e / ou SCRUM, não teria esse problema. Existem muitos aplicativos gratuitos para ajudar com isso. Rally (rallydev.com) é ótimo (não é grátis !!)

Defina linhas de tempo e metas e mantenha-as. Parece que você precisa aplicar habilidades gerenciais básicas. Se eles não produzem, então se livre deles. Você paga por resultados. Você daria US $ 10 para Mc Donalds por 1/2 de um hambúrguer?

Se você é um desenvolvedor de qualquer tipo, então você deve ser capaz de dividir um projeto com estimativas de tempo para cada parte. Dê as estimativas para os desenvolvedores e você e sua equipe podem discuti-los e concordar. Se você disser 5 horas e eles disserem 15, faça-os explicar por que serão 15 e não 5. Mesmo que você não saiba do que eles estão falando, você pode sentir o cheiro da BS. Chame-os e faça-os explicar. Isso vai reduzir a porcaria. Isso é o que faço todos os dias e funciona até com funcionários difíceis.

Sua única medida deve ser a realização.

O trabalho está feito?

Não? Obtenha outro desenvolvedor.

É tão fácil que ainda não entendo por que as pessoas tentam controlar outras pessoas (impossíveis de fazer), enquanto o que você deve fazer é parar de trabalhar com elas.

Se eles são terceirizados ou offshore, o problema é o mesmo. A única diferença é a localização e o fato de que é mais difícil tentar controlar alguém que está a 4000 km de distância.

Se você não é um desenvolvedor ou gerente de projetos experiente do que você realmente não tem qualificações para tentar gerenciar uma equipe de desenvolvimento e tentar fazê-lo só vai levar à frustração e uma perda de dinheiro a longo prazo. Contrate um gerente de equipe em quem você possa confiar, terceirize para um fornecedor (em vez de contratar programadores individuais terceirizados) ou aprenda os detalhes do desenvolvimento de software.

Seu trabalho como gerente não é controlar os programadores, é dar a eles tudo o que precisam para realizar o trabalho.

Se uma tarefa não progredir tão rápido quanto você deseja, não culpe o proprietário da tarefa, mas analise o que está bloqueando. Nem sempre é culpa do programador. Pode ser uma falta de ferramentas corretas, uma entrega atrasada na documentação de entrada, um ar condicionado quebrado ...

Como regra geral, quando enfrenta um problema, encontre a causa raiz e resolva-o, não encontre um responsável.

Claro que vai custar tempo e dinheiro. O software não é gratuito, nem mesmo o Linux. Na verdade, você só vai conseguir o que você paga.

Para começar, esse é um problema difícil, pois realmente não há uma boa métrica que você possa usar para classificar a produtividade de um desenvolvedor em relação a outro. Se você usar algo como linhas de código (LoC), você pode descobrir que um desenvolvedor só escreve 1000 + LoC, mas se ele está apenas obtendo informações do banco de dados, é quase tão difícil quanto o 200 LoC que alguém escreveu para analisar dados que está sendo inserido, ou mesmo a única linha de código que foi escrita por alguém perseguindo um bug desagradável?

Uma ideia que me veio à mente foi ter um sistema de rastreamento onde as tarefas que precisam ser feitas seriam inseridas (ex: "Get x do banco de dados e mostradas aos usuários", " Corrija o estouro de pilha, mas no módulo y ") e faça com que todos os seus desenvolvedores" votem "em quantas horas eles acham que seriam necessários para executar cada tarefa. Depois de votar em todos, você pode avaliar isso e ver como eles se comparam ao que os desenvolvedores estão realmente resolvendo o problema. Provavelmente haveria um pouco de calibração envolvida e ainda há maneiras de se jogar o sistema, mas pode ser uma maneira de obter uma idéia justa do que eles esperam um do outro e, portanto, uma métrica justa a ser usada para julgá-los. / p>     

Você não deve medir a produtividade dos desenvolvedores - o gerente deve fazer isso em vez de você, porque ele está lá e você não está.

Torne obrigatório. No final de cada dia, solicite que as equipes enviem um scrum diário na forma de um e-mail ou outro, respondendo às seguintes perguntas: 1. O que eu fiz hoje? 2. O que eu vou fazer amanhã? 3. O que eu preciso do Team Leader, para que eu possa fazer meu trabalho amanhã?