KISS: Keep it small and simple.

Estas viñetas fueron vistas en La masa, el ladrillo, la bota, el bocadillo...

KISS: "Keep it small and simple", o en una versión más agresiva (y que me gusta más) "Keep it simple, stupid!".

Y sin embargo, las viñetas de la izquierda son la vida misma, por lo menos en los proyectos en los que he participado (la mayoría aplicaciones transaccionales).

Es que el principio es simple, pero hacerlo es lo más complicado del mundo.

La complejidad del negocio está ahí, es imposible hacerla desaparecer. Sería tonto pensar que la búsqueda en internet es tan simple como la interfaz de Google.

Lo que hacen Google y Apple y que en general no logramos hacer nosotros (y que tampoco logra hacer Microsoft, si es que lo intenta) no es hacer desaparecer mágicamente la complejidad del negocio, sino incorporarla al sistema sustrayéndola de la vista del usuario.

Así, cuanto más simple hacia fuera, más complicado por dentro.

Pensemos ahora en un sistema más transaccional, del tipo "Evaluación del desempeño" (algo en lo que tuve experiencia). En todos los productos que he visto (y en los que he desarrollado) básicamente el sistema brinda una serie de opciones para ingresar al personal, configurar relaciones evaluador-evaluado y armar formularios que luego administra, muestra resultados, informes, etc.

El clásico menú del sistema, por ejemplo, es una pregunta: "¿Qué es lo que ud. quiere hacer?" Si lo preguntamos es porque no lo sabemos (espero). Así, una mayor cantidad de posibilidades revela un mayor desconocimiento del deseo del usuario de parte del sistema y eso revela... un mayor desconocimiento del negocio por parte del proveedor del sistema.

Volvamos al otro extremo, donde todo es más claro: es obvio que Google ha plasmado en su sistema un conocimiento del negocio "búsqueda en internet" muchísimo más profundo que el que cualquier ser humano individual (usuario) pueda llegar a tener. Por eso no nos pregunta más que lo mínimo indispensable: un par de términos relacionados con aquello que queremos. En nuestro ejemplo del sistema de evaluación pareciera que ni siquiera sabemos para qué entró el usuario al sistema.

A la luz de lo que vengo escribiendo hay un error de concepto en eso: el sistema es el experto, no el usuario. El sistema debería saber cómo se hace una evaluación de desempeño, no limitarse sólo a administrarla. No debería preguntar quién es el evaluador y quién es el evaluado. De alguna manera, el sistema debería inferirlo a partir de los datos que sí maneja el usuario y formular las preguntas necesarias para armar la evaluación, en los términos que maneja el usuario.

Por ejemplo: "¿Qué quiere evaluar?" A partir de la respuesta del usuario el sistema debería determinar las preguntas y también qué puestos deben evaluarse quiénes deberían hacerlo. Así, si contesto "Habilidad de los vendedores" el sistema armaría un cuestionario con preguntas del tipo "¿Se expresa correctamente en forma verbal?", preguntarme quiénes son los vendedores y quiénes sus jefes, etc.

Ahora me doy cuenta de que yo, como desarrollador, no sabía si tal o cual método era el mejor para un caso determinado (y por tanto no pude plasmarlo en el sistema)... ¿Cómo resolvía la situación, entonces? Se lo preguntaba al usuario. El sistema se lava las manos, volviéndose una excelente herramienta para hacer mal lo que no debería haberse hecho.

Más complejo todavía, el sistema podría arrancar con "¿Cuál es el objetivo de desempeño que desea cumplir?" y el usuario responder "Aumento del 50% en las ventas". Luego el sistema podría proponer, entre otras acciones, una evaluación, cursos, etc.

La diferencia de concepto es abismal. Digamos que estoy cruzando la línea divisoria entre un sistema transaccional y un sistema experto. La diferencia entre la herramienta y el conocimiento del negocio.

Muchas veces se vende una cosa por otra, y esto termina en el desengaño del cliente, que creyó comprar una solución y termina con una herramienta que sirve para hacer (eficientemente) algo que él no sabe hacer... como si yo quisiera viajar a Francia y me vendiesen un jet (ojalá pudiese pagarlo)... más me valdría un pasaje de avión de tercera clase.

Hágan el experimento... miren alguna de esas pantallas del sistema que están desarrollando o utilizando y piensen:

• ¿Cuánto del negocio (que el sistema ya debería saber) se le está preguntando al usuario?
• ¿Cuánta terminología de la que aparece en pantalla tiene más que ver con el sistema ("Ingresar formulario") que con el negocio ("Evaluar")?
• Qué pasos podrían ahorrársele al usuario al incorporar al sistema qué es lo que hay que hacer de acuerdo al estado actual del mismo, en vez de que el usuario guíe al sistema a través de una serie interminable de menús y opciones.

Ésas preguntas son muy sugerentes, pero...

• ¿Cómo hago que analistas y programadores adquieran ese nivel de conocimiento del negocio para el que trabajan? Google lo tiene resuelto: viene de las universidades, del ámbito científico, la empresa contrata conocimiento y lo almacena en forma de algoritmos, como todo lo que toca.
• ¿Qué posibilidades necesito incorporar al sistema para plasmar ese conocimiento del negocio? Si le pregunto al usuario "¿Qué desea evaluar?" más me vale tener una respuesta (o caeríamos en el estilo Microsoft, cuyos ayudantes de resolución de problemas siempre terminan con "¿Esto ha resuelto la situación", "No", "Pues jódase Contacte con asistencia al usuario" y el ayudante se cierra).
• ¿Qué necesito hacer para acortar la brecha entre la interfaz del sistema y el usuario? El lenguaje natural (escrito, oral) es terriblemente complejo, pero aún sin llegar al extremo de que el usuario formule preguntas en su propio lenguaje creamos una gran complejidad. Pensemos en el salto cualitativo que representa pasar de varios ABM's de configuración a un "Wizard".

En definitiva, supongo que por eso existe Google, Apple... y el resto del mundo.