A grande besteira que é o timesheet para medição de produtividade

Assuntos Gerais
#1

Eu gosto desse forum pois aqui tem gente de diversos perfis, tem gente experiente, outros começando e outros no meio do caminho. Mas em sua maioria são pessoas técnicas que com certeza já esbarraram nessa babaquice que é o tal timesheet.
Pra quem não está familiarizado com este termo irei explica-lo. É um relatorio de tudo que voce fez no dia, todas as suas atividades e quanto tempo gastou nelas. Existem muitos tipos de visões dessa coisa, seja por componentes, tarefas ou o que o gerente quiser medir.
Isso na esperança de que voce será preciso como um relógio suiço dizendo exatamente quantas horas e minutos gastou para fazer aquela famigerada atividade. Os problemas reais começam para voce quando o cara quer com isso dizer quem é bom e quem não é. Isso mesmo, pela ferramenta ele espera dizer quem é o mais produtivo. :lol:

Sério, esse negocio de querer usar ferramentas administrativas da época de Henry Ford na informatica já chegou ao limite. Alguém tem que faze-los parar pois nós não apertamos parafusos! :x Como é que alguem quer medir produtividade com base em relatorios furados e ilusórios.
Pensem nisso. Informatica não é um apertar de parafusos em uma fabrica com uma linha de produção. Já passou da hora desses caras acordarem para a vida! :roll:

Eu já vi isso ser implantando em diversos lugares e empresas e sempre era mascarado, injusto e premiava os piores da equipe. Os caras que faziam tudo rapidinho pra ir embora mais cedo. Pensem nisso tambem.

#2

Calma lá amigão. Não é a faca que mata, mas a mão que a usa! e esse mesmo instrumento que serve pra matar, serve como ferramenta quando bem utilizado.

Concordo com você que essa história de usar timesheet pra comparar desempenho é furada.

Agora, que ver uma utilidade do timesheet? VOCÊ pode usar o timesheet para medir quanto tempo levou em uma tarea e utilizar isso futuramente em tarefas semelhantes. eu faço minhas timesheets e as uso dessa forma. E acredite ou não, elas são úteis. Mas elas são utéis PRA MIM, não pra outra pessoa. E elas são úteis quando tenho que fazer algo que já fiz antes.

#3

Eu uso uma planilha pessoal das coisas que estou fazendo, não efetivamente para ver minha produtividade, pois acho tolice extrema achar isso mais importante do que tudo, mas faço uso dessa planilha pessoal apenas para saber exatamente o que fiz e quando fiz.

Às vezes posso esquecer o que fiz, digo, se for um detalhe pequeno, pode-se perder no tempo, assim, registro o que fiz, quando fiz e a aplicabilidade disso, entretanto, como dito antes, essa planilha é apenas para meu uso, e acho ela boa para me orientar. Mesmo assim não sou totalmente diligente à ela.

Mas estou de acordo com as “medições” de produtividades e suas fragilidades.

#4

Estive discutindo esse assunto com meu Líder e ele foi incisivo de que o time sheet é essencial nos projetos…

Alguém conhece algum outro tipo de controle? Ou aprimoração do time sheet convencional?

#5

Ex: Onde trabalho, apontamos horas da seguinte maneira:

Suponhamos que esteja alocado no projeto XPTO e ele levasse 500h sendo sua locação de 75%, diariamente lançando 6h de trabalho, se já trabalhou 10 dias foram então 60h de esforço… Mas, com base nisto não é seguro se basear para saber o status/andamento do projeto etc, visto que muitos GPs não são técnicos, isto é, provavelmente não entenderia caso o Analista Programador detalhasse seu real serviço… Concorda?

#6

Mas é um erro medir o progresso do projeto com base em horas trabalhadas.

Por exemplo, um projeto prevê 10 features, com uma estimativa de 1000 horas de desenvolvimento. Trabalhar 300 horas não quer dizer que o projeto andou 30%, quer dizer apenas que você trabalhou 300 horas; Pois nestas 300 horas você pode ter entregado apenas 1 feature.

Enfim, existem muitas falácias entre as atuais práticas de mercado. Apontamento de horas é uma delas.

#7

[quote=Grinvon]Eu uso uma planilha pessoal das coisas que estou fazendo, não efetivamente para ver minha produtividade, pois acho tolice extrema achar isso mais importante do que tudo, mas faço uso dessa planilha pessoal apenas para saber exatamente o que fiz e quando fiz.

