Estimación de las propias tareas

15. September 2011 22:51 by Oscar.SS in Gestión Proyectos, Personal  //  Tags: , ,   //   Comments (2)

Recuerdo en una ocasión, concretamente en el transcurso de una entrevista de trabajo, un empleador me preguntó si me veía en condiciones de estimar la duración de las tareas durante el ciclo de vida de un desarrollo.

Lo cierto es que la pregunta me desconcertó un poco, la entrevista era para un puesto de programador, y no me esperaba para nada una pregunta de este tipo. Quizás simplemente quería estudiar mi reacción ante una pregunta algo atípica para el puesto.

Yo respondí, con cierta seguridad (falsa seguridad), que me veía en condiciones de estimar con acierto mis propias tareas, pero quizás con menos exactitud las tareas ajenas a mi implicación directa...¡o algo así!

Mi interlocutor con cierto aire de condescendencia, me contestó que no me preocupara, que precisamente eso, el estimar las tareas de un proyecto y por ende la duración del mismo, es precisamente la tarea más complicada de esta profesión. 

Pues bien, sin darme cuenta mi respuesta no fué en absoluto acertada. Vengo observando desde hace algún tiempo que incluso realizar una estimación con exactitud de las propias tareas es mucho más difícil de lo que parece. Y supongo que esto no me sucede a mí solo....¡eso espero!  ;-)

Por un lado opino que este desacierto en la estimación de los pequeños módulos de un proyecto de los que en última instancia somos únicos responsables puede tener múltiples consecuencias negativas. Y por otro lado creo que esta habilidad, como todo en este mundo, se puede desarrollar siempre que pongamos el foco en ella y la practiquemos con los métodos que consideremos oportunos.

 

Algunas consecuencias negativas

En primer lugar me gustaría señalar el daño al amor propio. Parte de tu trabajo es códificar, analizar, implementar, desplegar, etc. Pero también lo es conocer que tiempo te puede llevar realizar cada una de estas tareas. No porque te lo pida un responsable de proyecto o un cliente, simplemente porque es parte de la forma en la que organizas tu trabajo e incluso hasta tu vida. De igual forma que te molestas (yo me cabreo) cuando un algoritmo no hace lo que tiene que hacer, o cuando se te ha olvidado comprobar una referencia nula, igualmente debes comprometerte con el hecho de conocer que partes de tu trabajo te lleva más o menos tiempo ejecutar.

Puedes perder la confianza de tu responsable de proyecto. Si continuamente le das estimaciones erróneas, se entiende que demasiado optimistas, este dejará de confiar en tu habilidad para determinar los tiempos de tu trabajo y comenzará a confiar en su habilidad que puede ser incluso peor que la tuya...¡esto lo haces tú en dos días!

Es un marketing nefasto para el trabajo realizado. Por muy bien que compile tu código (ni que unos compilaran mejor que otros), por muy bien documentado que esté tu código (aquí si), por muy perfecto que sea tu modelo de datos, etc y etc...Si le prometiste 3 días y se lo entregas en 5, será este hecho el que se grabará en su cabeza (y posiblemente en la del cliente) no teniendo importancia alguna el resto de tu fantástico trabajo.

Puede suponer una carga adicional de trabajo para tus compañeros. Al crear esta desconfianza es posible que otro compañero tenga que ayudarte o darte pequeños empujones (con el tiempo collejas) y como consecuencia te toque pagar las "cañitas en el after work".

 

¿Como desarrollar esta habilidad?

Aquí es cuando yo me tiro a la piscina y comparto con vosotros algo que se me ha ocurrido y que por lo tanto tiene la validez de...permitirme la expresión...¡un billete de 1 euro con la cara de Franco!

En primer lugar, como he comentado al principio, debemos poner el foco en el problema. Empezar a concienciarnos de su importancia y tomar pequeñas medidas, siempre que las circunstancias lo permitan, para poco a poco perfeccionar esta habilidad.

Una posible actuación podría ser confeccionar un registro de las distintas tareas que llevamos a cabo durante los proyectos. 

Este registro nos permitiría conocernos un poco mejor en dos aspectos distintos. Por un lado que tipos de tareas nos llevan más tiempo realizar, y por otro, cuales son las tareas en las que más nos equivocamos a la hora de estimar su duración.

Soy consciente que este trabajo adicional solo es posible en ciertas circunstancias, dependiendo siempre del estado actual del proyecto, de la presión, etc. Pero creo que podría ser muy provechoso conocerse y poco a poco poder ofrecer una estimación más exacta.

Es más, me voy a envalentonar, y digo que debería estar incluido (si no lo está ya) en la definición de Work Items del TFS y poder aprovechar mediante minería de datos esta información. Por cierto, para todos aquellos que hacéis uso de la Técnica Pomodoro, quizás se podría medir la estimación en pomodoros.

Es cierto que no es una ciencia exacta, la misma tarea en distintos proyectos no tienen porque tener la misma duración, pero no deja de ser un intento o acercamiento al problema y sobre todo a conocernos un poco mejor en una faceta, creo yo, descuidada por muchos de nosotros como profesionales.

En fin, espero vuestros comentarios...¡portaros bien!  ;-)

Comments (2) -

JAGH
JAGH
10/4/2011 3:55:32 PM #

El mayor problema es cuando estimas sobre lo desconocido, en las cuales tienes que ir ajustando tus estimados conforme pasa el tiempo, ya sea para ir agregando tiempo o restarlo en caso de que resulte fácil aquello que es "desconocido", ser sincero casi nunca falla sobre todo si lo comunicas lo mas pronto posible.

Oscar.SS
Oscar.SS
10/4/2011 4:34:30 PM #

No puedo estar más de acuerdo contigo Jagh.

Evidentemente lo complicado es acertar sobre lo desconocido y posiblemente lo que he propuesto no sirva de nada. Tan solo era un intento por encontrar un patrón común en lo que es desconocido.

Como siempre muchas gracias por tu opinión!!

Recent Comments

Comment RSS

Month List