Estimativas de duração de tarefas com Fibonacci
Estimar a duração de uma tarefa é sempre um exercício de alguma incerteza. Quando mais complexa essa tarefa ou quanto mais ela se pode prolongar no tempo, mais incerteza existirá sobre a sua duração.
https://www.metodoagil.com/planning-poker/planning_poker_cone_da_incerteza/
Uma das "teorias" no mundo do desenvolvimento de softwares, usa metodologias ágeis, atribuindo às tarefas não directamente um custo de horas, mas sim um custo ou unidade de esforço para realizar determinada tarefa.
Sendo a actividade de engenharia, em concreto o traçado de vias de comunicação muito dependente de softwares e quase se poderia transpor a ideia de programação para este tipo de tarefas. Assim podemos encarar um projecto rodoviário ou ferroviário como um conjunto de ordens que se dão a um software. Seja um projecto desde o zero ao produto final, sejam alterações pontuais por exemplo numa directriz ou rasante.
Para atribuir o nível de esforço a uma tarefa, poderíamos usar uma escala linear de números. Por exemplo, num trabalho muito preliminar, apenas para o estudo de soluções em planta, a alteração de um raio, poderia ser uma tarefa de nível 1. A alteração de um raio num projecto de execução já num estado adiantado poderia ser uma tarefa de nível 100 (imagine que seria necessário alterar desenhos já feitos...). Podemos pensar que a complexidade das tarefas não é assim tão proporcional, na medida em que o seu nível de esforço é maior implicam mais alterações e supostamente na nossa actividade de engenharia "vial" interferências com outras especialidades e outros motivos que se poderiam encontrar para que a linearidade não seja uma escolha acertada. Assim a solução adequada é usar uma escala por exemplo exponencial... em metodologias ágeis usa-se por vezes uma escala relacionada à sequencia de Fibonacci.
1, 2, 3, 5, 8, 13, 21, 34 ...
Podemos desde já colocar um limite à complexidade de uma tarefa, por exemplo 21 ou 34, e se necessário for dividir alguma tarefa que tenha um nível maior que estas em sub-tarefas.
Em conjunto com esta ideia, podemos estimar que uma esquipa, ou uma pessoa pode executar por semana uma determinada quantidade de esforço. A título de exemplo, um engenheiro de traçado poderia executar 30 unidades ( 6 por dia...?). Temos assim um ponto de partida adaptável conforme a evolução deste sistema seja implementado.
A ter em conta também para a atribuição do esforço, as condições de trabalho e comunicação; a clareza de objectivos; a facilidade proporcionada pelo software ... O nível de detalhe do projecto é muito importante. Alterar um raio num estudo de soluções não é o mesmo que alterar um raio num projecto de execução.
A título de exemplo, algumas actividades:
Seria necessário refazer os perfis longitudinais de um eixo, a outra escala. Para refazer esses desenhos em ISPOL podemos dizer que seria uma tarefa de nível 1 ou 2.
Alterar a rasante num projecto base de um ramo de Auto-estrada com implicação na zona de influência do AE, podemos dizer que é uma tarefa de nível 5 ou 8.
Com os dois exemplos acima um engenheiro teria ocupação para 1 ou quase dois dias.
Não esquecer depois as actividades de outras pessoas, como desenhadores, engenheiros de outras especialidades, direcção etc...
Esta estimativa de duração de tarefas pode ser ajustada em reuniões semanais com a equipa.
Comentários
Enviar um comentário
Obrigado pelo seu contacto.