Às vezes posso esquecer o que fiz, digo, se for um detalhe pequeno, pode-se perder no tempo, assim, registro o que fiz, quando fiz e a aplicabilidade disso, entretanto, como dito antes, essa planilha é apenas para meu uso, e acho ela boa para me orientar. Mesmo assim não sou totalmente diligente à ela.

Mas estou de acordo com as “medições” de produtividades e suas fragilidades.[/quote]

Estou de acordo e gosto desta ideia, gostaria de fazer mais isto, hoje só faço quando o projeto tem histórico problemático com um monte de gente mais preocupada em procurar culpados do que encontrar soluções.

A gerencia de projetos em TI infelizmente é péssima, ao menos nos lugares por onde passei. Tem muita gente que não tem formação na área e as vezes nem uma carreira interessante em termos de experiência para ocupar tal cargo. Muitos destes acabam utilizando estes artefatos de forma ineficiente e cometendo injustiças.

flws

#8

Isso é uma coisa que sempre questionei.
Como todo sistema, um timesheet depende da idoneidade da informação inserida. Agora, como garantir isso se o próprio GP pede para que insira horas em outro projeto, por que o que está sendo desenvolvido está com o planejamento estourado?
Além do que, essa medição está total e fundamentalmente fadada à boa vontade do sujeito lançar as horas de forma adequda, o que, convenhamos, nem sempre é o que acontece.
Claro, o profissionalismo de cada um é o que dita como ele irá proceder. Só que se eu sei que para o projeto ABC eu uso 10h e tenho 25 alocadas e no BCD eu uso 20 horas, mas tenho 15 alocadas, sei que posso “gambiarrar” a coisa.
E faço a mesma questão que o andredecotia, outras metodologias? O que seria mais eficaz?

#9

[quote=rmendes08]Mas é um erro medir o progresso do projeto com base em horas trabalhadas.

Por exemplo, um projeto prevê 10 features, com uma estimativa de 1000 horas de desenvolvimento. Trabalhar 300 horas não quer dizer que o projeto andou 30%, quer dizer apenas que você trabalhou 300 horas; Pois nestas 300 horas você pode ter entregado apenas 1 feature.

Enfim, existem muitas falácias entre as atuais práticas de mercado. Apontamento de horas é uma delas.[/quote]
Sem contar aquela estratégia de chegar para o desenvolvedor/analista ou o que seja e perguntar “Como está o projeto XDR?”. Ele, sem saber como está responde “70%”.
Alguém desconta as horas do café? Do cigarrinho (quem fuma)? Do tempo pra ler uma notícia na globo.com? Pra responder ao guj?

#10

[quote=fantomas]

A gerencia de projetos em TI infelizmente é péssima, ao menos nos lugares por onde passei. Tem muita gente que não tem formação na área e as vezes nem uma carreira interessante em termos de experiência para ocupar tal cargo. Muitos destes acabam utilizando estes artefatos de forma ineficiente e cometendo injustiças.

flws[/quote]
Uma coisa que sempre digo é que as empresas só veem que algo precisa ser mudado quando começam a ter prejuízos.
Se, utilizando coisas ineficazes eles ainda conseguem lucrar, por que eles irão investir em melhores profissionais ou metodologias?

#11

[quote=drsmachado][quote=fantomas]

A gerencia de projetos em TI infelizmente é péssima, ao menos nos lugares por onde passei. Tem muita gente que não tem formação na área e as vezes nem uma carreira interessante em termos de experiência para ocupar tal cargo. Muitos destes acabam utilizando estes artefatos de forma ineficiente e cometendo injustiças.

flws[/quote]
Uma coisa que sempre digo é que as empresas só veem que algo precisa ser mudado quando começam a ter prejuízos.
Se, utilizando coisas ineficazes eles ainda conseguem lucrar, por que eles irão investir em melhores profissionais ou metodologias?[/quote]

Isso é bem verdade. É por isso que existem empresas que crescem sempre e crescem bem, e existem aquelas que ao menor sinal de crise quebram.

#12

[quote]Mas é um erro medir o progresso do projeto com base em horas trabalhadas.

