miércoles, 29 de marzo de 2017

System Thinking: Facilitación gráfica sistémica

Facilitación gráfica sistémica


En nuestro pensar conversan constantemente el zorro racional y el colibrí emocional. Y, tal vez, para compensar tanta planificación y frivolidad racional, el agilismo trajo el pensamiento y facilitación visual a la mesa de la ingeniería de software. Pienso que encontrar el equilibrio entre estos dos mundos es inmensamente fructífero en el desarrollo de software. Si nos quedamos entrampados en el pensamiento visual y sus herramientas, como post-its y colores nos podemos perder en el holismo y con él en el desorden. Y no salir de la baldosa de la racionalidad ingenieril nos puede hacer ciegos de la creatividad y cortos en la innovación. El arte es encontrar el camino del medio.


Bajo el marco de la agilidad se emplean las facilitaciones gráficas para traducir conceptos complejos y ayudar a razonar o analizar problemas complejos en un lenguaje visual de palabras e imágenes. Esta estrategia puede ser una manera muy eficaz de resumir y comunicar ideas, permitir a los participantes ver e interiorizar el panorama general de una discusión o presentación y facilitar el análisis de la realidad y de sistemas. Pero considero que las dinámicas divertidas y coloridas no debería reemplazar a la ingeniería ni los post-its reemplazar el modelado de sistemas.

Facilitar gráficamente no debería ser graficar por graficar. Cuando dibujamos, lo que hacemos es modelar. Hacemos una representación simplificada de un sistema en algún punto particular en el tiempo o el espacio destinado a promover la comprensión del sistema real (Bellinger 2004); por tal motivo, hay que tener en cuenta que modelar de una forma acertada, para comprender el sistema real, requiere usar herramientas apropiadas. Sino podríamos llegar a modelar ideas que no se condicen con la realidad, perder tiempo, llegar a problemas que no son causa raíz y/o llegar a soluciones que no lo son y que hasta pueden llegar a ser problemas futuros.

Diagramación y notación


La facilitación gráfica no nos sirve de nada en ingeniería de software (más que como entretención, embellecimiento o apoyo de una conversación) si no usamos “herramientas conceptuales de diagramado” con estándares de notación, “conceptos de sistemas” y herramientas 'ingenieriles'. No es necesario usar lenguaje técnico ni usar los diagramas en forma estricta, se pueden adornar y enriquecer gracias al uso de la creatividad. Pero, a mi criterio, no se debería perder de vista que debemos mantener cierta concordancia con la realidad y el profesionalismo que la disciplina requiere.

A continuación comparto un conjunto de “herramientas conceptuales de diagramado” que todo facilitador gráfico y sistémico podría emplear:


  1. ADL: es un lenguaje de descripción de arquitectura (Architecture Description Language) como lenguaje informático para crear una descripción de una arquitectura de software. Algunas ADL que se han desarrollado son: Acme (desarrollada por CMU), AADL (estandarizada por SAE), C2 (desarrollada por UCI), SBC-ADL (desarrollada por National Sun Yat-Sen University), Darwin (desarrollada por Imperial College Londres) y Wright (desarrollado por CMU).
  2. BD: El diagrama de bloques (Block Diagram) es la representación del funcionamiento interno de un sistema, que se hace mediante bloques y sus relaciones, y que, además, definen la organización de todo el proceso interno, sus entradas y sus salidas.
  3. BPMN: Business Process Modeling Notation. Modelo y Notación de Procesos de Negocio, es una notación gráfica estandarizada que permite el modelado de procesos de negocio, en un formato de flujo de trabajo (workflow). Se usan en análisis de negocio y análisis de procesos.
  4. CD: Conceptual Diagram, Concept Map or Concept Draw.
  5. CLD: Causal Loop Diagram. Un diagrama de bucle causal (CLD) es un diagrama causal que ayuda a visualizar cómo las diferentes variables en un sistema están causalmente interrelacionadas. El diagrama consta de un conjunto de palabras, flechas y signo de acusación (acusación directa o inversa). Se usan en dinámica de sistemas.
  6. ER: Entity Relationship Diagram con Entity Relational Model. Diagramar entidades y relaciones para modelar bases de datos en software o entidades en un dominio de datos (Big Data, etc.).
  7. EER: Enhanced entity–relationship model. Diagramar entidades y relaciones.
  8. ERD: Diagrama de entidades de bases de datos (Entity Relationship Diagram (ERD)).
  9. FBD: Functional Block Diagram.
  10. FC: Flow Charts (for control flow).
  11. DFD: Data Flow Diagram.
  12. DDD diagrams: Domain Driven Design.
  13. MMD: Map Mind Diagram.
  14. SBD: Signals Block Diagram.
  15. SC: Structure Chart.
  16. SFD: Stock and Flow Diagrams.
  17. SSADM: Structured Systems Analysis and Design Method.
  18. SIPOC: Supplier-Input-Process-Otputs-Customer. Sirve para modelar sistemas en una perspectiva de Proveedores (Suppliers), Entradas (Inputs), Procesos (Process), Salidas (Outputs) y Clientes (Customers). Usado en análisis de procesos y sistemas.
  19. UML: es un lenguaje de modelado (Unified Modeling Language) visual común y semántica y sintácticamente rico para la arquitectura, el diseño y la implementación de sistemas de software complejos, tanto en estructura (diagramas de componentes, estructura compuesta, implementación, de objetos, de paquetes) como en comportamiento (diagramas de actividades, comunicación, de secuencia, máquina de estado y de casos de uso). Puede servir para modelar algunos sistemas no software también.
  20. C4 Model (for Software Architecture): El modelo C4 es una técnica de notación gráfica ajustada para modelar la arquitectura de los sistemas de software donde se modelan: context, containers, components y el code. Se basa en una descomposición estructural de un sistema en contenedores y componentes y se basa en técnicas de modelado existentes, como el lenguaje de modelado unificado (UML) o los diagramas de relación de entidad (ERD) para la descomposición más detallada de los bloques de construcción arquitectónicos.
  21. VSM: Value Stream Mapping o mapeo de flujo de material  información. Usado en análisis de procesos y sistemas.
  22. ASME: Diagramas de procesos Norma ASME.
  23. Cursograma: diagrama de ingeniería industrial.
  24. IDEF0: Método de Modelado Funcional IDEF0, diseñado para modelar las decisiones, acciones y actividades de una organización o sistema. Se deriva del lenguaje de modelado gráfico establecido Structured Analysis and Design Technique (SADT) desarrollado por Douglas T.Ross y SofTech, Inc.
  25. Organizadores Gráficos:
    1. VENN: Diagrama de Venn.
    2. Organigrama.
    3. Telaraña.
    4. Mapas conceptuales libres.


¿Qué profesionales suelen necesitar diagramar?


En general la facilitación la puede hacer cualquier persona o profesional que necesita facilitar el entendimiento de un dominio de realidad o analizar sistemas, procesos, comportamientos y estructuras. Por eso son los Agile Coaches o trainers quienes suelen facilitar gráficamente.
Aunque, generalmente, son los Arquitectos de Software (Arquitectos de Soluciones, Arquitectos de Infraestructura y Arquitectos de Big Data), los Modeladores de Datos, los Analistas de Negocio, los Analista Funcionales, Analistas de Procesos y Analistas de Sistemas, quienes profesionalmente se ven en la necesidad de modelar y diagramar.
Espero que te haya servido este post para incursionar en alguna manera de diagramar y facilitar gráficamente lo que deses.


Referencias:



Publicado por en
Etiquetas: ,

No hay comentarios:

Publicar un comentario

Suscribirse a: Enviar comentarios (Atom)