Un MODELO de pescado

La llamada que no puede faltar al medio día,  hola princesita ¿almorzaste?

• -          Del otro lado, no mama
• -          Por qué no si era pescadito a ti te gusta el pescado
• -          Eso no era pescado ...
• -          Si  señorita era pescado.  Pienso si filete de tilapia
• -          No, donde están los ojitos, donde están esas cosas con las que nada, donde está la colita. Ese no es un pescado  ¡Uds. son muy torpes al comprar un pescado!

Tiene toda la razón,  su modelo mental de pescado no correspondía a la imagen que veía en el plato:

 

Lo que esperaba mi hija

Lo que estaba en el plato

Conclusión: Decepción.

 Esto nos ha pasado en otras instancias de vida y profesionales.  El símil del requerimiento que ingreso a fábrica de desarrollo vs  el producto final construido.  La pregunta  regresa cuando inician los controles de cambio, en la escala de responsabilidad en fabrica  se inicia el juego de tingo tango haber a quien le queda en la mano -donde estuvo el punto de fallo-, para gestionar ese conocimiento para futuros desarrollos.

Siempre me he cuestionado como se ha  trabajado en la mejora tanto de la arquitectura de las aplicaciones y su refactorización, así como en la mejora de la cooperación entre el llamado negocio y los equipos de desarrollo.   En los RFC no faltaba la frase “aplicar las mejores prácticas”.  Es que en el documento estaba, si ve aquí dice: aplicar ¡las mejores prácticas! Entonces pasa la pelota y ¡tango! Y el negocio dice “Aquí el experto es Usted”. Y era claro si el responsable de abstraer los conceptos de negocio pensaba en el filete de pescado mientras el usuario le describía el pescado con ojos, colita y esas cosas con las que ¡nada!

Y ya que hablamos de mejores prácticas  y patrones (a propósito de la tarea de patrones de GRASP, bueno ese será un próximo blog, ah claro hay que falsear ese cero prometido en clase por no responder). Ahora pienso más las habilidades lingüísticas claves en el trabajo del desarrollador. 

Los patrones de conversación  para obtener un mejor conocimiento de los expertos de dominio, los tipo de preguntas que deberían prohibirse ahí la frase de - La calidad de la información obtenida indica la calidad de las preguntas formuladas -. Los patrones de conversación planteados como  una estrategia bien formulada que ayude a clarificar y entender las necesidades reales del interesado.  Preguntas de calidad, Navegación a través de una conversación, permanecer centrado en  hilo central de conversación, extracción de conocimiento a partir de la información que recopiló durante una conversación. En un curso de SCRUM ante la tarea de escribir historias de usuario vino esa parálisis mental de cómo sintetizar como escribir esa idea en un Post-it,  me acuerdo que nos entregaron de diferentes colores unos aun más pequeños que otros, pero eso no fue de mucha ayuda.

Haciendo la tarea anterior llegue a un párrafo que me pareció cierto pero que no asumimos a ratos en el día a día por  dar una respuesta se obvian la relación natural de los datos. La jerarquía DIKW (Datos, Información, Conocimiento, sabiduría), hace parte de una de las teorías del conocimiento que intenta estructurar y explicar cómo la información pasa por un proceso en el que empezamos teniendo datos aislados; y terminamos adquiriendo un cierto nivel de sabiduría partiendo de estos datos.

Entonces personalmente creo, que el reto en el camino hacia adquirir el nivel de sabiduría, esta en realizar gestión del conocimiento adquirido para aplicarlo de la mejor manera posible en el futuro, pero en no en el mundo difuso y tan ambiguo “con las mejores prácticas, ahí dice”, fundamentados en conocimiento histórico, en un método.

Por ahora a la plaza y a comprar: será mojarra, esa tiene ojitos colita y esa cosa con la que ¡nadan!