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?

Me resulta curioso la cantidad de veces que se compara el desarrollo de software con la industria automovilística. Coloquialmente comparamos la venta de un programa con la venta de un coche en cuanto a que la formación no se incluye con el vehículo, hay que pagarla aparte (Auto escuela). Comparamos el proceso de diseño de un coche con el de diseño de una aplicación, las pruebas de calidad que utiliza la industria del automóvil con las que utilizamos quienes hacemos programas. Pero nos equivocamos, como dice Alejandro Sanz, "no es lo mismo".

Además de las diferencias "palpables" y obvias, un automóvil no es como un programa. En un automóvil se gasta mucho dinero durante el proceso de diseño, se gasta dinero durante el lanzamiento y durante la producción física del mismo. En el desarrollo de un programa se gasta mucho dinero en el proceso de diseño, pero no en el de producción, al menos no con el software "empaquetado".

Durante el diseño de un vehículo los ingenieros se atienen a una serie de normas, tanto internas de la casa (estilo, tamaño, motores, etc.), como de las autoridades, en materia de seguridad, apariencia (dos faros, luces traseras, emisiones contaminantes, ruidos, etc.). Se hacen planos, se hacen cálculos, se montan maquetas, un prototipo, se hacen unidades de prueba que ser testan y se van corrigiendo, cada parte del vehículo se somete a una serie de pruebas de desgaste, de especificaciones funcionales (¿A que no sabías que la palanquita que sirve para abrir o cerrar las bocas de ventilación debe tener una resistencia indicada entre un mínimo y un máximo? Si está por debajo del mínimo puede vibrar, puede moverse "a su antojo" y si supera el máximo es difícil de manejar, requiere más atención, no lo puede hacer un niño. Algún día contaré porque se esto.), paralelamente mientras se terminan de pulir aspectos del vehículo, en las factorías se van preparando los procesos para la llegada del nuevo modelo, se van adquiriendo las herramientas necesarias, se reprograman los robots, muchas cosas. Finalmente un día, se empieza a producir el vehículo, se van cogiendo las piezas y se van montando, después de un periodo de tiempo, al final de la cadena de montaje, van apareciendo los vehículos montados y se llevan a los concesionarios para que los vendan.

Con un programa algo similar al inicio. Los analistas describen que es lo que ha de hacer el programa, pero... ¿Hay alguna autoridad que les indique que normas ha de cumplir el software, que indique un mínimo de calidad, de funcionalidad...? lo dejo en el aire. Luego se diseñan los objetos, las tablas, las pantallas, listados, informes, enlaces con bases de datos, protocolos, etc. (dependiendo del tipo de aplicación), luego los programadores hacen prototipos, empiezan a codificar el programa, se hacen pruebas, se verifica que todo funciona según lo previsto, se hacen las últimas modificaciones, y a producir, pero resulta que ésta producción es muy sencilla: grabar CDs y empaquetar, y si se distribuye por internet, ni se graba ni se empaqueta.

Es decir, que durante la fase inicial en los dos casos hay mucho recurso y mucho trabajo, pero luego en la fase de producción, en un caso continuan los gastos y en otro casi insignificantes.

Y no terminan ahi las diferencias...

continuará ...

No es habitual en este blog comentar estas cosas, pero me ha llamado mucho la atención que al intentar hacer una búsqueda en Google me salga esto.

¿A alguien más le ha ocurrido?

Si para una empresa "normal", que caigan sus servidores o servicios es una catástrofe, para una empresa como Google lo que hace es dañar su imagen, está claro que no de forma irremediable ni grave, pero si esta situación perdurara en el tiempo, seguro que si que pasaría a tener más repercusión, estoy convencido que incluso a nivel de medios de comunicación.