Hablamos de desarrollo de software, y de cualquier cosa que venga a cuento de eso.
Un poco en joda, un poco en serio, depende el humor del día.

lunes, 16 de febrero de 2009

Frankenstein, el líder de proyecto (IX).

ATENCIÓN: ¡No sigas si no has leído la octava parte! Y si no has leído nada empieza por el principio.


[Resumen: El módulo de pago a proveedores es terminado justo a tiempo por la recién nacida criatura de Frankenstein y pasa a pruebas. El analista a cargo tiene un extraño intercambio de palabras con el no menos extraño programador a raíz de un pequeño error en la especificación que finalmente es aclarado, pero…]

El analista se sentía mal. El cansancio mental había dado lugar al físico. Las pruebas del módulo de pago a proveedores lo estaban matando.

Los problemas habían comenzado la semana anterior, con aquel primer incidente del campo “Nombre” especificado como fecha… “Tendría que haber dejado las cosas en claro en ese momento, ahora es tarde”, pensó.

El programador había exigido –de una forma no muy sutil- que se corrigieran las especificaciones y se le asignaran las tareas correspondientes y él había accedido. Fue un grave error.

Un día después de aquello se instalaba la versión revisada del módulo. Y el formulario “Alta de responsables de aprobación de pagos” había vuelto a explotar, no sin antes revelar un sinfín de errores menores en la pantalla (una falta de ortografía, un par de tipeo, algún que otro mensaje confuso, botones no alineados). Esta vez, el problema final era que al intentar vincular un usuario que ya estaba vinculado al sistema éste explotaba por un –qué más- error de clave primaria en la base de datos.

La segunda conversación con el programador había transitado más o menos por los mismos carriles del día anterior. “Jaime” -el analista no conocía el nombre del programador y a estas alturas no deseaba saber nada más de él, así que había elegido uno a voluntad. El nombre, que surgió casi de inmediato, hacía referencia a aquel autómata del “Superagente 86”- volvió a dejar en claro con su particular estilo que no haría nada por fuera de las especificaciones o que no le fuera asignado a través del sistema de tareas.

Y él había accedido. Fue un grave error. Una semana después, con más de 200 incidentes ingresados uno por uno al sistema de asignaciones, con la quinta revisión del módulo instalada, tenía que admitir que era poco y nada lo que había avanzado realmente. Fue a hablar con Frankenstein.

-Te quería hablar de Ja… del chico éste, del nuevo.

-Increíble, ¿no?

-Si, realmente. Mirá, ya corrigió más de 200 incidentes y…

-¡En una semana! Es fantástico, este chico.

-Pero…

-¿Pero?

-Esto no funciona. Yo sé que esto te va a sorprender, me siento estúpido por no haberlo sabido parar a tiempo…

-¿Qué? ¿Hay algún problema?

-Es raro, estrictamente hablando, no, no hay. En los papeles está todo bien, quiero decir. Pero el chico se limitó a implementar lo que decían las especificaciones a rajatabla, como si no las hubiese leído realmente. El problema es que cada error, cada incongruencia -por más grosera que fuese- terminó en el sistema.

-Bueno, por fin alguien que respeta las especificaciones. Es cuestión de corregirlas.

-Si, ahora es cuestión de corregirlas y corregir el código, otra no queda. Pero el chico tendría que haberlas detectado y avisado, ¿entendés? Eso es lo que me preocupa. Hay errores que son sutiles en un documento de varias páginas, pero que al programar se vuelven demasiado groseros, demasiado obvios. No es común que pasen de largo. Si no fuera por esas formas tan extrañas que tiene… pensaría que está actuando con malicia. Pero en realidad creo que simplemente no piensa. Es eso, el chico simplemente no piensa.

-¡No es ese su trabajo! Para eso tenemos analistas, ¿no? Habrá que ajustar el trabajo de análisis y la revisión de las especificaciones –a Frankenstein le brillaron los ojos… ¿por qué limitarse a crear sólo programadores?

-Víctor… por más que ajustes las especificaciones éstas nunca serán perfectas… si el programador no le pone aunque sea un poco de ganas…

-Eso ya lo hemos discutido y estamos en desacuerdo. De todas maneras no tiene sentido que nos internemos en esas cuestiones metafísicas ahora, veremos luego. Por lo pronto pasále las correcciones y listo.

-Ése es el problema. Son demasiadas. En su mayoría pequeñeces, un sinfín de pequeñeces que hay que detallar individualmente porque si no simplemente no las corrige. No doy abasto…

Pero Frankenstein estaba cegado.

-Mirá. Las especificaciones estuvieron a cargo del equipo de analistas. Y por lo que me decís durante la codificación se las respetó a rajatabla. Creo que es responsabilidad del equipo de analistas asegurarse de que esa falta de calidad no retrase el proyecto. ¿No te parece?

El analista se sentía mal. Estaba cansado, realmente cansado. Eran las nueve de la noche, ya no podía fijar la vista en el monitor. Decidió irse a casa. Al pasar frente al cubículo de “Jaime” soportó maquinalmente el ritual de despedida al programador:

-¿Te falta mucho?

-Sí.

-Ya no queda nadie. Apagá cuando te vayas –pero sabía que “Jaime” se quedaría toda la noche.

…continuará. Actualización: capítulo X.

Bookmark on Delicious Twit this votar Compartir en Facebook Suscríbete al feed Menéalo

2 comentarios:

navarros dijo...

Uhmmm... en la siguiente tormenta habrá que crear al SA (SuperAnalista). Que analice hasta el mínimo detalle, de forma concisa y concienzuda y en el mínimo tiempo, eso lo solucionará....o no?.
Quizás sea necesario también un SLP (SuperLiderdeProyecto), bueno no es problema, hay tormentas de sobra...ya esta,esto es lo definitivo...o no? y que ocurre con ese cliente quisquilloso con sus cambios, ajustes y sin saber lo que quiere......:)

AcP dijo...

¡¡¡Necesitamos un SC (SuperCliente)!!!