- Es una pregunta sobre herramientas y técnicas efectivas para transmitir a otras personas un modelo mental para entender un sistema o producto, y hacerlo crecer en conjunto
- Como forma de desarrollar un modelo mental, se menciona la experiencia de construir y mantener directamente un sistema
- Las formas de transmitirlo se acercan más a explicaciones informales, como garabatear en una servilleta, explicar con gestos al lado de alguien o desmenuzar el tema verbalmente mientras se piensa en conjunto
- Un documento que enumera funciones o cataloga de forma exhaustiva las áreas superficiales puede ser completo, pero quizá no baste para crear o transmitir el modelo mental del tema
- La experiencia de usar directamente una herramienta o producto bien diseñado puede ayudar al mismo tiempo al proceso de desarrollar y transmitir un modelo mental
Enfoque de la pregunta
- El punto central es qué herramientas o técnicas son efectivas para transmitir y hacer crecer modelos mentales
- La pregunta aborda dos direcciones a la vez
- Cómo desarrollar un modelo mental
- Cómo transmitir un modelo mental a otras personas
Ejemplos y planteo del problema
- Como ejemplo de desarrollo de un modelo mental, aparece el enfoque de construir y mantener un sistema
- Las formas de transmitir un modelo mental consisten en alinear la comprensión en el trabajo, por ejemplo:
- Garabatear en una servilleta
- Explicar con gestos al lado de alguien
- Explicar algo en una situación en la que se está pensando en conjunto
- Un documento que enumera funciones o cataloga el alcance superficial puede ser completo
- Sin embargo, ese tipo de documento quizá no llegue a crear o transmitir el modelo mental de ese tema
- La experiencia de usar directamente una herramienta o producto bien diseñado se trata como una forma de lograr tanto el crecimiento como la transmisión de modelos mentales
- La pregunta final pide conocer qué herramientas y técnicas le resultaron efectivas a cada persona, y por qué lo fueron
1 comentarios
Opiniones de Lobste.rs
Los ologs son un buen formalismo para transmitir una ontología
Si se trata de un proceso de larga ejecución con mucho estado interno, los diagramas de estado y statecharts son útiles para documentar el sistema
Los usuarios del sistema normalmente no perciben la estructura del sistema real. Una razón es que el espacio Nakatomi solo se vuelve visible para quienes hacen mal uso del sistema, y porque también existen regiones del espacio de estados para comportamientos no intencionados, como las weird machines
Otra razón es la perspectiva de que el propósito de un sistema es lo que hace: el usuario puede construir una razón de ser personal a partir de lo que el sistema hace por él, pero puede no notar el propósito global que pretendían sus diseñadores y mantenedores
Escribe un libro y contrata a un editor
Esto me parece cercano al problema central de la educación. He escuchado dos categorías: aprender haciendo y la guía de expertos; una tercera sería enseñar
La pregunta más importante es si se pueden crear modelos que se aprendan más fácilmente reutilizando principios y diseños similares, o si mediante abstracción se puede reducir la necesidad de aprenderlos por completo. Eso sí, debe estar bien definido por dónde se filtra la abstracción
En ese sentido, The Programmer's Brain de Felienne Hermans es interesante. Me llamó la atención que el enfoque de “voy a resolver varios ejemplos para que mires” que se usa para enseñar matemáticas a niños pequeños también funciona bastante bien en la enseñanza de programación
En un entorno laboral, para onboarding, sería algo como “mira cómo investigo este bug” o “mira cómo vuelvo a entender este subsistema que no toco desde hace tiempo”
En ingeniería de software ayuda dividir los modelos mentales entre historias de usuario e implementación técnica
Normalmente las historias de usuario son requisitos de primer orden, es decir, el valor que se busca lograr, y la implementación técnica son los elementos de segundo orden necesarios para alcanzar ese objetivo
Las historias de usuario explican el valor que se entrega al cliente, y la implementación técnica explica cómo las restricciones del sistema construido limitan esas historias de usuario
A veces ambas se superponen, de modo que la historia de usuario queda restringida por la implementación técnica o, al revés, se elige una implementación técnica para lograr la historia de usuario. Pero muchos comportamientos del sistema pueden enmarcarse en una de las dos
Luego solo queda elegir la herramienta que mejor encaje. UML sirve bien para dibujar mapas de objetos, los diagramas de flujo para explicar flujos. Los diagramas de estado sirven para explicar estados y transiciones permitidos o no permitidos, y las variables y tablas de estado sirven para enumerar todos los valores posibles
La mejor forma de aprender a dibujar un sistema es pedirles a tres personas distintas que hagan cada una su propio diagrama. Incluso una misma idea puede representarse de formas sorprendentemente diversas, y la mayoría son igual de válidas, pero revelan distintos aspectos del tema. Es parecido al arte
Principalmente uso diagramación más formal. Aun así, cuando toca garabatear en tiempo real durante una pantalla compartida, a veces abro jspaint, y si es algo que otra gente va a ver después, uso algo como Figjam
La razón por la que diagramar y señalar funcionan tan bien es que son de nuestras herramientas más antiguas, y siguen siendo útiles, para dirigir la atención. Antes de hablar, señalábamos y llorábamos, y para ubicación y navegación señalar es mucho más inmediato que el lenguaje; por eso sigue existiendo el mercado de los apuntadores láser
Peter Gårdenfors trata este tema con bastante detalle en The Geometry of Meaning: Semantics of Conceptual Spaces. Barbara Tversky también tiene mucha investigación sobre diagramación y estructuración cognitiva del espacio, y “What Constitutes an Effective Representation?” de Peter Cheng presenta criterios bastante cuantitativos para una representación eficaz
Shadowing, pairing y sesiones de pizarra funcionan bien. En esto, ambas partes deben dibujar y hacer preguntas
También ayudan cosas como elegir y ejecutar juntos un proyecto para expandir o modificar el modelo, quizzes, que el aprendiz vuelva a enseñar, memorizar y escribir a mano
La memorización pura siempre debe usarse junto con otros métodos; no debe convertirse en el único. También ayuda diagramar o garabatear fuera de la pizarra, hacer análisis de brechas comparando con otros modelos o soluciones, y ese tipo de reflexión contemplativa y medio inconsciente como el tiempo en la hamaca
Creo que hay que distinguir entre representaciones para transmitir y representaciones para realizar la tarea real. Esta última no se mencionó aquí, pero está más cerca de la “ejecución”
Los modelos ejecutables suelen transmitir mal, por lo general porque las fronteras de abstracción son malas. En computación casi siempre son abstracciones con fugas
Entender qué hace algo puede quedar oculto detrás de la montaña de esfuerzos acumulados para hacer que lo haga de manera eficiente. Por eso aparece la necesidad de garabatear en una servilleta y explicar: “a este nivel de abstracción, que encaja con tu modelo mental actual, este sistema funciona así”
La documentación es un entregable aparte, así que tiende a quedarse atrás respecto del modelo ejecutable, y para evitarlo hay que mantenerla con mucho cuidado. Una forma aún más difícil es acoplar la documentación directamente al código o, como en la programación literaria, poner la documentación por delante del código
Por eso, al transmitir modelos mentales, normalmente tiene sentido usar métodos que requieran el mínimo esfuerzo y mantenimiento: garabatos en servilletas y trabajar con el sistema real juntos con el paso del tiempo
Hay una razón por la que a los recién llegados se les empieza con bugs sencillos en vez de ponerlos a redactar documentos de diseño
Un recién llegado necesita aprender haciendo, así que un tutorial puede ser lo más apropiado. Pero después de meter mano un poco, es muy probable que ya lleve encima algunos malentendidos, y una explicación sobre garabatos en servilletas puede ayudar a deshacerlos
Así que, si decides escribir tutoriales, no intentes hacer el documento “de todo”; escribe un buen tutorial con un foco claro
La respuesta es escribir
El software es bastante interesante porque es un medio dinámico personal
Creo que los sistemas interactivos ayudan. Por ejemplo, algo como un depurador visual para enseñar Python y las variables representadas en cajas