No en todas las ocasiones conocemos el negocio de nuestros clientes. Al menos no con el suficiente nivel como para poder traducir sus procesos internos en una aplicación o un servicio. Y es difícil “materializar” un diseño o una arquitectura que no se tiene en la cabeza. Algunos trucos mentales, y un poco de imaginación, nos pueden ayudar a llevar su lógica interna a un entorno más conocido.
Aplicación de gestión de Zoológicos
Debe ser algo complicado de gestionar: poca gente sabrá cómo funcionan. Pero no voy a hablar de esa dificultad… le voy a dar la vuelta:La seguridad alrededor de uno de los proyectos en los que participé hace un buen tiempo era tal, que no podíamos conocer qué eran realmente las “cosas” que gestionaba. Todas las entidades del negocio, los actores, los procesos, eran siglas de las que no tenía el significado real. Es muy difícil gestionar y codificar la abstracción de que un CZ envía un TR a un GSH, siempre que un OM de alto nivel lo valide. Es programar a ciegas.
Así que cambié el negocio del cliente a una gestión de Zoológicos.En mi cabeza, un Cuidador envía Comida a un Elefante, siempre que un Veterinario de alto nivel lo valide. Esto bajó a tierra los procedimientos internos de la aplicación, y el sistema empezó a tener algo de sentido. Es algo “peregrino”, pero funcional. Dotando de éste significado las reglas que gestionaban el sistema estaban mucho más claras: había contenedores de alimentos, de distintos tipos, que podían o no ser adecuados para las distintas especies. Todo el entorno estaba regido por una serie de cargos, director, jefe de mamíferos, del acuario, que validaban o no las distintas operaciones, y gestionaban el presupuesto del zoo.
En general la experiencia mejoró la comunicación. El cliente, que se lo tomó con humor, podía hablarme del negocio, sin miedo a contar más de lo que podía saber, y yo entendía de lo que que hablaba. El trabajo era bastante más fluido, porque los dos podíamos hablar el mismo lenguaje.
Y he de reconocer que también resulta más jovial y agradable trabajar de esta manera.
La imagen mental de la churrera
Cambiar un procedimiento o sistema a una imagen mental, de algo más conocido para nosotros, nos puede ayudar a trabar en su análisis e implementación.
- Una extracción de datos de ficheros se puede convertir en una churrera, en la que los ficheros entran po un extremo, van pasando por una serie de “cajas” que hacen procesos con sus datos, y terminan en un contenedor en base a su contenido.
- Un clúster de máquinas puede convertirse en una araña gigante, en la que cada pata realiza un trabajo orquestado desde la cabeza de la araña. Nidos de pequeñas arañitas se encargan del proceso de tareas, ordenadas por “mamá”.
- Una arquitectura de red puede convertirse en el cableado de una casa, la puerta a la calle es el firewall externo, y el perchero en la entrada es un honeypot que distraiga a los intrusos.
Un usuario final e incluso nosotros mismos, probablemente, entenderemos mejor que sus ficheros ya impresos van al “cajón de los descartados”, que al “repositorio histórico de ficheros”.
El refuerzo de la imagen mental
Por regla general, no trabajamos con datos reales de nuestros clientes, sino que generamos y gestionamos nuestro propio juego de datos de desarrollo y pruebas. Estos datos pueden traducirse en nombres y datos en nuestra aplicación, modelados para reforzar imagen mental.
Si estos datos están correctamente relacionados reforzarán esta ilusión, lo que nos ayudará a gestionar de una manera más táctil y cercana el sistema. Traduciendo datos abstractos, secuenciales, autogenerados, a algo más real, les dotamos de un significado, una semántica, que ayuda en la composición del trabajo real.
También pueden ayudar a detectar y minimizar los problemas en las aplicaciones, mejorando la calidad de las aplicaciones y servicios “sin coste” adicional:Si en una pantalla de nuestro desarrollo vemos que *USUARIO001 envía un mensaje a BUZON_56″, no nos llamará la atención: puede ser correcto o no. En cambio, si en una pantalla de nuestro desarrollo vemos que *CUIDIADOR_ACUARIO envía un mensaje a BUZON_REPTILES”, instantáneamente nos daremos cuenta de que hay un problema con nuestro proceso: ese usuario no debería estar autorizado a usar ese buzón.
Evitemos los nichos
A un médico, a un policía, se le presume una vocación. A un informático, se le presume el frikismo. En ambos casos, creo que debería ser hasta un requisito, no una ventaja competitiva. Sin salirme del tema, asumiendo este mindset, podemos estar tentados de llevar estas visualizaciones a nuestro hobby favorito. Cargando datos en el sistema en base a nuestro juego de ordenador preferido, o a los personajes de la serie Juego de Tronos, o de la saga Star Wars.
Conocí a un programador que llamaba a sus variables con nombres de emperadores romanos. Estaba estudiando historia. En su código había cosas como public Vector viriato = null;
No lo hagamos. Si la idea es que “materialicemos” un sistema abstracto, no deberíamos hacerlo de forma que sólo nosotros (o los fans de Star Wars) entendamos los datos. Más aún cuando trabajamos en un equipo. Usemos ideas generales, que todo el mundo pueda entender.
El nombre del viento
Abstraer los sistemas, y datos, a imágenes más familiares con nosotros, con nombres y conceptos conocidos, nos puede ayudar a realizar más eficiente y coherentemente nuestro trabajo de análisis y desarrollo, mejorar la comunicación y compresión del sistema, así como a reducir las incidencias.
Y… no menos importante… también hace el trabajo más ameno.
