Abe's Brain

jueves, enero 29, 2009

Metodologías

Hola de nuevo.

En la carrera nos enseñaban que los proyectos se dividían en varias fases. Puede que con otros nombres, puede que alguna no estuviera; pero más o menos tenían esta pinta: análisis, diseño, implementación y pruebas. Todo muy bonito e ideal, pero tras varios proyectos desarrollados en el mundo real sólo puedo decir que son todos una panda de mentirosos que trataban de engañarnos.

Los proyectos se dividen en fases sí, pero no tienen nada que ver con las arriba mencionadas. Aún tengo que perfilar los nombres y hacer un poco más de investigación antes de sacar lo que será mi primer libro y best-seller; ¿Metodologías? ¿Dónde te crees que estás, chico?, que explicará las fases desde el punto de vista del programador. En unos años, y si las ventas acompañan, saldrá una continuación desde del punto de vista de los analistas, ¿Metodologías? Ah, sí, hace muchos años me hablaron de una. Después me retiraré y me dedicaré a firmar libros.

Dichas fases son las siguientes.

- Primera fase. Comienzo.

El proyecto comienza. Nadie lo está programando. Nadie está haciendo análisis, documentación o nada que se le parezca. Pero el proyecto comienza. Lo que quiere decir que, aunque tú estés escuchando música y leyendo críticas de cine alguien está pagando por ti. Sí, suena genial en principio; pero el tiempo de desarrollo comienza a contar.

Un tiempo indeterminado después te llega un diseño técnico. No se puede ser muy exigente claro, llegas a un punto en el que te conformas con que no te llegue una servilleta vía fax... Puede ser un extenso documento con diseños de las pantallas o una página con una vaga explicación de lo que tiene que hacer la aplicación. Lo normal es, con lo que te llega, suspirar y tirar pa'lante.


- Segunda fase. Incertidumbre.

Tarde o temprano te encuentras con algo que no sabes qué significa, no entiendes cómo se hace (o por qué) o, simplemente, y esto es lo mejor, llegas a un “pendiente de confirmar/revisar/diseñar”. En el segundo libro dedicaré un apartado a la práctica de mencionar una palabra o concepto abstracto, a más de la mitad del documento, sin explicar qué es y usándolo como si lo hubieras usado previamente. Pero a lo que íbamos, tienes unas (normalmente muchas) dudas que necesitan resolución. Escribes un correo, lo mandas a quien proceda y esperas.

Y esperas. Y cuando te aburres de esperar puedes, en el mejor de los casos, seguir por otro sitio. En el peor, comienzas a improvisar con lo que tú crees que se debe hacer, ya sea por experiencia previa o porque has visto muchas películas.


- Tercera fase. Calma.

El cliente tiene acceso a una versión en desarrollo del programa. Pueden pasar dos cosas, que lo que ve no le guste o que se acuerde de un montón de cosas que no estaban en la servilleta. Hay que volver a reunirse para ver qué tiene que hacer la aplicación y rehacer los diseños, pero tranquilos porque no tienen ni la más mínima prisa.

Esta fase también se llama "el ojo del huracán" porque tú estás en medio sin hacer nada, en calma total, pensando que estás a salvo. Lo cierto es que mejor te tirarías al suelo y te harías una bola. O te esconderías de toda la mierda que te va a caer encima. Programar es tontería porque te lo van a cambiar: más música y blogs.


- Cuarta fase. Caos.

Alguien, que no es tú, recuerda que hay una fecha de entrega que hay que cumplir, y que ha permanecido inamovible a todos los simpáticos sucesos de fases anteriores (y así debe seguir por alguna oscura razón). El cliente decide lo que quiere, aparentemente, y a ti te llegan todos los cambios de golpe más unos cuantos añadidos de regalo, porque tú lo vales.

Te pegas un atracón para acabar a tiempo y, con suerte, lo consigues. Tranquilo, tranquilo, si no es con suerte, es con horas extra.


A continuación, como recompensa, puede haber una última fase en el que el cliente te manda, entre otras cosas, incidencias o bugs que se va encontrando. Las otras cosas que manda son cambios en los estilos (que por supuesto nadie te dijo cómo tenían que ser) y, sí, más desarrollos nuevos. Evidentemente a todo lo llama incidencias/bugs, para qué complicarse. Se han dado casos de incidencias en los que el cliente pregunta cómo sería el funcionamiento correcto.


Por último puedes tomarte un asqueroso café de máquina y robar un taquito de folios.

Etiquetas: , ,

7 Comments:

Blogger El Aprendiz

Muy cómico, a la par que gráfico y real.

Hubo una época en que creía que las grandes compañías tenían la autoridad necesaria para decir a sus clientes "No, tu lo que pediste fue esto, deja de dar la paliza."

Pero quizás les salga más rentable esclavizar seres humanos haciéndoles trabajar horas extra no reconocidas (ni monetariamente ni espiritualmente) en días que no deberían trabajar y hacer como que no ha pasado nada...

Yo he visto informes de incidencias sobre cosas que hacía otra empresa que nos mandaban a la nuestra.

30/1/09 07:41  
Blogger El Aprendiz

P.D: He soltado una lagrimilla al ver un post en el RSS...

30/1/09 07:41  
Blogger Miguel Herrero

Sí, se echan en falta :)

Y con este es fácil sentirse identificado.

30/1/09 08:56  
Blogger WaaghMan

Sólo puedo decir que el que dijo "El cliente siempre tiene la razón" merece arder en el infierno durante toda la eternidad.

31/1/09 11:53  
Blogger Rochgs

¿No hay fase de comunicación con otros departamentos?: Developers Are From Mars, SysAdims from Venus.

1/2/09 01:07  
Blogger María

Supongo que cuando deje de ser una "mantenida" yo también lo sufriré y no lo voy a llevar nada bien :P

Me alegro de que hayas actualizado :)

3/2/09 10:43  
Anonymous Anónimo

Llego muy tarde, lo sé xDD Me ha gustado el post, qué risas. En mi primer curro era un poco así, en este último no tanto ... pero las prisas siempre están presentes xD

14/3/09 15:02  

Publicar un comentario

<< Home