Puertas que se abren

Todo lo que un sistema hace debería estar justificado por un requerimiento del cliente. Lo que falte será un incumplimiento, y lo que sobre horas de trabajo perdido. Por lo menos así reza la teoría.

En muchos casos el equipo de desarrollo no tiene contacto directo con el cliente final, sino con un analista funcional, o un líder de proyecto que conoce el negocio, o alguien que cumple una función por el estilo. En este caso el cliente, desde el punto de vista del equipo, será esa persona.

Siguiendo con la teoría, el cliente presenta un requerimiento, el equipo lo evalúa, lo presupuesta en horas y el cliente decide. La negociación económica -cuando corresponde- debe enfocarse en el precio de la hora, no en la cantidad. Pensémoslo de esta manera: si quiero pintar mi casa, necesito tantos litros de pintura y puedo buscar el mejor precio, pero no comprar menos, y no tiene sentido discutir este punto. Pero el software no es pintar una casa, y hay sutilezas. Hay muchas, muchísimas variables internas del proveedor de software que hacen que uno tarde significativamente más o menos que otro en hacer prácticamente lo mismo. De todas maneras, el punto importante aquí es que es el equipo el que determina cuántas horas requiere para el proyecto. Sé de equipos en los que la parte funcional no entiende esto y es motivo de discusión. Porque -si han evaluado honestamente- no hay forma de que el requerimiento se cumpla en menos tiempo, así tengan una pistola en la cabeza. Tengo que reconocer que por suerte no he sufrido esto en carne propia.

Concentrémonos en el tema de las variables internas, pensando en un sistema informático que soporta un sistema administrativo (sistemas de venta, de facturación, de marketing, etc.). Más específicamente, en la interfaz con el usuario (IU). En este tipo de sistemas, la IU es por lejos el subsistema más complicado. ¿Por qué? Porque hace de interfaz entre dos lógicas completamente diferentes. Una cuestión es una interfaz entre dos sistemas, en donde las cosas están bien definidas en un momento dado, de mejor o peor manera. Con las personas -los usuarios- es imposible. Lo que una persona ve con claridad, a otra le parece incomprensible. Uno quiere trabajar así, otro quiere trabajar asá, y el área funcional quiere satisfacerlos a todos -con razón, ya que ellos son los que pagan-. Tratamos de promediar, de establecer métodos, estándares, pero el problema con los promedios es que no representan a nadie, y cada cliente viene con sus pequeñas variaciones. Si tenemos un sistema que vendemos a varios clientes, esas "pequeñas variaciones" acumuladas generan el clásico infierno de las pantallas de "opciones" o "configuración general" con miles de variantes, que son típicas en este tipo de software.

Así que es en la IU donde como desarrolladores tenemos que esforzarnos en buscar los puntos realmente importantes para concentrarnos en ellos. Es decir, aquel subconjunto de pantallas más utilizadas y poner todos los "chiches" ahí, y dejar el resto del sistema en la forma más simple posible que sea funcional al usuario.

Hay que tener en cuenta que, por suerte, es en la IU donde el proveedor tiene más poder de decisión. En general el cliente tomará la primera propuesta y pedirá modificaciones siguiendo la línea que se le presenta. Es raro que un usuario venga con un boceto de una pantalla, más bien tiene una idea de la funcionalidad que quiere agrupar en cada una, pero no más que eso. El resto lo tomará de lo que nosotros le presentemos.

La típica frase gira alrededor de "¿no se podría poner en la pantalla de facturación un ayudante como el que está en la de presupuesto?". Así que más vale que el "ayudante" que pusimos en la pantalla de presupuesto no haya sido el producto de un rato de ocio o el exceso de creatividad de algún programador, porque ahora se ha convertido en un estándar para el usuario, que probablemente termine queriéndolo en todos lados.

Y ahora viene el párrafo donde aparece el título: "No abras esa puerta" (la frase no es mía, si el autor quiere crédito no tiene más que mandarme un mail, él sabe quién es). Es decir, ojo con ofrecer espontáneamente funcionalidad en la UI que luego nos cueste mantener o replicar, o que genere demasiada complejidad, o que incluso se aparte demasiado del estilo del resto del sistema.

Un ejemplo. Empecé a jugar con la técnica que mucho después terminaría siendo "Ajax" en una pantalla bastante simple de ingreso de CV a una base de datos. Lo típico en ese momento era una tablita al estilo:

Título	Establecimiento	Año de ingreso	Año de egreso

(bueno, con más estilo, pero la idea se entiende)

Así que hice una grilla que editaba por "Ajax" (no tenía ninguna utilidad que lo hiciera, era puro javascript a mano) un objeto guardado en sesión, del lado del servidor. Transformé la tabla en un ABM clásico, con ventanas pop-up que editaban los datos de cada fila. Claro, estaba jugando, experimentando. No había encapsulado nada, y no era nada prolijo por adentro. Incluso habían graves cuestiones no resueltas (recuerdo por ejemplo que las llamadas al servidor eran asincrónicas, sólo porque no sabía que se podía hacer sincrónico).

Había varias listas parecidas en la pantalla: "Idiomas", "Experiencia"... y claro, no se podía hacer unas de una manera y otras de otra. Copié y pegué hasta reproducirlo en todas las listas. ¿En qué terminó todo esto? En una pantalla lenta, pesada y tosca, con problemas de redibujado en el Internet Explorer, que ni siquiera se mostraba decentemente en otros navegadores y que cumplía la misma funcionalidad que la anterior, pero que obligaba al usuario a utilizar intensivamente el mouse... un asco. Y yo tratando de explicar que no, que había sido un experimento, que ahora ya está en esa pantalla pero que no tiene por qué extenderse a todas las demás, que eso del redibujado era grave, que no tengo tiempo para hacer todo prolijo de vuelta, que emprolijarlo a partir de lo que está es casi imposible, etc., etc... es decir, terminé tratando desesperadamente de cerrar esa maldita puerta.

Años después, trabajando en base a un framework en javascript estilo Ajax, con ventanas, llamadas sincrónicas al servidor, y un montón de temas ya resueltos y con el Internet Explorer 7, la cuestión se volvió moneda corriente. Por supuesto gran parte del framework fue desarrollado y mejorado prolijamente a lo largo de **mucho tiempo** por el que ahora es algo así como el "Team Leader" en donde trabajo (repito lo de los créditos).

Resumen. Las puertas pueden y deben abrirse... a su debido tiempo, o nunca.