Os programadores falamos de reescribir un programa e na nosa voz non hai un rastro de dúbida ou escribimos unha proposta para substituír Windows por Linux e non nos treme o pulso, pero cando alguén nos pregunta cando imos rematar, ficamos paralizados, trémenos todo o corpo, sóbenos a presión arterial e comezamos a farfallar.
É un tema complicado, o das estimacións. Os nosos xefes queren saber cando vai estar arranxado un erro, ou engadida unha función, ou rematado un programa, e nós non sabemos que lles dicir, porque moitas veces é coma nas películas: calquera cousa que digamos pode ser usada na nosa contra.
“O afeitado con présa tarda unha hora, e sen présa tarda quince minutos.”
Sobre a maneira de estimar o tempo, circula moito o consello de adiviñar o mellor que poidas, multiplicar por tres e subir unha dimensión. Ou sexa: se pensas que che vai levar dous días, di seis semanas. É unha broma, pero non totalmente: moita xente observou que se din “dous días” e non rematan ao cabo dese tempo, as consecuencias son bastante desagradables para eles. Visto iso, mellor poñer unha marxe de seguridade.
Moitas veces, o motivo polo que non sabemos o tempo que nos vai levar facer unha tarefa é que nunca a fixemos antes. É como se alguén me pregunta canto tempo vou tardar en facer unha parece de ladrillos. Internet dime que un obreiro pode poñer mil ladrillos nun día, pero sospeito que eu, se despois do primeiro día quedan dez ladrillos de pé, xa podo estar contento.
Co paso do tempo, despois de escribir moito código e facer as outras cousas, comezamos a desenvolver unha intuición sobre o tempo que nos leva facelas. Esa intuición, porén, só serve para nós mesmos: eu sei canto me vai levar a min, pero non canto lle vai levar aos meus compañeiros.
Outro factor que afecta á fiabilidade da estimación é o tamaño da tarefa. Sempre é chistoso cando alguén pretende estimar o tempo que vai levar completar un proxecto enteiro. Divídeno en tarefas, tratan de estimar cada tarefa individualmente, e suman os tempos. Se son especialmente sofisticados na súa tolemia fan un diagrama de Gantt para ser máis precisos. No final dese proceso teñen un número que inscriben na documentación do proxecto como “neste día rematamos”.
Ese número é pouco mellor que un número aleatorio: a probabilidade de que o proxecto estea rematado o 24 de maio de 2024 (ás catro e media da tarde) é ínfima, e iso sabémolo todos.
As estimacións non son un número ou data determinados, senón que son un rango de valores. Cando dicimos “vou rematar isto nunha semana” na realidade queremos dicir “vou rematar isto nalgún momento entre os próximos cinco e dez días”. Polo tanto, ao sumar as estimacións de cinco tarefas de “unha semana”, o resultado non é “dentro de cinco semanas” senón “entre 25 e 50 días”.
Esta é unha maneira na que podedes curar a vosa parálise á hora de dar estimacións: non deades estimacións precisas, porque é imposible e non é o que o voso xefe de proxecto ou cliente quere. Case sempre, o que queren é un rango de valores ou datas nas que vós confiedes:
“Penso que mañá ou pasado remato.” “Vai estar listo no final da semana que vén ou no principio da outra.” “Isto vaime levar como mínimo un mes, pero a febreiro non chega.”
A partir de agora, probade a dar esa clase de estimacións, ou a pedilas se estades a xestionar un proxecto, e dicídeme como vos vai.
A ilustración desta Folla procede dun gravado de Thomas Rowlandson.
1 comentario