Panqueque System

Ésta caracterización la escuché hoy en la oficina y me quedó dando vueltas en la cabeza. Hablando de los causales del no muy lento ocaso de cierto producto ERP, se mencionó el hecho de que el sistema "se panquequeaba cada dos por tres". Es decir que los requerimientos, el diseño o las funcionalidades incluidas cambiaban abruptamente ("se daban vuelta") en forma continua, de forma tal que se reescribían casi completamente.

Si bien el cambio y la evolución son elementos comunes y deseables en el desarrollo de un sistema, se supone también cierta racionalidad. Se agrega o quita funcionalidad a partir de un núcleo conceptual que se mantiene en el tiempo o que cambia muy gradualmente.

Persiguiendo la idea, se me presentaron dos orígenes para un Panqueque System, que probablemente puedan luego sub-clasificarse: problemas en las definiciones y dependencia del cliente.

Lo que tienen en común ambos orígenes, que es en definitiva lo que define al panqueque, es el lugar en donde se encuentra la indefinición. Para que un sistema de vueltas en el aire sobre el fuego, ésta debe estar ubicada en el punto de apoyo de todo sistema: la definición del negocio. No en un sentido funcional ("cómo se ordenan los elementos en la pantalla X"), sino aquélla que nos define tiempos, alcances y restricciones generales del proyecto ("hemos vendido un sistema de XXX, que abarca el circuito desde A hasta B. Debemos dar muestras de avance cada TTT meses...").

La definición de negocio es ante todo una apuesta estratégica, la adopción de un riesgo, la declaración de una visión de muy general alcance. Es el terreno de la intuición, de la política, del regateo y la conquista del cliente.

El origen "problemas en las definiciones" implica graves fallos en la definición del negocio: o no hay seguridad sobre a qué negocio apuntamos, o el negocio es demasiado innovador o no hay suficiente conocimiento en el equipo acerca de él, etcétera.

Es esperable que si el proyecto sobrevive a un fuerte bamboleo inicial las definiciones se vayan asentando con el correr del tiempo, a fuerza de prueba y error. Como reza el adagio, "en la marcha se acomodan los melones".

Desarrollar en un ambiente así requiere de muchísima habilidad, prolijidad, de una arquitectura extremadamente resistente a los cambios y un fuerte énfasis en el encapsulamiento y modularización de toda funcionalidad en el sistema, entre muchas otras cosas. Puede que se cumplan los requerimientos, pero que el código se vuelva completamente inmanejable en poco tiempo.

Así y todo, aún considerando el peor de los casos (necesidad de recodificación), no deja de ser un modelo de desarrollo viable. Si la idea resultante realmente tiene éxito, llegará un punto en el que justifique una recodificación que materialice la experiencia obtenida.

Peor es, como en el caso del ERP que inicia este comentario, cuando existe en el seno de la empresa una lucha entre dos visiones antagónicas del negocio. No hablamos ya de discusiones dentro del equipo de desarrollo, sino de aquéllas que se dan en un nivel superior, aquél en el que se define "negocio". Puede ser una lucha interna propia (por ejemplo entre dos consultores estrella de la empresa) o proveniente del propio cliente (por ejemplo entre los dos socios que conforman la empresa que nos contrata). Ya sea una pelea explícita o implícita, esperemos recibir palos ora de un lado, ora del otro.

El impacto dentro del equipo es la sensación de hacer y deshacer continuamente las mismas funcionalidades o de estar implementando en realidad dos sistemas completamente diferentes, separados apenas por un par de opciones de configuración. También es posible que se dé un alto nivel de esquizofrenia en el sentido de que lo que por un lado se nos requiere, por el otro sea fuertemente criticado.

Si lo pensamos detenidamente nada impide, en teoría, satisfacer ambas necesidades, reutilizando lo posible. Pero digo en teoría porque en la práctica es común que la lucha de poder entre las dos visiones genere requerimientos "de destrucción de la otra parte", que vistos a la distancia pueden hasta ser divertidos. Por ejemplo: "retirar completamente del sistema la funcionalidad XXX". Vaya un requerimiento, ¿dónde está el por qué, el relevamiento, el análisis? En estos casos las causas reales no pueden describirse fácilmente ni mucho menos escribirse. ¿Qué les parece un documento en el que se lea "esta visión del módulo de ventas es infantil e inútil y no resiste el más mínimo análisis de alguien con experiencia en el rubro"?

Y así el Panqueque System se va dorando vuelta y vuelta, un poco de un lado un poco del otro. Eventualmente estará bien cocinado (de ambos lados) o quemado de uno o ambos, lo que para el caso es lo mismo.

Resta para una segunda parte el segundo origen del Panqueque System: dependencia del cliente, que aparecerá en breve. ¿Tu proyecto es un panqueque?

Actualiazación: sigue en Panqueque System II: Un caso de dependencia del cliente.

Actualiazación II: ¡Obsesionado con los panqueques! Panqueque System III: El infierno de las preferencias.