jueves, 25 de septiembre de 2008

Panqueque System II: Un caso de dependencia del cliente.

En Panqueque System hacía referencia a esos sistemas en los que el rumbo cambia 180º de vez en cuando, en una forma tal que por más ágil que uno quiera ser, termina embrollando el desarrollo.

Se me habían ocurrido dos causales: problemas en las definiciones y dependencia del cliente. Había empezado por desarrollar un poco el primero. Vamos al segundo.

Trabajé casi siempre en empresas chicas, a lo sumo medianas. Así que conozco de primera mano la importancia de el cliente, sobre todo cuando se lo puede nombrar en singular y ya se sabe de quién estamos hablando.

En el caso que tengo en mente, la aparición de un comensal importante, de buen apetito y bolsillo aparentemente generoso motivó la aceleración del cierre de un producto de evaluación de desempeño que si bien teníamos prácticamente terminado todavía no había sido utilizado en una evaluación real.

La idea original era atraerlo con un buen precio por evaluación más algún sablazo por customizaciones que, bien implementadas, serían nuevos sabores a ofrecer en nuestra recién abierta panquequería, que tenía forma de aplicación web.

Creo que el modelo de negocio, tan natural en estos tiempos que corren, era demasiado innovador para el momento del rubro (no es autobombo, yo sólo picaba código), y el cliente demasiado grande.

Esos dos factores se juntaron para que se negociaran cambios de tal magnitud y especificidad que en la práctica hicieron imposible su aplicación como opciones a ofrecer al público en general.

De un lado del escritorio no existía la mentalidad de utilizar una aplicación web como un "servicio enlatado", por lo que se terminó pidiendo cualquier cosa.

Del otro lado la dependencia económica era tal que se terminó concediendo cualquier cosa, y el desarrollo tuvo que abrirse en dos versiones divergentes, una dedicada exclusivamente a éste cliente y otra estándar que permanecía en vidriera.

Así, se vendió el desarrollo de un programa a medida al precio de un par de customizaciones. Y como era una aplicación web, el cliente comió una vez, dos tal vez, y satisfecho su apetito continuó por su camino libre de ataduras, sin nunca más volver.

Creo -ya aclaré que estoy alejado del rubro- que no se logró posicionar la versión estándar como un servicio web a utilizar "como está" y que actualmente se encuentra más o menos abandonada.

Esta anécdota ejemplifica bien la situación en la que el panqueque gira y gira en el aire hasta romperse en dos mitades. En este caso un comensal un poco grosero picoteó apenas de una de ellas, encima pagando sólo el proporcional, y el cocinero se quedó con las sobras. Sobras que pueden servir de tener a quién ofrecérselas a tiempo, pero no fue éste el caso, me parece.

Mi opinión es que la clave está en la metodología. Si el proyecto crea una base de componentes o una capa de negocio reutilizable que soporte los cambios de tecnología, conformarán en realidad no una pérdida en horas de trabajo sino una inversión.

Ésa salida sólo puede darse si es apoyada conscientemente por el entorno de negocio del desarrollo. Si se presiona a los programadores a cumplir con los requerimientos en tiempos extremadamente ajustados (en este caso, forzando un nuevo desarrollo en tiempos de "customización"), el código resultante tendrá una calidad acorde, y no será para nada reutilizable.

¿Es compatible la entrega en esos tiempos con calidad y posibilidad de reutilización? Las metodologías ágiles nos han enseñado que es posible entregar rápido y refactorizar después. Podemos hacer una implementación desprolija (aunque correcta para el usuario, eso es indispensable) si luego tenemos tiempo de capitalizar la experiencia reorganizando y reescribiendo el código donde sea necesario. Pero muchas veces gana la idea cortoplacista de producto terminado y a otra cosa... una panquequeada más que termina con lo poco que quedaba en el suelo. Otra variación conocida de esa frase es esperemos a que surja un nuevo negocio... por supuesto, y a que los tiempos se ajusten nuevamente.

Queda para otro post una situación más, el infierno de las preferencias. Es el caso en el que para cada nuevo cliente creamos un nuevo gusto y terminamos estancados en el mencionado infierno con más sabores que comensales. Pero como dije, será para otro día.

Actualización: Ya llegó el día: Panqueque System III: El infierno de las preferencias.

1 comentario:

Anónimo dijo...

Muy "evocador" el artículo, si, muchos hemos pasado por esto. Mi experiencia es parecida, en mi caso logramos un nivel de reuso del producto más que decente. Digo del producto y no del código porque por dentro es otro cantar. En vez de quedarse en la vidriera se ha estado desplegando varias veces al año pero con un nivel de "sufrimiento" y "sorpresas" que es todo un purgatorio. ¿Qué falló? Pues como dices, a falta de hacerlo bien a la primero, el haber "refactorizado" la herramienta después.

No obstante, en mi opinión, para esto también hace falta un perfil alto en el equipo, no todos los miembros del equipo "saben" hacer el código bien. Se me enfadarán pero es así.