[quote=romarcio]Vamos dizer que você trabalha 8 horas diarias (8-12hs e 14-18hs)e participa do projeto X.
As 8hs você começa e liga o timer. As 8:30 você sai do PC para ir tomar um café e retorna as 8:45.
Lá pelas 9:30 sai de novo para ir ao banheiro e retorna as 9:40.
Lá pelas 10:40 sai de novo para atender seu telefone e volta lá pelas 10:50.
E assim vai o dia até chegar as 18hs.
No final do mês você vai enviar o relatório de horas do time tracker para seu gestor e ele vai ver que de 8 horas diarias, você gastou 7 trabalhando no projeto e 1 hora fora do projeto.
Outro motivo é caso você tenha mais de um projeto para trabalhar, dai vai marcar separadamente o horário para cada projeto. E no dia da entrega dos projetos, o gestor vai ver que você trabalhou 20hs no projeto X e 18hs no Y.
As vezes, manutenção e inclusão de novas funções no sistema são calculadas através de horas gastas no processo. Então essas horas marcadas também podem servir para eles saberem quantas horas devem cobrar do cliente.[/quote]
Veja que as duas se enquadram nas situacoes que eu citei acima.
-
O que importa para o custo eh quanto eu paguei pelo seu tempo de participacao no projeto, nao quanto tempo de fato voce ficou sentado em frente a maquina. O tempo em que voce estava tomando cafe, estava no banheiro ou estava ao telefone eu tambem estou pagando, portanto isto tambem faz parte do custo do projeto. E existem formas melhores de se medir a produtividade dos desenvolvedores do que contando o tempo em que eles ficam em frente a maquina. Este eh um calculo falho, cujo resultado nao me serve de nada. O que eu quero saber é quanto eu gastei no fim das contas, nao micro-dividir para saber quanto tempo eu estou gastando com funcionarios tomando cafe. Isso é irrelevante a nao ser que eles passem boa parte do dia na sala de cafe. Mas eu vou comecar a perceber isso a partir do momento que o ritmo do trabalho diminuir. Ou seja, quando menos funcionalidades estiverem sendo entregues para o cliente, comparadas ao ano/mes/dia/semana anterior.
-
Essa é a pior situacao, voce nao deve atribuir varias tarefas a mesma pessoa ao mesmo tempo. Entao, se alguem tem que trabalhar em mais de um projeto, voce deve garantir que seja feita uma coisa de cada vez. Depois de terminada a tarefa A (cujo esforco voce vai conseguir descobrir pela data/hora de inicio e fim), comeca-se a tarefa B. No fim somam-se as tarefas dos mesmos projetos e voce tem o custo deles em separado. Mas repare que isto vale para os projetos de manutencao, quando nao faria sentido ter um programador para cada projeto porque nao ha demanda para isso. Em casos de projetos maiores, deve-se manter programadores focados exclusivamente nisto.
Isso eh tao certo quanto dois e dois, quatro. Se voce tem tres tarefas de uma semana, fazendo uma de cada vez, apos a primeira semana, voce tem uma pronta, apos a segunda voce tem duas, e finalmente voce tem a terceira apos tres semanas. Se voce tentar fazer as tres ao mesmo tempo, ao fim da primeira semana voce nao tem nada pronto, ao fim da segunda tambem nao e ao fim da terceira muito provavelmente tambem nao vai ter nada ainda. Voce gastou um tempo consideravel tirando o foco de uma e iniciando outra, depois indo para a terceira e voltando e assim por diante.
Mas mesmo assim vamos desconsiderar o tempo de mudanca de tarefas, fazendo uma de cada vez voce leva o mesmo tempo do que fazendo aos tres ao mesmo tempo, com a diferenca de que voce tem coisas prontas antes.
O grande problema esta na dificuldade de priorizar, normalmente os gerentes fracos so conseguem descobrir a prioridade de algo depois que ele vira urgente, ai larga tudo de lado para apagar o incendio. Depois, aquilo que ficou de lado comeca a se mostrar urgente tambem, e la vai o gerente direcionar os esforcos para o fogo. Eles gostam de ter a sensacao de que “esta andando”, como se fosse ficar pronto naturalmente, apos o tempo estimado, mesmo sendo levado com mais tres ou quatro funcionalidades. Mas no fim das contas estao eles mesmos atrasando os trabalhos.