Estimar el tiempo
Una de las cosas más dificiles que se le pueden pedir a una persona es que estime el tiempo que empleará para concluir una tarea, y eso porque tiene que predecir el futuro, tiene que anticiparse a los imprevistos, a las complicaciones. Normalmente nos basamos en los fallos y los aciertos de otras veces que hemos tenido que estimar cosas similares, es decir, en las experiencias pasadas.
Para un programador esto se convierte en un suplicio, al menos para mi. Joel Spolsky dice que "sólo un programador puede estimar el tiempo que empleará en hacer una tarea", vale, pero hay tantos factores a tener en cuenta que estimar el tiempo se convierte en poco más que decir una cifra al azar... entre 5 y 15 horas... Está claro que mas o menos sabes cuanto te puede costar, pero ... SI TE DEDICARAS SOLO A ESO, si no tuvieras interrupciones, si el ordenador no se quedara colgado cuando menos lo espera, si no encuentras un bug en una librería que estás utilizando, si... si...
Si lo que estas haciendo es planificar todo un proyecto, la cosa se complica, peor, es imposible acertar. Dependencias entre tareas, varios programadores, vacaciones por el medio, un infierno.
Como dije en otro post anterior, estoy evaluando varias herramientas de planificación, pero me he dado cuenta que no son las herramientas lo que fallan (bueno salvo que algunas tienen carencias), sino la metodología. Estoy buscando algún método que me ayude a acertar más con los plazos, con los tiempos.
Ahora, en la empresa, hacemos lo siguiente:
1) Nos reunimos para ver que nuevas funcionalidades ha de tener el programa. En base a las incidencias recogidas de los clientes (bugs, problemas, etc.), en base a conversaciones con ellos, comparandonos a la competencia, detectando posibles mejoras, ideas nuevas, etc.
2) Decidimos cuales de ellas se han de implantar en la próxima versión, sabiendo que tenemos 6 meses (más o menos) de plazo, y teniendo en cuenta que utilizamos los 2 últimos para pruebas, empaquetado y distribución, disponemos de 4 meses de desarrollo.
3) Repartimos las funcionalidades entre los programadores, en base a varios criterios, cosas que ya han hecho, cosas relacionadas, etc.
4) Pedimos a los programadores que estimen el tiempo (yo soy uno de los programadores), y aqui es donde fallamos.
5) Metemos el tiempo estimado en una lista de tareas de Outlook para tenerlo en un sitio, hasta que encontremos la herramienta adecuada.
Respecto al punto 4, que es donde "estimamos tiempos", creo que fallamos en que no analizamos profundamente las funcionalidades, en que no detallamos lo suficiente cada tarea, que lo hacemos a ojo de buen cubero.
Como comenta Joel en su famoso artículo: Planificación indolora de proyectos, deberíamos dividir una tarea en pequeñas partes hasta que cada una de ellas fuera de una duración entre 1 y 16 horas, y para poder hacerlo hay que parase a analizar muy profundamente lo que vamos a hacer.
Hemos pensado que una forma de hacerlo es estandarizar los tiempos, me explico, al analizar profundamente una tarea, granularizar el trabajo hasta el nivel de decir que necesitamos una tabla nueva con X campos, un campo nuevo en tal tabla, un procedimiento almacenado que haga "noseque", un par de clases con estas propiedades y estos métodos. ¿Con ello que hacemos? Pues tendríamos una tabla con tiempos que dijera: Por cada tabla nueva Y horas, por cada campo modificado X, por cada procedimiento almacenado T si es sencillo, T2 si es medio, T4 si es complejo, etc.
Luego ir recogiendo los tiempos reales empleados en cada tarea y comparlarlos con los estandarizados y ver las desviaciones, y cada X tiempo (cada año por ejemplo) ir ajustando los tiempos estándar para que reflejen la realidad.
¿Que os parece? ¿Una chorrada? ¿Conoceis o utilizais algún método para estimar tiempos?
Para un programador esto se convierte en un suplicio, al menos para mi. Joel Spolsky dice que "sólo un programador puede estimar el tiempo que empleará en hacer una tarea", vale, pero hay tantos factores a tener en cuenta que estimar el tiempo se convierte en poco más que decir una cifra al azar... entre 5 y 15 horas... Está claro que mas o menos sabes cuanto te puede costar, pero ... SI TE DEDICARAS SOLO A ESO, si no tuvieras interrupciones, si el ordenador no se quedara colgado cuando menos lo espera, si no encuentras un bug en una librería que estás utilizando, si... si...
Si lo que estas haciendo es planificar todo un proyecto, la cosa se complica, peor, es imposible acertar. Dependencias entre tareas, varios programadores, vacaciones por el medio, un infierno.
Como dije en otro post anterior, estoy evaluando varias herramientas de planificación, pero me he dado cuenta que no son las herramientas lo que fallan (bueno salvo que algunas tienen carencias), sino la metodología. Estoy buscando algún método que me ayude a acertar más con los plazos, con los tiempos.
Ahora, en la empresa, hacemos lo siguiente:
1) Nos reunimos para ver que nuevas funcionalidades ha de tener el programa. En base a las incidencias recogidas de los clientes (bugs, problemas, etc.), en base a conversaciones con ellos, comparandonos a la competencia, detectando posibles mejoras, ideas nuevas, etc.
2) Decidimos cuales de ellas se han de implantar en la próxima versión, sabiendo que tenemos 6 meses (más o menos) de plazo, y teniendo en cuenta que utilizamos los 2 últimos para pruebas, empaquetado y distribución, disponemos de 4 meses de desarrollo.
3) Repartimos las funcionalidades entre los programadores, en base a varios criterios, cosas que ya han hecho, cosas relacionadas, etc.
4) Pedimos a los programadores que estimen el tiempo (yo soy uno de los programadores), y aqui es donde fallamos.
5) Metemos el tiempo estimado en una lista de tareas de Outlook para tenerlo en un sitio, hasta que encontremos la herramienta adecuada.
Respecto al punto 4, que es donde "estimamos tiempos", creo que fallamos en que no analizamos profundamente las funcionalidades, en que no detallamos lo suficiente cada tarea, que lo hacemos a ojo de buen cubero.
Como comenta Joel en su famoso artículo: Planificación indolora de proyectos, deberíamos dividir una tarea en pequeñas partes hasta que cada una de ellas fuera de una duración entre 1 y 16 horas, y para poder hacerlo hay que parase a analizar muy profundamente lo que vamos a hacer.
Hemos pensado que una forma de hacerlo es estandarizar los tiempos, me explico, al analizar profundamente una tarea, granularizar el trabajo hasta el nivel de decir que necesitamos una tabla nueva con X campos, un campo nuevo en tal tabla, un procedimiento almacenado que haga "noseque", un par de clases con estas propiedades y estos métodos. ¿Con ello que hacemos? Pues tendríamos una tabla con tiempos que dijera: Por cada tabla nueva Y horas, por cada campo modificado X, por cada procedimiento almacenado T si es sencillo, T2 si es medio, T4 si es complejo, etc.
Luego ir recogiendo los tiempos reales empleados en cada tarea y comparlarlos con los estandarizados y ver las desviaciones, y cada X tiempo (cada año por ejemplo) ir ajustando los tiempos estándar para que reflejen la realidad.
¿Que os parece? ¿Una chorrada? ¿Conoceis o utilizais algún método para estimar tiempos?
17 comentarios
José Luis Sánchez -
El programa que buscas existe, yo lo encontré ahce tiempo y era un reloj que ponias en marcha y parabas y computabas el tiempo que asignabas al proyecto. Además estaba hecho con Delphi y venía con código fuente. Lo malo es que ni se como se llama el programa ni donde lo dejé, si es que no lo borré.
Hay un libro sobre Proceso sofware personal en pearson educación. Yo no lo he leido pero lo estuve hojeando en una libreria y tenía buena pinta. El ISBN es 84-7829-052-4
Jose Alberto -
Un saludo.
Francisco Javier López Pellicer -
Gervasio Varela -
Cuidado. Cuando contratas a un cliente lo haces a precio cerrado a plazo cerrado. ¿Estarías dispuesto a descontarle en factura 10.000 porque has sido capaz de entregarle el producto 1 mes antes de lo previsto? El cliente estará contento si le entregas el producto en el plazo previsto siempre que no le de problemas. Si lo entregas 1 mes antes puede que haya 1 mes de fallos ocultos en el programa ;).
----
Totalmente cierto, se me fué la olla, me estaba refiriendo mas bien a un desarrollo in-house, y con lo de acabar antes no me refiria a apurar mas... sino a sobrestimar los tiempos para tener margen.
Le estoy echando un vistazo al gnotime, por que igual me viene bien para hacer un pequeño seguimiento del tiempo empleado en mi PFC.
Por cierto, creo que es bastante probable que gnotime se pueda hacer funcionar en windows, si está hecho un C medianamente estandar... debería funcionar.
Jose Alberto -
El problema de gnotime es que es para Linux, no es que Linux sea un problema por favor ;), sino que nosotros programamos para Windows, hacemos software "empaquetado"... y programamos bajo Windows.
Francisco Javier López Pellicer -
Os planteo el siguiente ejemplo: a lo largo de una jornada laboral de 8/9 horas. ¿Cuantas tareas relevantes se pueden realizar? Si el grado de exactitud que queremos es muy elevado (por ejemplo, control al minuto) y las tareas que se finalizan por una persona a lo largo del día son pocas (2 ó 3), ¿merece la pena la tener en cuenta el minuto?
Otro ejemplo relacionado con la planificación. Si las tareas que diariamente se finalizan por una persona son muchas (y por tanto los minutos son importantes), ello implica una extensa y detallada labor de planificación previa... que es propensa a muchos cambios. Debido a que no es una planificación estable por su nivel de detalle ¿qué se gana por haber bajado al minuto?
Salvo en procesos muy definidos y repetibles (transformaciones de datos, aplicación de plantillas, procesos de operador, o una empresa con un CMM2/ISO9000 exitoso y no burocrático) querer llegar a una precisión inferior a 1 hora en el registro de tiempo me parece un esfuerzo que no aporta valor añadido a la gestión del proyecto.
José Alberto: Respecto a la herramienta de 2 clicks. ¿Has probado gnotime?
Jose Alberto -
Por ese motivo, actualmente continuo buscando un sistema que permita registrar el tiempo dedicado a una tarea de forma semiautomática. En principio se trata de una aplicación que a un máximo de 2 clicks de distancia permita iniciar/parar el registro de tiempos, la he buscado, pero ninguna de las encontradas complia el requisito que he mencionado, además de trabajar el red local, por ello la estamos desarrollando.
Lucas Rodríguez Cervera -
El problema que tuvimos es que cuando la gente tiene que registrar horas con un nivel de detalle tan pequeño, hace falta muchísima disciplina, y la tendencia de la gente es a reportar las horas lo más rapidamente posible. Si no hay calidad en la colecta de horas, la información es de mala calidad y las estimaciones serán imprecisas, lo que es bastante peligroso (sobretodo si sirven como input para cotizar un proyecto).
Jose Alberto -
Pero como gerente o coordinador del proyecto, me interesa tener una estimación lo más aproximada posible de cuando tendremos terminado el trabajo, y no me sirve el coger el tiempo estimado inicialmente y multiplicarlo por tres, porque entonces cierro la empresa.
A mi me sirve para poder decidir que funcionalidades implementamos en cada "release" que lanzamos, es decir, para ver si con el tiempo "estándar" que tenemos para lanzar una release podemos hacer tal o cual cosa.
Francisco Javier López Pellicer -
Respecto a la estimación tiene que servir como mapa de carreteras interno. Desde mi punto de vista no importa si es exacta o no (+ exacta implica + coste burocrático). Lo que importa es que sea precisa (+ precisa implica + informativa). Por ejemplo, es una forma de transmitir objetivos claros. Si eres miembro de un equipo y participas en un proyecto complejo ¿cuál es tu trabajo? ¿cuál es el esfuerzo que se espera que hagas? Al menos con la estimación hay una referencia (que no un dato objetivo). Según evolucione el proyecto esa referencia debería de variar.
Acerbaturix -
Pero sin duda yo creo que el factor principal es la experiencia, el haber realizando antes muchos proyectos y de muchos tipos, por que aunque te bases en lineas de código, de alguna forma tienes que estimar cuantas lineas de codigo serán.
Además, en este sector yo creo que puede ser algo mucho más variable que en la construcción, ya que es habitual que en muchos proyectos se exploren/implanten algunas nuevas tecnologías con las que los desarrolladores pueden no estar del todo familiarizados, lo cual nos lleva a tiempos de aprendizaje, etc.
Hay muchísimos factores, y yo creo que la única forma de conseguir una estimación medianamente decente es mediante la experiencia y sobre todo tirando a lo alto, tanto en tiempo como en coste. El cliente se quedará mucho más contento si le entregas el producto un mes antes de lo previsto 10.000 menos de coste que si se lo entregas 15 días despues por intentar ajustar la estimación.
Francisco Javier López Pellicer -
Francisco Javier López Pellicer -
http://www.sei.cmu.edu
Son los responsables de esta metodología.
Quizás te merezca la pena ir a esta URL. Tiene un "curso" bastante completo en PSP
http://www.csm.ornl.gov/~v8q/Homepage/Class/PSP/Lectures/PSPLectures.htm
Jose Alberto -
Creo que enfocarlo hacia la dificultad "a priori" y según la experiencia es mejor, puesto que problemas complejos pueden requerir un análisis muy prolongado y luego pocas líneas de código.
Por cierto, Francisco, ¿me podrías pasar URLs de donde leer sobre dichas técnicas?
Francisco Javier López Pellicer -
Jose Alberto -
Está claro que no es igual hacer una página web que una aplicación de escritorio, y dentro de cada proyecto de página web no es igual uno que lleva flash de otro que no lo lleva, etcetera... Pero seguro que seríamos capaces de hacer unas tablas de tiempos estándar para poder acertar más en la estimación de tiempos.
Jaime Irurzun -