Por exemplo, um projeto prevê 10 features, com uma estimativa de 1000 horas de desenvolvimento. Trabalhar 300 horas não quer dizer que o projeto andou 30%, quer dizer apenas que você trabalhou 300 horas; Pois nestas 300 horas você pode ter entregado apenas 1 feature.

Enfim, existem muitas falácias entre as atuais práticas de mercado. Apontamento de horas é uma delas.[/quote]

Certo, mas isso aparece, pois a maioria das ferramentas de TimeSheet também tem o indicador do percentual de conclusão da tarefa. Nenhum gestor prudente olha para as horas, e apenas as horas.

Portanto, o gestor vê que a tarefa está levando mais tempo do que o estimado e pode tentar entender o por que. Ele também pode tomar a decisão de abandonar aquela tarefa, coloca-la na fila para priorizar outra mais importante, etc… Na pior das hipóteses, ele pode cortar outras tarefas com base nessa, ou pode simplesmente dizer para seus superiores o quão mais caro irá ficar o projeto.

Eu acho que o Timesheet sozinho é um péssimo indicador de produtividade (como praticamente qualquer indicador solitário).

Mas ele é uma ótima ferramenta, mesmo com a imprecisão inerente do lançamento, para acompanhar o projeto. Ele pode ser facilmente rateado para custo. Ele pode ser usado a favor do funcionário e, se usado corretamente em reuniões de Sprint, pode servir de feedback para que as pessoas e a equipe estimem melhor.

Não conheço nenhuma metodologia que não faça uso de algum tipo de timesheet.

#13

[quote=andredecotia]Estive discutindo esse assunto com meu Líder e ele foi incisivo de que o time sheet é essencial nos projetos…

Alguém conhece algum outro tipo de controle? Ou aprimoração do time sheet convencional? [/quote]

Sim,medir QUALIDADE ao invés de horas trabalhadas.

#14

Faz um ano que meu gerente substituiu as timesheets por um sistema de tickets.

Hoje utilizamos o OTRS para gerenciar as solicitações.

Nele o nosso único trabalho é notificar o fim da tarefa ou o fim das etapas. O sistema, por si só, já gerencia o tempo de cada atividade.

O modelo de ticket está atendendo nossas necessidades com mais precisão de que timesheets, no nosso caso as timesheets estavam demasiadamente atrapalhando os desenvolvedores quando procuravam novas atividades, buscar atividade não é trabalho do desenvolvedor, é do gerente de projetos, e este deve conhecer sua equipe e saber para quem deve alocar determinada tarefa.

No modelo de ticket, quando vêm a solicitação, o gerente repassa com o requisito e o tempo do prazo é contado a partir do momento que sinalizamos o início da tarefa. Concluída a tarefa, agente fecha o ticket e pronto.

Neste sistema temos controle de tudo: bugs, novas implementações, evolutivos, corretivos, chamados para a equipe de suporte, etc.

Antes eu achava que o timesheet me ajudava a dizer em quanto tempo eu elaborava a tarefa, mas a realidade a coisa opera totalmente diferente em desenvolvimento. Tem aqueles dias que sua produtividade é afetada por algum fator externo, e você viaja mais do que raciocina, assim uma tarefa pode levar o dobro do tempo, do contrário, quando a inspiração está em alta, é possível finalizar na metade do tempo. Fora o fator de você ficar preocupado de esquecer de apontar alguma tarefa no timesheet.

Sendo automatizado, o sistema garante que a tarefa foi executada em uma margem de tempo considerada real, pois o desenvolvedor não pode alterar a data de início, nem a de término. Parte dele a atenção de iniciar e finalizar a tarefa.

Isto posto, minha opinião final sobre timesheet:
É um sistema ultrapassado que permite adulteração dos dados das tarefas executadas, não sendo base confiável para medição de produtividade.

#15

Se o sistema conta tempo, sinto em informar, mas vocês tem timesheets.
Talvez não apareça para os desenvolvedores, mas parece para os gerentes.

É o que eu estava falando. Usar somente o tempo seria tão idiota quanto usar somente o percentual de tarefas concluidas.

Mas o tempo é uma informação importantíssima, e não vejo como gerenciar um projeto sem saber, mesmo que de forma aproximada, quanto tempo se gasta nas coisas.

#16

Com certeza Vini,mas o grande problema são os “gestores” que ainda acham que 2 dias geram 16 horas de trabalho ininterrupto.

#17

Assim como temos POGramadores, temos maus gestores…

#18