El hábito de SALirme del proyecto (2/3)

El proyecto SRM

En el año 2000, una empresa de servicios de televisión interactiva de pago por visión (pay per view), nos adjudicó un proyecto para que sus usuarios pudieran recargar tarjetas monedero a través de los descodificadores de los televisores. Nosotros teníamos que implementar la parte central de intercambio de mensajes con las entidades financieras. Denominamos a este proyecto “Servidor de Recarga Monedero (SRM)”.


Se trataba de un sistema de misión crítica (muchos usuarios, muchas transacciones económicas, alto coste por indisponibilidad de los sistemas). Se requería un nivel de servicio superior a 400 usuarios concurrentes y 30 recargas por segundo. 

Era un proyecto de mucho riesgo: El registro de riesgos tenía muchos riesgos por innovación, complejidad técnica, dependencia de terceros, gestión del cambio, etc. Yo me afanaba en gestionar todos estos riesgos, pero no vi el principal. Como dice Tom DeMarco: Tenía cuidado de no tropezar con los raíles, pero no vi “el tren que se acerca”. En mi caso, ese tren tenía que ver con los recursos humanos. 

Mi gran baza para este proyecto era Fernando, un excelente analista con el que yo ya había trabajado muy bien. No había trabajado con Eva, pero tenía buenas referencias como programadora. Paloma entraría después de sus vacaciones. Paloma no había programado en C++, aprendería durante el proyecto. Más tarde contrataríamos a otros dos programadores. 

Empezamos Fernando, Eva y yo con la gestión de los requisitos. Cuando llegó Paloma, se dedicó a formarse en C++. Fernando y yo nos turnamos para tomar vacaciones. A su vuelta, Fernando me dijo que se iba de la empresa. Cuando Eva volvió de las suyas, me dijo que también se iba.

Fernando se fue de la empresa en agosto, pero hasta octubre no podría sustituirle por Israel (otro excelente analista todoterreno). Como a mí no se me daba mal programar en C++, decidí ponerme. Ante mis jefes, yo ponía el grito en el cielo, claro, pero en el fondo, me gustaba. Paloma seguía estrictamente mis instrucciones. Lo mismo hicieron más tarde Pedro y Antonio (recién contratados). La siguiente figura muestra la evolución el organigrama durante los 6 meses del proyecto.

AN1=Fernando, AN2=Israel, PR1=Eva, PR2=Paloma, PR3=Pedro, PR4=Antonio

La complejidad técnica era formidable (y muy estimulante, a la vez):

• Cada transacción de recarga (el requisito eran 30 por segundo) tenía que intercambiar aproximadamente unos 20 mensajes entre distintos sistemas. Estos mensajes no eran inteligibles (estaban codificados).
• Era un sistema en tiempo real porque había lógica dependiente del tiempo (si se superaban timeouts, había que encaminar los mensajes de otra forma). Muchas veces, sólo descubríamos que nuestros prototipos fallaban después de dejarlos funcionar varias horas por la noche, cuando se saturaban los recursos del sistema operativo.
• Los otros sistemas con los que había que intercambiar mensajes no estaban disponibles (de hecho, los proyectos para desarrollarlos ni habían comenzado). Así que tuvimos que implementar simuladores.

Cuando llegó Israel, yo creía que habíamos superado la primera iteración de desarrollo (centrada en la arquitectura del sistema). Los grandes bloques del sistema ya funcionaban, y los programadores (por su propia iniciativa), ya comenzaban a especializarse: Paloma se especializó en mensajes, Antonio en el núcleo, Pedro en las comunicaciones. 

Sin embargo, Israel me hizo ver que el SRM no iba a cumplir los requisitos: Hizo pruebas de estrés y comprobó que era imposible superar 200 usuarios concurrentes y 10 recargas por segundo. 

¡Había que rediseñar el núcleo de arriba abajo!

Siguiente >
< Anterior